Presentation describing my efforts to build clocks with sub-nanosecond accuracy using GNSS and AI in a home time lab.
I first gave this presentation on July 9, 2026 at the STAC Summit at the National Physical Laboratory (NPL) in Teddington, London, and gave an updated version on August 12, 2026 on the Time Appliances Project call.
The PDF here is the August 12 version (v4). The July version is preserved in this repository's git history if you want it.
This talk is a sequel to my earlier presentation, Last Nanoseconds to UTC (2025), which asked whether sub-nanosecond GNSS clock sync is even possible. This one is about building it.
This presentation covers the research required to work in this area, and the resulting PePPAR-Fix software for building precision GNSS clocks.
You can view the presentation PDF here on GitHub, download it for offline viewing, or watch the recording of the August 12 talk, published by the Time Appliances Project.
There is also a recording of the "dress rehearsal" for the July version, kept for the record.
My presentation style is heavy on visuals and light on bullets, with my narration giving the key points verbally, so viewers of the PDF miss a bit of what the live audience heard.
Four slides longer, and nearly all of the new material came out of writing Topics In Timekeeping — a collection of pages covering the ground this talk has to move through quickly.
- Three pictures of the same satellite, in order of how wrong they are: master clocks in orbit, then the ground steering them, then the truth — the satellites free-run, the ground computes corrections, and your receiver does the arithmetic.
- What a correction stream buys, as two numbers instead of a paragraph: roughly 25x less error and 100x more frequent updates than the broadcast navigation message.
- A very expensive thermometer. Eight minutes of quantization error from a u-blox F9T as the lab warmed and cooled; unwrapped, the oscillator's phase walks out to 120 ns and back.
- A trading campus that agrees with itself far better than it agrees with UTC — 200 ps between any pair of ports across a half-mile campus, against +/-15 ns RMS to UTC.
Plus one sharpened result: the clock reaches sub-nanosecond stability while still achieving only about 3 ns of agreement between clocks. Those are two different ways of being wrong, and the gap between them is the work that remains.
I introduce my frame of reference as retirement from low-latency trading, where precise network timestamps are required in datacenters — which left me wondering about the limits of accurate clock synchronization using fixed-position GNSS.
A section of slides provides background on the tradeoffs that must be made between fast but approximate answers to position/time questions and slower but more precise answers.
It's common to think of GPS satellites as autonomous master clocks. This abstraction works fine until you need position/time accuracy better than a handful of meters/nanoseconds. The earthbound infrastructure supporting the satellites is what limits accuracy.
The common GNSS chips in our cell phones use only the simplest processing algorithms with the coarsest models and corrections to produce approximate answers. But the same received signals can be processed through more complex algorithms using far more precise models and corrections to produce more accurate answers by two or three orders of magnitude.
A largely visual section of the presentation focuses on GNSS antennas, since they are a critical part of getting precise answers.
Without time to list all small effects that must be considered to get accurate time, the presentation highlights three:
- Intersystem bias — Clock differences across GNSS constellations.
- Datum offsets — The land itself moves over time (plate motion), so positions must be tied to a dated reference frame.
- Solid-Earth tides — Believe it or not, the solid earth beneath you rises and falls about daily, adding GNSS errors if not accounted for.
I show a block diagram of PePPAR-Fix software that uses raw GNSS carrier phase observations to precisely drive a disciplined oscillator. This section includes a parts list totaling about $1000 and a photo of one of the clock prototypes I built to run PePPAR-Fix.
Deviation plots show improvement over a simple GNSS PPS receiver and the future work to be done in pursuit of better stability. Progress toward two-clock agreement goals is given.
This work covers about four months of fairly intense research in 2026. I went from understanding only the basics of time via GNSS to a much deeper appreciation for the work needed to get sub-nano performance. I went from zero to 140,000 lines of Python code and tests for processing GNSS signals and disciplining precision oscillators. None of this would have been possible without AI and the pioneering work of others. I give some thoughts on how I worked profitably with AI by giving my agents great power, but limiting their blast radius if something were to go wrong.
One goal of this work was to leave a trail of crumbs for anyone who wants to follow. The code is open source at PePPAR-Fix, and the slides include a complete parts list. The measurement tools behind my earlier Last Nanoseconds to UTC work — including the dual u-blox F9T experiments — are in f9tResearch.
This all stands on the shoulders of others, especially Ole Petter Rønningen, who built the first PPP GPSDO, and John Ackermann, N8UR, for an inexpensive time-interval counter and divider.