|
|
|
|
|
by geoffeg
1778 days ago
|
|
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. |
|
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?)