Hardware guide

Choose the hardware behind your clock. Explore firmware and client targets, then compare their displays, timestamp capture, clock resolution and reference sources.

Firmware targetT096 · GitHub README

Heltec T096

A GNSS-backed reference clock with physical timestamps for both BLE transmission and reception. One platform can serve as a grandmaster, a hot standby or a relay clock.

Protocol features

These firmware profiles use the same hardware in different clock roles.

GrandmasterIndependent GNSS / PPS source: Originates the network time reference from its own GNSS time and PPS. Eligible, authorized clocks participate in automatic source selection.
Hot standbySynchronized, eligible and admitted: Follows the serving grandmaster while preparing to take over. HOT requires synchronized time, independent source eligibility and current permission.
Relay clockBoundary-clock profile: Disciplines its own clock from an authenticated parent and originates a separate downstream timing train, preserving the original root and inherited source age.

A relay preserves its upstream reference; it does not gain independent grandmaster authority. Role support and the measured precision of a specific path are separate capabilities.

Recognizing the clock’s state

The firmware display keeps source, role and synchronization state visible. The analog dial appears in the locked GM and HOT previews; GPS acquisition uses the status panel.

T096 Grandmaster · locked screen rendered from firmware — Grandmaster · locked
The serving GPS reference shows the analog dial and GM state.

T096 HOT standby · locked screen rendered from firmware — HOT standby · locked
The standby keeps a synchronized dial while following the serving grandmaster.

T096 GPS synchronization screen rendered from firmware — GPS synchronization
The acquisition panel remains visible while the GPS reference is settling.

Firmware UI previews rendered from the repository at the display’s native 80 × 160 pixels, using illustrative state inputs. They are not photographs or live lock observations.

Additional relay screen previews

Candidate illustrations for relay profiles and acquisition states.

T096 Following RC1 firmware UI preview — Following RC1
A downstream clock follows one relay hop and shows the RC1 source marker.

T096 Relay clock operation firmware UI preview — Relay clock operation
The RC profile shows its disciplined local time while serving downstream.

T096 Relay acquisition firmware UI preview — Relay acquisition
The relay is acquiring its parent; an analog lock is not displayed yet.

Hardware specifications

The CPU cycle, timestamp tick and PPS accuracy describe different parts of the clock.

Processor & clocks
Specification	Value & timing relevance
MCU	Nordic nRF52840 Arm Cortex-M4F Source
CPU clock / cycle	64 MHz / 15.625 nsSource
Timestamp timer / tick	16 MHz / 62.5 ns Hardware capture and compare; 32-bit counter. Source
Memory	1 MB flash · 256 KB RAMSource

BLE & physical timestamps
Specification	Value & timing relevance
BLE radio	2.4 GHz · Bluetooth LE 1M, 2M and LE Coded PHY capability; measured precision profile uses BLE 1M. Source
BLE TX timestamp	Hardware event capture RADIO ADDRESS event → PPI → TIMER capture. Source
BLE RX timestamp	Hardware event capture RADIO ADDRESS event → PPI → TIMER capture; receive reference delay requires calibration. Source
Event capture path	Peripheral-to-peripheral PPI latches the counter without waiting for a software callback. Source

GPS / GNSS reference
Specification	Value & timing relevance
Onboard receiver	Unicore UC6580 · L1 + L5Source
PPS timing accuracy	20 ns RMS Manufacturer family specification; see reference notes below. Source
PPS capture	GPIO event → PPI → TIMER Uses the same 16 MHz counter as the BLE timestamps. Source
Source discipline	GNSS time + physical PPS A fresh fix, pulse and valid time association establish the reference. Source

Board & integration
Specification	Value & timing relevance
Display	0.96-inch colour TFT · 80 × 160Source
Power	USB-C 5 V · lithium batterySource
Board dimensions	52 × 25.4 × 10.26 mmSource
Other onboard radio	SX1262 LoRa PToB precision results on this page use BLE. Source

Understanding the 20 ns PPS specification

Unicore’s UC6580 family brochure lists 20 ns RMS time accuracy. This describes PPS timing accuracy, rather than free-running oscillator drift or the total error of a BLE clock.

The UC6580x-00 R1.7 datasheet lists 5 ns RMS. Match the chip variant, receiver settings and measurement conditions before using either figure in an accuracy budget. Antenna, electrical and capture delays also contribute. The research paper documents these reference specifications.

T096 timing architecture

Follow hardware capture through the servo, SoftPLL and delivered clock. Explore each mode and trace drift or offsets.

Open the interactive schematic

From physical event to shared time

BLE TX, BLE RX and GPS PPS edges can be captured against the same local counter. Follow-up timing identifies the actual transmit event; the receiver uses those observations to discipline its clock.

