Why our long-range time link will hop channels

A shared time reference becomes more useful when it can reach the equipment where the work happens. A remote sensor station or a second building may sit beyond a practical Bluetooth link, while still needing timestamps that can be compared with the rest of an installation.

We are taking PToB’s LoRa path toward that longer-distance role, adding a second timing transport alongside local BLE reception. The direction combines narrower radio channels, short timing packets and channel hopping. Together, they let us trade data capacity for link sensitivity while keeping a deliberate budget for shared airtime and the applicable radio rules.

For the first fixed installations, we will also use known, configured distances to calculate time of flight. Extending the radio’s reach makes the signal’s travel time part of the clock problem.

Spend airtime on the reference

LoRa provides a useful tradeoff for time distribution: we need relatively little data, but want that data to remain receivable over a difficult path. At a given spreading factor, narrower bandwidth can improve receiver sensitivity while reducing the data rate. Increasing the spreading factor can buy additional sensitivity, also at the cost of longer transmissions. Semtech’s modulation guide describes those relationships.

That makes packet size important. Narrowing the channel makes each symbol take longer, so we want the frequently repeated timing message to carry only what the receiver needs to associate an observation with its source and time. Less frequent descriptive information can travel separately. Authentication and the information needed to reject an invalid observation still belong in the design.

“Narrow” and “short” describe different choices here. Narrow refers to occupied radio bandwidth; short refers to the payload and resulting airtime. We want enough sensitivity to reach the installation, with enough room left for acquisition, corrections and other spectrum users.

The receivers will remain passive: they listen to the broadcast without acknowledging every timing update. One transmission can serve many clocks. Adding a receiver therefore need not add another exchange to the air, which is particularly valuable when a robust LoRa transmission is comparatively slow.

Move the broadcast across channels

A repeating time service needs an airtime plan as much as a packet format. Channel hopping distributes transmissions across frequencies, and can make successive updates less dependent on one locally obstructed or interfered-with channel. It does not reduce the total airtime or guarantee reception; packet length and cadence still set that budget.

For the United States 902–928 MHz design, hopping also supplies a regulatory route worth building around. Under 47 CFR § 15.247(a)(1)(i), a hopping system with measured 20 dB channel bandwidth below 250 kHz needs at least 50 hopping frequencies, with occupancy on any frequency limited to 0.4 seconds within a 20-second period. The rule also requires pseudorandom ordering and equal average use by each transmitter. Its digital-modulation route instead specifies a minimum 6 dB bandwidth of 500 kHz.

Those are measured bandwidth definitions. A modem’s nominal setting alone does not establish compliance. Channel spacing, receiver synchronization, power, antennas and emissions also have to satisfy the applicable requirements. Hopping is our intended design direction; completed FCC qualification remains a separate outcome.

We therefore need to budget the whole broadcast, including corrections and acquisition information, and account for repeated visits to each channel. Passive receivers must be able to discover the schedule, follow it and recover after missed updates. A receiver that has lost the schedule needs to reacquire it before treating observations as usable time.

Account for the distance first

Radio signals take about 3.34 microseconds to travel one kilometre in free space. Across ten kilometres, that is about 33.4 microseconds. These rounded calculations use the SI speed of light; they are large enough to matter when the aim is precision time transfer.

Our starting point is a fixed installation with a known distance between transmitter and receiver. We will configure that distance and calculate the nominal propagation delay as distance divided by the speed of light. The receiver can then associate a transmitted reference with its expected arrival time, accounting for the journey between the antennas.

This gives us a practical first deployment model without requiring a ranging exchange from every listener. It also makes the assumption inspectable: where are the antennas, how was their separation established, and how uncertain is that distance?

Geometric distance accounts for one part of the delay. Antennas, cables, radio electronics, timestamp capture and reflected paths can add bias or variation. A fixed-distance correction cannot remove those effects by itself. Moving receivers and automatic distance estimation require further work; our initial approach assumes the installation stays in place.

Preserve the timing event across the link

A long packet can still carry a precise reference if its timestamp belongs to a clearly identified physical radio event. The receiver must relate its own captured event to that same reference, with the intervening delays accounted for. Software receiving a completed packet is another event, with its own scheduling delay.

Our existing LoRa contract already separates physical event association from packet delivery and allows a later packet to report a correction for an earlier transmission. The longer-range design needs to preserve that discipline through channel changes and missed packets. Between observations, the local clock predicts forward; the age and validity of its reference still matter.

We will need measurements across channels, signal levels and fixed paths to establish the precision that reaches a receiver. The precision measured on our BLE paths cannot simply be assigned to LoRa. Narrower channels, compact broadcasts and balanced hopping give us a practical architecture to investigate, while configured installation distances let us begin accounting for propagation from the first fixed deployments.

The same design space is worth exploring for the MeshCore and Meshtastic communities. Both already balance range, message speed and airtime through their radio settings. A coordinated hopping design could combine narrower channels’ sensitivity with frequency diversity and a route toward meeting the US hopping requirements, while compact messages help contain occupancy. The additional link budget would come from the modem settings; hopping would spread transmissions across frequencies and reduce dependence on one interfered-with channel. Their bidirectional messaging and relay traffic make coordination more involved than our passive time broadcast. Discovery, missed-hop recovery and compatibility would need their own design and measurements, but the potential to extend useful range makes this a worthwhile shared research direction.