PToB applies Precision Time Protocol (PTP) principles to BLE-enabled MCUs, using radio-event timestamps and follow-up data to synchronize clocks across wireless devices.
Sub-100 ns PPS-shadow RMS.
Sub-microsecond internal prediction RMS.Results depend on the MCU’s timing path.
The grandmaster broadcasts a time reference to receive-only listeners; no pairing is required.
Illustrative topologyPublic reception · Receive time without pairing.
Time mesh · Preserve source identity across hops.
GM elections · Select an authorized time source.
A receiver records the physical arrival of a time broadcast. Follow-up data identifies when the original event left the source, allowing the receiver to estimate clock offset and drift. The timing path and calibration determine the precision each device can achieve.
A time source publishes an event over BLE.
A capable receiver timestamps the physical radio event.
Follow-up data identifies the original transmit instant.
The receiver disciplines its own clock to the source.
Basic scanners can use the broadcast time. Higher precision requires hardware timestamps and a calibrated clock model.
The two implementations use different timing paths: physical radio-event capture on Nordic’s nRF52840, and controller-to-timer mapping on ESP32-S3. The results below name the reference used to measure each one.
Physical radio events provide the timestamp reference, with a fixed edge correction trained before validation.
Controller timestamps are mapped into a local timer to predict the shared clock between received events.
A PPS-shadow measurement checks the receiver’s already-published BLE time at a separately captured pulse-per-second (PPS) reference edge, using the same hardware counter. That reference is used for validation and does not train the BLE clock.
T096 results are uncentered PPS-shadow RMS from two approximately 600-second validation runs, using a fixed edge correction trained before validation. ESP32-S3 results are internal published-prediction RMS across all 359 targets in the documented normal 600-second run.
RMS is not a worst-case bound or absolute UTC certification. The ESP32 run includes a 1,010 ns maximum error and periods without fine clock publication. Independent electrical-output accuracy, cold start, source transitions, and operating conditions require their own measurements. These values describe the named device configurations, not every BLE receiver or mesh path.
Compare reported timing results and protocol availability across the BLE synchronization research cited in our papers, including Nordic’s proprietary timeslot reference design.
| Approach | Transport & hardware | Reported precision | Measurement & conditions | Protocol / standard |
|---|---|---|---|---|
| Nordic timeslot demo2016 | Proprietary radio timeslots100 Hz · no competing stack in the cited test | 65.6 ns Mean GPIO differenceSD 41.0 ns · max 220 ns | Logic-analyzer GPIO comparison30 minutes; 439,445 toggles. Two nearby nRF52 development kits. | Open reference codeVendor demo using proprietary timing packets; no standardized BLE time service. |
| PToB · T096This project | Passive BLE advertisingNordic nRF52840 · fixed edge correction | 70.2–76.4 ns Uncentered RMSMAE 57.3 / 60.4 ns · SD 69.3 / 72.5 ns · P99 158 / 219 ns | PPS-shadow referenceTwo ~600 s validation runs; 600/600 and 598/599 PPS observations. GPIO output not independently measured. | Public protocol proposalPTP-inspired service contract, profiles, and wire format. Not an adopted standard. |
| MicroSync2024 | Connected BLEnRF52840 · central + three peripherals | 272 ns Mean absolute errorSD 319.2 ns · 99% CDF 591.25 ns · RMS not reported | External GPIO comparison · 800 MHzHigh-accuracy scheduling. Bidirectional exchanges and PA/LNA timing signals. | Published research protocolBLE connection transport. Synchronization and scheduling described in the paper. |
| PToB · ESP32This project | Passive BLE advertisingESP32-S3 · controller-to-timer mapping | 319.5 ns Internal prediction RMSMAE 244.5 ns · P99 930 ns · max 1,010 ns | Internal published prediction600 s normal run; all 359 physical targets. Fine clock publication has gaps. | Public protocol proposalThe same PToB service contract on a different hardware timing path. |
| BlueSync2021 / 2022 | Connectionless BLE beaconsHardware event capture + follow-up timestamps | 320 ns Average sync error per 60 sBest reported setting · single hop | Two commercial BLE SoCs10-minute sessions without resynchronization. Drift-management and packet settings vary. | Published research protocolBLE beacon transport. Timing and drift-management methods described in the paper. |
| CheepSync2015 / 2016 | BLE advertisingnRF24Cheep broadcasters · Android listeners | ~10 µs Average single-hop accuracyLow-level timestamps and error compensation | Advertiser-to-listener experimentsHeterogeneous passive listeners on resource-constrained hardware. | Published research protocolBuilt on Bluetooth 4.0 advertising. Timing service described in the paper. |
Rows are ordered by the displayed timing value. RMS, mean absolute error, standard deviation, and mean GPIO difference are distinct statistics measured under different test conditions. The studies do not establish a matched output-accuracy or energy benchmark. BLE transport alone does not define a standardized time service.
Read the comparison methodsWhen devices timestamp an event against a common clock, their observations can be compared even if the messages arrive at different times.
Use a shared time reference to correlate readings from environmental sensors, clocks, and event recorders without pairing each device or adding timing cables.
A future gateway could carry a wired PTP reference to wireless sensors and portable instruments, preserving source identity and accounting for uncertainty along the path.
Shared timestamps could align cues and recordings from compact production gear. Adapters would need to map frame rates and time scales; genlock requires a separately qualified output.
Timestamps on a common clock could help correlate samples from wearable and bedside sensors. Power, reliability, and clinical validation must be established for each medical application.
Download the current protocol proposal for service profiles, timestamp semantics, and mesh forwarding, or the research paper for calibration methods and device measurements.
Service profiles, timestamp semantics, authority admission, and mesh forwarding.
Physical-edge calibration, clock synchronization, and measured device performance.
These editions are dated 2 October 2026. The source repository is planned for release on GitHub after cleanup.
Jonathan Yantis leads hardware development, protocol design, and research, with GPT 6.1 contributing to implementation, analysis, and documentation.