Topics In Timekeeping · Timekeeping in Datacenters

How to configure antenna position for datacenter GNSS receivers?

Updated Aug 10, 2026 • GNSS, antennas, timing, datacenter

If you don’t know your exact location, you can’t know the exact time.

That is the whole page in one sentence, and it is worth a moment because the two halves sound unrelated. Position is a surveying problem. Time is a clock problem. What connects them is that a GNSS receiver does not measure time at all — it measures how long a signal took to arrive, and it cannot turn that into a time without knowing how far the signal came.

Get the distance wrong and you get the time wrong by exactly that much. Every foot of vertical error is about a nanosecond, and the receiver will report that wrong time with complete confidence, because from where it sits nothing looks amiss.

So this page is not really about position. It is about how to get the time right.

Your phone is solving a harder problem than you need solved

The GNSS receiver in your phone expects to be moving with you. It has no idea where it is from one moment to the next, so it solves continuously for four unknowns — three of position and one of time — and needs at least four satellites in view to do it.

A datacenter antenna is bolted to a roof. It moves only with the smooth rotation of the Earth, which is to say it does not move at all in any sense the receiver cares about. So you can simply tell the receiver where it is, and let it solve for one unknown instead of four.

That buys two things:

• A better time solution, because the arithmetic has less to do and fewer ways to go wrong.
• Time from as little as one satellite in view, instead of the four a moving receiver needs. In a datacenter, where the sky view is usually whatever the roof and the neighboring buildings left you, that can be the difference between having time and not having it.

What a national lab does

A national lab would likely hire a professional surveyor to establish the exact position of a new antenna mount before it had an antenna mounted or was ever connected to a timing receiver. They are working down in the double-digit picoseconds, where millimeters of antenna position error matter.

The receiver is then configured with that surveyed position and never solves for position at all. The question “where is the antenna?” gets answered once, by somebody whose job it is, with instruments built for it.

What datacenters actually do

Accuracy requirements are not usually that stringent for datacenter timing, so it is common — and reasonable — to let the receiver work out its own position.

The important question is how long that goes on.

Watching the sky for longer produces a more accurate fix, because some of the error is random and averages down over time. But the benefit does not continue indefinitely: the geometry of the satellite orbits limits what averaging can buy after a couple of days.

So the optimal behavior is fairly clear. Spend a couple of days solving for the position of a new antenna, then switch to solving only for time.

Why that is seldom the default

Because it leaves a vulnerability, and the vulnerability is silent.

If the antenna moves while the receiver is assuming it is fixed, the time is wrong and nothing says so. No alarm, no degraded status, no obviously bad number — just a steady offset that arrived the day somebody adjusted a mount or a storm shifted a bracket.

Manufacturers default to the safe behavior rather than the accurate one, which is the right call for a product that has to work in installations nobody supervises.

If you take the accurate option, the silence is the thing you have to engineer around — see is my clock right?

If you would rather not commit to that

There is usually a middle path, and an easier one.

Survey-in. The receiver initially solves for position, then switches automatically to fixed-position mode once a time or accuracy threshold is reached. Most of the benefit, none of the paperwork.

Always solve for position. The receiver never stops. Simplest of all, and never silently wrong about a moved antenna.

Both have costs worth knowing before choosing:

• A receiver always solving for position is less likely to produce stable time output, because the position solution wanders and the time solution wanders with it.
• A receiver that switches to fixed mode after a threshold will very likely restart its position search after every power failure — and arrive at a different answer each time. NIST measured exactly this: repeated cold-start surveys on one antenna landed within about half a meter of each other, and the results were consistently biased high relative to a properly computed solution, for reasons they could not identify.

That last point is the one people do not expect. A survey-in receiver does not converge on an answer and keep it. It converges on a slightly different answer every time it is asked.

The limits of position accuracy

Two separate things make the vertical axis the problem.

It matters most. Vertical error contributes most directly to time error, because of the geometry between an antenna and the satellites above it.

It is hardest to measure. GNSS resolves height less accurately than horizontal position, because the inclination of the satellite orbits means a receiver never sees the geometry from below. The axis you most need is the one the constellation is worst at.

And there are more ways to misread it

Height is quietly ambiguous in a way latitude and longitude are not:

• Above ground level (AGL) is what a building drawing usually means. It is not a geodetic quantity at all.
• Above mean sea level (AMSL), or orthometric height, is referenced to the geoid — the equipotential surface approximating sea level, which is bumpy because the Earth’s mass is not evenly distributed.
• Ellipsoidal height is what GNSS natively computes: height above a smooth mathematical ellipsoid that approximates the Earth’s shape.

The geoid and the ellipsoid differ by tens of meters, varying with location. Reading one as though it were the other is a tens-of-meters error — a hundred nanoseconds or so, vastly larger than anything else on this page. Different reference frames and datums add a meter or two on top of that.

And do not expect the GPS or compass app on your phone to give you elevation to the nearest foot. It is lucky to be right within ten.

What is actually achievable — two very different regimes

The achievable number depends entirely on which method you used, and the gap between them is three orders of magnitude. Quoting one figure for “antenna position error” hides the whole decision.

Our own operational antenna positions carry σ ≈ 12 mm, which is 40 ps. That is not a heroic number — it is what an offline solution on a day of observations routinely produces, using processing somebody else already built and runs for free.

If you are about to type those coordinates into a configuration file, it is worth knowing how many of the decimal places can mean anything — centimeter-class work needs more digits than most forms give you, and meter-class work needs fewer than most people supply.

The consequence is the useful part. Once you are in the second row, antenna position stops being your limiting term and the feedline takes over as the largest thing in your budget. That is the whole reason this page insists on the offline route: not because 15 ns is intolerable, but because leaving it there means you never get to have the more interesting problem.

NIST’s own measurements make the point. Evaluating a low-cost dual-frequency timing receiver’s built-in survey mode, they wanted height good to 30 cm — one nanosecond — and the survey did not deliver it. The results were biased high by an amount they could not explain, and their recommendation is the one this page opened with: compute the position properly, and configure it in.