Topics In Timekeeping · What Is UTC

Can I build my own link to UTC(NIST)?

Updated Aug 12, 2026 • UTC, GNSS, timing, metrology, datacenter

Skip the details — take me to the bottom line ↓

A superb frequency reference, free. Not a time reference.

That is the honest one-line answer, and the gap between those two sentences is the whole page.

NIST sells a bundle — hardware, a common-view service, optionally a rubidium — as TMAS. The obvious question is whether the service is welded to the hardware. It is not: NIST publishes its observations the same way PTB and the Royal Observatory of Belgium do, and anyone with a receiver and a network connection can difference against them.

What NIST actually publishes

Two independent feeds, both free, neither requiring an account.

An IGS station whose clock is UTC(NIST)

NIST operates NIST00USA in Boulder as an ordinary IGS station. Section 6.1 of its site log is the sentence that matters:

Standard Type: EXTERNAL H-MASER. Input Frequency 5.0 MHz. Input signal is UTC(NIST). It is generated by an Auxiliary Output Generator (AOG) steered to UTC(NIST) from one of five H-masers in our ensemble.

That is the whole trick, and it is what separates a time-transfer station from a geodetic one. The receiver’s own clock is the laboratory’s realization of UTC — so its raw observations carry UTC(NIST) in them, and differencing against them is differencing against UTC(NIST) itself. PTBB and BRUX are set up the same way, which is why those two names come up constantly in time-transfer papers.

The receiver is a Septentrio PolaRx5TR tracking GPS, GLONASS, Galileo, BeiDou, QZSS and SBAS. Daily 30 s multi-constellation RINEX, about 4.7 MB, anonymously downloadable — no login — from BKG:

https://igs.bkg.bund.de/root_ftp/IGS/obs/2026/206/NIST00USA_R_20262060000_01D_30S_MO.crx.gz

CDDIS carries the same files but now wants Earthdata credentials. BKG does not.

The BIPM time-transfer tree

The second feed sits on the same server that publishes Circular T, under pub/tai/data/<year>/time_transfer/. About forty laboratories deposit CGGTTS tracks there and about sixty deposit PPP solutions, monthly, raw and BIPM-corrected. nist is among them.

Open NIST’s file and the header is a calibrated link laid open:

RCVR = PolaRx5TR (5.4.0)     LAB = nist      REF = UTC(NIST)
X = -1288398.600 m  Y = -4721697.050 m  Z = 4078625.450 m   FRAME = ITRF
INT DLY = 28.8 ns (GPS P1),  26.6 ns (GPS P2)     CAL_ID = 1001-2022
CAB DLY = 275.5 ns
REF DLY = 115.3 ns

Antenna coordinates to the millimeter, every delay term stated, and a CAL_ID naming the BIPM campaign that determined them. This is what a professional link looks like when it is not hiding anything.

We ran it, and here is what came out

Two results, from a single day of observations — 2026-07-25 — with both ends processed through the same correction stream so the datum cancels. Neither needed a calibration, and that is the point of both of them.

First, a check that the method works at all

Before differencing anything, run NIST’s own observations through the pipeline and look at what falls out. If the machinery is sound, the answer should look like a hydrogen maser, because that is what is clocking that receiver.

That is maser-class, which is exactly what a receiver clocked by UTC(NIST) should look like. It says nothing about our clock and everything about whether we can trust the next number.

Then the real one: two national timescales, differenced through us

Now do it twice — once against NIST, once against USNO — and subtract. What comes out is [UTC(USNO) − UTC(NIST)], computed entirely from public observations by somebody with no calibration and no standing whatsoever:

What we could not get is the number you would most expect: our own clock against UTC(NIST). Not for want of trying, and the reason turned out to be more interesting than the numbers above.

Why our own clock did not appear in the answer

A timescale is three things: the duration of one tick, an origin, and a count of ticks since. It is worth holding that definition in mind here, because a GNSS receiver never observes satellites against UTC. It observes them against a timescale of its own — it declares the origin, and it counts the ticks.

