--- title: "LoRa-Kanalwechsel für präzise Zeit über große Entfernungen — PToB-Blog" description: "Warum PToB schmalere LoRa-Kanäle, kurze Zeitpakete und Kanalwechsel untersucht und bei ersten festen Installationen die Signallaufzeit anhand bekannter Entfernungen korrigieren will." url: "https://ptob.dev/de/blog/passives-lora-kanalwechsel/" language: "de" robots: "index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" representations: {"application/json":"https://ptob.dev/de/blog/passives-lora-kanalwechsel/?format=json","text/markdown":"https://ptob.dev/de/blog/passives-lora-kanalwechsel/?format=markdown"} format_description: "https://ptob.dev/agent-formats.json" --- # Warum unsere Zeitverbindung über große Entfernungen die Kanäle wechseln soll Eine gemeinsame Zeitreferenz weiter tragen: schmalere Kanäle für Empfindlichkeit, kurze Pakete für begrenzte Funkbelegung und bekannte Installationsentfernungen zur Berücksichtigung des Signalwegs. [Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 1. November 2026 5 Min. Lesezeit ![Konzeptbild einer gemeinsamen PToB-Zeitreferenz für nahe Uhren über BLE und einen entfernten festen Empfänger über LoRa, mit Laufzeitkorrektur anhand bekannter Entfernung und schematischem Kanalwechselablauf.](https://ptob.dev/blog/passive-lora-dual-timing-v2.png) Vorgeschlagene Richtung. Eine gemeinsame Referenz versorgt nahe Uhren über BLE und entfernte feste Empfänger über LoRa mit Kanalwechseln. Bekannte Entfernungen liefern die anfängliche Laufzeitkorrektur. Die drei Kanalzeilen sind schematisch; Reichweite und Präzision müssen gemessen werden. In diesem Beitrag Eine gemeinsame Zeitreferenz wird nützlicher, wenn sie die Geräte am Arbeitsort erreicht. Eine entfernte Sensorstation oder ein zweites Gebäude liegen vielleicht jenseits einer praktikablen Bluetooth-Verbindung und brauchen dennoch mit dem Rest der Installation vergleichbare Zeitstempel. Wir entwickeln PToBs LoRa-Pfad in Richtung größerer Entfernung und ergänzen lokalen BLE-Empfang um einen zweiten Zeittransport. Die Richtung verbindet **schmalere Funkkanäle, kurze Zeitpakete und Kanalwechsel**. So lässt sich Datenkapazität gegen Verbindungsempfindlichkeit tauschen, bei bewusstem Budget für gemeinsame Funkbelegung und geltende Funkregeln. Für erste feste Installationen wollen wir außerdem **bekannte konfigurierte Entfernungen zur Berechnung der Signallaufzeit** nutzen. Mit größerer Funkreichweite wird die Laufzeit des Signals Teil des Uhrenproblems. ## Funkzeit für die Referenz nutzen LoRa bietet eine nützliche Abwägung für Zeitverteilung: Wir brauchen wenig Daten, wollen sie aber über schwierige Pfade empfangbar halten. Bei gleichem Spreizfaktor kann schmalere Bandbreite die Empfangsempfindlichkeit verbessern und zugleich die Datenrate senken. Ein höherer Spreizfaktor kann weitere Empfindlichkeit bringen, ebenfalls auf Kosten längerer Übertragungen. [Semtechs Modulationsanleitung](https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf) erklärt diese Beziehungen. Damit wird die Paketgröße wichtig. Ein schmalerer Kanal verlängert jedes Symbol; die häufig wiederholte Zeitnachricht soll deshalb nur tragen, was der Empfänger zur Zuordnung von Beobachtung, Quelle und Zeit braucht. Seltener benötigte beschreibende Informationen können separat übertragen werden. Authentifizierung und Angaben zum Ablehnen ungültiger Beobachtungen gehören weiterhin zum Entwurf. Schmal und kurz bezeichnen hier verschiedene Entscheidungen. Schmal meint die belegte Funkbandbreite; kurz die Nutzdaten und daraus folgende Belegungszeit. Wir wollen genügend Empfindlichkeit für die Installation und zugleich Raum für Synchronisationsaufbau, Korrekturen und andere Frequenznutzer. Die Empfänger bleiben passiv: Sie hören die Aussendung, ohne jede Zeitaktualisierung zu bestätigen. Eine Sendung kann viele Uhren versorgen. Ein zusätzlicher Empfänger muss deshalb keinen weiteren Funkaustausch auslösen – besonders wertvoll, wenn eine robuste LoRa-Übertragung vergleichsweise langsam ist. ## Die Aussendung über mehrere Kanäle verteilen Ein wiederkehrender Zeitdienst braucht neben dem Paketformat einen Funkzeitplan. Kanalwechsel verteilen Sendungen auf Frequenzen und können aufeinanderfolgende Aktualisierungen weniger von einem lokal verdeckten oder gestörten Kanal abhängig machen. Sie verringern weder die gesamte Belegungszeit noch garantieren sie Empfang; Paketlänge und Takt setzen weiterhin das Budget. Für den US-Entwurf im Bereich 902–928 MHz bieten Kanalwechsel auch einen regulatorischen Weg, an dem sich die Entwicklung ausrichten lässt. Nach [47 CFR § 15.247(a)(1)(i)](https://www.ecfr.gov/current/title-47/section-15.247) braucht ein Hopping-System mit gemessener **20-dB-Kanalbandbreite unter 250 kHz** mindestens **50 Wechselfrequenzen**; je Frequenz ist die Belegung auf **0,4 Sekunden innerhalb von 20 Sekunden** begrenzt. Die Regel verlangt außerdem pseudozufällige Reihenfolge und im Mittel gleiche Nutzung durch jeden Sender. Der Weg über digitale Modulation verlangt dagegen mindestens **500 kHz Bandbreite bei 6 dB**. Das sind Definitionen gemessener Bandbreiten. Die nominelle Modemeinstellung allein belegt keine Konformität. Kanalabstand, Empfängersynchronisation, Leistung, Antennen und Emissionen müssen ebenfalls die geltenden Anforderungen erfüllen. Hopping ist unsere geplante Richtung; abgeschlossene FCC-Qualifizierung bleibt ein eigenes Ergebnis. Wir müssen deshalb die gesamte Aussendung einschließlich Korrekturen und Informationen zum Synchronisationsaufbau budgetieren und wiederholte Besuche jedes Kanals berücksichtigen. Passive Empfänger müssen den Plan entdecken, verfolgen und nach verpassten Aktualisierungen wiederfinden können. Hat ein Empfänger den Plan verloren, muss er sich erneut darauf synchronisieren, bevor Beobachtungen als nutzbare Zeit gelten. ## Zuerst die Entfernung berücksichtigen Funksignale benötigen im freien Raum etwa **3,34 Mikrosekunden für einen Kilometer**. Über zehn Kilometer sind es etwa **33,4 Mikrosekunden**. Diese gerundeten Rechnungen nutzen die [SI-Lichtgeschwindigkeit](https://www.bipm.org/en/publications/si-brochure); für präzise Zeitübertragung sind die Werte erheblich. Unser Ausgangspunkt ist eine feste Installation mit bekannter Entfernung zwischen Sender und Empfänger. Wir konfigurieren diese Entfernung und berechnen die nominelle Laufzeit als **Entfernung geteilt durch Lichtgeschwindigkeit**. Der Empfänger kann eine gesendete Referenz dann ihrer erwarteten Ankunft zuordnen und den Weg zwischen den Antennen berücksichtigen. Das liefert ein praktikables erstes Aufbaumodell ohne Entfernungsaustausch mit jedem Empfänger. Die Annahme bleibt prüfbar: Wo stehen die Antennen, wie wurde ihr Abstand ermittelt und wie unsicher ist diese Entfernung? Geometrische Entfernung erklärt einen Teil der Verzögerung. Antennen, Kabel, Funkelektronik, Zeitstempelerfassung und reflektierte Pfade können Bias oder Schwankungen hinzufügen. Eine Korrektur anhand festen Abstands beseitigt das allein nicht. Bewegte Empfänger und automatische Entfernungsschätzung brauchen weitere Arbeit; unser erster Ansatz setzt eine unveränderte Installation voraus. ## Das Zeitereignis über die Verbindung erhalten Auch ein langes Paket kann eine präzise Referenz tragen, wenn sein Zeitstempel zu einem klar identifizierten physischen Funkereignis gehört. Der Empfänger muss sein eigenes erfasstes Ereignis derselben Referenz zuordnen und dazwischenliegende Verzögerungen berücksichtigen. Wenn Software ein vollständiges Paket erhält, ist das ein anderes Ereignis mit eigener Verarbeitungsverzögerung. Unser [bestehender LoRa-Vertrag (Englisch)](https://github.com/yantisj2/PToB/blob/main/protocol/rc8/README.md) trennt bereits physische Ereigniszuordnung von Paketzustellung und erlaubt späteren Paketen, frühere Sendungen zu korrigieren. Der Langstreckenentwurf muss diese Sorgfalt über Kanalwechsel und verpasste Pakete erhalten. Zwischen Beobachtungen sagt die lokale Uhr voraus; Alter und Gültigkeit ihrer Referenz zählen weiterhin. Wir brauchen Messungen über Kanäle, Signalpegel und feste Pfade, um die beim Empfänger ankommende Präzision festzustellen. Die auf BLE gemessene Präzision lässt sich LoRa nicht einfach zuschreiben. Schmalere Kanäle, kompakte Aussendungen und ausgewogene Kanalwechsel ergeben eine praktikable Forschungsarchitektur; konfigurierte Installationsabstände lassen uns schon bei ersten festen Aufbauten die Signallaufzeit berücksichtigen. Diesen Entwurfsraum lohnt es auch für die [MeshCore-](https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md) und [Meshtastic-](https://meshtastic.org/docs/configuration/radio/lora/)Gemeinschaften zu erkunden. Beide wägen mit Funkeinstellungen bereits Reichweite, Nachrichtengeschwindigkeit und Funkbelegung ab. Ein koordinierter Hopping-Entwurf könnte die Empfindlichkeit schmalerer Kanäle mit Frequenzvielfalt und einem Weg zu den US-Hopping-Anforderungen verbinden; kompakte Nachrichten begrenzen die Belegung. Das zusätzliche Verbindungsbudget käme aus Modemeinstellungen; Kanalwechsel würden die Aussendungen verteilen und die Abhängigkeit von einem gestörten Kanal verringern. Beidseitige Nachrichten und Relaisverkehr machen ihre Koordination aufwendiger als unseren passiven Zeitbroadcast. Suche, Wiederanlauf nach verpassten Kanalwechseln und Kompatibilität brauchen eigene Entwürfe und Messungen. Die Aussicht auf mehr brauchbare Reichweite macht dies dennoch zu einer lohnenden gemeinsamen Forschungsrichtung. Jeder Zeitstempel braucht eine Referenz. **Welches Ereignis wurde erfasst?** ## Die Einzelheiten erkunden [Warum PToB? Die Projektrichtung: von preiswerten Funkplatinen zu einem gemeinsamen präzisen Zeitmesh.](https://ptob.dev/de/blog/warum-ptob/)[Passive Präzisionszeit auf ESP32 Warum eine ausgesendete Referenz vielen Empfängern gemeinsame Zeit ohne individuellen Austausch ermöglicht.](https://ptob.dev/de/blog/passives-ble-esp32/)[ESP32-Holdover Die Rate einer lokalen Uhr lernen und messen, wie ihre Vorhersage zwischen Referenzen altert.](https://ptob.dev/de/blog/esp32-holdover-unter-einer-mikrosekunde/) ## Quellen und weitere Lektüre Primärquellen zu den besprochenen Geräten und Methoden. 1. [PToB · Öffentlicher LoRa-Zeitvertrag](https://github.com/yantisj2/PToB/blob/main/protocol/rc8/README.md) Bestehende einseitige Zeitaussendungen, physische Ereigniszuordnung, spätere Korrekturen und separate Quellengültigkeit. 2. [Semtech · LoRa and LoRaWAN, AN1200.86](https://www.semtech.com/uploads/technology/LoRa/lora-and-lorawan.pdf) Abwägungen zwischen Bandbreite, Spreizfaktor, Empfindlichkeit und Funkbelegungszeit in der LoRa-Funkschicht. 3. [eCFR · 47 CFR § 15.247](https://www.ecfr.gov/current/title-47/section-15.247) US-Anforderungen an Hopping, Bandbreite, Belegung, Leistung, Antennen und Emissionen. 4. [BIPM · SI Brochure](https://www.bipm.org/en/publications/si-brochure) Die exakte Vakuumlichtgeschwindigkeit hinter den gerundeten Laufzeitbeispielen. 5. [MeshCore · Frequently asked questions](https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md) LoRa-Funkeinstellungen, Empfindlichkeit, Störungen und Belegungszeit in MeshCore-Netzen. 6. [Meshtastic · LoRa configuration](https://meshtastic.org/docs/configuration/radio/lora/) Modemprofile sowie Reichweiten-, Geschwindigkeits- und gemeinsame Funkeinstellungen eines Meshtastic-Meshs. ## Diesen Beitrag zitieren Jonathan Yantis. Warum unsere Zeitverbindung über große Entfernungen die Kanäle wechseln soll PToB-Blog. Veröffentlicht am 1. November 2026. Artikel-Permalink: [https://ptob.dev/de/blog/passives-lora-kanalwechsel/](https://ptob.dev/de/blog/passives-lora-kanalwechsel/) [Zurück zum Blog](https://ptob.dev/de/blog/)[Messnachweise des Projekts ansehen](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/de/blog/passives-lora-kanalwechsel/#webpage", "url": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/", "name": "LoRa-Kanalwechsel für präzise Zeit über große Entfernungen — PToB-Blog", "description": "Warum PToB schmalere LoRa-Kanäle, kurze Zeitpakete und Kanalwechsel untersucht und bei ersten festen Installationen die Signallaufzeit anhand bekannter Entfernungen korrigieren will.", "inLanguage": "de", "keywords": [ "LoRa", "Kanalwechsel", "Präzise Zeit", "Funkbelegungszeit", "Signallaufzeit" ], "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/de/blog/passives-lora-kanalwechsel/#breadcrumbs" }, "mainEntity": { "@id": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/#article" }, "translationOfWork": { "@id": "https://ptob.dev/blog/passive-lora-channel-hopping/#webpage" } }, { "@type": "BreadcrumbList", "@id": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "PToB", "item": "https://ptob.dev/de/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://ptob.dev/de/blog/" }, { "@type": "ListItem", "position": 3, "name": "Warum unsere Zeitverbindung über große Entfernungen die Kanäle wechseln soll", "item": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/" } ] }, { "@type": "Blog", "@id": "https://ptob.dev/de/blog/#blog", "url": "https://ptob.dev/de/blog/", "name": "PToB-Blog", "description": "Entwicklungsnotizen über gemeinsame Zeit, preiswerte Hardware und die Experimente hinter PToB.", "inLanguage": "de", "publisher": { "@id": "https://ptob.dev/#jonathan-yantis" }, "isPartOf": { "@id": "https://ptob.dev/#website" }, "blogPost": [ { "@id": "https://ptob.dev/de/blog/esp32-sensoren-ble-synchronisieren/#article" }, { "@id": "https://ptob.dev/de/blog/esp32-uhren-grundlagen/#article" }, { "@id": "https://ptob.dev/de/blog/zuverlaessige-firmware-zeitmesh/#article" }, { "@id": "https://ptob.dev/blog/lab-sensor-timing-economics/#article" }, { "@id": "https://ptob.dev/de/blog/starlink-lokaler-stratum-1-zeitserver/#article" }, { "@id": "https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#article" }, { "@id": "https://ptob.dev/de/blog/gnss-resilientes-zeitmesh/#article" }, { "@id": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/#article" }, { "@id": "https://ptob.dev/de/blog/esp32-holdover-unter-einer-mikrosekunde/#article" }, { "@id": "https://ptob.dev/de/blog/lokale-zeit-utc-netz/#article" }, { "@id": "https://ptob.dev/de/blog/grandmaster-ausfall-und-uhrenensemble/#article" }, { "@id": "https://ptob.dev/de/blog/ble-uhren-innenraumnavigation/#article" }, { "@id": "https://ptob.dev/de/blog/passives-ble-esp32/#article" }, { "@id": "https://ptob.dev/de/blog/warum-utc/#article" }, { "@id": "https://ptob.dev/de/blog/warum-ptob/#article" } ] }, { "@type": "BlogPosting", "@id": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/#article", "url": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/", "headline": "Warum unsere Zeitverbindung über große Entfernungen die Kanäle wechseln soll", "description": "Warum PToB schmalere LoRa-Kanäle, kurze Zeitpakete und Kanalwechsel untersucht und bei ersten festen Installationen die Signallaufzeit anhand bekannter Entfernungen korrigieren will.", "mainEntityOfPage": { "@id": "https://ptob.dev/de/blog/passives-lora-kanalwechsel/#webpage" }, "isPartOf": { "@id": "https://ptob.dev/de/blog/#blog" }, "author": { "@id": "https://ptob.dev/#jonathan-yantis" }, "publisher": { "@id": "https://ptob.dev/#jonathan-yantis" }, "inLanguage": "de", "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": "Drahtlose Zeitübertragung über große Entfernungen", "keywords": [ "LoRa", "Kanalwechsel", "Präzise Zeit", "Funkbelegungszeit", "Signallaufzeit" ], "wordCount": 1055, "citation": [ { "@type": "CreativeWork", "name": "PToB · Öffentlicher LoRa-Zeitvertrag", "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" } } ] } ```