[geoffeg]

Nice project, I've been working on something similar, but with an Arduino (Adafruit ESP32), an Adafruit GPS featherwing and a RTC. I originally started with a Linux-based solution like yours but no matter what I did I couldn't get the accuracy below about 5ms and my goal is sub-ms (verified with an oscilloscope.)

[jrockway]

Yeah, I think you're on the right track. I like less and less having a Linux box to maintain, and there is less control over the timing of internal operations compared to a microcontroller, of course. On the other hand, Chrony is really, really good, and it would be a lot of code and debugging to write something that good from scratch.

With the Beaglebone, it's theoretically possible to drive the oscillator from a calibrated clock source (use the PPS pulse to discipline an oscillator). I was too lazy to build such a circuit and observe the effects. Some uBlox timing GPSes let you output a suitable signal (you can adjust the frequency in software), but the adjustability range when I last checked wasn't enough to make it work for the Beaglebone. Once you have the MCU running at a well-defined and stable frequency, I think it's possible to give Linux extremely accurate data, or at least know which clock cycle was the start of a second. I don't actually know how much any of this will help, and it's honestly not within my capability to measure.

For me, the outcome of my GPS clock project is that I never have to set my clock, and it looks really good. Running "chronyc sources" is always pleasurable as well, but I probably wouldn't notice a clock that's 20ms off unless I was comparing it against WWVB or something.

[Terretta]

Yours does look fantastic.

Also enjoy mashing up accuracy with nixie tubes, feels very atomic '50s futurism:

- Atomic: http://www.nixie.dk/~jthomas/atomicnixie.html

- WWVB: http://www.nixie.dk/~jthomas/wwvb.html

[jrockway]

A WWVB receiver is on my todo list. I did buy a cheap module that they use in clocks, and I get no signal whatsoever (New York City). WWV (shortwave) I can hear sporadically. That is basically a result of the modules using the legacy WWVB signal, and not the newer phase-modulation signal, which is easier to receive at low signal strengths.

Having said that, this has been on my to-build list for a while, though: http://www.maxmcarter.com/rubidium/index.php

I also want to run the WWV-time-of-arrival experiment myself, and I think I have all the equipment necessary, just haven't done it. https://www.physics.princeton.edu//pulsar/K1JT/HFTOA_1.pdf

[geoffeg]

That's a useful feature of the BeagleBone. When I originally built my clock with a Raspberry Pi I used a GPS with a PPS line and hooked that into one of the Pi's GPIO lines. I could get the Pi's clock synced to the GPS very accurately (easily sub-ms) with that (using chrony), but the problem became then updating the display (similar to your setup, a 7-segment MAX7219-driven display). I started looking into writing a kernel module to update the display when the PPS-driven interrupt happened. I think, from reading the kernel documentation, there may even be some support for firing off events when the PPS occurs, but I realized it might be "easier" at that point to move to an arduino-ish solution.

I agree that I wouldn't likely notice a ~20ms jitter on the display, but I'm kinda of having fun figuring out how to make it as accurate as possible.

[jrockway]

I measured how long it took on average to write out the display, and I set my program to write out the display at that time. The values are in the source code in that repo, but if it was 1ms, at 23:59:59.999, I'd wake up and write out 00:00:00. (Scheduling jitter could be a problem, but comparing when my program starts writing data to the actual PPS signal with an oscilloscope, it seemed amazingly consistent to me. I don't have my data around to really confirm that, though.)

I have that video linked to Github and within about ~10ms, you can tell that things are working really well when the audio and visuals line up. (I say ~10ms, because there is a 2ms propagation delay between the radio station I'm receiving and the clock display changing, and it looks perfect to the eye. If it's a little longer than that, you'll notice -- WWV with ~8ms propagation delay makes you question whether or not the display is updating correctly. It is hard to discern 8ms, of course, but I think it's noticeable if you're looking for it. This, BTW, is why I hate 60Hz monitors. Your brain definitely notices the 16ms it takes from pressing a key to it showing up on the screen. We get used to it, but why tolerate failure when you can make it perfect?)

[jcrawfordor]

If you're looking for a relatively low-cost option for "always correct" wall clocks, Primex radio clocks are popular enough that they are very cheap used on eBay, and if you live in a city there is a decent chance there is a GPS-disciplined Primex transmitter within receiving range (hospitals, schools commonly have them, you can check with an SDR). Or for a standalone solution, the sadly discontinued Primex SNS series of digital and analog wall clocks are just WiFi NTP clients. Supply is becoming limited since they were discontinued but they still run fairly cheap used. Initial setup (WiFi credentials, NTP server, etc) is slightly eccentric but can be done with tools available online.

The analog wall clocks are battery powered and with the default config of re-sync every 3 days, the batteries last years.