The question that decides everything is: where does the tick duration come from?

If the receiver has no external reference input, the ticks come from a TCXO soldered to its own board. Every pseudorange, every carrier phase, every PPS edge is timed against that oscillator. So when we solved for the receiver clock and differenced it against UTC(NIST), what we measured was the offset of a free-running TCXO — not the disciplined oscillator we actually care about. The disciplined oscillator is steered separately and does not appear in the raw observations at all.

That distinction is the difference between a receiver that wants to be your clock and one that expects you to have one, and it is the reason the numbers above stop where they do. Redoing this measurement on an externally clocked receiver is a different experiment, and it deserves its own page rather than a footnote on this one.

What common view gives you for free

Common view is the oldest trick in time transfer and still one of the best. Two stations observe the same satellite at the same moment and each records the difference between the satellite’s signal and its own clock. Subtract the two records and the satellite’s clock error — which both stations saw identically — vanishes exactly.

You are then no longer relying on the satellite to know what time it is, which is the single largest term in an ordinary GNSS timing solution. Everything the satellite got wrong is common-mode and cancels.

The gate: your end is not calibrated

Here is where the free path stops, and it is worth being exact about why, because the reason is not obvious and it is not about software.

Common view hands you stability for nothing. It hands you accuracy only if the delays are known at both ends. Look again at NIST’s header and notice the magnitudes:

Those are not small corrections. They are hundreds of nanoseconds of pure systematic offset, and NIST knows theirs because the BIPM measured them. You do not know yours. Guess them and you get a measurement that is beautifully stable, perfectly repeatable, and wrong by an amount you cannot state — which is precision without trueness, the exact failure the metrology section exists to name.

How the professionals get the number

By physically carrying a calibrated receiver to the site. BIPM’s calibration campaigns take a “golden reference” travelling system, co-locate it with the station under test, run both for weeks, and difference them. The published report for campaign 1001-2022 gives the resulting uncertainty as uCAL(P3) = 0.9 ns, built up from — these are the largest contributors, not the whole budget, which is why they do not sum to the total on their own:

Two things leap out of that table. The first is that a sub-nanosecond link is achievable and somebody has done the work to prove it. The second is more useful to you: even in a professionally executed calibration, the largest single uncertainty is the antenna cable — which is precisely the argument the feedline page makes from the other end. The people who are best at this still find the wire is the hard part.

You cannot download a travelling receiver. But the door is not actually closed, and the section below is about what it costs to walk through it.

And this is the point at which the choice of technique stops mattering. A calibrated end is what turns any of these links into a number you can defend — common view, all-in-view, or GPS PPP time transfer alike. Pick the technique on its merits; the wall is in the same place for all three.

What a home calibration actually resolves into

The clearest published worked example on mass-market hardware is Ricardo Píriz’s at GMV, who calibrates timing receivers against GMV’s own UTC realization. He measured a 96 ns total offset between a u-blox ZED-F9T’s timepulse and UTC on a Keysight 53230A time interval counter over 24 hours, and took it apart:

We had calibrated beforehand the delay of the antenna (16 ns) and the delay of the 10-meter antenna cable (52 ns). This leaves a delay of 28 ns for the F9T device.

His later and more rigorous method removes any dependence on the stability of UTC or GPS time by subtracting a co-located calibrated receiver’s CGGTTS from the counter reading — TIC − CGGTTS = D. That gives 93.9 ns total for the F9T and 77.9 ns for a Septentrio mosaic on the same antenna, with day-to-day repeatability of 0.3 ns and 0.28 ns respectively. The 16 ns between those two totals is the difference between the two receivers — an unrelated quantity that happens to share a number with the antenna delay above, and the two should not be read as connected.

So could you calibrate everything except the antenna?

The natural next thought, and the answer is more encouraging than the question assumes — but the encouragement is in a different place than you would expect.

