How to configure feedline length for datacenter GNSS receivers?
An uncalibrated antenna feedline is likely your largest source of error to UTC. A run of coax that nobody measured can put tens of nanoseconds between your clock and the truth — quietly, permanently, and with nothing in the system disagreeing. What makes it a configuration problem rather than a hardware one is that the fix is a single number typed into the receiver; what makes it a hard configuration problem is that the number is genuinely difficult to come by.
Why you have this problem at all
The GPS in your phone is a single integrated unit: antenna and receiver millimeters apart. Whatever delay exists between them is tiny, fixed, and dealt with at the factory. You have never had to think about it, because you have never had a reason to.
That integration does not survive a datacenter. GNSS signals do not usefully reach the inside of a building, so the antenna goes outside and the receiver stays in the rack — and the two are now joined by tens of meters of coax that belong to you.
Splitting the phone in half is what creates this problem. Everything below is a consequence of that split.
What the antenna knows, and what your clock needs
Signals from many satellites combine at the antenna. What falls out of that combination is the position of the antenna, and the time at the antenna.
Your clock is not at the antenna. The marker that defines the top of the second arrives up there first, then spends the length of the feedline travelling down to the receiver. A receiver that treats when I saw it as when it happened ticks late — by exactly the delay of the cable, every second, forever.
The fix is to make the receiver anticipate. Knowing the delay, it can work out when the next top of second will occur at the antenna and emit its own tick at that instant — which is before it will see the corresponding signal arrive.
That is worth sitting with, because it inverts how people assume compensation works. It is not a correction applied after the fact. It is the receiver deliberately running ahead of its own input, by an amount you have to tell it.
Tell it wrong and it runs ahead by the wrong amount. That error lands directly in your offset from UTC and stays there.
Why it goes wrong even when everyone is competent
You may not have run the feedline. You may not own it. In a datacenter, quite possibly somebody ran it years ago on a work order, and did a perfectly good job by every standard that applied to them.
And here is the thing they would have had no reason to think about: for almost every cable in the building, length does not matter. Ethernet, fiber, power — you run what you need, within limits, and nothing downstream cares whether it was 12 meters or 30. That instinct is correct nearly everywhere. It happens to be wrong for exactly one cable in the room.
So the number is often unrecorded, because nobody recording it knew it was a number worth recording.
What actually matters is the delay, not the length
Worth being precise here, because the distinction turns out to be the whole practical problem.
The quantity your clock needs is the delay — how long the signal takes to get from the antenna to the receiver. Length is not that quantity. Length is one input to calculating it, and the other input is the velocity factor of the specific coax: the fraction of the speed of light at which a signal moves down it.
That fraction varies more than you might expect. Solid-polyethylene coax runs about 0.66; foam dielectric about 0.85. In delay terms:
| Coax dielectric | Velocity factor | Delay |
|---|---|---|
| Solid polyethylene | 0.66 | 5.05 ns/m |
| Foam | 0.85 | 3.92 ns/m |
Same length, and nearly 30% different delay.
Which is why “by length” is a trap
Here is the same clock, configured both ways. It offers a choice of compensation method:
Look at the ratio in both screenshots: 10 m ↔ 50 ns, 20 m ↔ 100 ns. Five nanoseconds per meter, fixed. That is a velocity factor of 0.66 baked in — a perfectly sensible default, and the correct one for solid-polyethylene coax.
If your cable is foam dielectric, its real delay is 3.92 ns/m. Configure 20 m “by length” and the clock applies 101 ns of compensation to a cable that actually delays by 78 ns. You have just introduced 23 ns of error while carefully entering a correct number.
Entering a length asks the equipment to guess your velocity factor. Entering a delay does not — it is the quantity that matters, stated directly, with no assumption in the middle.
The gold standard is to measure it
Everything up to here computes the delay. Better to measure it.
The instrument is a cable tester with a time domain reflectometer (TDR) function. It sends a pulse down the cable and times the reflection off the far end, which means it is measuring the actual delay of the actual cable — not a published velocity factor, not a length you estimated, not a service loop you forgot. Temperature, age, the connectors, the bit that got kinked during installation: all of it is in the answer, because all of it is in the cable.
You will probably have to disconnect the antenna at one end and your clock at the other, so this is a maintenance-window job rather than a five-minute one.
Many cable testers will happily report a length. To do that they have to assume a velocity factor — and now you are back in exactly the trap you bought the instrument to escape, with the assumption buried one level deeper where you cannot see it.
Take the reading in nanoseconds. The delay is the quantity that offsets your clock from UTC; the length was only ever a way of guessing at it.
While you are there, check whether the instrument is reporting one-way or round-trip time — a TDR measures a there-and-back journey, and different tools present that differently. A factor of two is a large error to inherit from a menu setting.
If you cannot measure it
Two things to look up, and neither needs test equipment.
The velocity factor comes from the coax manufacturer. Identify the cable type — usually printed on the jacket along with everything else — and look up its published figure. This is a datasheet lookup, not a measurement.
The length is often printed on the jacket too. Most coax carries sequential length markers every foot or meter, so for an installed run you can frequently read the marker at each end and subtract, without pulling anything. The cable has been telling you its length the whole time.
Add a little for the service loop you cannot see, be honest that it is an estimate, and remember the estimate is being multiplied by a velocity factor that is itself a published typical rather than a measurement of your cable.
What this is worth
A 30 m run misjudged by one velocity factor is about 34 ns. A run whose length is wrong by 3 m is about 15 ns. Both are large compared with the survey errors that occupy far more attention, and both are fixed by reading two labels and typing one number.
It ends in the same place as not letting the receiver survey itself: measure it if you can, look it up if you cannot, and configure the result. Do not accept a default and do not guess.
That is practice 4 of eight on the datacenter GNSS time best practices list, and the other seven are the same kind of cheap.