Flex6500 and WSJT-X timing

Michael Reid

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.

Mike, K6DRY

NX6D Dave

For what it's worth, Delta Times on the order of a few tenths of a second, both plus and minus are par for the FT8 course.  They are close enough for encoding and decoding to take place.

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.

Sergey R5AU

Hi Mike, i did many FT8 QSO's and using for Synh purpose NetTime apps 



however Dave right and Radio itself has no relation to the clock synh topic and nevetheless , many QSO's i did with start transmission with delay in 2-3 sec. !

DH2ID

There are a lot of NTP programs around, but I like Time-Sync best, because I don't have to have admin rights to run it and it's uncomplicated and stable. You can easily change the update interval in the ini file. I've set it to 300, as time synchronizing every 5 minutes is perfect for me.
You can get the freeware here: https://www.speed-soft.de/software/time_sync/index.php?language=en
Alex - DH2ID

Bob G W1GLV

I have a GPSDO mounted in my 6500 and the DT times for WSJT-X are in the order of .2 to .3 seconds all the time. I have plenty of decodes to deal with. Have fun, this is amateur radio.

Lucas - W6AER

I use BktTimeSync by IZ2BKT, works very well and even supports GPS if you have one attached. http://www.maniaradio.it/en/ I have also used other products and even one paid product and this was seems very good and works on windows 10 even with the latest updates. There are many good ones, including ones already suggested above. There are also some not so good ones, so use caution.

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!

John - AI4FR

Yes, the time is off. I have a 6700 with the GPSDO. The difference is easily noticed while listening to WWV on a legacy radio and the 6700 at the same time. The 6700 is always behind, usually by .3 or .4 seconds. The same will hold true on other modes as well, such as when that DX station on phone says "QRZ". Others will be calling them when you are hearing the RZ in QRZ. You will be about a half of a second behind the crowd. Does this hurt you in FT8. Not at all that I have noticed with 15k FT8 Q's in the log. Being an SDR, it takes that tiny fraction of a second to process the signal and send it to your speakers. Would I give up the SDR in favor of a legacy radio? Never, there is no going back. The Flex has spoiled me.

Bob K8RC

I know of no situation where the SSDR clock, as displayed, has any input on timing questions. AFAIK, it's just displaying computer time. I would enjoy knowing if it has a function other than "eye candy".

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.

73,
Bob, K8RC

bahillen

Windows time is bad news for this timing. I use Dimension 4 and has been fine for several years. It up dates every 2 minutes and you can see the minor corrections. Don’t forget there is delay between the standard location and your station. 73 Bill W9JJB

N6OIL

You know John, all this time I thought it was just me. When working pileups I would unkey and already hear stations calling, I didn't think the radio introduced any delays. Is this normal with all SDR's?

Martin AA6E

Your NTP client (Meinburg or other sync software) is trying to adjust your computer's clock to true UTC, and that usually works with some msec accuracy IMO.  The "problem" is that the signal you hear at the radio's output is delayed by 100s of msec because that's how SDR radios work.  The signal is delayed by every stage of processing (eg, filtering).   It's worse with the IF filter response set to "sharp" (requiring more processing).  You might change to "broad" and see some improvement.

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.