With Píriz’s method you never have to separate the antenna out at all. The quantity TIC − CGGTTS = D is the delay of the whole chain as one number — antenna, cable and receiver together. The 16 / 52 / 28 decomposition exists only because he wanted to publish a receiver figure other people could reuse. If all you want is your own chain calibrated, the lump is the answer, and the antenna term never has to be prised out of it.

So the antenna is not the obstacle. The obstacle is the reference: the method needs a calibrated time-transfer receiver on the same antenna, running alongside yours. That is the travelling receiver in cheaper clothes, and it is still the thing you cannot download.

Two more things TMAS sells that are not the measurement

Latency. The BIPM files are monthly batches published weeks after the fact. TMAS uploads every ten minutes and you read the answer in a browser. If you are disciplining a clock in real time, the public route is useless to you; if you are calibrating a frequency standard or auditing last quarter, it is entirely adequate. Know which one you are doing.

The report. Traceability cannot be self-issued. However good your measurement, the deliverable an auditor wants is a calibration report with a national metrology institute’s uncertainty on it, and that is a document, not a number you computed yourself.

So what is the free path actually good for?

More than the above might suggest, and the split is clean enough to state as a rule: you get frequency at full accuracy, and you do not get time at all.

The reason is not that anything cancels. It is that offset and rate are orthogonal — two genuinely independent ways for a clock to be wrong, measured by different arithmetic. An unknown constant delay is an error in where the origin sits. A frequency measurement asks how fast the ticks come, and never consults the origin at all. A fixed 300 ns you cannot account for ruins your claim about what time it is and has nothing to say about how fast your clock runs — not because it was removed, but because it was never one of the terms.

That single fact makes a home-built link genuinely valuable:

• Frequency calibration against UTC(NIST), at full accuracy and no cost. The delay you do not know is not in this measurement. This is the strongest thing on the list and the one most people miss.
• Long-term stability and holdover characterization of your own standard, against a reference that is not your own GNSS receiver — which matters, because a receiver cannot audit itself.
• Step detection. If your offset from UTC(NIST) jumps 40 ns one Tuesday, something in your installation changed. The absolute value being unknown does not stop the change from being obvious.
• Checking a vendor’s number without taking their word for it.
• A second opinion on your antenna position, since a PPP solution from the same observations is the recommended fix for letting a receiver survey itself.

And what it is not good for: any sentence beginning “we are traceable to”. That sentence has to be bought.

What you get free, and what you have to buy

• Frequency: free, and at full accuracy. Nothing is missing from this number. Calibrate a standard, characterize its holdover, check a vendor’s claim — all of it works today, on public data, with no permission from anybody.
• Time: not at any price you can pay yourself. Your delays are unknown, and an unknown constant ruins an offset while leaving a rate untouched. This is not a software problem and no amount of processing fixes it.
• You can still monitor what you cannot claim. A step in an uncalibrated link is a step in your hardware. If the offset jumps 40 ns on a Tuesday, something changed on Tuesday, and not knowing the true value never mattered.
• Copying a published calibration gets you started, not finished. Reproduce a chain somebody documented and you inherit their 1–2 ns floor plus an unmeasured per-unit term — our own bench found two nominally identical receivers further apart than two different models. Better than a guess. Not a calibration.
• Traceability is a document, not a measurement. It cannot be self-issued at any level of skill. That is what a service like TMAS actually sells, alongside ten-minute latency the public files will never match.

So: build it. Then use it for the half that works, and buy the other half if somebody outside your organization has to accept the answer.

Where to go next

• Comparing distant clocks — the survey this page is an attempt at: common view, all-in-view and PPP time transfer, why BIPM retired the first, and where TMAS sits as the commercial example.
• Choosing a GNSS timescale for syncing datacenter clocks — where TMAS sits among the alternatives, and why it is a different kind of answer from the other three.
• What “traceable to UTC” actually requires — the paperwork problem this page keeps running into.
• An uncalibrated antenna feedline is likely your largest source of error to UTC — the 0.5 ns that dominates even BIPM’s own error budget, and the hundreds of nanoseconds it becomes when nobody measures it.