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 am waiting on a board spin for my current VFD wall clock/rss feed (I screwed up the HV grounding) but this project is on such a different level. The project itself is cool enough that the nixie portion is just a side note, whereas every other nixie project is explicitly about using them for display. This would be cool on a 7-segment.
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.
When I was working on testing Facebook's PCIe Time Card on my Pi CM4 last week (it has GNSS and a rubidium atomic clock built in), I found out about this project, and thought it looked amazing!
Confirmation bias struck me and I read this as "Raspberry Pi Nixie Alarm Clock" and now I'm disappointed. I really need an alarm clock and would love to build one out of a pi. I see a ton of blog posts and stuff. Has anyone actually done that and could recommend?
I'm actually starting this right now with my two teenage kids who are interested in going to college for CS. We are using an esp32 instead of a Raspberry Pi, but I'm having them work through all the hardware and software requirements to get sound (I2S) output, display, WiFi, etc.
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 have seen a few alternatives, but are there any nixie replacements which have the features of a nixie (elegantly-shaped lettering, warm glow, solid stroke as opposed to dots) without the voltage issues and rarity? Lixie seems to have stopped producing, etc.
I guess it sounds like you're looking for an alternative technology? but in case you haven't seen them, these folks make them - https://www.daliborfarny.com/
They have a very interesting project of a clock custom built for NASA to calibrate high speed cameras. Apparently these tubes can switch 100,000 times a second and their lack of any flicker makes them well suited to this purpose: https://www.daliborfarny.com/project/calibration-display-for...
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.
That is interesting, but a numeric LED display only flickers if you choose to use PWM drivers. LEDs might have met NASA's 1/1000th of a second requirement in a simpler way than nixie tubes. Not as nifty for sure.
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".
I would love to try stacked EL components; I'm pretty sure you can make them fairly transparent, and manganese doped zinc-sulfide should make roughly the correct color?
Still requires high (compared to electronic components) voltage
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 kind of admire the fun in the project and the thought and workmanship, but I’ll steer clear of calling this clever.
See there’s no benefit in using a $1500 rubidium oscillator as a holdover for a $500 GPSDO board when the application is an alarm clock. Kind of like paying $2000 to count the atoms in the souls of your shoe.
I've been wanting to build a Raspberry Pi controlled Nixie clock - but instead of a Atomic Clock, I'm going just use a USB GPS dongle. Also set it up as a NTP server for machines on my home network.
I'm working on just that. The GSP NTP server is handled by a different Pi, but makes little difference. I used Chrony and it's working like a charm[1].
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.
I've had a Pi GPS clock running for 6 years now, it's fantastic. It's not only an NTP server for my house but it's been contributing to pool.ntp.org for the duration as well. I adore it.
Good luck with the project. Are you adding the GPS component as a hobby challenge? If it's going to be an NTP server, then it could also be an NTP client.
Its more of a hobby project. Have a spare Rpi 3b and Usb GPS dongle from another project. Plus, saw some cool projects on the nixie sub. Figured, it would make a nice looking retro clock in my home office. The USB dongle is a big finicky. So if I can't get that to work - then I might just make it into a NTP client and let it sync up with a public server. Nothing on my LAN or homelab is mission critical where I need that level of time accuracy.
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.)
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.
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.)
I have just checked my NTP server, and it's funny that I also see a bad time.cloudflare.com, among a set of 4 random NTP servers from the FreeBSD pool.
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.
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.
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.
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.