What are the limits of GNSS time accuracy?
Skip the details — take me to the bottom line ↓
GNSS time is a prediction, and that single fact sets every limit on this page.
Not the radio link, not the geometry, not the speed of light. Your accuracy is bounded by how good somebody’s forecast of a satellite clock’s future error happened to be at the moment your receiver used it — because that forecast is what a correction is. Everything below is an unpacking of that sentence, and every number in it comes from the same place.
Getting from the common mental model to what actually happens takes two steps, and each one moves the intelligence further from the satellite.
First order: the satellite knows what time it is
The intuitive model. There are atomic clocks up there, they are excellent, and the satellite tells you what they read.
Everything in that sentence is true except the last clause, and the last clause is the one everyone relies on.
Second order: the ground steers the satellite’s clocks
A better model, and the one most people arrive at next. If the satellite clocks drift, presumably somebody on the ground measures the drift and steers them back.
This is not wholly wrong — occasional adjustments do happen — but it is not the mechanism that gets you accuracy, and believing it leaves you unable to explain why correction streams exist at all.
Best: the clocks free-run, and your receiver does the correcting
The satellites’ clocks are superb and nobody is steering them continuously. They run free and drift. The ground segment measures that drift and uploads corrections, the satellite relays them — a bent pipe, not a brain — and the correction is applied in your receiver.
That last part is the piece that took me longest to internalize, and it is the one worth carrying away. Your box is not receiving the time. It is receiving a signal from a drifting clock, plus a separately delivered estimate of how wrong that clock is, and doing the arithmetic itself.
The correction was computed on the ground, from observations taken earlier, and describes what the satellite clock will read. It is a forecast of a drifting quantity, and it was already slightly stale when it left the ground.
So GPS Time is, in the phrase that stuck with me, a real-time prediction of what USNO will eventually define as UTC(USNO) — prediction because UTC has not been computed yet, and eventually because the definitive answer arrives about a month later.
The corrections are not one thing
Expand that third panel and the single arrow labeled clock corrections turns out to be three quite different paths, arriving by different routes, at different freshness, enabling different things.
Read it by color and the argument is immediate. Orange comes from space and is raw. Blue comes from the ground and is computed. Nothing the satellite knows about itself is authoritative.
The three blue correction paths differ in ways that decide what you can do:
Coarse broadcast corrections ride in the navigation message every satellite already sends. Free, global, no internet — and refreshed on the order of ten minutes to two hours, which is why they are coarse. Enough for SPP-class work.
Galileo HAS is broadcast as a separate signal-in-space on E6-B. Still free, still global, still no internet needed, and far fresher — but its first phase carries no phase biases, which makes it a float PPP source rather than an ambiguity-resolving one.
Internet corrections come from a GNSS analysis center over a network link, with registration or a subscription. The fastest and most accurate of the three, and — when they come from a single self-consistent analysis center — they carry the phase biases that make PPP-AR possible.
That maps directly onto the acquisition column of the matching table: SPP, float PPP, and PPP-AR are not three grades of receiver so much as three grades of correction.
Precise streams are re-issued every five seconds, and a stream that hands you a five-second-old correction is meaningfully worse than its interval suggests.
Something needing refreshment that often was never a measurement of the present. It was a forecast, and forecasts decay.
And here is what that costs you, measured
Two figures so far have shown the shape of the problem. This one puts numbers on it.
The eye should travel down and to the right, and the distance it travels is the point: leaving the broadcast navigation message for a real-time correction stream buys two orders of magnitude in freshness and one in error, in a single step. Your receiver’s raw observations do not improve when you spend more here. Everything separating a hundred-nanosecond consumer fix from a sub-nanosecond disciplined clock lives in the corrections applied on top.
Read the left-hand cluster carefully
The four broadcast points are the interesting part, because they refute the obvious reading of their own axis. Within that cluster, update rate is not what sets accuracy. Galileo refreshes every ten minutes and lands at 0.22 ns; GLONASS refreshes every thirty minutes and lands at 3.82 ns, seventeen times worse at the median and forty times worse at the 95th percentile. Galileo updates more often and is better, so cadence cannot be the explanation.
What is left is the clock on board and the ground segment behind it — Galileo flies passive hydrogen masers where GLONASS flies caesium. That is why the figure draws two soft regions and one arrow rather than a line through seven points: a fitted line would assert a relationship that holds between the tiers and demonstrably fails within one.
The prediction scorecard on another page also puts GLONASS an order of magnitude behind the other three. It is worth being precise that these are not the same measurement: BIPM’s scorecard grades the broadcast UTC offset against UTC, while this figure measures satellite clock and orbit error against a precise correction stream. Different quantity, different reference, different observer.
Two unrelated methods agreeing is worth more than either alone — and it is the reason the advice on the timescale page is pick any constellation but GLONASS rather than a hedge.
Four caveats, because the plot is more quotable than it is careful.
The four broadcast points are measured here; the three stream points are published figures. The broadcast numbers come from a 24-hour capture of the CNES stream, 8.8 million rows, on the logic that the correction a stream supplies is the broadcast error it removes. The residuals quoted for HAS, IGS-RTS and single-analysis-center SSR are their providers’ numbers. The figure does not distinguish the two, so this sentence has to.
The y axis is per-satellite error, not your clock’s error. A receiver averages over every satellite in view, so its clock solution beats any single point on this plot. Nothing here is an end-to-end budget.
One 24-hour window, one site. Constellation error varies with geometry, with the upload schedule, and with which satellites happen to be up.
Real-time sources only. Post-processed IGS products reach about 20 ps — far better than anything plotted — but arrive 17 hours to two weeks late, which disqualifies them for a running clock and not for anything else.
Why you cannot get below a few nanoseconds to UTC
Everything above compounds into a floor. Between the constellation’s own prediction error, the granularity of the broadcast offset to UTC, and the fact that UTC will not be defined for another month, aligning to UTC in real time runs out of road at a few nanoseconds.
But that is a statement about UTC, not about clocks.
When you can just call it GPS Time
If your requirement is that your clocks agree with each other, and no timestamp has to be handed to anybody outside your estate, then the constellation’s own timescale is a perfectly good reference — and you can align to GPS Time or Galileo System Time specifically, far below the floor that applies to UTC.
Everyone tracking the same constellation shares its prediction error. It is common-mode, and it cancels in every comparison you make internally.
The matching table shows sub-nanosecond as achievable, and this page says you cannot get below a few nanoseconds. Both are true, because they are about different things.
Sub-nanosecond agreement with a constellation timescale: achievable. Sub-nanosecond trueness against UTC: not, in real time, by anyone.
So the useful question is not “how close to UTC can I get?” but “does anything I do actually require UTC?” For a great deal of datacenter work the answer is no, and knowing that is worth a lot of money.
The one thing to carry away
- Nothing up there knows what time it is. The satellites’ clocks free-run and drift; the ground measures that drift and publishes a forecast of it; your receiver does the arithmetic. Every limit on this page follows from that one sentence.
- Your accuracy is somebody’s forecast, and forecasts decay. Which is why a correction’s freshness is a specification in its own right, and why a five-second-old one is meaningfully worse than its interval suggests.
- Buying accuracy means buying corrections, not receivers. The raw observations do not improve when you spend more. Everything between a hundred-nanosecond fix and a sub-nanosecond clock lives in what you apply on top.
- Within the broadcast tier, cadence is not the lever. Galileo updates more often than GLONASS and is seventeen times better; the difference is the clock on board, not the schedule.
- A few nanoseconds to UTC is the floor, and it may not be your problem. If nobody outside your organization has to accept your timestamps, GPS Time is a perfectly good timescale and the last few nanoseconds to UTC are a cost with no benefit.
Where to go next
- Which GNSS constellation keeps the best time? — how well these predictions have actually been doing, measured and published monthly by the people who define the answer.
- Traceability — what it takes to make a claim about UTC that somebody else has to accept.
- When agreement matters more than being right — the same argument from the application’s side.