Topics In Timekeeping · Timekeeping in Datacenters

What makes an accurate GNSS timing receiver?

Updated Aug 12, 2026 • GNSS, timing, datacenter, buying, oscillators

Skip the details — take me to the bottom line ↓

Every GNSS receiver will hand you a PPS and a claim about how accurate it is. The claims cluster suspiciously close together, so they are not much use for choosing. The capabilities are far more revealing, because each one changes what you are able to do rather than what somebody is willing to assert.

First: which of these are you buying?

Two quite different products get called “a GNSS timing receiver”, and half the confusion in this subject comes from advice written for one being read by somebody holding the other.

A module, or a geodetic receiver. A u-blox ZED-F9T or a Septentrio mosaic-T at the module end; a Trimble NetRS or a Septentrio PolaRx at the geodetic end. You wire into its PPS and its serial stream yourself, and you are building the clock. Everything downstream — the oscillator, the discipline loop, the holdover, the protocols — is yours to supply.

A GPS network clock. A 1RU box you rack, feed an antenna, and give an IP address. There is a module inside it, but it is a hidden component: you never see its PPS jitter or its serial stream, because the vendor has already wrapped it in an oscillator, a discipline loop and a protocol stack. You are buying the clock, and what you get out is NTP and PTP.

Both hand you a PPS. Only the network clock hands you a protocol, and only the module hands you the parts.

Here they are in roughly the order they start to matter. The shape of the list is the interesting part: the first few make the receiver a better clock, and the last two stop it from having to be your clock at all.

A good timing receiver wants to be your master clock. A great one knows you already have a better short-term clock, and that what you actually want is to compare that clock against GNSS.

1. Two frequency bands

The single biggest jump, and the one to spend money on first.

The ionosphere delays the signal by tens of nanoseconds, and it varies with the sun, the season and the hour. A single-frequency receiver has to model that delay from broadcast parameters. A dual-frequency receiver measures it, by comparing two signals that the ionosphere delayed by different amounts.

NIST quantified the difference on their own hardware: over a long baseline, single-frequency measurements ranged up to 50 ns in a day where dual-frequency stayed within about 10 ns. Same antennas, same roofs.

2. Antenna supervision

Cheap, widely fitted, and more useful as a diagnostic than as an alarm — once you understand precisely what it is watching.

It watches the antenna connection, not the signal. The receiver offers DC on the coax to power the antenna and measures the current consumption; too little reads as open coax, too much as a short. That is a statement about electrical load, and it is only loosely coupled to whether you are receiving anything.

Both failure modes are real and both are common:

• Great signal, apparent disconnection. A splitter or an inline amplifier that does not mimic an antenna’s current draw will read as open forever while the signal is perfect.
• No signal, connection fine. Aluminum foil over the antenna will do it in seconds. The current consumption doesn’t change, so the antenna supervisor is entirely happy.

So on its own it is a liar in both directions. What makes it valuable is the correlation: if signal quality changes and the connection state changes at the same moment, you have learned something a single indicator could not tell you. If signal drops and the connection is unchanged, look at the sky, the firmware, or somebody’s foil. That is the second-clock argument in miniature — two indicators that share almost nothing, read together.

For a clock builder using a GNSS receiver module there is one more reason to want it, and it is the strongest one on this page. An antenna fault is usually the leading indicator that holdover is in your near future — but the useful part is what happens in between.

PPS might keep on ticking for many seconds after an antenna disconnect, and your discipline loop will keep steering on it. So note your DO steering value at the moment the supervisor flags the disconnect. If PPS is lost not long after that, you may be able to undo whatever transient the failure induced by restoring that earlier steering value and locking it in for holdover, rather than coasting on whatever the loop learned while its reference was falling apart.

Which is the holdover page’s own argument arriving from a new direction: holdover coasts on the last thing the loop was told, so the last thing it was told had better not be nonsense.

3. Carrier-phase smoothing

The pseudorange code measurement — the one that tells you unambiguously which nanosecond it is — is noisy. The carrier phase is exquisitely quiet but tells you only the fractional part of a cycle, with a whole number of cycles unknown.

Smoothing the code with the carrier gets you most of the carrier’s quietness without solving the ambiguity problem at all. It is nearly free — a one-state recursive filter per satellite per band, a few operations an epoch — and it is the difference between a jittery PPS and a steady one.

4. A PPS output — and know what to expect from it

Table stakes for both audiences, but you should expect very different things.

From a module or geodetic receiver, expect jitter. Its PPS is generated directly from the receiver’s own timebase, so it inherits that oscillator’s short-term noise and lands on a quantized tick. That is not a defect; it is what a raw PPS is. Smoothing it is your job, and doing it is most of what building a clock consists of.

From a network clock, expect it already smoothed. The whole point of the box is that an internal oscillator has been disciplined to GNSS and the PPS comes off that oscillator rather than off the receiver. It should be quiet, and it should keep being quiet through holdover, because the same oscillator carries both jobs. A network clock whose PPS jitters like a bare module has not done the thing you paid for.

One question for both: where does the connector sit relative to the module? On a u-blox EVK-F9T, the rear SMA carries a buffered timepulse — the board’s parts list names NC7SZ125/126 logic buffers — so the connector is single-digit nanoseconds after the module pin, not the few hundred picoseconds a centimeter of trace would cost. That is a real term in an error budget, and it drifts with temperature.

5. Quantization error output

