# PToB — Precision Time over BLE > Sub-1us MCU time transfer over Bluetooth and USB; Software PLL clock discipline between heterogeneous devices. LoRa time transfer is a separate experimental fallback, with sub-1us performance unqualified. Jonathan Yantis leads protocol design, hardware development and research; GPT 6.1 contributes implementation, analysis and documentation. PToB is an independent public proposal, not an adopted Bluetooth SIG or IEEE standard. ## Start here - [Project overview](https://ptob.dev/): Mechanism, separate MCU measurements and research papers. - [Deployment guide](https://ptob.dev/deployment/): One, two or three T096 grandmasters; ACTIVE/HOT/COLD roles; RC1/RC2 relay clocks and RC3 receiving leaves; separate experimental LoRa fallback; RC/DC USB time transfer to macOS. - [Hardware guide](https://ptob.dev/hardware/): Target capabilities, operating roles, displays and measured references. - [Research results](https://ptob.dev/research/): Dated measurements, methods, coverage, limits and public sources. ## Deployment scenarios - [Share a reference with nearby devices](https://ptob.dev/deployment/?scenario=single#explore): Begin with one qualified T096 grandmaster and receivers in direct radio range. Each receiver disciplines its own local clock from the broadcast timing. One source has no standby. Losing usable reference time can interrupt valid timing at every dependent receiver. - [Establish an ACTIVE / HOT pair](https://ptob.dev/deployment/?scenario=pair#explore): Place two independently GNSS-capable GMs in direct radio range. One serves as ACTIVE; the other becomes HOT only after source, synchronization, readiness and successor-grant checks pass. Two GM-capable clocks are not two sources to average. Durable failover and uninterrupted timing remain unqualified. - [Keep a third candidate at the center](https://ptob.dev/deployment/?scenario=triple#explore): Add the third GM after the ACTIVE/HOT pair is established. It normally remains COLD, receiving timing while continuing its own local GNSS qualification. COLD is not a second HOT. Independent references and failure modes determine source diversity; an extra GM does not guarantee continuity. - [Extend outward from a redundant core](https://ptob.dev/deployment/?scenario=relays#explore): Keep the GM group together and place relay clocks between it and remote receivers. RC1 and RC2 discipline local clocks and originate new downstream timing events. Clients following RC2 remain leaves. RC3 here names the receiving tier, not another supported relay stage. Each extra link needs its own measured uncertainty and recovery evidence. - [Keep a separate estimate over LoRa](https://ptob.dev/deployment/?scenario=lora#explore): An optional, configured LoRa transmitter distributes local GM time or its accepted BLE source. Compatible receivers keep that input separate and prefer BLE while it is usable. LoRa total uncertainty and passive freshness remain unknown. This fallback grants no RC7 publication, GM promotion or USB source authority. RF range is deployment-specific. - [Bring the clock into a macOS application](https://ptob.dev/deployment/?scenario=usb#explore): Use a T096 RC to bring mesh time to USB, or a dedicated T096 DC image for local GNSS-to-USB time. Both feed the same macOS client and its private chrony user clock. The normal GM backend does not publish a USB source map. The default client leaves the OS clock unchanged and does not serve LAN time. Absolute UTC accuracy remains unqualified. Current operating guidance was reviewed on 22 October 2026 against the T096 0.15.164 checkpoint and RC7 target guides. A topology illustration does not measure RF latency, operating range, timing error or uninterrupted service. Each relay originates a new timing train and retains the original root; RC3 clients do not add another transmitting relay stage. ## Measurements and source data W12 ESP32-S3 delivered BLE time measured 60.3 ns relative-PPS RMS across 522/600 observations on 24 October 2026, including a source-transition gap. Its stable 300/300 window reached 38.3 ns RMS. Downstream relay and sampled TX results retain their separate denominators and tails. The earlier T096 one-relay result remains 62.504 ns PPS-shadow RMS across 436/602 usable/nominal boundaries. - [W12 ESP32-S3 PPS and relay baseline](https://ptob.dev/research/#w12-utc-basis): 24 October 2026; W12 0.2.10 / T096 0.15.169. W12: 60.328 ns RMS including bias, 522/600 eligible, 78 unavailable, max 180 ns. Stable second window: 38.312 ns RMS, 300/300, max 121 ns. Downstream PPS: 61.922 ns RMS, 451/600, max 211 ns. Sampled TX: 108.306 ns RMS, 58/120 scored, 61 missing matches, one lacking PPS brackets, max 226 ns. Zero nominal PPS log gaps. RF, GPIO and absolute UTC remain unqualified; full timing gate open. [Evidence and offline verifier](https://github.com/yantisj2/PToB/tree/main/evidence/s3/2026-10-24-w12-utc-basis). - [One-relay PPS-shadow result](https://ptob.dev/research/#t096-relay): 2026-10-12, native 0.14.43, T096 GM → T096 relay → T096 receiver. RMS including bias 62.504 ns; 436/602 usable/nominal boundaries (72.425%). This historical one-intermediary experiment is separate from current firmware and physical two-relay precision. - [PPS-shadow observations (CSV)](https://ptob.dev/data/t096-v14-one-relay-20261012.csv): All 504 observed edges, including invalid-reference and map-unavailable records. Preserve all validity fields and the 602 nominal-boundary coverage denominator. - [Original public evidence](https://github.com/yantisj2/PToB/tree/main/evidence/v14/2026-10-12): Method, calibration, observation gaps and V14 evidence provenance. - [Timing results (JSON)](https://ptob.dev/results.json): Three direct 2 October configurations plus separate 12 October T096 and 24 October W12 PPS/relay records; references, units, denominators and limits. - [USB/macOS findings](https://ptob.dev/hardware/#macos-results): Experimental private chrony user clock and causal USB frame mapping. Estimator RMS and shared-source agreement do not establish absolute UTC accuracy. ## Research papers - [PToB Viability: Rooted BLE Timing Meshes for Heterogeneous Edge Networks](https://ptob.dev/papers/ptob-viability-preprint.pdf): A whole-system assessment of rooted BLE timing, hot standby, heterogeneous relays and macOS, with scaling and power tradeoffs and a future PTP edge bridge. - [V14 protocol proposal](https://ptob.dev/papers/ptob-v14-sig-proposal.pdf): Passive time profiles, authenticated grandmaster coordination, and boundary-clock relays. - [Earlier protocol proposal, 2 October 2026](https://ptob.dev/papers/ptob-proposal.pdf): Historical version; retain its evidence date and measurements. - [V14 research paper](https://ptob.dev/papers/ptob-v14-preprint.pdf): The path to V14, one-relay PPS-shadow results, hardware timing limits, and remaining validation. - [Earlier research paper, 2 October 2026](https://ptob.dev/papers/ptob-preprint.pdf): Historical version; retain its evidence date and measurements. - [Beyond USB Packet Arrival: Frame-Identified Time Transfer to macOS](https://ptob.dev/papers/usb-macos-time-transfer-chrony-20261015.pdf): A macOS user-level chrony clock: 23–339 ns settled estimator RMS, 414 ns shared-source agreement and 328 ns causal USB prediction, with explicit availability and calibration limits. - [A Shared Time Base for Robotic gPTP and TSN Systems](https://ptob.dev/papers/ptob-gptp-tsn-robotics-preprint.pdf): PToB at the edge of wired robot timing: a proposed shared time base, compatibility boundaries and a staged validation programme. - [From Virtual Clock Discipline to Physical Synchronization: White Rabbit Lessons for PToB and Future Tunable Targets](https://ptob.dev/papers/white-rabbit-study-20261015.pdf): What PToB already implements, calibration gaps, and a White Rabbit-inspired roadmap for tunable oscillators and physical clock control. - [Low-Level Timing on ESP32-S3: Event Capture, Clock Bridges, and Causal Validation](https://ptob.dev/papers/ptob-esp32s3-low-level-timing.pdf): A seven-page implementation guide to continuous hardware capture, narrow IRAM clock bridges, causal fitting, GNSS witnessing and estimated TX, with explicit calibration limits. ## Timing architectures - [T096 / nRF52840](https://ptob.dev/hardware/t096/timing/): Physical radio timestamps, GNSS PPS, software clock discipline, relays and USB. - [W12 / ESP32-S3](https://ptob.dev/hardware/esp32-s3/timing/): Controller-to-timer mapping, bounded relay train publication and independent PPS checks. - [CoreClock](https://ptob.dev/hardware/coreclock/timing/): A distinct ESP32-S3 target; keep its timing and qualification separate from W12. - [Reported-method comparison](https://ptob.dev/#comparison): Original statistics and references; not a matched benchmark. ## Measurement scope - RMS describes the stated population; it is not a worst-case bound. - These measurements do not establish independently calibrated absolute UTC accuracy or independent electrical GPIO output accuracy. - W12 retains 78/600 unavailable PPS records; downstream retains 149/600 unscorable records and a 211 ns tail. Sampled TX scores 58/120 with a 226 ns maximum. The full timing gate remains open. - Results apply to the named tested configurations and profiles, not every BLE MCU or multi-hop mesh path. - Cross-study RMS, MAE, standard deviation, and GPIO means use different references and conditions; they are not a matched output-accuracy or energy benchmark. - The independent PPS witness tests the already-published BLE clock and does not train it. Preserve separately trained frozen calibration, signed bias, missing observations and expired maps. - LoRa fallback is a separate unqualified estimate and grants no RC7 relay, GM promotion or USB source authority. The default macOS client leaves the system clock unchanged. ## PToB Blog - [PToB Blog](https://ptob.dev/blog/): Engineering notes on shared time, inexpensive hardware and the experiments behind PToB. - [Submicrosecond timing on ESP32 with passive BLE](https://ptob.dev/blog/passive-ble-esp32/): How PToB brings submicrosecond relative timing to ESP32-S3 with passive BLE reception, and how the architecture compares with active Wi-Fi FTM. - [Why PToB is standardizing on UTC](https://ptob.dev/blog/why-utc/): Why PToB chose UTC over TAI for MCU clock synchronization, with TAI offset compatibility, mesh epoch continuity and CoreS3-SE GNSS/PTP diagnostics. - [From spare radio boards to a precision time mesh.](https://ptob.dev/blog/why-ptob/): PToB began with unused Meshtastic and MeshCore boards. Our aim is an open precision time mesh across inexpensive MCUs, multiple radios and PTP networks. ## Public sources - [Source repository](https://github.com/yantisj2/PToB) - [Credits](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) - [Licensing](https://github.com/yantisj2/PToB/blob/main/LICENSING.md)