From spare radio boards to a precision time mesh.

How much timing precision is already sitting unused in a small radio board?

PToB started by repurposing boards bought for Meshtastic and MeshCore into precision grandmaster clocks. They offered an inexpensive starting point: a microcontroller, radios and, on suitable boards, a GNSS receiver with a pulse-per-second signal. The question was how far careful engineering could take that hardware.

We are applying advanced AI techniques to accelerate design, implementation and evidence analysis. The aim is to push clock synchronization on inexpensive hardware through an open protocol adaptable to many devices. Physical measurements decide which ideas survive.

The results are pushing the timing precision we can extract from inexpensive hardware, opening opportunities for sensors, instruments and robotics. We want to share the code, methods and evidence openly so others can reproduce the work and extend it.

Start with hardware people already have

The nRF52-based Heltec T096 became a practical grandmaster and receiver platform. We also want full support for the ESP32-based Meshnology W12, extending its existing receiver and experimental relay work into a broader set of clock roles. The hardware guides distinguish what each target currently supports.

Other GNSS/PPS-equipped devices belong in that exploration, including the LILYGO T-Watch Ultra. An accessible PPS signal makes a board interesting; capturing it accurately, associating it with the correct second and qualifying its clock behavior are the work of a port. Support for these additional roles and devices is a goal, not an existing compatibility promise.

From a grandmaster to a rooted mesh

A single clock became a larger problem: how do you distribute its time through several devices while retaining a verifiable account of where that time came from?

PToB builds on Precision Time Protocol ideas: timestamp a defined event, carry follow-up information and track the relationship between clocks. A Software PLL estimates offset and frequency drift between heterogeneous devices. Frequency error continues to accumulate between updates, so maintaining that relationship matters as much as setting the initial time.

Today’s BLE timing mesh is rooted. Receivers follow a selected source, and relays preserve its origin and path. That makes source identity, loops, stale information and changes of parent part of the timing problem. Multi-master support adds another challenge: available grandmasters must coordinate without competing roots silently giving receivers different meanings of time. The architecture paper explains the current approach and its limits.

Measure the clock a receiver actually has

A receiver can report a small fitting error while still having an offset against an external reference. We use shadow PPS to examine that difference: capture a reference pulse and evaluate the receiver’s already-published BLE clock at that instant. The comparison pulse observes the clock; it does not train that BLE clock model.

The nRF52 relay measurements and current W12 ESP32-S3 baseline show sub-microsecond relative timing on specific paths. The seconds-to-nanoseconds guide puts these intervals in context. Observation counts, tails and gaps matter alongside RMS. These comparisons do not, by themselves, establish calibrated UTC accuracy. Future posts will unpack how we measure offsets and what each measurement can tell us.

Parallel timing paths

We have already introduced LoRa as an additional timing-delivery path. The next step is to investigate how two methods can check and complement one another, rather than treating the second radio only as a fallback. Current LoRa work is functional and experimental; it does not inherit the precision measured on BLE.

Further candidates include Wi-Fi fine timing measurement, including 802.11mc, and eventually UWB. These offer ways to investigate propagation delay and timing alongside BLE. Ranging capability alone does not provide a synchronized clock. Each path needs its own timestamp model, calibration and uncertainty—and two radios sharing one source are still sharing that source’s errors.

Toward a blended multi-master ensemble

The longer-term goal goes beyond following one selected PTP-style root. Each grandmaster would create a timing stream while listening to the others. The mesh could then estimate a blended time from several clocks, accounting for their quality, uncertainty and common dependencies.

That could improve stability and support holdover when a reference disappears or becomes unstable. It also creates difficult questions: which sources are independent, how should a changing clock be weighted, and how do you prevent a clock from indirectly averaging its own time back into itself?

This ensemble is planned research. It must preserve source provenance, reject faulty inputs and expose growing uncertainty during outages. A blended clock would still need independent validation; averaging cannot remove a bias shared by every contributing source.

Nordic precision, broader hardware

We particularly enjoy Nordic’s hardware timing support. On nRF52, radio events can capture a timer through peripheral interconnects without waiting for a software callback. It is a strong foundation for precise timestamps. We have also extended many of these methods into ESP32, where controller-to-counter mapping and event capture require different techniques.

The nRF54 family is a future PToB target. We want to explore its oscillator-tuning controls and Bluetooth Channel Sounding capabilities on supported parts. Whether those features improve clock discipline or delay estimation is something to establish experimentally, not assume from a radio specification.

Across PTP environments

We also want to extend time between wired PTP environments, across profiles and out to wireless devices. The gPTP/PToB robotics paper sets out one direction. A useful bridge must preserve the meaning of the time it carries, including its domain, rate, source and uncertainty; forwarding a timestamp alone does not establish interoperability.

That is the programme ahead: broader hardware support, parallel timing methods, carefully measured bridges and, eventually, a blended multi-master ensemble. This blog will follow the engineering decisions and experiments behind that work, with the research and evidence available for closer inspection.