[jrockway]

What's interesting to me is how the form factor of timing GPS modules has stayed constant over the years. I started my GNSS timing journey with a used Trimble GPS from the 2000s, and it has the same form factor and pinout as the modern multi-constellation timing GPSes from uBlox.

I've had a GPS clock going for several years at this point, and without an atomic clock or really any fanciness (just LinuxPPS and Chrony), I see about +/- 380ns, which is pretty good. NTP to the Internet gives me jitter in the range of about 20ms-70ms, about 5 orders of magnitude worse.

(The version a few iterations ago looked like this: https://github.com/jrockway/beaglebone-gps-clock. But I now have a uBlox multi-constellation GPS, which is much more accurate with my limited view of the sky from my Brooklyn apartment. And I 3D printed the case, so it actually looks presentable instead of like some crazed madman that attacked a plastic case with a hacksaw -- which is exactly how I made the first case. As for the DS3231 RTC that I added... that seems to be stable within about 1.5us, which is pretty impressive. I tuned it a little bit with the trim register, though.)

My takeaway from this article is that the project seems quite compelling, but a lot of cost is added to support PTP. I see why Facebook needs that, but to sync time precisely throughout my lab, all I need is a coaxial cable with 10MHz on it. I don't mind if my workstation is 20ms off UTC.

[Terretta]

Thanks for the "one clock" mention for east coasters, about half price from Amazon vs. LaCrosse directly:

https://www.lacrossetechnology.com/products/404-1235ua-ss

https://smile.amazon.com/gp/product/B01CCHXTE2/

In the Zoom Age, ambiently glanceable accurate (for humans) time is super useful, as is the temporal pie chart of time left vs. how much I have to care how much time is left illustrated by analog clock faces.

[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.

[binkHN]

> I don't mind if my workstation is 20ms off UTC.

This is one of the reasons for OpenNTPD's existence. They wanted something that was simple and a ~50ms deviation was part of the design goals/trade off for this.

http://www.openntpd.org/goals.html