BLE TX / RXGPS PPS

Hardware capturePPI event interconnect

16 MHz counter62.5 ns per tick

Hardware latching removes software callback latency from the capture coordinate. Calibration accounts for differences between the transmit and receive reference edges.

A 15.625 ns CPU cycle helps execute the estimator. A 62.5 ns timer tick determines the capture grid. Neither number alone is an end-to-end accuracy guarantee.

A reference for sub-microsecond timing

The T096 provides the hardware capture and GNSS reference needed to build a precision timing network. The V14 research paper measured a grandmaster → relay clock → receiver path against an independent local PPS witness.

Measured one-relay PPS-shadow phase
Statistic	Result
RMS, including bias	62.504 ns
95th-percentile absolute error	123.25 ns
99th-percentile / maximum	160.25 / 191 ns
Usable / nominal observations	436 / 602 72.425%

These results measure fractional-second phase in the usable PPS-shadow population over approximately 602 seconds. Missing reference edges and expired maps remain in the coverage count. Calibrated electrical output and absolute UTC accuracy need their own measurements.

For a sub-100 ns absolute-error limit on 95% of observations, validate the complete timing path against that percentile. The measured 62.504 ns RMS and 123.25 ns P95 describe different performance criteria.

Read the measured results

Source references

Explore the protocol packets

Firmware targetW12 · GitHub README

Meshnology W12

An ESP32-S3 BLE clock client and relay clock. Follow a grandmaster or relay, discipline a continuous local clock, and publish a new downstream timing train while preserving the original source and its age.

Protocol features

The native W12 firmware supports receiving time, following relay parents and serving downstream relay timing.

BLE clock clientDirect grandmaster or relay parent: Follows an authenticated timing stream, pairs each received original with its later correction, and disciplines a continuous local software clock with phase, rate and source-expiry checks. Parent discovery can be automatic or explicitly selected.
Relay clock · RC1 / RC2Receive and publish on BLE100: Follows its parent while originating a new downstream timing train at 16 Hz. RC1 follows the root; RC2 follows RC1. Each relay preserves the original source, authenticated path, inherited age and permission.
Authenticated participationScoped parent and child admission: Binds timing to the admitted parent, source and boot scope. Child admission and same-path renewal preserve the timing train; changed sources or paths retire the old clock context. Expired and mismatched timing is refused.
Independent GNSS / PPS observationExplicit verified L76K profile: Tracks navigation-packet activity, fix freshness and physical PPS separately. The PPS observer uses a model available before each edge, with separately labeled raw/mapped prediction and bounded curvature. GNSS is off by default and never trains BLE or creates GM authority.

The relay server uses BLE100. BLE50 is client-only; GM and HOT source roles remain unfinished.

Choose a listening profile

Receiving and relaying use the same timing chain, with different radio ownership.

Supported W12 profiles
Profile	Behavior
BLE100 client	Continuous BLE reception. The explicit fine-clock build adds continuous 80 MHz MCPWM capture, exact packet association and capture-frozen dense fitting. Non-fine builds retain the baseline descriptor/GPTimer path.
BLE100 relay	Concurrent parent reception and downstream RC7 publication. Supports RC1 and RC2 with separate child admission, frozen publication maps and original source-freshness checks. TX uses four validated programmed-clock projections; actual RF timing remains unqualified.
BLE50 client	Client-only reception in a nominal 450 ms opportunity each second, with all radio owners closed by 500 ms and the remaining half-second reserved for quiet. The local clock continues between receive windows.

These are firmware listening policies. Physical RF duty, acquisition gaps and delivered-time accuracy are measured separately for each profile.

Firmware screen previews

The landscape OLED keeps the immediate parent, original grandmaster and relative lock state visible on direct and relayed timing paths.

W12 Grandmaster lock landscape OLED preview rendered from firmware — Grandmaster lock
Following REF-A directly. The lock icon and 03:12 timer show sustained relative lock; the footer shows 234 ns causal RMS and the projected hold horizon.

W12 Following RC1 landscape OLED preview rendered from firmware — Following RC1
RC-A RC1 identifies the immediate relay parent. The original grandmaster remains REF-A, with 02:08 of relative lock and 276 ns causal RMS.

W12 Following RC2 landscape OLED preview rendered from firmware — Following RC2
RC-B RC2 identifies a second-level relay parent. The R marker indicates relay-only parent selection; root REF-A, lock duration and local clock diagnostics remain visible.

Firmware previews at the native 128 × 64 pixels, with illustrative values and public clock names. RMS is the causal model error; H is its estimated hold horizon. These example states do not report live lock or independently measured output accuracy.

Hardware specifications

