So you set up your Ultimate3/3S kit as well as you can for sending WSPR, and you have a nice QRP Labs QLG1 GPS receiver kit calibrating the frequency, correcting drift, setting the locator and maintaining realtime clock accuracy. But you have done some experiments with your remote friend, and he sees non-zero DT. Or, you are a receiving station and you see non-zero DT on your WSPR program for stations which you think are using the Ultimate3/3S. How can they have a non-zero DT if everything is supposed to be GPS controlled?

This is an investigation to determine whether there is any bug in the Ultimate3/3S code which makes the timing incorrect; or whether the DT arises elsewhere. What is DT? It is a parameter reported by the WSPR software for each decoded transmission, which is supposed to indicate "Delta-Time" (DT), meaning how far off the ideal timing the station is.

A reminder that according the protocol specification, WSPR transmissions ideally start on the 2nd second of even minutes. The WSPR transmission consists of 162 symbols, each has a duration of 256/375 seconds.


In case you don't have time to read all of the following, here's my conclusion first. The U3S with firmware v3.09c was tested. The timing is very close to perfect. The WSPR transmission starts 67ms late, and the overall message has a duration 25ms shorter than it should be. Considering the duration of a WSPR tone is 683ms, both these "errors" are a small fraction of a single WSPR tone. There is NO error which could explain any DT report in WSPR, except perhaps 0.1s since the resolution in WSPR is limited to 0.1 seconds. Any DT must arise elsewhere.

Update 21-Sep-2016

I found this interesting thread, a discussion with Joe K1JT and Steve K9AN. Apparently there is an offset of 1 second already mistakenly built into the decoder program. See

Experimental method

I set my U3S up with frequency 10.002000MHz, Frame = 2 (i.e. transmitting every WSPR frame), with GPS connected, the QRP Labs QLG1. The output of the U3S is beat with my 10MHz OCXO frequency reference using a simple 2-diode mixer which is described here. The audio output is fed via an audio USB input device to my old Win XP laptop. That produces the audio tone in the laptop, at about 2kHz.

Additionally I feed the 1 pulse per second (pps) signal from the GPS, superimposed on top of the audio. It creates spikes on the audio, at the start and finish of the 1pps (which has 0.1 seconds duration). This makes it easy to make extremely precise timing measurements. Please see here for a photo and circuit diagram of this mixer.

Audio program Audacity is used to record the audio, and use the cursors and zoom facilities to make accurate timing measurements. The duration of the 100ms signal from the GPS is 0.1 seconds. The start of the second is the rising edge of the 1pps signal and is supposedly accurate to less than 10ns. On audacity the rising edge of the 1pps signal looks like a very brief negative spike, and the falling edge 0.1 seconds later looks like a very brief positive spike.

This experimental method is extremely pure, because it does not matter if any delays or latency are imposed by the PC measurement audio analysis etc. It literally takes the extremely precise 1pps from the GPS, and overlays it on top of the RF output from the U3S.

I also visually compared the clock at with the clock on the LCD of the U3S, during the few seconds before the U3S transmission starts. The clocks match exactly! This eliminates any possibility of a 1 second offset in the U3S. In fact the 1pps from the GPS (as interpreted by the U3S) is visibly slightly ahead of the moving second hand of the clock on the PC screen, I'd say under 0.1 seconds, just a very slight offset. This is presumably processing time over the network and in the PC etc.


I took the resulting Audacity file and cut off the start and end as accurately as possible, to show a complete 2 minute cycle, see image below. Then I could zoom in using Audacity and make various measurements. The three pictures below show the whole transmission, and a zoom on the start and end of the transmission. To make the measurements I kept zooming in until I could see the individual ADC samples of the audio, which led to a very accurate measurement. 

The one second 1pps leading edge occurs in the audacity file at 0.99569 seconds. This small offset relative to 1.00000 which it should be, is due to my error in trimming the start of the file.

Remember that by the WSPR specification, the transmission starts on the 2nd second of even minutes. The start of the WSPR RF envelope, the first tone, occurs at 1.06295 seconds into the file. Allowing for the file trimming error, this means that the WSPR transmission starts 67.27ms later than it should do.

