Raspberry Pi Nixie Atomic Clock
github.com
github.com
I've been doing small hobby iterations of gps nixie clocks for a decade. I'm using a pi in my latest iteration, but man this project really goes the distance. It does everything I want to do in my most ambitious vision of the project and then goes another 50% further. Really excellent stuff.
I thought I was being fancy by syncing to time.gov and using NIST's atomic clock, but having an independent atomic clock is awesome. Granted, it's likely not as accurate, but for a wall clock the difference won't show up for centuries. Just the best parts of hobby electronics, a nerd project that is extremely technically impressive for a result that non-hobbyiest people shrug their shoulders at.
My end goal is to have them create a backend api server for syncing data to the alarm clock, and then a mobile app so they can change settings remotely. I figure it is a good learning project for them to touch a lot of disciplines (hardware, embedded firmware, circuit design and layout, 3d modeling, web services, mobile apps) to see what they gravitate towards.
I've worked with vacuum tubes a bit in audio amplifiers, but this seems wild, honestly. Does anyone know how Nixie tubes can manage such a feat? 100,000 times a second? It's incredible.
I don't know how fast they can switch on and off though, for the purposes of something like the above. Don't particularly trust the internet on this one because switching speed isn't really the diode part (which would be very fast), but rather the emitted light...which I assume lags a bit at "off".
What appears to be a commercialized version: https://www.banggood.com/Geekcreit-Pseudo-Glow-Tube-Clock-DI...
Still requires high (compared to electronic components) voltage
I've been looking for more time sources to add to my own GPS clock: https://github.com/jrockway/beaglebone-gps-clock (which is one of those boring ones that everyone has).
I have been thinking about buying a rubidium oscillator from eBay for fun, but basically anticipated the problem the author had -- they have been mistreated for years before finally landing on eBay, and aren't any good. GPS is my only frequency reference, so I wouldn't really be able to fix it; I'm at the mercy of my very obstructed view of the sky.
I'd like to be able to measure how badly out of sync I get when I fall down from 16 satellites to 4 satellite throughout the day. I can sort of intuit that from the data I get right now (I send "chronyc sourcestats" to influxdb every 30 seconds, and you can see that when the GPS signal gets bad, the frequency error in my system clock also gets bad.), but I'd like to measure it conclusively. Will probably spend a bunch of money on the problem and become even more unsure which way is up ;)
The link to the "time to digital converter": https://www.ti.com/lit/ds/symlink/tdc7200.pdf is very interesting, and I totally forgot that I should be measuring AC powerline cycles to see how they're doing relative to GPS.
(In the past, I also incorporated a WWVB receiver, but get such a terrible signal in New York that I didn't get any usable data out of it. I then dropped the ceramic antenna and that was the end of that project. I have since realized that I can buy a phase-modulation receiver inside of a clock, throw away the clock, and try that, however. Ordering one right now, actually! Thanks HN!)
I'm settling for a regular RTC[2] rather than an atomic clock for the fallback though.
Designing the PCB's is taking a bit of time though, me being rather new and Nixie tubes being 170V does slow things down a bit.
[1]: https://news.ycombinator.com/item?id=28372861
[2]: https://www.nxp.com/products/peripherals-and-logic/signal-ch...
Mine was built with a much older version of this board - https://store.uputronics.com/index.php?route=product/product.... I like using the HAT as a dedicated solution instead of the USB route.
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.
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.
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.)
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.
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.)
Even if the time.cloudflare.com is much closer to me than the other servers, at 8 ms delay, it also has a large offset of around 3 ms from the true time.
While that is much worse than the other servers, it is still 2 orders of magnitude away from the hundreds of ms of your case.
Besides the 4 random servers from a pool, I also use 4 individually selected NTP servers. For example, because I live in Europe, one of them is the NTP server of the French astronomical observatory (Observatoire de Paris, SYRTE).
I have been using NTP for decades and I typically see on my own NTP server (from my home) an offset less than 0.2 ms with a jitter between 1 ms and 2 ms, while the delays to the reference servers vary between 8 ms and 250 ms, with most between 40 ms and 60 ms.
I have configured NTP on a large number of computers and I have never seen offsets above 10 ms, but it is true that most of them had reasonably good Internet access, over Ethernet, TV cable, optical fiber or high quality wireless links.
I can imagine that a very bad Internet access, with highly variable delays to the reference servers might confuse NTP, but I have no longer seen such cases since around 2001/2002, i.e. since the last time when I have used dial-up access over a phone modem.