Specifications for the ESP32-S3 silicon and the W12 reference hardware. CoreClock has its own firmware-target record.

Processor & clocks
Specification	Value & timing relevance
MCU	Espressif ESP32-S3 Dual-core Xtensa LX7 Source
CPU clock / cycle	Up to 240 MHz / ≈4.167 ns Cycle length at 240 MHz. Source
Crystal reference	40 MHz / 25 ns W12 reference crystal. Source
Local timer / tick	Fine BLE100: 80 MHz / 12.5 ns Continuous MCPWM1; delivered coordinates round to 50 ns. Baseline BLE100 and BLE50 use 20 MHz GPTimer. Source
On-chip memory	512 KB SRAM · 384 KB ROM Flash and PSRAM capacities depend on the board/module. Source

Radio & timestamp hardware
Specification	Value & timing relevance
BLE radio	Bluetooth 5 LE · 2.4 GHz 1M, 2M and LE Coded PHYs; advertising extensions. Source
Wi-Fi hardware	2.4 GHz · 802.11 b/g/n Shares radio resources with BLE; hardware presence alone does not establish a timing service. Source
BLE RX reference	Captured marker + exact packet join Fine PDU191 uses an empirical RX-active falling edge; PDU159 retains descriptor timing. RF endpoint remains unqualified. Source
Relay timing train	RC7 · 190 bytes · 16 Hz BLE100 relay profiles originate downstream timing with corrections for earlier publications. Source
BLE TX reference	Four-projection programmed estimate Rounded mean through a frozen map; nominal LE1M ADDRESS is start +40 microseconds. RF uncertainty remains unknown. Source

W12 integration
Specification	Value & timing relevance
Firmware target	Meshnology W12 These hardware details apply to W12. CoreClock has its own target record.
Display	OLED W12 uses a separate display path from the T096 TFT.
GPS / PPS	Explicit L76K RX39 / PPS41 profile Default OFF; enable48 LOW on the verified route. GNSS observes the BLE clock and never disciplines it. Source
PPS capture	MCPWM0 PPS → production counter Fine builds bracket its map with MCPWM1 CURRENT latches. Preserve raw/mapped prediction, enclosure and causal availability. Source
Peripheral interfaces	GPIO · UART · SPI · I²C · USBSource

ESP32-S3 · W12 timing architecture

Trace BLE reception into the disciplined clock and working RC7 relay publisher. Inspect slot placement, frozen maps, downstream timing trains and later corrections.

Open the interactive schematic

From received event to delivered time

W12 0.2.10 offers an explicit fine-clock BLE100 profile: a continuous 80 MHz MCPWM counter captures the receive-active marker, which is joined to the exact retained packet. Authenticated original/correction pairs then train a dense phase and rate fit. Baseline BLE100 and BLE50 retain descriptor timing through GPTimer.

Captured RX markerFine BLE100 · 80 MHz / 12.5 ns

Exact packet associationEvent + channel + capture epoch

Delivered clockCausal model · 50 ns coordinates

The callback records availability after the event. Fine PDU191 uses an empirical falling-edge convention; PDU159 retains descriptor phase. Counter resolution, RF endpoint accuracy and calibrated UTC are separate.

For relay operation, the publisher freezes the clock map associated with each outgoing original and carries its correction in later advertisements. The downstream receiver repeats the capture-and-pairing process against that relay.

Inspect the receiver and relay publisher

For capture arithmetic, clock mapping and causal validation, read the low-level ESP32-S3 timing paper (PDF).

Clock state and service continuity

Normal receiver profiles start automatically and run indefinitely under their availability and fault policy. Finite diagnostic capture ends logging while the clock continues running.

FOLLOWFresh accepted parent timing: The displayed time comes from the current authenticated BLE clock. The source root and immediate relay parent remain distinct.
LOCK_ESTRelative model meets its tracking screens: The causal error history and hold projection meet the firmware’s relative lock criteria. This is a model-based tracking state; independent output accuracy has its own reference and measurement.
HOLDPreviously delivered clock remains usable: The clock extrapolates within its permitted held policy. The hold estimate counts down; new admission or a screen refresh cannot renew an old timing observation.
Acquiring / unavailableNo usable clock, expiry or fault: The display withdraws live time when the clock is unavailable. Reacquisition requires fresh accepted timing in the current scope.

How a relay handles a timing gap

During a bounded timing gap the relay can retain its authenticated path and periodic train for up to 30 seconds, while clearing corrections and timing readiness. Its count-zero packets preserve synchronization without offering usable timing corrections.

A fresh accepted parent pair restores timing on that train. A real source, boot or path change retires the old scope. Explicit stop, fault and update paths retain bounded controller shutdown.

Reference and precision scope