This 67.27ms delay in starting the RF envelope is the time required for the U3S code to:

  1. Detect and respond to the 1pps signal arrival
  2. Encode the Callsign, Locator and Power into sequence of WSPR symbols to be transmitted
  3. Set up the timing for the WSPR tones
  4. Calculate Si5351A registers and communicate them over I2C to the Si5351A
  5. The Si5351A's delay to get the PLL locked on frequency etc

Now the complete WSPR transmission is supposed to take 162 * 256/375 seconds = 110.592 seconds. In the file, it should therefore finish at 110.592 seconds + 1.06295 in the file = 111.65495. In other words, 1 minute 51.65495 seconds.

The actual finish time is 1:51.63028. The WSPR transmission is therefore 24.67ms shorter than it should be, an error of 0.02%. This error is explained my the resolution of the timing loop in the U3S, and time consumed by other tasks being performed in the U3S.

So the U3S starts its WSPR transmission 67ms too late, and it completes 25ms faster than it should. Both errors are very small! In other words, the U3S is as close to perfect, as makes no difference. It is very closely conforming with the WSPR protocol specification. Any reported DT cannot arise at the transmit side.

Possible explanations for the DT may be one or more of the following:

  • Use of an older firmware version, in which there may have existed possible timing errors. There were improvements made in v3.09 (release 21-Oct-2015) for the timing of the CW dits which was previously slightly off at higher speeds. Even so, those timing errors were smaller than one CW "dit" at 12wpm - which means less than 0.1 seconds error. So it seems it could not account for the DT seen on WSPR reports.
  • Delays arising due to propagation effects. Somehow the WSPR program is calculating DT based on some kind of averaging of the WSPR signal. Propagation could cause fading or doppler etc etc which could alter this calculation.
  • Delays arising elsewhere in the receive chain. These could include:
    • Hardware/OS delay, getting the audio at the PC input, into the analysis program i.e. WSPR
    • DSP delay - any receiver doing DSP adds delay to the audio signal, necessarily.
    • SDR delay - similarly if people are using SDR for the receiver, then again there will be delays incurred in the processing of the data and conversion to final audio
    • Inaccuracy in PC clocks, which are synchronised to internet time protocol servers or something, but presumably delays or inaccuracies could be occurring due to internet network latency, delays in the PC OS, etc etc.
    • I don't know what logic the WSPR software uses to calculate DT. Maybe it makes some kind of adjustment to try to account for processing times.

I believe my measurement method described above has eliminated ALL of the above delays, and is accurately measuring ONLY the nature of the transmission timing of the U3S itself, in direct comparison with the extremely accurate 1pps signal from the GPS receiver. As a result of this investigation, I am satisfied that the timing of the WSPR transmission in the U3 is very accurate. 

JT65 Timing experiment

Next I repeated the same experiment, with the same method, on a JT65 transmission from a development version of the U3S firmware.

I trimmed the audio file so that it started at exactly 0:00.00000 (yes 5 decimal places of seconds precision). Then I could zoom in and measure the start and end of the RF envelope. Start: 0:01.04549 and end: 0:47.84506. The JT65 protocol specification requires JT65 to start on the 2nd second of the minute, similar to WSPR. The tone duration in JT65 is 4096/11025 seconds, and there are 126 tones.

Using this information I can determine that the start of the JT65 transmission is 45ms late (DT = +0.045s), and it is 12ms shorter than it should be (an error of 0.025%). The 45ms delay at the start is the time it takes the U3S to recognise and respond to the 1pps, calculate and set up the Si5351A registers, encode the JT65 message, etc.

The conclusion here is similar to the WSPR situation: far as I can see, this transmission is extremely close to perfect. The actual DT in the transmission is 0.0s when expressed to 1 decimal place. If anything else is reported, it can only arise due to other factors in the propagation and receiver path. E.g. propagation, network delays settiing the time on the PC, delays in DSP in the receiver, delays in the decoding software, or the method used for measuring DT in the WSJT software.