locked Re: Clock Sync #Timesync


Thanks Jim.  As I suspected, there was much I didn’t understand.  One good point is that the new USB3 cable is much better quality than the old one.


As part of my military service I was a calibration team chief.  Our time/frequency reference was via a VLF time signal supplied by NBS and broadcast courtesy of the Navy.  That was 1975 time frame.  How far have we come.


I will remove the older GPS puck.  It has been concerning me anyway. 


I am in the middle of a rebuilding a Raspberry Pi 2 and I have the Adafruit GPS hat.  If I can get that working, I will discontinue using the pucks.  Prices do change and the Adafruit hat ran $62 with shipping, but it will be an interesting project.  Thankfully there is an abundance of help from those who have already accomplished this project to guide me.



Dan – K4SHQ



From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Jim Pennino via groups.io
Sent: Monday, July 19, 2021 10:55 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Clock Sync #Timesync


In my testing I have tried various combinations of multiple receivers and I do NOT recommend attaching more than one reference clock, i.e. a GPS, to a machine.

NTP will work with more than one, but I have seen some strange things happen when both devices are of equal quality.

For devices of equal quality, it appears to take ntp longer to decide which one to select and occasionally marks both as false tickers. I am guessing that is because the developers of ntp never envisioned someone could actually afford having more than one high quality source and the selection algorithms are having difficulty deciding between them.

For devices of unequal quality, ntp will quickly pick the better device and the second device from then on serves no purpose, e.g. with a USB GPS and a PPS serial GPS, ntp quickly selects the PPS serial GPS.

I suggest moving one GPS to another machine or just keep it as back up in the remote case of failure.

As for delay times, the actual delay will depend on ALL the hardware involved. My value of 30 milliseconds is a rough average for all the systems I've tested and is just a starting point. Of all the devices I've tested, the VK-162 showed the least delay and the device with the largest delay was about 750 milliseconds, so yes, the delay can be quite large. If the delay pushes 1,000 milliseconds or goes over that (I have seen one that did which got binned), I would not trust the device for time keeping and use something else. Your numbers look reasonable to me.

A couple of other miscellaneous notes while I'm at it:

If one assumes the velocity factor of a USB cable is about 80%, that means about 250 microseconds of propagation delay per meter. As delay times are in the milliseconds, then a 4 meter USB extension cable should add about 1 millisecond of delay, which is down in the noise level of the jitter. Some quick testing of extension cables shows this to be true. I would, however, only use shielded cables in a RF environment least the cables become antennas.

During my career I often worked with clients that had a real need for accurate time and it was not unusual for a client to spend tens of thousands of dollars in today's money on hardware plus my fees to achieve this. In my retirement I became interested in how far the state of the art has progressed and wondered about the quality of time keeping hardware available for the arbitrary limit of $50 as well as what useful things can be done with a Raspberry Pi, thus all this testing.

I decided to up the game and have ordered a GNSS disciplined OCXO oscillator. While the oven controlled oscillator just guarantees an accuracy of a few nanoseconds, at $180 it is about $600 cheaper than a rubidium oscillator and there are limits to retirement hobby spending. As a bonus this will provide a 10 MHz reference that is +/- 0.0002 Hz for my frequency counter, or anything else with an external reference input.

If anyone is interested in either/or high accuracy time keeping or frequency measurement, I can write up the results after I have done testing of this device.


Join main@WSJTX.groups.io to automatically receive all group messages.