W12’s clock and relay service have been exercised on direct and relayed paths. The timing schematic distinguishes implemented support, the timestamp reference used by each stage, and measurements needed to characterize delivered error.

Causal error and hold estimateRelative to the received timing stream: The dashboard scores prior delivered predictions against later timing observations. Fit scatter, causal RMS and the model’s hold horizon describe different aspects of tracking. The projected horizon is a model estimate, rather than an empirical percentile.
Independent PPS comparisonOptional receiver-side reference: Only the explicit verified W12 L76K profile enables RX39/PPS41 and supply enable48 LOW. Fine builds bracket its software map between production counter latches. Raw/mapped next-PPS prediction, delivered BLE phase and UTC-second association are different metrics. Missing models and activation races remain in the denominator.
Relay transmit referenceEstimated coordinate in the reviewed implementation: The publisher joins selected payload/publication/event/channel to a frozen map and averages four validated programmed-clock projections. Nominal LE1M ADDRESS is start plus 40 microseconds. It remains an estimate with unknown RF uncertainty; missing or inconsistent projections refuse the correction.

Current capability boundaries

The shared provisional receive adjustment (+7671 ns) affects delivered clock copies only; the raw oscillator fit stays unshifted. A separate +4026 ns relay residual follows nominal ADDRESS. These are relative path parameters with unmeasured transfer to other units/profiles, not RF or UTC calibration. A PPS-relative producer can select a whole-second civil offset while preserving each timestamp’s nanosecond fraction: UTC_ns = relative_ns + K × 1,000,000,000. The integer offset does not reduce timestamp resolution.

GM and HOT source roles remain unsupported on W12. The relay preserves upstream source authority; it does not become an independent grandmaster.

BLE50 is a client profile and does not use the fine-clock backend. Its window policy is separate from measured RF duty, usable-update coverage and blackout accuracy. Wi-Fi timing and PTS remain disabled in these profiles.

Measured W12 clock and relay timing

24 October 2026 · Nordic source → W12 receiver / estimated relay → T096 witness. Two 300-second windows follow a 120-second warmup, with W12 0.2.10 and T096 0.15.169. Receive and relay adjustments were frozen before validation.

W12 · delivered clock at GNSS PPS

Relative-PPS RMS including bias: 60.3 ns
Eligible / logged observations: 522 / 600 · 87.0%
Mean / standard deviation: +40.7 / 44.5 ns
Absolute P95 / P99 / maximum: 122 / 156 / 180 ns

All 78 source-unavailable records remain. The first window includes a source transition; the stable second window separately measured 38.3 ns RMS across 300/300 observations, with a 121 ns maximum. Across both windows, 466/522 eligible errors are strictly below 100 ns and all 522 are below 200 ns.

After the W12 relay · downstream T096 PPS

Relative-PPS RMS including bias: 61.9 ns
Eligible / logged observations: 451 / 600 · 75.2%
Mean / standard deviation: −5.5 / 61.7 ns
Absolute P99 / maximum: 154 / 211 ns

109 no-map, 36 expired and four reference-ineligible records remain unscorable. One eligible error reaches or exceeds 200 ns.

Sampled transmitted time · measured at downstream RX

Received-output RMS including bias: 108.3 ns
Scored / selected transmissions: 58 / 120 · 48.3%
Mean / standard deviation: +13.9 / 107.4 ns
Absolute P99 / maximum: 226 / 226 ns

61 selected transmissions lack a matching follow-up record; one lacks PPS brackets. Three scored errors reach or exceed 200 ns. This sampled path includes the existing downstream receive correction and does not isolate RF transmit delay.

The UTC-basis repair preserves nanosecond phase: all 522 eligible W12 records have identical relative and UTC fractional phases. The separate GNSS predictor measured 35.2 ns raw / 41.9 ns mapped RMS across 600/600 predictions; it evaluates its own prior model and does not measure delivered BLE accuracy.

The full timing gate remains open because availability gaps, downstream tails and unknown GNSS, GPIO/cable, RF and absolute UTC bounds remain. Physical W12 output timing and GM operation are unqualified. These measurements do not certify other units or profiles.

W12 PPS samples (CSV) · Downstream PPS (CSV) · All selected TX (CSV) · GNSS predictions (CSV) · Full results (JSON) · Provenance and offline verifier

Source references

Explore the protocol packets

Firmware targetCoreClock

CoreClock

A BLE clock client built on M5Stack CoreS3 with a GPS v2.1 PPS reference. Its five-minute test produced 300 usable GPS PPS comparisons out of 300, with 137 ns RMS error.

Protocol features

