What are the limits of GNSS time accuracy?
The limits are not about radio or geometry. GNSS time is a prediction, so its accuracy is bounded by how good the corrections are — and corrections are forecasts of errors that have not happened yet.
19 pages · all tags
The limits are not about radio or geometry. GNSS time is a prediction, so its accuracy is bounded by how good the corrections are — and corrections are forecasts of errors that have not happened yet.
You are not choosing a receiver so much as choosing whose timescale you end up on. There are three ways to do it, they differ by a factor of a hundred in cost, and most datacenters should take the cheapest.
The data you would need is public, free, and better than most people realize. You can build the measurement in a weekend. What you cannot build is the one thing that turns it into a number somebody else has to accept.
You cannot run a cable, and neither clock can be the source for the other. So you both watch a third clock in the sky — which drags its error into your answer. Every technique here is a different way of removing it.
Eight things worth doing, from the closing slide of a talk on getting the last nanoseconds to UTC. Most cost nothing but attention, and most of the error they remove is invisible until somebody checks.
Six traits, in the order they start to matter. The last one separates a box that wants to be your master clock from a box that knows you already have a better one.
When GNSS goes away your clock coasts on the frequency it was last told. How far it drifts is decided by your room more than your oscillator — which is why a holdover measurement and a holdover specification are different objects, and only one of them is a promise.
Timing failures are usually quiet, and nothing inside a wrong clock knows it is wrong. The only detector is a second clock — and the boundary between what the two share and where they are independent decides what you can learn by comparing them.
GNSS, a fiber from a national lab, a commercial delivery service, or NTP from the internet. Why GNSS usually wins below 100 ns, and why you want more than one.
Not one relationship but two: a whole number of seconds you can look up, and a sub-nanosecond prediction that two control loops — one running in minutes, one in weeks — spend their lives maintaining.
Folklore says Galileo. BIPM measures it daily, per constellation, and publishes the answer — and over fourteen months the folklore does not hold up.
Each decimal place of latitude and longitude buys a factor of ten. Knowing where the useful digits stop saves arguing about the ones that cannot mean anything.
If you don't know your exact location, you can't know the exact time — about a nanosecond of error for every foot you are off vertically. Here is how to get it right.
An uncalibrated feedline is likely your largest source of error to UTC — tens of nanoseconds from a cable nobody measured. Here is how to find the number and configure it.
Averaging buys you improvement that stops. What is left when it stops is bias — and the same story plays out in position, in time, and in frequency.
The same talk, four slides longer — and almost everything new in it came out of writing the timekeeping pages rather than building the clock
Thirty pages on precise time in datacenters — what limits GNSS accuracy, what traceability actually requires, and how you would know your clock was still right. Not blog posts. Pages I intend to keep correct.
Building a sub-nanosecond clock from a $1000 parts list, and what four months of AI-assisted research actually looked like
Is sub-nanosecond UTC sync possible? Literally no. Practically yes — and the difference is the whole point