--- title: "LoRa channel hopping for long-distance precision time — PToB Blog" description: "Why PToB is pursuing narrower LoRa channels, short timing packets and channel hopping, with fixed-distance propagation correction for initial installations." url: "https://ptob.dev/blog/passive-lora-channel-hopping/" language: "en" robots: "index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" representations: {"application/json":"https://ptob.dev/blog/passive-lora-channel-hopping/?format=json","text/markdown":"https://ptob.dev/blog/passive-lora-channel-hopping/?format=markdown"} format_description: "https://ptob.dev/agent-formats.json" --- # Why our long-range time link will hop channels Carry a shared time reference farther. Use narrower channels for sensitivity, short packets to control airtime, and known installation distances to account for the journey. [Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 1 November 2026 5 min read ![Concept illustration of a shared PToB time reference serving nearby clocks over BLE and a distant fixed receiver over LoRa, with known-distance propagation correction and a schematic channel-hopping timeline.](https://ptob.dev/blog/passive-lora-dual-timing-v2.png) Proposed direction. A shared reference serves nearby clocks over BLE and distant fixed receivers over a hopping LoRa path. Known distances supply the initial propagation correction. The three channel rows are schematic; range and precision require measurement. In this post 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](https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf) 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)](https://www.ecfr.gov/current/title-47/section-15.247), 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](https://www.bipm.org/en/publications/si-brochure); 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](https://github.com/yantisj2/PToB/blob/main/protocol/rc8/README.md) 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](https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md) and [Meshtastic](https://meshtastic.org/docs/configuration/radio/lora/) 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. Every timestamp needs a reference. **Which event did you capture?** ## Explore the details [Why PToB? The project’s direction, from inexpensive radio boards to a shared precision time mesh.](https://ptob.dev/blog/why-ptob/)[Passive precision time on ESP32 Why broadcasting a reference lets many receivers share time without individual exchanges.](https://ptob.dev/blog/passive-ble-esp32/)[ESP32 holdover Learning a local clock’s rate and measuring how its prediction ages between references.](https://ptob.dev/blog/esp32-sub-microsecond-holdover/) ## Sources and further reading Primary references for the hardware and methods discussed. 1. [PToB · Public LoRa timing contract](https://github.com/yantisj2/PToB/blob/main/protocol/rc8/README.md) Existing one-way timing broadcasts, physical event association, later corrections and separate source validity. 2. [Semtech · LoRa and LoRaWAN, AN1200.86](https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf) Bandwidth, spreading factor, sensitivity and airtime tradeoffs in the LoRa physical layer. 3. [eCFR · 47 CFR § 15.247](https://www.ecfr.gov/current/title-47/section-15.247) United States hopping, bandwidth, occupancy, power, antenna and emissions requirements. 4. [BIPM · SI Brochure](https://www.bipm.org/en/publications/si-brochure) The exact speed of light in vacuum used for the rounded propagation-delay examples. 5. [MeshCore · Frequently asked questions](https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md) LoRa radio settings, sensitivity, interference and airtime considerations for MeshCore networks. 6. [Meshtastic · LoRa configuration](https://meshtastic.org/docs/configuration/radio/lora/) Modem presets and the range, speed and shared radio settings used by a Meshtastic mesh. ## Cite this article Jonathan Yantis. Why our long-range time link will hop channels PToB Blog. Published 1 November 2026. Article permalink: [https://ptob.dev/blog/passive-lora-channel-hopping/](https://ptob.dev/blog/passive-lora-channel-hopping/) [Back to the blog](https://ptob.dev/blog/)[Inspect the project evidence](https://github.com/yantisj2/PToB/blob/main/evidence/README.md) ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://ptob.dev/#website", "url": "https://ptob.dev/", "name": "PToB", "alternateName": [ "Precision Time over BLE", "Precision Time over Bluetooth" ], "description": "Bluetooth and USB software clocks: W12 60.3 ns relative-PPS RMS over 522/600 observations, separate 64 s sampled holdover, and CoreSE diagnostics.", "inLanguage": [ "en", "de" ], "publisher": { "@id": "https://ptob.dev/#jonathan-yantis" } }, { "@type": "Person", "@id": "https://ptob.dev/#jonathan-yantis", "name": "Jonathan Yantis", "url": "https://github.com/yantisj2/PToB/blob/main/CREDITS.md" }, { "@type": "Project", "@id": "https://ptob.dev/#project", "name": "PToB", "alternateName": "Precision Time over BLE", "url": "https://ptob.dev/", "description": "An independent protocol project researching precision time transfer across Bluetooth-enabled microcontrollers and USB clients.", "sameAs": "https://github.com/yantisj2/PToB", "member": { "@id": "https://ptob.dev/#jonathan-yantis" }, "knowsAbout": { "@id": "https://ptob.dev/#protocol" } }, { "@type": "Thing", "@id": "https://ptob.dev/#protocol", "name": "Precision Time over BLE", "alternateName": "PToB", "description": "An experimental PTP-inspired protocol proposal for wireless clock synchronization over Bluetooth Low Energy." }, { "@type": "WebPage", "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#webpage", "url": "https://ptob.dev/blog/passive-lora-channel-hopping/", "name": "LoRa channel hopping for long-distance precision time — PToB Blog", "description": "Why PToB is pursuing narrower LoRa channels, short timing packets and channel hopping, with fixed-distance propagation correction for initial installations.", "inLanguage": "en", "keywords": [ "LoRa", "Channel hopping", "Precision time", "Radio airtime", "Propagation delay" ], "isPartOf": { "@id": "https://ptob.dev/#website" }, "author": { "@id": "https://ptob.dev/#jonathan-yantis" }, "about": { "@id": "https://ptob.dev/#protocol" }, "dateModified": "2026-11-01T00:00:00.000Z", "image": "https://ptob.dev/blog/passive-lora-dual-timing-v2.png", "breadcrumb": { "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#breadcrumbs" }, "mainEntity": { "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#article" } }, { "@type": "BreadcrumbList", "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "PToB", "item": "https://ptob.dev/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://ptob.dev/blog/" }, { "@type": "ListItem", "position": 3, "name": "Why our long-range time link will hop channels", "item": "https://ptob.dev/blog/passive-lora-channel-hopping/" } ] }, { "@type": "Blog", "@id": "https://ptob.dev/blog/#blog", "url": "https://ptob.dev/blog/", "name": "PToB Blog", "description": "Engineering notes on shared time, inexpensive hardware and the experiments behind PToB.", "inLanguage": "en", "publisher": { "@id": "https://ptob.dev/#jonathan-yantis" }, "isPartOf": { "@id": "https://ptob.dev/#website" }, "blogPost": [ { "@id": "https://ptob.dev/blog/esp32-wireless-softpll/#article" }, { "@id": "https://ptob.dev/blog/esp32-clock-fundamentals/#article" }, { "@id": "https://ptob.dev/blog/firmware-stability-time-mesh/#article" }, { "@id": "https://ptob.dev/blog/lab-sensor-timing-economics/#article" }, { "@id": "https://ptob.dev/blog/starlink-local-stratum-1-ntp/#article" }, { "@id": "https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#article" }, { "@id": "https://ptob.dev/blog/gnss-resilient-time-mesh/#article" }, { "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#article" }, { "@id": "https://ptob.dev/blog/esp32-sub-microsecond-holdover/#article" }, { "@id": "https://ptob.dev/blog/local-time-utc-mesh/#article" }, { "@id": "https://ptob.dev/blog/grandmaster-failover-multi-master-ensemble/#article" }, { "@id": "https://ptob.dev/blog/ble-clocks-indoor-navigation/#article" }, { "@id": "https://ptob.dev/blog/passive-ble-esp32/#article" }, { "@id": "https://ptob.dev/blog/why-utc/#article" }, { "@id": "https://ptob.dev/blog/why-ptob/#article" } ] }, { "@type": "BlogPosting", "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#article", "url": "https://ptob.dev/blog/passive-lora-channel-hopping/", "headline": "Why our long-range time link will hop channels", "description": "Why PToB is pursuing narrower LoRa channels, short timing packets and channel hopping, with fixed-distance propagation correction for initial installations.", "mainEntityOfPage": { "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#webpage" }, "isPartOf": { "@id": "https://ptob.dev/blog/#blog" }, "author": { "@id": "https://ptob.dev/#jonathan-yantis" }, "publisher": { "@id": "https://ptob.dev/#jonathan-yantis" }, "inLanguage": "en", "dateCreated": "2026-11-01T00:00:00.000Z", "dateModified": "2026-11-01T00:00:00.000Z", "datePublished": "2026-11-01T00:00:00.000Z", "image": "https://ptob.dev/blog/passive-lora-dual-timing-v2.png", "articleSection": "Long-distance wireless time transfer", "keywords": [ "LoRa", "Channel hopping", "Precision time", "Radio airtime", "Propagation delay" ], "wordCount": 1055, "citation": [ { "@type": "CreativeWork", "name": "PToB · Public LoRa timing contract", "url": "https://github.com/yantisj2/PToB/blob/main/protocol/rc8/README.md" }, { "@type": "CreativeWork", "name": "Semtech · LoRa and LoRaWAN, AN1200.86", "url": "https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf" }, { "@type": "CreativeWork", "name": "eCFR · 47 CFR § 15.247", "url": "https://www.ecfr.gov/current/title-47/section-15.247" }, { "@type": "CreativeWork", "name": "BIPM · SI Brochure", "url": "https://www.bipm.org/en/publications/si-brochure" }, { "@type": "CreativeWork", "name": "MeshCore · Frequently asked questions", "url": "https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md" }, { "@type": "CreativeWork", "name": "Meshtastic · LoRa configuration", "url": "https://meshtastic.org/docs/configuration/radio/lora/" } ], "about": { "@id": "https://ptob.dev/#protocol" } } ] } ```