Deploy a wireless timing network

Share a reference clock across nearby devices, extend it through relay clocks, and bring network time into macOS. Start with a direct connection, then add source redundancy and wireless reach.

Explore a deployment

Start with one source. Add a standby, another candidate, then the links that reach your devices.

Share a reference with nearby devices

Begin with one qualified T096 grandmaster and receivers in direct radio range. Each receiver disciplines its own local clock from the broadcast timing.

Illustrative topology · select a device
Serving timing networkOne root reference, several local clocks. BLE reception supplies the observations; each device maintains its own clock model. Select a device to read its role.GM AACTIVELocal GNSS + PPSSensorBLE clientsRoot A · parent AInstrumentBLE clientsRoot A · parent AServing timing networkOne root reference, several local clocks. BLE reception supplies the observations; each device maintains its own clock model. Select a device to read its role.GM AACTIVEGNSS + PPSSensorBLE clientsRoot A · parent AInstrumentBLE clientsRoot A · parent A
BLE timing Packet = sender / root

One root reference, several local clocks. BLE reception supplies the observations; each device maintains its own clock model.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Correlate camera, IMU and acquisition logs around one robot, or timestamp a compact group of sensors.
Verify before extending
Check the GM’s fix, live PPS and source readiness. Confirm each receiver’s actual selected parent, fresh source and timing lock.
Know the boundary
One source has no standby. Losing usable reference time can interrupt valid timing at every dependent receiver.

Establish an ACTIVE / HOT pair

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.

Illustrative topology · select a device
Serving timing networkOne ACTIVE serves time. The appointed HOT follows its timing and independently qualifies a local source. Select a device to read its role.Grandmaster coreGM AACTIVELocal GNSS + PPSGM BHOTQualified successorReceiversBLE clientsRoot A · parent AServing timing networkOne ACTIVE serves time. The appointed HOT follows its timing and independently qualifies a local source. Select a device to read its role.Grandmaster coreGM AACTIVEGM BHOTReceiversBLE clientsRoot A · parent A
BLE timingGM coordinationUnavailable path Packet = sender / root

One ACTIVE serves time. The appointed HOT follows its timing and independently qualifies a local source.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Add a standby reference to a robotics test area or an instrument cluster before extending its wireless footprint.
Verify before extending
Confirm the same ACTIVE/HOT appointment on both members. If no candidate qualifies, NO HOT is an honest state while a healthy ACTIVE can continue serving.
Know the boundary
Two GM-capable clocks are not two sources to average. Durable failover and uninterrupted timing remain unqualified.

Keep a third candidate at the center

Add the third GM after the ACTIVE/HOT pair is established. It normally remains COLD, receiving timing while continuing its own local GNSS qualification.

Illustrative topology · select a device
Serving timing networkOne ACTIVE serves the receivers, one HOT is appointed, and a third GM remains COLD. A healthy pair keeps its appointment when a candidate arrives. Select a device to read its role.Grandmaster coreGM AACTIVELocal GNSS + PPSGM BHOTQualified successorGM CCOLDAdditional candidateReceiversBLE clientsRoot A · parent AServing timing networkOne ACTIVE serves the receivers, one HOT is appointed, and a third GM remains COLD. A healthy pair keeps its appointment when a candidate arrives. Select a device to read its role.Grandmaster coreGM AACTIVEGM BHOTGM CCOLDReceiversBLE clientsRoot A · parent A
BLE timingGM coordinationUnavailable path Packet = sender / root

One ACTIVE serves the receivers, one HOT is appointed, and a third GM remains COLD. A healthy pair keeps its appointment when a candidate arrives.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Keep another source-capable device available at a central equipment location while receivers extend into surrounding areas.
Verify before extending
Observe the original pair and every follower as the newcomer joins. A local HOT label alone is insufficient; preserve source gaps and missing observations.
Know the boundary
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

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.