(Modules and geodetic receivers only. A network clock has already used this internally, and has nothing to report.)

A PPS edge cannot land wherever it likes. It has to fall on a tick of the receiver’s internal clock, so it is systematically early or late by a sawtooth-shaped amount — and on a receiver clocked at 125 MHz, that is 8 ns of error you could remove if only you knew its sign and size each second.

Good timing firmware tells you. It reports the quantization error for the edge it just produced or will next produce, so your loop can correct for it. A receiver that does not report it is not less quantized, only less forthcoming, and you have thrown away the single cheapest nanosecond on the whole board.

6. Raw observations out

(Modules and geodetic receivers. Do not expect these from a network clock — that is not what it is for.)

The difference between a box that gives you an answer and a box that gives you evidence.

A receiver that emits raw code and carrier-phase measurements — as RINEX, or a format you can convert — lets you reprocess the same day with better correction streams months later, run your own PPP solution, survey the antenna position properly rather than letting the receiver guess, and compare your clock against a national laboratory’s.

None of that is possible with a box that only ever tells you its conclusion. If you expect to still care about this subject in two years, weight this trait above its position on the list — it is the one that compounds, because everything you might later want to do turns out to require it.

7. A time-mark or PPS input

Now the flip. A time-mark or external-interrupt input lets the receiver timestamp an edge you give it — which means it can measure your clock against GNSS, instead of only reporting its own.

That is a different instrument. The receiver stops being a source and starts being a comparator, and comparison is what you actually need if you already own something good. The ZED-F9T does this on its EXTINT pins and reports the result in its own messages.

And this is the one place a network clock joins in. Some of them accept a PPS input for exactly this purpose — feed it another clock’s PPS and it will tell you the difference. That is the cheapest way to compare two clocks against each other that exists, and it turns a box you bought as a source into a box that can also audit one.

8. A reference frequency input — and this is the one

The last trait is the one that changes the category, and it is the one most datasheets bury.

Start from what a receiver can actually do, which is narrower than it looks. No GNSS receiver ever observes a satellite against UTC. It observes the satellite against a timescale of its own — and a timescale is three things: a tick duration, an origin, and a count. The receiver always supplies the origin and always does the counting.

So the only question left is where the tick duration comes from.

Without a reference input, the ticks come from a TCXO soldered to the receiver’s own board. Every pseudorange, every carrier phase, every PPS edge is timed against that oscillator. It is a few dollars’ worth of quartz in a can, and its short-term instability is baked into every observation the receiver will ever give you.

With one, the ticks come from your oscillator — and the receiver’s clock estimate simply is your oscillator’s error against GNSS. Not a proxy for it, a direct measurement of it.

Which is why the receivers in national laboratories all have this input and all use it. NIST’s IGS station runs a Septentrio PolaRx5TR whose site log records its frequency standard as “EXTERNAL H-MASER, 5.0 MHz”, with the note that the input signal is UTC(NIST). The receiver is not the clock. It is the instrument that compares the clock to the sky.

The same split shows up in hardware you can actually buy. Septentrio’s mosaic module says it plainly — “the module can use its internal TCXO as frequency reference, but also accepts an external frequency reference on the REF_I pin”, 10 MHz, 0.5–1.7 Vp-p. The ZED-F9T’s pinout has the time-mark inputs of trait 7 but no reference frequency input at all.

A network clock, of course, has its oscillator inside. That is the product.

Which traits apply to which

Read the two columns and the split is clean. A module is judged on what it exposes; a network clock is judged on what it has already done for you. The traits that matter most to one are meaningless to the other, which is why a datasheet comparison across the two is nearly useless.

Reading the list backwards

Work down from the bottom and the modules sort into two kinds.

A receiver that wants to be your clock takes a signal in and gives a PPS out. If its PPS is good enough, you are done — and if you have got this far and concluded that is you, what you probably want is a network clock and somebody else’s engineering.

A receiver that expects you to have a clock takes your 10 MHz in, times everything against it, and tells you how your clock compares to GNSS. That box is useless on its own and indispensable the moment you own a rubidium, a maser, an OCXO, or anything else whose short-term stability beats a TCXO.

Knowing which one you are shopping for saves more money than any specification on the datasheet. And it is a question the vendor questions page never quite asks, because it starts from the assumption that you are buying a clock rather than the parts to build one.

If you read nothing else

• Decide which thing you are buying before you compare anything. A network clock has already made these decisions; a module hands you the parts and the work. Half the traits above are meaningless on one and decisive on the other.
• Two frequency bands is the one to spend money on. It is the only item here that changes the physics rather than the bookkeeping, and it is a purchase decision you cannot retrofit.
• Ask what the firmware will tell you, not just what the hardware does. Quantization error, raw observations and an honest status are the difference between a box you can audit and a box you have to trust. Same silicon, and the non-timing parts report nothing.
• A reference frequency input is the fork in the road. Without one, whatever you bolt on the outside is a second hop. With one, your oscillator is the receiver’s clock and the measurement is direct. That single line on a datasheet decides whether the box wants to be your clock or expects you to have one.
• Ask which signal combinations run together, not how many bands are listed — and remember any delay figure you were given is only valid for the combination it was measured on.

Where to go next

• Ways to get time into a datacenter — the layer above this one: whether GNSS is the right source at all.
• Questions to ask a clock vendor — what to ask once you know which kind of box you want.
• What do I put in for my antenna’s position? — the setting that wastes the most of a good receiver’s capability.