ESP32 holdover: a minute below one microsecond
Frozen software clocks on ESP32 reached a minute below 1 µs at sampled P99. Next, we want to learn how temperature history could improve their predictions.
A precision clock gets interesting when its reference disappears. A low synchronization error tells us how well it follows; holdover tells us how long its own prediction remains useful. For inexpensive ESP32 hardware, crossing a minute below one microsecond would make short radio interruptions a much more manageable timing problem.
Our W12 experiments have reached 64 seconds below 1 µs at sampled P99, using frozen software clocks checked against later BLE observations. The inspiration comes from the microcomputer-compensated crystal oscillator, or MCXO: learn enough about an oscillator to predict its behavior. Commercial MCXOs use specialized resonator thermometry and compensation. We are exploring what can be learned with the crystal and counters already on an ESP32-S3 board.
A minute on a frozen clock
While BLE time is available, W12 learns its local clock’s rate. At hold entry, it freezes the selected rate and phase. Rate selection uses only observations already received; future packets cannot improve that prediction retrospectively.
For the experiment, offset copies of the clock keep running while the normal receiver continues synchronizing. Later BLE packets become witnesses: they check each frozen copy without correcting it. At each tested age, we retain that run’s worst sampled absolute error so far. P99 then describes those per-run maxima. A good final sample cannot erase an earlier crossing.
The fully replayed 64-second window contains 128 prefixes, with P99 760 ns and maximum 879 ns. A separate fixed cohort of 128 mature runs passes through 75 seconds at P99 983 ns, then fails at 76 seconds. That finer analysis uses its own population; it does not extend every rolling display result to 75 seconds. Both devices’ later rolling windows ended at 24 seconds.
These overlapping runs share clock history. They measure agreement with received BLE time during normal operation, with gaps and unknown outcomes retained. They establish neither continuous accuracy between witnesses nor independently calibrated UTC or electrical output. A deliberate reference outage and physical grandmaster transition remain separate experiments.
Capture the thermal history first
Temperature is an obvious suspect when a learned rate stops predicting well. It is also easy to compensate the wrong thing. The ESP32-S3 sensor measures silicon temperature; the quartz can follow a different temperature and lag. An earlier thermal-correction trial reached 3.663 µs maximum error against 362 ns for its paired baseline. Production HOLD now uses BLE rate alone; temperature learning runs in shadow, making predictions without steering the delivered clock.
Our next step is a compact temperature-and-rate history for longer experiments. The proposal pairs one-second sensor observations with trained BLE frequency estimates, retaining variation, their relationship and missing-data counts. Half-hour summaries would keep storage small while preserving boot and source changes. Persistent collection is still planned, with flash-write timing and recovery checks required before enabling it.
We want warming, cooling and workload changes across several boards, followed by validation on runs the model has never seen. A useful thermal model must improve frozen-clock predictions and their tails, including recovery. A neat temperature curve alone will not earn a place in the clock.
What an external DS3231 could add
An external DS3231 offers a temperature-compensated oscillator and battery-backed calendar. Its specified ±2 ppm from 0–40 °C corresponds to 120 µs of drift in a minute at that frequency error. Sub-1 µs over 60 seconds needs roughly 17 parts per billion of residual rate error, even with perfect starting phase. The datasheet alone cannot promise that.
It could still provide useful longer-term continuity and another oscillator to characterize. We would capture its square-wave edges in hardware, learn phase and frequency against the live reference, then measure prediction through outages. Timestamping I²C calendar reads would introduce another timing path to characterize. Aging trim and calibration may improve an individual unit, but short-term noise, thermal changes and capture delay need measurement. We have no DS3231 holdover result yet.
Holdover in a multi-master mesh
Holdover also belongs in our future multi-master grandmaster strategy. A receiver tracking several streams could bridge a brief loss using its local prediction while evaluating the remaining sources. Each contributor’s measured stability, observation age and transported uncertainty would help determine its weight.
Shared references and recirculated timing cannot count as independent clocks. A good local prediction also cannot renew expired source authority. The aim is useful continuity with visible limits: learn while references are healthy, measure how predictions age, and let that evidence decide how long each clock deserves to contribute.