Time geeks, the story of how the US got time zones and a coordinated the time in them
Trains used to stay on the local time of their origination station???
That needed a School House Rock episode :)
Planet Money: The Day of Two Noons (Classic)
Episode webpage: https://www.npr.org/2023/05/10/1175316221/standard-time-zones-noon-clock
Prototype of my next project - a PTP clock with a 1,000,000fps, 1us display, with a true displayed accuracy of better than 500ns with respect to PTP time. No, I don't know why this is useful. Maybe some high speed photography setup with a need for absolute timestamping (though I imagine this is something already offered by high speed camera setups).
I think I've got most of the hard timing stuff sorted out now, and the synchronization with PTP and display updating is working. It needs some polish, custom PCB, a case, POE, etc. but the concept is pretty much proven. Next step is to design that PCB to get away from Nucleo dev board while I continue working on the firmware.
Learned a bunch about DMA to get the us display working. The last two digits have their own SPI bus because there's barely time to transmit the 16 bits at max clock within 1us. To make this work practically, I generate a 100-entry table of display updates, and just DMA circularly through it with transfers triggered by a PTP synchronized timer. Synchronized timers also generate the display latch signals which actually update the display. Getting it all to work was tricky, it uses 3 cascaded timer peripherals, 2 DMAs and 3 different ISRs to handle the time sync and display updates.
Actually validating the time offset of the _displayed_ value will be interesting. I'm thinking a fast photodiode on one or the digits or something. No idea what the actual time delay of an LED is (though it should be well less than 100ns I think).
PS I'm not sure what's going on with the minutes display, but ignore that, it's some assembly issue or a bad chip. Whatever it is isn't too pertinent to the timing etc. problems I've been solving.
One news item, that nobody reported on last year is, that we now have three optical transitions measured to just 1e-16 (88Sr+), 1.8e-16 (87Sr) and 1.9e-16 (171Yb).
This means, that we now have three atom species that can be used for optical clocks, whose uncertainty is below what the realization of the second was, just a few years ago.
https://doi.org/10.1088/1681-7575/ade4d1
https://doi.org/10.1088/1681-7575/abc232
https://doi.org/10.1088/1681-7575/adb754
Today in things I have not done in a long time: Giving presentations on atomic clocks.
You might have heard, that CGPM will vote on whether to (de facto) abolish leapseconds in October, due to the technical problems it causes, each time we have a leapsecond. And because of the prospect of the first ever negative leapsecond.
https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-UT1-UTC&id=6
What not enough people are talking about is that earth is very likely speeding up because of climate change:
https://doi.org/10.1038/s41561-024-01478-2
https://doi.org/10.1073/pnas.2406930121
Coming back to OSHW atomic clocks. After thinking for a while. I think the cheapest option is to build a 87 Rb vapor cell coherent population trapping clock. I.e. one that shines a laser onto a vapor cell, which is modulated with half the hyperfine splitting.
The only special part needed would be the vapor cell, which can be had for 1k€ at Thorlabs (and others). Laser diodes are fairly easy to get, though need to be selected for modulation bandwidth.
1/3
Random musing of the day: What would it take to build an open source atomic clock?
Designing an atomic clock and making the design open is easy. Heck, there are plenty of schematics and drawings of commercial clocks online. But making it such that Joe and Jane Average could replicate it at home without any parts or devices that are hard to get or extremely expensive? That's a tough nut.
Picked up a very obsolete Symmetricom TimeSource 2700 on eBay, solely to harvest the PRS10 Rubidium Frequency Standard inside (which go for more than double what I paid for the donor). Now I can proudly report that I have an atomic clock!
Preliminary tests suggest the PRS10 works; it reports that it is healthy, but has rather a lot of drift vs. GPS PPS, when the control loop is tuned per defaults, anyway. More investigation is required.
Nice of the seller to include the original manual for this obsolete and useless gear. These boxes are I guess a bit of an interesting artifact of precision time. They were used as a "BITS" clock source for synchronous telecom in a data centre or central office, where access to a sky view for GPS was awkward or expensive. CDMA required precision time to function, so base stations would always have GPS-synchronized clocks, which could be recovered from the CDMA signal. With CDMA sunset long ago, and little usefulness in this asynchronous, Ethernet world, they are paperweights now.
If you're interested in precision time, it might be a good way to source your own atomic clock. Most folks know they are worthless for their original purpose, but perhaps not that they contain a precious atomic clock.
Replaced the cheap Netgear switch with a Cisco C2960CX. This increased the static offset from ~1.2μs to ~2μs. Interesting, and seems to corroborate asymmetric delay based on the network switch. I'd need to think a bit more on it and how it interacts with PTP's delay compensation, but the difference in serialization time between 1G and 100m might also be a factor here.
The brief period where the offset falls off a cliff is when the switch was disconnected and the local PTP clock was free running. The shallower downslope was when the GPSDO (with an OCXO) was free running after I bumped the setup and rebooted that machine. Due to the poor antenna setup, it doesn't recover until hours later and we see the new offset.
How chrony interprets the performance of local PPS vs. PTP. Green trace is the offset of the local clock and GPSDO PPS, captured locally using the BeagleBone timer capture hardware (see my previous posts on that platform). Yellow is the offset between the local clock and the ptp4l-synchronized PHC. ptp4l is receiving time from the timing NIC test platform.
The jitter looks fairly comparable, which is impressive to me. There's a constant offset of around 1.3μs. At the moment it's unclear which is 'wrong', I will need to make some actual measurements to determine that. It could be caused by an issue with the capture code on the BeagleBone (or its interrupt timing), an asynchronous network delay through the switch, or something else.
I think the network theory is most likely, since one side is at 1G and the other at 100m, it seems very plausible the delays would be different in each direction even with store+forward.
FLOX Advocate
Keenan Tims
Attila Kinali