BLE clock clientReceives the network reference: The clock display shows the selected source, drift estimate and BLE tracking state alongside the analog dial.
GPS PPS comparison300 / 300 usable observations: The attached GPS v2.1 module supplies PPS for timing comparisons. The reported five-minute result retains the same frozen correction throughout.

The clock at a glance

CoreClock BLE client screen with analog dial, UTC zone, source and drift telemetry — Clock and timing state
The full client view pairs the dial with source and tracking information.

CoreClock gold analog face showing time and date — Analog clock face
A focused view of the clock’s time and date presentation.

Supplied CoreClock screen images. On-screen FIT RMS is a servo-fit diagnostic; the results below describe GPS PPS comparison error over the five-minute test.

Measured against GPS PPS

Five-minute test passed300 / 300 usable PPS comparisons · 100% coverage

Unchanged frozen correctionHeld unchanged across the test

Reported five-minute GPS PPS comparison
Statistic	Result
Mean offset	+111 ns
RMS error	137 ns
Jitter RMSVariation about the mean offset	80 ns
P95 / P99	242 / 278 ns
Maximum error	310 ns

RMS includes the mean offset; jitter RMS describes variation around it. These results apply to the reported CoreS3 + GPS v2.1 configuration and unchanged correction over this five-minute test.

Hardware specifications

CoreS3 provides the ESP32-S3 processor and display. The stacked GPS v2.1 module adds the GNSS receiver and physical PPS reference.

CoreS3 processor & board
Specification	Value & timing relevance
MCU	Espressif ESP32-S3 Dual-core Xtensa LX7 Source
CPU clock / cycle	240 MHz / ≈4.167 ns Cycle length at the documented CPU clock. Source
Local timer / tick	20 MHz / 50 ns Timer configuration shown in the supplied CoreClock screen. Tick length is separate from measured clock error.
Memory	16 MB flash · 8 MB PSRAMSource
Display	2.0-inch touch IPS · 320 × 240Source
BLE radio	Bluetooth 5 LE · 2.4 GHzSource
Power & integration	USB-C · M5-Bus module stackSource

GPS v2.1 reference module
Specification	Value & timing relevance
GNSS receiver	AT6668Source
Satellite systems	GPS · QZSS · BeiDou · Galileo · GLONASSSource
Time interfaces	UART data + PPS output PPS is the physical comparison reference for the reported test. Source
Antenna	External active antenna · SMASource
PPS uncertainty	Configuration dependent A PPS output does not by itself establish calibrated absolute UTC accuracy.

CoreClock timing architecture

Trace the CoreS3 BLE receiver, fixed civil epoch and independent PPS witness. Its target-specific paths and measurements have their own schematic.

Open the interactive schematic

Source references

Performance figures and screen images supplied by the project operator. Hardware specifications are documented by the manufacturers.

StickS3 · Time Diagnostic

StickS3 · GitHub README

A pocket instrument for inspecting a PToB network. See the grandmaster and hot standby, compare timing streams, and investigate link health from the M5Stack StickS3’s colour display.

Time Diagnostic (TD) is the primary profile: it starts automatically, samples the network and puts source status beside the quality of the received link. Six pages take you from a quick health check to the observations behind it.

Start with network health

Identify the serving grandmaster and reported hot standby, then check whether the selected link is delivering usable observations. Source permission and signal strength have separate readouts, so a strong signal does not hide missing time information.

Native TD read the network at a glance preview; illustrative values — Read the network at a glance
GM and HOT standby identities, selected link, delivery, signal strength and sampled source permission share the front panel.

Native TD check the source behind the signal preview; illustrative values — Check the source behind the signal
Inspect report age, source epoch, original time-envelope age and TTL. GPS/PPS health and UTC error remain explicitly UNKNOWN.

All TD previews on this page use the exact reviewed V17 firmware renderer at its native 135 × 240 resolution, with illustrative values and synthetic peer identities. They are not live device captures or measured performance results.

The GM/standby report is checked at startup and every 120 seconds. Link delivery below 85% raises a warning. Signal smoothing and a 150 ms health-banner persistence filter keep the display readable; raw source permission and fault handling remain immediate.

Compare streams over time

Stream Quality puts the sampled GM and relay histories on the same chart. Cycle between jitter, observed loss and RSSI to distinguish timing variation from changes in reception.

Native TD relative jitter chart with illustrative GM and relay histories — Relative jitter
Compare GM and relay observations on a logarithmic scale over 120 seconds. This is relative timing scatter, not UTC accuracy.

Native TD observed packet loss chart with illustrative GM and relay histories — Observed packet loss
See event gaps within listening stints. Planned sampling boundaries are excluded; this is not an independent over-air loss measurement.

Native TD signal strength chart with illustrative GM and relay histories — Signal strength
Follow sampled periodic-report RSSI for the same streams. Dashed extensions hold the last value; gaps and sample ages remain visible.