Illustrative topology · select a device
Serving timing networkRoot A remains the original reference throughout the path. Each relay originates its own train; the shared pulse illustrates clocks marking the same time boundary, not measured RF transit. Select a device to read its role.Grandmaster coreGM AACTIVEServing referenceGM BHOTSuccessorGM CCOLDCandidateRC1Relay clockRoot A · parent ARC2Relay clockRoot A · parent RC1Local clientsReceive via RC1Root A · parent RC1RC3 client AReceiving leafRoot A · parent RC2RC3 client BReceiving leafRoot A · parent RC2Serving timing networkRoot A remains the original reference throughout the path. Each relay originates its own train; the shared pulse illustrates clocks marking the same time boundary, not measured RF transit. Select a device to read its role.Grandmaster coreGM AACTIVEGM BHOTGM CCOLDRC1Relay clockRoot A · parent ARC2Relay clockRoot A · parent RC1Local clientsReceive via RC1Root A · parent RC1RC3 client AReceiving leafRoot A · parent RC2RC3 client BReceiving leafRoot A · parent RC2
BLE timingGM coordination Packet = sender / root

Root A remains the original reference throughout the path. Each relay originates its own train; the shared pulse illustrates clocks marking the same time boundary, not measured RF transit.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Correlate sensor samples across a corridor, separate work areas or distributed telecom test instruments.
Verify before extending
Add one hop at a time. Check the actual selected parent, root, fresh source and timing at each hop; measure availability and error at the final client.
Know the boundary
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

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.

Illustrative topology · select a device
BLE usable timing networkBoth radio paths may carry the same original source. BLE remains the preferred input; transport diversity does not create independent reference diversity. Select a device to read its role.GM AACTIVELocal GNSS + PPSLoRa bridgeGM profileSelected BLE source ADual-input receiverBLE preferredLoRa available separatelyBLE usable timing networkBoth radio paths may carry the same original source. BLE remains the preferred input; transport diversity does not create independent reference diversity. Select a device to read its role.GM AACTIVEGNSS + PPSLoRa bridgeGM profileBLE source ADual-input receiverBLE preferredLoRa available separately
BLE timingLoRa timingUnavailable path Packet = sender / root

Both radio paths may carry the same original source. BLE remains the preferred input; transport diversity does not create independent reference diversity.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Explore a fallback time display or remote monitoring path where the preferred BLE link can become unavailable.
Verify before extending
Use compatible LoRa-enabled builds, the same group configuration and the proper antenna. Confirm the sole transmitter, original root and separate input states.
Know the boundary
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

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.

Illustrative topology · select a device
Mesh via RC timing networkChoose one attached USB source. This view follows mesh time through the RC. Captured USB frame boundaries are matched to the Mac’s frame reference and monotonic clock. Packets deliver captured records; their arrival time does not define clock phase. Select a device to read its role.GM AACTIVELocal GNSS + PPST096 RCMesh → USBSelected BLE sourceT096 DCOther USB optionNot selected heremacOS clientUSB frame mappingCaptured SOF ↔ MachchronyLocal user clockOwned chronyd -xMesh via RC timing networkChoose one attached USB source. This view follows mesh time through the RC. Captured USB frame boundaries are matched to the Mac’s frame reference and monotonic clock. Packets deliver captured records; their arrival time does not define clock phase. Select a device to read its role.GM AACTIVEGNSS + PPST096 RCMesh → USBBLE sourceT096 DCOther USB optionNot selectedmacOS clientUSB frame mappingCaptured SOF ↔ MachchronyLocal user clockOwned chronyd -x
BLE timingUSBLocal interface Packet = sender / root Captured USB frame

Choose one attached USB source. This view follows mesh time through the RC. Captured USB frame boundaries are matched to the Mac’s frame reference and monotonic clock. Packets deliver captured records; their arrival time does not define clock phase.

GM A · ACTIVE

The serving grandmaster supplies the root reference. GM selection alone is insufficient: local GNSS fix, live PPS and the source qualification dwell must pass.

Use this when
Compare acquisition timestamps, inspect source health and correlate host observations with a wireless instrument network.
Verify before extending
Choose a compatible RC or DC source. Check the USB source identity, source validity and observation age, then evaluate the delivered clock separately from fit RMS.
Know the boundary
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.

Topology illustrates operating roles, not measured range, latency or uninterrupted service. Current T096 guidance uses G5 coordination and RC7 timing; historical paper measurements retain their own versions and test conditions.

Extend timing through two relay stages

