In WSJT-X FT8, the WSJT-X clock and the computer clock correspond exactly, and correctly, to the WWV signal at 10 MHz. The computer uses Meinberg for timing. However, the Flex 6500 clock (next to the TX symbol at the bottom of the Flex screen is ~ 0.3 – 0.5 seconds delayed (easily noted by simultaneously listening to the WWV pulses). Also, even though the WSJT-X and computer clocks are correct, most of the FT8 signals in the Band Activity window are reported as DT = 0.3 – 0.5 seconds, apparently matching the Flex clock. I can’t believe that my time is correct and everyone else is off. Using latest versions of Windows 10, SDR v. 2.4.9, and WSJT-X. Why is the DT not ~ 0.0 and matching the WSJT-X clock? What is going on? What have I missed?
Thanks for any advice.
The clock in the SSDR display is almost certainly generated by SSDR on the PC, and has little or nothing to do with clocks in the radio. The SSDR clock is calibrated in UTC, and is probably produced by a low priority process in the SSDR code. It could be slightly behind, but serviceable enough.
Comparing any clock to WWV audio ticks isn't going to be very accurate. Propagation delays from Ft. Collins to your location and processing delays in the radio will make the tick a little late all of the time.
If all of the FT8 transmitters you can hear were synchronized to a millisecond, you would still see a range of delta times since their signals travel different distances, are subject to differing amounts of processing delay at the source, etc.
I have no idea how close the Meinberg NTP implementation comes to the "correct time". It's forte is that it works on keeping the system clock's delta T within some range more or less constantly, correcting for drift in the local hardware clock. I think that's all it is trying to do. I've never looked into what configurations, if any, may be available for tightening the delta.
You can get the freeware here: https://www.speed-soft.de/software/time_sync/index.php?language=en
Alex - DH2ID
If you prefer really accurate time via internet but no GPS, get NTP tool and it will tell you how fast time servers respond, trip delay and so on. Pick the one closest to you with the least delay. There are many free ones around. This is NOT used to set the time but rather help you determine what is the best server to use for doing so in your other application which actually sets it.
Hope this helps!
And for all, including DH2ID, if your time client is not running with elevated administrative privileges it isn't working.
Beginning with Windows 7, setting the system clock has required admin privileges. This was required by a known exploit that involves a malevolent program altering system time.
If a time client is running without admin privileges then its settings are being ignored without generating any notice to the user, leaving your computer system clock to twist in the wind. Some time client software includes a clock display that may be corrected but if the computer system clock is uncorrected WSJT-X will not benefit.
While Windows does have a built-in time sync it doesn't, apparently, run that often. The i7/Windows 10 laptop I am on right now has been measured as much as 1.6 seconds off compared to a local cesium clock synchronized with USNO. Just now it is running 0.6 seconds fast. Last sync was about 15 hours ago.
There is probably a different (smaller?) delay on the transmit side.
If we were very fussy, we might ask the WSJT crew to measure and/or allow for radio-specific processing delays. But I really don't think it matters for normal ham work.