Follow a symptom into the detail

Native TD Relay Test page with illustrative observations — Relay Test
Find nearby relays by signal strength, inspect hop and advertised stream, and explicitly enable or stop a bounded relay request.

Native TD RF Health page with illustrative observations — RF Health
Inspect boot-total receive, matched, gap and rejection counters alongside channel coverage, raw RSSI range and API errors.

Native TD Sample Detail page with illustrative observations — Sample Detail
Read the selected stream’s jitter, maximum, sample age, source age, receive ratio, PHY and synchronization failures.

Normal TD operation observes the network with relay requests off. Relay Test makes a request an explicit operator action; its on-screen state stays visible.

Six pages, one front button

Time Diagnostic controls
Action	Result
Short press	Advance through Health, Stream Quality, Relay Test, RF Health, Sample Detail and Source Health.
Hold on Stream Quality	Hold 1.5 seconds to cycle jitter → loss → RSSI.
Hold on Relay Test	Hold 1.5 seconds to toggle the relay request. Turning it off stops renewal; the displayed lease limit is five seconds.
Hold on the front page	Switch operating profile. Mode switching is restricted to the front page.

Also available: relay-clock profiles

StickS3 can also follow and relay network time. Relay Client prefers a usable GM with relay fallback; Relay Only selects an RC1 parent for RC2 operation. These profiles provide the analog clock and relay-status views.

RC1 follows the GM directly; RC2 follows RC1. The original root, source age and publication permission remain part of the timing path. Receiving or relaying time does not grant grandmaster or hot-standby authority.

Earlier native relay-clock preview showing RC2 operation — RC2 clock display
Earlier reviewed relay-profile renderer with illustrative inputs. LOCK_EST, RMS and HOLD are model diagnostics, not output-accuracy measurements.

Hardware specifications

StickS3 combines the processor, display and battery in one compact enclosure. The PToB firmware gets its time reference from the BLE network.

StickS3 processor & board
Specification	Value & timing relevance
MCU	ESP32-S3-PICO-1-N8R8 Dual-core Xtensa LX7 · 240 MHz. Source
Memory	8 MB flash · 8 MB Octal PSRAMSource
Display	1.14-inch colour LCD · 135 × 240 ST7789P3; six Time Diagnostic pages, with clock views in relay profiles. Source
Power	USB-C 5 V · 250 mAh batterySource
Dimensions / weight	48 × 24 × 15 mm / 20 gSource
Controls & expansion	Two programmable buttons · Hat2-Bus · GroveSource

PToB timing configuration
Specification	Value & timing relevance
Local timer / tick	20 MHz / 50 ns Free-running timer with a numerical phase and rate map. Tick length is separate from delivered accuracy.
BLE radio	Bluetooth LE · 2.4 GHz TD samples GM and relay streams; relay profiles also publish downstream timing. Source
Profiles	Time Diagnostic · Relay Client · Relay Only TD is the default diagnostic profile. Relay profiles support RC1 and RC2 operation.
Downstream timing	16 Hz · originals + later corrections In relay profiles, the clock originates a separate timing train; normal TD observation does not.
Local GNSS reference	No onboard GPS / PPS This firmware follows network time; it does not supply an independent GM reference.
Transmit reference	Estimated TX coordinate Used in relay profiles, with unknown uncertainty; not a TD output-accuracy measurement.

What the instrument tells you

TD helps inspect network roles, received stream quality and source freshness. PERMITTED and VALID AD describe the signed source envelope at the observed transmission, with sample age shown. They do not establish local UTC accuracy.

StickS3 has no onboard GNSS receiver. Relative jitter, observed event gaps and RSSI are diagnostic observations; calibrated output accuracy, GPS/PPS health and absolute UTC error require a separate reference. Unknown or stale observations remain visible.

Source references

Explore the protocol packets

Client targetmacOS · GitHub README Experimental user clock

A fine USB clock, disciplined with chrony

BLE-derived time reaches the Mac through a USB relay. Our native client fits hardware-captured USB events to Mach time, then feeds a private chrony instance. Applications can follow its user-level clock while macOS time stays unchanged.

Read the USB time-transfer preprint

Sub-microsecond settled RMS over five minutes

In the completed 300.065 s trial, TC-01 supplied BLE time to TC-04, which carried it over a direct USB connection to the Mac. Chrony’s reported RMS stayed below 1 µs throughout the predeclared 60–300 s settled window.

