- You might have even better precision if you stay away from CPU0 and also set idle=poll in your kernel command line. Lots of things (including other interrupts) often land on CPU0. It would not be my first choice for something where I wanted high timing precision.
- The transmission site for WWVB has hundreds of water bottles to insulate the equipment from temperature swings.
https://jila.colorado.edu/news-events/articles/spare-time
- Austin from austinsnerdythings.com here! Posted this last night and went to sleep. Definitely didn't expect to wake up to it #1 on HN this morning!
Some notes that weren't included in this post:
I do have my LEA-M8T generating time pulses at 16 Hz, with a dpoll of -4 in the chrony config. The poll interval of 16 seconds means it gets 256 samples which also improved the stability.
I do also have that mentioned BH3SAP GPSDO sitting next to me on my desk. I had Claude update the firmware to allow "flywheel" behavior so it continues to generate pulses in the absence of GPS PPS. That's coming in another post. Also had Claude update the firmware to spit out TSIP (trimble proprietary protocol) info for lady heather.
Going to go through the comments and answer a couple other things I see.
Happy to answer any other questions!
by easygenes
2 subcomments
- You can go further and replace the cheap Pi oscillator crystal with a proper TCXO, as others using them for NTD have done and documented: https://raspberrypi.stackexchange.com/questions/74482/switch...
That should give you 4-5x less drift than his results (though you could pair the techniques for even better figures)
by geerlingguy
4 subcomments
- It's an SBC-scale OXCO. I half wonder if adding a larger heatsink, or even putting thermal mass around the existing oscillator could also help, or if the heating is more localized in the PCB itself.
Always fun new things to learn when doing something "simple" like setting up an NTP server!
- Why not put a resistor (for heating) and a bit of foam insulation on the crystal?
This is way more direct than spacebar heating.
You could also add a transistor attached to the resistor and a GPIO and use the clock drift as a proxy for temperature. PID is probably enough but since you have a 24 hour cycle you could calculate a baseline heating schedule.
- Instead of dedicating an entire Raspberry Pi with fancy pinning and temperature management by burning CPU time, wouldn't a micro-controller and a precise external oscillator fare better for time-keeping stability? I would assume that a STM32 discovery kit running a NTP server on its Ethernet port could probably do better.
- I would not have considered artificially-working the SOC to maintain a steady temp! When the wattage is that low, however, it makes sense to burn a few extra bucks a year versus some kind of overengineered cooling system.
- There was a paper on this in 2022. Not sure if it's used in production or not.
https://www.usenix.org/conference/nsdi22/presentation/najafi
- It's the good old OCXO - Oven Controlled Crystal Oscillator. But the heating element is the CPU. Fucking hilarious.
- I too thought that using an Oven stabilized crystal oscillator world be the best approach, but as I read on, I realized that doing it entirely in software was an interesting way to go, and well worth the journey.
- What sorts of cool things can you do with perfectly synchronized clocks? The one that springs to mind might be catching a bullet or “catching” a light pulse, perhaps? Triangulating lightning strikes, or other EM events? Maybe some kind of TEMPEST hackery?
I’d love to have a highly precise clock but I’d also like to be able to do something with it!
by anonymousDan
3 subcomments
- Couldn't you model the effect of temperature on clock drift and try to factor that in dynamically (e.g. using a temperature sensor) instead of burning CPU unnecessarily?
- > Instead of software thermal control, I could add an actively cooled heatsink with PWM fan control. This might achieve similar temperature stability while using less power overall.
Love this (honestly). Interesting article!
by conroydave
0 subcomment
- love this line FTA:
"Is It Worth It?
For 99.999% of use cases: absolutely not."
by throwaway81523
1 subcomments
- I wonder about using an RPI Pico for this instead, using the Pico's synchronous PIO gizmo to intercept the PPS pulses.
by HPsquared
3 subcomments
- A microsecond is still quite a lot if GPS is involved, that's about 1000 light-feet!
- Wouldn't a temperature compensating algorithm be just as effective?
- I love this. Chasing perfection for perfection alone.
by jazzyjackson
0 subcomment
- What, no rubidium?
- some ideas -
1. using a second hand single frequency Ublox LEA-M8T GNSS receiver is not a good idea in 2025 when a dual frequency GNSS receiver chip can be purchased online for as little as $20-30. buy one of those ublox ZED-F9P receivers with the 2018/2019 firmware, they get you the exact same timing performance as ZED-F9T with QEerr support. PPS jitter is going to drop from 20ns to less than 2ns after qErr compensation.
2. you can replace that highly unstable crystal oscillator with a $10 used OCXO + $20 PLL board and save that PID temperature controller to be used as the secondary oven for that OCXO. people have been doing that for Raspberry Pi for ages.
3. or you can configure your GNSS receiver to output a 10Hz signal from the PPSOUT pin so chrony can get 10 updates per second, GNSS receiver's internal TCXO is going to be more stable than raspberry Pi's crystal oscillator.
4. for more fun - just keep measuring the frequency drift vs. temperature change. a sample set of 24-48 hours of such measurements should be enough to figure out the tempco of that unstable crystal oscillator so you can get chrony to do the drift compensation. from memory, chrony supports such a temperature compensation lookup table to be specified.
good luck and have fun
by jauntywundrkind
2 subcomments
- Amazing project, great write-up. Would love to see a temperature graph as well! I'm wondering how good the PID controller here is working.
For future improvements, a cheap but effective win might be to put a temperature sensor on the oscillator (or two or three in various places). And use that to drive the PID loop.
Even if just experimental & not long term, it would be nice to have data on how strong the correlation is between the cpu & oscillator temperatures. To see their difference and how much that changes over time. Another graph! CPU vs txco (vs ambient?) temperatures over time.
- For RPI's an industrial graded SD it's mandatory.
- That's a neat software solution. My first inclination would be to grab a soldering iron and replace the crystal with either a TCXO or a socket to provide an external clock disciplined to the 1PPS.
by kevin-scott21
0 subcomment
- [dead]
by Walt-Stevens21
0 subcomment
- [dead]
by jason-richar15
0 subcomment
- [dead]
by generalgosttw
0 subcomment
- [dead]
by generalgosttw
0 subcomment
- [dead]
- Or just put an RTC in it
- The related question is:
Is the Pi going the Pentium 4 route?
- What's the point in reading posts like this when the solution "they" came up with is basically, "tell Claude to make a script which does whatever"? I read blog posts to read thoughts from people, not computers
Hacker News