5 ms·

Why not just use NTP to get time data from someone else’s (more accurate) atomic clock?

geerlingguy 5y ago
I'm guessing this is more of a fun project than serious—the display on the nixie tubes won't refresh quickly enough to demonstrate the rubidium oscillator's ability to hold nanoseconds of time. But in the case of potentially also using this board as a Stratum 1 clock (it has GPS/GNSS built in...), why would it not be as accurate as pretty much any other clock that serves up NTP time? It would surely be a lot more accurate than any sync via NTP going over the public internet.
- willis936 5y ago
  You could push nixies down from +200 us to roughly +/- 5 us with a current sense circuit feeding a tracking circuit (either a hardware PLL or digital DLL) with feedback from the PPS gen circuit. Most of the inaccuracy of nixie displays (that are done properly and conventionally) is that the nixies require a few hundred us to build up enough charge to ionize the gas. If you send your HV trigger out before the actual start of second then you can account for the static part of this offset. Reducing the random part would be... a trick. Low and constant temperature would be a decent starting point. My next ideas are based around taking out the feedback loop and replacing it with static offsets based on an empirical model. Taking measurements of the nixie state transition delay (ie 1 to 2 takes a different amount of time than 2 to 3) would provide useful information. You could take temperature measurements and induce temperature over a range and build a matrix of the nixie state transition delay measurements. The temperature and transition matrix you can use as a priori that is weighted against actual feedback measurements.
willis936 5y ago
NTP isn't going to beat a GPSDO by any metric, especially when the LO is Rb.
jrockway 5y ago
NTP is really not that good. I'm looking at "chronyc sources" on my GPS-disciplined clock, and relative to GPS time, the NTP sources are +/- 100s of milliseconds off. I'm sure most of this is the flakiness intrinsic in a consumer-grade ISP, but even after measuring them over a long period of time they tend to drift at about 1 part per million. (That's a second off every 12 days.) Comparatively, a tuned TXCO connected to the same clock is about 0.009 parts per million off, and many would consider that unacceptable. GPS is actually an extremely good time reference. On the ground, you can be sure of the time to about 50ns, and the internal clocks on the satellites are kept synchronized to UTC time. (Which variant of UTC depends on the satellite constellation. The US uses the US Naval Observatory for GPS; China has their own version of UTC for BeiDou, etc.)
- adrian_b 5y ago
  Hundreds of milliseconds is not normal for NTP. What is normal for NTP is to have an error not greater than 10 millisecond. If you see such huge NTP errors, you should change your reference NTP servers. Make sure to have more of them, e.g. at least 4 or 5, and they should be from some reputable sources, not from your local ISP. Also make sure that your hardware RTC clock is adjusted to the value of the NTP clock at power-off, to prevent a large difference between the RTC clock and NTP at power-on, which would require a long time for the local time to reach the network time. For the same reason, your NTP might need to be configured to make a time jump at startup, instead of trying to very slowly diminish the initial difference, which could be of many seconds with a poor RTC clock.
  - jrockway 5y ago
    I just pick 4 random servers from the Debian pool to monitor, but my reference clock is GPS time. The RTC on the board has been carefully calibrated to be accurate to 10 parts per billion. time.cloudflare.com seems to be the worst. It's stratum 3 which is weird for an infrastructure company to be operating. (I dunno, maybe someone just made a shitty NTP server and set their reverse DNS to cloudflare. I didn't investigate.)
    - 5y ago

I'm guessing this is more of a fun project than serious—the display on the nixie tubes won't refresh quickly enough to demonstrate the rubidium oscillator's ability to hold nanoseconds of time. But in the case of potentially also using this board as a Stratum 1 clock (it has GPS/GNSS built in...), why would it not be as accurate as pretty much any other clock that serves up NTP time? It would surely be a lot more accurate than any sync via NTP going over the public internet.

willis936 5y ago
You could push nixies down from +200 us to roughly +/- 5 us with a current sense circuit feeding a tracking circuit (either a hardware PLL or digital DLL) with feedback from the PPS gen circuit. Most of the inaccuracy of nixie displays (that are done properly and conventionally) is that the nixies require a few hundred us to build up enough charge to ionize the gas. If you send your HV trigger out before the actual start of second then you can account for the static part of this offset. Reducing the random part would be... a trick. Low and constant temperature would be a decent starting point. My next ideas are based around taking out the feedback loop and replacing it with static offsets based on an empirical model. Taking measurements of the nixie state transition delay (ie 1 to 2 takes a different amount of time than 2 to 3) would provide useful information. You could take temperature measurements and induce temperature over a range and build a matrix of the nixie state transition delay measurements. The temperature and transition matrix you can use as a priori that is weighted against actual feedback measurements.

willis936 5y ago

NTP isn't going to beat a GPSDO by any metric, especially when the LO is Rb.

jrockway 5y ago

NTP is really not that good. I'm looking at "chronyc sources" on my GPS-disciplined clock, and relative to GPS time, the NTP sources are +/- 100s of milliseconds off. I'm sure most of this is the flakiness intrinsic in a consumer-grade ISP, but even after measuring them over a long period of time they tend to drift at about 1 part per million. (That's a second off every 12 days.) Comparatively, a tuned TXCO connected to the same clock is about 0.009 parts per million off, and many would consider that unacceptable. GPS is actually an extremely good time reference. On the ground, you can be sure of the time to about 50ns, and the internal clocks on the satellites are kept synchronized to UTC time. (Which variant of UTC depends on the satellite constellation. The US uses the US Naval Observatory for GPS; China has their own version of UTC for BeiDou, etc.)

adrian_b 5y ago
Hundreds of milliseconds is not normal for NTP. What is normal for NTP is to have an error not greater than 10 millisecond. If you see such huge NTP errors, you should change your reference NTP servers. Make sure to have more of them, e.g. at least 4 or 5, and they should be from some reputable sources, not from your local ISP. Also make sure that your hardware RTC clock is adjusted to the value of the NTP clock at power-off, to prevent a large difference between the RTC clock and NTP at power-on, which would require a long time for the local time to reach the network time. For the same reason, your NTP might need to be configured to make a time jump at startup, instead of trying to very slowly diminish the initial difference, which could be of many seconds with a poor RTC clock.
- jrockway 5y ago
  I just pick 4 random servers from the Debian pool to monitor, but my reference clock is GPS time. The RTC on the board has been carefully calibrated to be accurate to 10 parts per billion. time.cloudflare.com seems to be the worst. It's stratum 3 which is weird for an infrastructure company to be operating. (I dunno, maybe someone just made a shitty NTP server and set their reverse DNS to cloudflare. I didn't investigate.)
  - 5y ago