15 October 2026 · firmware 0.15.53 / client 0.21 · one direct-XHCI setup
Measurement	Observed value
Chrony estimator RMS265 new tracking queries in the predeclared settled window. Median 129 ns; P95 263 ns. An internal estimate.	23–339 ns
Delivered clock vs fine sourceSame-instant shared-source comparison: 182 valid / 54 withheld of 236 observations. Maximum difference 1.315 µs.	414 ns RMS
Base USB causal prediction9,437 qualified inverse-counter forecasts, each evaluated against the preceding fit before ingest. Bias retained; no detrending.	328 ns RMS
USB errors / chrony restartsCompleted five-minute run. The previous separate trial had 46 daemon restarts.	0 / 0

The three timing numbers answer different questions. Chrony reports its own filter estimate; the delivered-clock comparison checks agreement with the fine stream at the same instant; base USB prediction tests the causal fit using only earlier observations. None is an independent measurement of absolute UTC error.

Startup is retained: the initial chrony estimator transient reached 32.072 ms. Settled RMS is below 1 µs, while the largest delivered-clock difference was 1.315 µs. One nanosecond (ns) is one billionth of a second.

Coverage, original deadlines and retained gaps

Explicit populations · unavailable readings remain unavailable
Coverage & reference	Observed count
Source-valid observationsSettled window, approximately 1 Hz. This is separate from delivered-clock availability.	235 / 236
Delivered comparisons54 withheld: 45 unidentified delivery gates, 7 stale references, 1 absent current anchor and 1 unavailable source permission.	182 / 236
Full-window comparisons0–300 s including startup; shared-source RMS 399 ns. Missing points are not filled.	220 / 296
Fine feeds / provenance violationsEvery feed retains valid source provenance and its original permission deadline.	2,102 / 0
USB tuples accepted / rejectedComplete forward replay of all 9,600 hardware tuples; 1,200 frame-layout checks, zero layout failures.	9,558 / 42
Valid source records / distinct UTC translationsThe retained UTC translation stayed constant throughout the observed source scope.	9,866 / 1

Source-valid and deliverable are different gates. These status counts are sampled about once per second; they do not establish continuous coverage. The finite helper completed its configured 9,600 samples at 299.991 s, followed by normal session cleanup.

The new missing-SOF-map classification preserves the original authority deadlines. No such event occurred naturally in this run, so physical coverage of that branch—and its causal role in the restart improvement—remains unproved. Focused firmware, host and real-daemon synthetic checks cover its retention and withdrawal rules.

The working macOS client

The main page leads with chrony’s estimator RMS. Press c for source, rate, freshness and feed statistics. Both views below replay the final eligible fresh status at 299.904 s from the measured run, through the native renderer.

Measured PToB main-page replay at 4 minutes 59 seconds: chrony tracking BLE Stratum 1, estimator RMS 98 ns, local-clock offset minus 32.631 ms, and the retained loss indicator. — **Main instrument · 98 ns estimator RMS**04:59 / 05:00 · tracking BLE / Stratum 1 · measured capture replay
The displayed 98 ns is a tracking estimate. The loss indicator preserves recent events; held display values never authorize a feed or extend source permission.

Measured PToB chrony-page replay: estimator RMS 98 ns, frequency plus 2.140 ppm, query age 0.27 seconds, 329 checks with zero failures, fine feed ready and no system-clock control. — **Chrony statistics · the same captured instant**04:59 / 05:00 · tracking BLE / Stratum 1 · measured capture replay
The displayed 98 ns is a tracking estimate. The loss indicator preserves recent events; held display values never authorize a feed or extend source permission.

Scroll the instrument horizontally on narrow screens. At this captured instant: estimator RMS 98 ns, frequency +2.140 ppm and delivered-clock difference 379 ns. The −32.631 ms readout compares chrony with local macOS UTC; it is a different measurement.

The UTC noise we found—and what comes next

The earlier stream repeatedly recomputed UTC translation from coarse observations while the fine monotonic map evolved separately. The corrected source binds one coherent integer translation and retains it across ordinary map updates. All 9,866 valid source records in the final trial kept the same translation, removing that repeated noise from the observed stream.

The next priority is delivery availability: source time was valid in 235 of 236 settled observations, while the app delivered 182 usable comparisons. We need explicit diagnostics for the remaining delivery gates, followed by controlled fit-window and load trials. Original source expiry stays enforced.

Independent UTC accuracy still needs calibration of the source’s initial UTC association and the physical USB-to-Mach timestamp bias. The final run used no external NTP reference; no NTP or gPTP superiority claim is made.

Earlier results, kept as separate experiments

The previous five-minute trial already achieved 414 ns shared-source RMS, but restarted chrony 46 times and delivered 103 of 236 settled comparisons. The final run improves observed continuity and deliverability; the direct timing agreement is essentially unchanged.

