Your Starlink as a local stratum 1 time server
An existing dish offers a local time source. We investigate what ordinary WiFi can deliver, what beacon timing adds, and where a cable or a better-disciplined access point could take it.
If you already have Starlink, you may already have the most expensive part of a local time source installed outdoors. Starlink documents a GPS-based NTP server at 192.168.100.1. A local client can ask the terminal for time without sending that NTP query to an internet time server over the satellite link. The service is best effort, with no accuracy guarantee.
That is an appealing starting point for a workshop, home lab or remote installation. We wanted to know how far inexpensive client hardware could take it: first with ordinary NTP, then with the fine clock information already present in WiFi beacons. The results make a useful local source worth investigating, while showing why a stratum number and a smooth timing display are only the beginning.
Start with the time server you already own
Our first capture accepted 37 NTP replies, all reporting stratum 1. Their round-trip delays ranged from 3.289 to 26.439 ms. Stratum 1 identifies a primary server in the NTP hierarchy; it does not certify a particular error at your computer. A host synchronizing to that server normally becomes stratum 2. If it serves other machines, those clients add another level.
For an existing chrony installation, the basic source entry is:
server 192.168.100.1 iburstThis is a source entry to add to an appropriate existing configuration, not a complete server setup. Check that the terminal is reachable from your LAN, record its reported state and compare it with other references. iburst speeds initial acquisition; it does not provide the custom beacon estimator used below. There is no reason to force a stratum number or turn on chrony’s unrelated local stratum option.
Keeping other suitable time sources gives you a cross-check when the terminal changes state. We have not qualified this installation through loss of GNSS, WAN outages or every router mode, and have not established its authentication capabilities. A local address alone does not establish trustworthy time.
The second clock hiding in WiFi beacons
An access point regularly broadcasts a beacon containing its Timing Synchronization Function, or TSF, counter. That gives a compatible receiver an observation of the AP’s local clock. It does not, by itself, say which UTC second that clock represents.
We used an ESP32-S3 W12 with driver receive-event timestamps and power saving disabled. A model built from earlier beacon/receive pairs predicted each new observation before adding it to the fit. This avoids treating a late software callback as the radio event.
In the roughly ten-minute beacon experiment, 5,858 logged observations gave 0.409 µs relative prediction RMS, 0.969 µs absolute P99 and a 1.346 µs maximum. All 40 residuals above one microsecond remain. A separate fit using software callback time had 5.427 µs RMS: the timestamp path matters.
Those are local predictive residuals, not UTC accuracy. The capture also missed one raw record among 5,859 accepted sample numbers, so its strict no-gap gate failed. Independent replay reconstructed 5,602 predictions; 256 logged rows lacked complete prior history. Neither those gaps nor fixed delays disappear because the fit looks good.
The experiment showed that beacons carry useful fine clock information. It did not show that the AP was GPS-disciplined. The terminal’s NTP clock, the AP counter and the client’s counters are different observable clocks, and their physical relationships remain unresolved.
What to expect over WiFi, with and without tuning
For an ordinary software NTP client on an uncharacterized WiFi link, our conservative planning estimate is a sub-millisecond to few-millisecond budget, allowing larger excursions under load. That is an engineering allowance, not a measured stock-client result or a Starlink specification. In the later runs, individual accepted NTP observations had about 3.9–4.6 ms residual scatter. A disciplined client can average noisy observations, but averaging cannot identify a constant one-way delay bias.
Practical tuning starts with a steady client, a clean radio path, sensible polling and a mature clock discipline. Compare quiet and busy periods, investigate power saving and avoid changing several settings at once. Shorter polls can track drift sooner, while longer averaging suppresses noise; the right balance depends on the clock and link. Our custom path additionally needs receive-event timestamp access that ordinary phone and laptop apps may not expose.
Our paired follow-up used 900 seconds of training followed by 900 seconds of evaluation in each of two runs. The NTP-only control was already tuned: an AP-free, 900-second weighted least-squares local-clock estimate, called WLS900. The hybrid combined NTP with AP clock information and a robust filter. These were not default chrony versus tuned chrony tests.
Each method first received its own fixed, GNSS-measured phase correction. With that prior correction, the same 900 future PPS witnesses per run gave:
| Run / method | RMS (µs) | Abs. P99 (µs) |
|---|---|---|
| R1 · NTP only | 37.180 | 67.329 |
| R1 · NTP + beacons | 19.226 | 43.079 |
| R2 · NTP only | 35.662 | 54.767 |
| R2 · NTP + beacons | 8.240 | 20.069 |
The hybrid improved RMS in both runs. In the first, that gain came from lower bias while centered scatter slightly worsened; the second improved both. Ordinary AP fits and servos had mixed results. Two windows on one boot are encouraging observations, not a general performance distribution.
The calibration qualification changes what an owner should expect. Without the prior GNSS phase correction, NTP-only raw phase RMS was 224.160/226.778 µs, and hybrid raw phase RMS was 217.046/218.521 µs. These raw values are observations of this setup, not a portable UTC bound either. Reproducing the tens-of-microseconds corrected results requires measuring the client/path/model phase base; it cannot simply be copied to another installation.
GNSS supplied that phase base and the validation witness, never frequency training. No future recentering or detrending improves the scores. Complete 900/900 scoring does not establish continuous service availability. The continuously updated models retain a 60-second source lease; a good frozen-clock forecast does not extend it. Earlier failed and incomplete experiments remain in the paper.
What a cable could change
Ethernet should remove WiFi contention, retries and radio power-save effects from the client path. It can also support better packet timestamping. It cannot remove a biased server timestamp, a terminal clock error or asymmetric delay elsewhere in the path.
Our wired estimate, still untested on this Starlink installation: a quiet wired software client could plausibly make tens of microseconds of relative clock agreement a useful first target, with roughly 10–100 µs as an initial engineering target band, rather than a predicted RMS or P99. Improvement could be small if the terminal’s timestamping or clock dominates. We would not promise a corresponding absolute UTC result, or a fixed improvement factor over WiFi.
There is precedent for substantially better Ethernet time transfer when the server, client and timestamp path are designed for it. Chrony’s independently measured wired examples show about 2 µs stability with a roughly 5 µs bias in one software-client setup, and much finer transfer with hardware timestamps at both ends. Those are different systems. A capable client NIC alone does not give a Starlink terminal a calibrated hardware-timestamped NTP service.
The useful next test is the same terminal with WiFi and Ethernet clients, fixed calibration, matched quiet/load windows and an independent PPS reference. Retain RMS, P99, maximum, gaps and recovery. Then we can replace the target band with a result.
How SpaceX could make the AP a better clock
The opportunity is to connect two things already present in the installation: a GPS-based terminal time source and frequent AP beacon events. We have not established how SpaceX currently relates those clocks. The following is a proposed design, subject to the hardware exposing suitable timing signals.
First, carry the terminal’s reference into the router with a measured clock bridge: hardware-timestamped exchange, a PPS connection where available, or another calibrated cross-timestamp path. Reading a software clock occasionally would leave unknown delay in that transfer.
Second, gently discipline the AP oscillator or maintain a continuously tracked mapping from its TSF counter to reference time. Preserve WiFi synchronization semantics rather than arbitrarily stepping TSF to a UTC epoch. Correcting a constant frequency difference is not enough; the system must track wander and recognize resets.
Third, expose that mapping to capable clients, tied to the actual MAC transmit event. It needs a reference epoch, offset/rate relationship, uncertainty, age and a clear reference-loss/holdover state. NTP can remain the broadly compatible entry point while fine-event metadata serves clients that can capture it. The terminal’s NTP receive/transmit timestamp path deserves the same calibration attention.
That could let frequent beacons carry the pace of a referenced clock while a slower exchange establishes its time coordinate. Our 0.409 µs relative beacon residual makes microsecond-class transfer a worthwhile research target for such a design; it does not supply the missing UTC calibration, client independence or physical-output measurement.
For an owner today, the inexpensive first step is to evaluate the NTP service already in the dish. For us, the next step is to measure what survives the complete terminal-to-AP-to-client chain. A disciplined AP could make that chain much more useful without putting a separate GNSS antenna beside every indoor device.