A relay synchronizes its own local clock, then originates a new timing train for the next area. The immediate sender changes at each link; the original grandmaster remains the root reference.

  1. GMOriginal referenceRoot A · sender A
  2. RC1First relay clockRoot A · sender RC1
  3. RC2Second relay clockRoot A · sender RC2
  4. RC3 clientsReceiving leavesRoot A · parent RC2

Place each relay where it can receive usable upstream timing and reach the next receivers. Add one hop at a time, verify the actual selected parent, and retain inherited age, expiry and uncertainty through the path.

Relay support depends on the target. T096 supports the bounded RC7 relay path. W12 BLE50 is client-only; W12 and StickS3 estimated-TX relay modes remain experimental. A receiving client beyond RC2 does not add another relay stage.

Explore the relay network

Measured through a T096 intermediary

62.5 ns PPS-shadow RMS including bias across GM → T096 relay → T096 receiver. The prospective one-relay experiment retained 436 usable observations out of 602 nominal boundaries (72.425%).

12 October 2026 · one intermediary, two BLE links · historical 0.14.43. Fractional-second phase; additional hops and absolute UTC need separate validation.

Read the one-relay research result

Keep BLE and LoRa inputs separate

Experimental LoRa adds a separate timing estimate alongside BLE. Both paths may originate at the same GM, so a second radio path does not create a second independent reference.

BLEPreferred while usable
The selected BLE path supplies the precision clock used by supported receivers, relays and the T096 RC USB publisher. Original source permissions and timing deadlines still apply.
LoRaSeparate functional fallback
A compatible receiver may use an unqualified estimate when BLE is unusable. Total uncertainty and passive freshness remain unknown. This input grants no RC7 relay publication, GM promotion or USB source authority.

LoRa is optional and disabled by default. It needs compatible build-time configuration, one designated transmitter and a suitable antenna. GM mesh participation can suppress passive LoRa reception; that suppression alone is not a fault.

Compare the two input states

Bring reference time
to the Mac

USB transfers hardware-captured timing records into the host. Choose a mesh-connected RC or a dedicated local GNSS source; both use the same captured-frame method.

From the wireless network

GNSS + GMBLE → T096 RCUSB → macOS

USB streaming is standard in the ordinary RC7 application. The attached RC can follow the GM or a supported relay path.

From local GNSS

GNSST096 DCUSB → macOS

Direct Connect is a separate flash-only image with Bluetooth disabled, no group enrollment and zero BLE hops.

The device captures USB start-of-frame boundaries. The client matches frame identities to the Mac’s USB reference and monotonic clock, then supplies an experimental user clock through its owned, unprivileged chronyd -x.

The default client leaves the macOS system clock unchanged and does not serve LAN time. Applications need the supplied interface or an explicitly configured time service. Fit RMS, delivered-clock agreement and independent UTC error describe different measurements.

Commission one link
at a time

Build confidence in the direct path before adding a reserve or another hop. Measure the complete source-to-client chain under the conditions in which it will operate.

  1. Qualify the reference

    Check GNSS fix, live PPS and source readiness. For an ACTIVE/HOT pair, confirm the appointment at both ends. References with shared failure modes do not provide independent diversity.

  2. Confirm the direct receiver

    Verify the actual parent, original root, fresh source and precision lock. Enrollment, a device name or visible RF activity alone does not establish usable time.

  3. Add one relay or candidate

    Observe the existing pair and followers as each device joins. Keep each target’s transmit limitations and the bounded relay depth visible in the deployment record.

  4. Observe loss and recovery

    Retain acquisition, missing samples, expired maps, source changes and withheld output. A continuing local display or LoRa estimate does not prove current precision-source permission.

  5. Measure at the final client

    Record the reference, signed error, bias-inclusive RMS, tails, coverage and observation window. Additional hops and host interfaces need their own measurements.

PToB is experimental. Durable multi-GM failover, continuous delivery and calibrated UTC/output accuracy remain unqualified. For robotics and sensor meshes, validate timestamp correlation at the application endpoint. For telecom, treat PTP interworking as a future integration direction.

Continue with the operating guides

Content follows the T096 0.15.164 operating checkpoint and current target guides, reviewed 22 October 2026. Diagrams use illustrative identities.