The earlier ten-minute USB study had 18,332 source observations. All twenty 30 s fitted windows had median / worst jitter σ of 0.155 / 0.288 µs; predicting each next 30 s block from the preceding block gave 1.053 µs RMS. Those exploratory fitted-window results remain distinct from the current 328 ns causal prediction.

That older build’s 1.465 ms UTC variation led to the translation fix above. Its ten NTP checks had ±52.884–96.552 ms uncertainty and could not calibrate the USB endpoint. Historical captures and the original operator screenshot remain preserved.

From a captured frame to a user clock

The tested path is TC-01 → BLE → TC-04 → USB → fine estimate → chronyd → application. The client discovers compatible timing relays on any USB port. Direct Mac Bluetooth is disabled.

Capture a shared eventHardware timestamp, then USB delivery: A 16 MHz timer captures the full-speed USB frame boundary in 62.5 ns ticks. Causal markers identify its matching host frame before any fine phase fit.
Predict with the preceding fitRolling model, original source permission: Up to 1,024 preceding accepted observations fit counter time to Mach time. Each forecast is evaluated before ingest. The exact source map and retained UTC translation produce the fine estimate; later maps never fill an earlier gap.
Discipline a private clockFine feed by default · system time unchanged: The app starts an unprivileged private chronyd with system-clock control disabled, feeds its SOCK refclock and reads its virtual clock. BLE is the selected refclock; Stratum 1 describes the hierarchy, not calibrated accuracy.

Explore the research

Beyond USB Packet Arrival: Frame-Identified Time Transfer to macOS now focuses on the final chrony integration and causal base USB results, with the UTC defect’s discovery and resolution, explicit populations and a concrete improvement sequence.

Research preprint · revised 15 October 2026. Includes the separate historical experiment, startup and missing readings, and the remaining calibration work.

Read the revised preprint (PDF)

An Apple silicon client target

One working setup, with the platform and timing assumptions made explicit. Other hosts and USB topologies need their own validation.

macOS ARM64 timing platform
Platform detail	Implementation & scope
Platform	Apple M-series · arm64 A native macOS client target. CPU frequency, core count and memory depend on the Mac; they are not timing accuracy specifications.
Host clock	Mach absolute + continuous time Mach tick conversion uses the runtime timebase. The absolute-to-continuous association is recorded separately.
USB reference	IOUSBHost microframe / time pair The client associates captured device frames with the host reference before evaluating counter phase.
Attached timing source	TC-04 over full-speed USB 1 ms device frames; a free-running 16 MHz counter supplies 62.5 ns capture ticks. Frame cadence does not set the timestamp accuracy.
Observed transport	USB timing at 32 Hz Periodic UTC/source information accompanies the precision stream. Packet arrival time does not train the boundary mapping.
Connection scope	Direct full-speed XHCI path Frame identity and clock maps are fenced by boot, USB and capture epochs. Other hubs, sleep / resume and reconnect conditions need their own qualification.
Comparison reference	Private user-level chronyd · fine feed BLE-derived USB time feeds a SOCK refclock. The app reads chrony’s virtual clock; macOS clock settings stay unchanged. External NTP was off in the final trial.

Source references

The paper records exact software versions, frozen capture hashes, analysis windows and evidence provenance. Screens replay measured status data; no private capture or physical identity is published here.

Heltec T096

Protocol features

Recognizing the clock’s state

Grandmaster · locked

HOT standby · locked

GPS synchronization

Following RC1

Relay clock operation

Relay acquisition

Hardware specifications

T096 timing architecture

From physical event to shared time

A reference for sub-microsecond timing

Source references

Meshnology W12

Protocol features

Choose a listening profile

Firmware screen previews

Grandmaster lock

Following RC1

Following RC2

Hardware specifications

ESP32-S3 · W12 timing architecture

From received event to delivered time

Clock state and service continuity

Reference and precision scope

Measured W12 clock and relay timing

W12 · delivered clock at GNSS PPS

After the W12 relay · downstream T096 PPS

Sampled transmitted time · measured at downstream RX

Source references

CoreClock

Protocol features

The clock at a glance

Clock and timing state

Analog clock face

Measured against GPS PPS

Hardware specifications

CoreClock timing architecture

Source references

StickS3 · Time Diagnostic

Start with network health

Read the network at a glance

Check the source behind the signal

Compare streams over time

Relative jitter

Observed packet loss

Signal strength

Follow a symptom into the detail

Relay Test

RF Health

Sample Detail

Six pages, one front button

RC2 clock display

Hardware specifications

What the instrument tells you

Source references

A fine USB clock, disciplined with chrony

Sub-microsecond settled RMS over five minutes

The working macOS client

The UTC noise we found—and what comes next

From a captured frame to a user clock

Explore the research

An Apple silicon client target

Source references