Tippen Sie, um passende Textstellen zu finden.
Wie viel Präzision steckt in einer kleinen Funkplatine? PToB erforscht, wie preiswerte Mikrocontroller ihre Uhren über Bluetooth synchronisieren können. Wir verbinden Ideen aus der präzisen Netzwerktechnik mit Messungen am Empfänger – und zeigen, was funktioniert, wo die Grenzen liegen und welche Fragen offenbleiben.
62,5 ns RMS im relativen PPS-Vergleich über ein Relais.
GM → T096-Relais (nRF52) → T096-Empfänger.Das Ergebnis hängt vom Zeitpfad des Mikrocontrollers ab. (PDF, Englisch)
V14-Grandmaster A sendet Zeitereignisse und spätere Korrekturen. Die Empfänger gleichen ihre lokalen Uhren durch passiven Empfang ab.
V14 · schematisches BeispielZeit empfangen · Ohne Geräte zu koppeln.
Zeit weitergeben · Auch über Relais bleibt die ursprüngliche Quelle erkennbar.
Quelle auswählen · Berechtigte Zeitgeber koordinieren ihre Rollen im Netz.
PToB verbindet ein erfasstes Funkereignis mit ergänzenden Zeitdaten. Der Empfänger berechnet daraus den Zeitversatz zur Quelle und verfolgt, wie schnell seine eigene Uhr läuft. Eine Software-Regelschleife (Software PLL) führt die lokale Uhr nach. Der Zeitpfad und seine Kalibrierung bestimmen die Präzision.
Ein Zeitgeber sendet ein Zeitsignal über BLE.
Ein geeigneter Empfänger erfasst das physische Funkereignis mit einem Zeitstempel.
Ergänzende Daten zeigen, wann dieses Ereignis ursprünglich gesendet wurde.
Der Empfänger führt seine eigene Uhr anhand der Quelle nach.
Einfache Scanner können die ausgesendete Zeit nutzen. Hohe Präzision braucht Zeitstempel aus der Hardware und ein kalibriertes Uhrenmodell.
Den Weg von der Hardwareerfassung über Servo und SoftPLL zur ausgegebenen Uhr verfolgen. Betriebsarten erkunden und Gangabweichungen oder Zeitversatz untersuchen.
Interaktives Blockdiagramm öffnenDen Weg von der Quelle über eine eigene Relais-Uhr zum Client verfolgen. Jedes Originalereignis seiner späteren Korrektur zuordnen und anschließend die exakten V14-Bytes sowie die Regeln zum Alter der Uhrenabbildung untersuchen.
V14-Paketexplorer öffnenSynthetische V14-RC1-Beispiele. Die physische Präzision ist nicht nachgewiesen.
Nordics nRF52840 erfasst physische Funkereignisse; der ESP32-S3 im W12 nutzt eine empirisch angepasste Erfassung der Empfangsaktivität. Die getrennten Versuche vergleichen die ausgegebene BLE-Zeit mit lokalen PPS-Beobachtungen. Pfad, Datum und Abdeckung bleiben für jeden Versuch separat ausgewiesen.
Grandmaster, Relais-Uhr und Empfänger verteilen Zeit über zwei BLE-Verbindungen. Gemessen wird gegen einen unabhängig erfassten lokalen Sekundenimpuls.
W12 prüft seine ausgegebene BLE-Uhr an lokalen GNSS-PPS-Flanken. GNSS beobachtet die Uhr, ohne sie zu trainieren; die Lücke beim Quellenwechsel bleibt im Gesamtergebnis enthalten.
Das stabile zweite Zeitfenster erreichte 38,3 ns RMS bei 300/300 Beobachtungen. Hinter dem W12-Relais maß T096 61,9 ns RMS bei 451/600 Beobachtungen und ein Maximum von 211 ns.
W12-Ergebnisse und TX-Grenzen lesenDie Holdover-Untersuchung vom 30. Oktober erreicht in einer separaten festen Kohorte 75 s und scheitert bei 76 s; spätere gleitende Fenster enden bei 24 s. Holdover-Stichproben garantieren keine durchgängige Genauigkeit.
Eine PPS-Beobachtung fragt die bereits veröffentlichte BLE-Uhr des Empfängers an einer separat erfassten Sekundenimpulsflanke (PPS) auf demselben Hardwarezähler ab. Die Referenz prüft die BLE-Uhr und trainiert sie nicht.
Das T096-Ergebnis über ein Relais vom 12. Oktober beträgt 62,504 ns RMS einschließlich Bias bei 436/602 auswertbaren/erwarteten Grenzen. Das W12-Ergebnis vom 24. Oktober beträgt 60,3 ns RMS einschließlich Bias bei 522/600 protokollierten PPS-Beobachtungen. Alle 78 nicht verfügbaren Einträge und das Maximum von 180 ns bleiben erhalten; das stabile Fenster mit 300 Stichproben wird separat ausgewiesen. Alle W12-Zeitfenster und Populationen ansehen.
Hinter dem W12-Relais beträgt die ausgegebene T096-PPS-Phasenabweichung 61,9 ns RMS bei 451/600 Beobachtungen und einem Maximum von 211 ns. Die separate TX-Stichprobe wertet 58/120 ausgewählte Sendungen aus: 108,3 ns RMS und 226 ns Maximum, bei 61 fehlenden Zuordnungen und einer Beobachtung ohne einschließende PPS-Marken. Messwege und Nenner unterscheiden sich.
RMS ist weder eine garantierte Fehlergrenze noch eine UTC-Zertifizierung. Physische Ausgabe, HF-Bezugspunkt und absolute UTC-Genauigkeit sind nicht nachgewiesen. Die Übertragbarkeit der Kalibrierung auf andere W12-Geräte und Profile ist nicht gemessen. Frühere Direktmessungen behalten ihre eigenen Datumsangaben.
Vier ESP32-S3-Ziele: W12, CoreSE Precision Clock, StickS3 und CoreClock. CoreSE ergänzt eine Touchscreen-Uhr, sechs Diagnoseseiten und ein separates Instrument zur Holdover-Beobachtung. CoreClock ist nicht öffentlich verfügbar.
PToB nutzt Zeitfunktionen der nRF52- und ESP32-S3-Plattformen, die sich auf kompatiblen Geräten wiederverwenden lassen. Die gemessenen Zielkonfigurationen stehen hier anderen BLE-Zeituntersuchungen gegenüber.
| Ansatz | Übertragung und Hardware | Berichtete Präzision | Messung und Bedingungen | Protokoll / Standard |
|---|---|---|---|---|
| ESP32-S3 · PToB24. Oktober 2026 | Passiver BLE-Advertising-EmpfangMeshnology W12 · ESP32-S3-Empfänger | 60,3 ns RMS der ausgegebenen Uhr im relativen PPS-Vergleich · einschließlich BiasP95 122 ns · P99 156 ns · Max. 180 ns | Lokale GNSS-PPS-BeobachtungZwei Fenster von 300 s; 522/600 auswertbar, 78 nicht verfügbar. Stabiles zweites Fenster: 38,3 ns RMS, 300/300. Nachgelagertes Relais: 61,9 ns RMS, 451/600, Max. 211 ns. Physische Ausgabe und kalibrierte UTC-Genauigkeit nicht nachgewiesen. | Öffentlicher ProtokollvorschlagW12-Empfänger mit feiner Uhr; empirische RX-Erfassung und kausale Uhrenabbildung. |
| nRF52 · PToB12. Oktober 2026 | Passiver BLE-Advertising-EmpfangHeltec T096 · nRF52840 · ein Relais | 62,5 ns RMS im PPS-Vergleich über ein RelaisP95 123,25 ns · P99 160,25 ns · Max. 191 ns | Unabhängige lokale PPS-Beobachtung601,576 s; 436/602 auswertbar/erwartet (72,425 %). RMS einschließlich Bias; Kalibrierung vor der Validierung eingefroren. GPIO-Ausgabe nicht unabhängig gemessen. | Öffentlicher ProtokollvorschlagPTP-inspirierter Dienstvertrag, Profile und Übertragungsformat. Kein verabschiedeter Standard. |
| Nordic-Timeslot-Demo2016 | Proprietäre Funkzeitfenster100 Hz · im zitierten Versuch ohne konkurrierenden Stack | 65,6 ns Mittlere GPIO-DifferenzStandardabweichung 41,0 ns · Max. 220 ns | GPIO-Vergleich mit Logikanalysator30 Minuten; 439.445 Umschaltungen. Zwei benachbarte nRF52-Entwicklungskits. | Offener ReferenzcodeHerstellerdemo mit proprietären Zeitpaketen; kein standardisierter BLE-Zeitdienst. |
| MicroSync2024 | Verbindungsorientiertes BLEnRF52840 · Zentrale und drei Peripheriegeräte | 272 ns Mittlerer absoluter FehlerStandardabweichung 319,2 ns · 99%-CDF 591,25 ns · RMS nicht angegeben | Externer GPIO-Vergleich · 800 MHzHochgenaue Ereignisplanung. Bidirektionaler Austausch und PA/LNA-Zeitsignale. | Veröffentlichtes ForschungsprotokollÜbertragung über BLE-Verbindungen. Synchronisation und Zeitplanung sind im Paper beschrieben. |
| BlueSync2021 / 2022 | Verbindungslose BLE-BakenHardware-Ereigniserfassung und ergänzende Zeitstempel | 320 ns Mittlerer Synchronisationsfehler je 60 sBeste berichtete Einstellung · ein Funkabschnitt | Zwei handelsübliche BLE-SoCsSitzungen von 10 Minuten ohne erneuten Abgleich. Driftbehandlung und Paketeinstellungen variieren. | Veröffentlichtes ForschungsprotokollÜbertragung über BLE-Baken. Zeit- und Driftverfahren sind im Paper beschrieben. |
| CheepSync2015 / 2016 | BLE-AdvertisingnRF24Cheep-Sender · Android-Empfänger | ~10 µs Mittlere Genauigkeit über einen FunkabschnittHardwarenahe Zeitstempel und Fehlerkompensation | Versuche zwischen Advertising-Sendern und EmpfängernUnterschiedliche passive Empfänger auf Hardware mit knappen Ressourcen. | Veröffentlichtes ForschungsprotokollAuf Basis von Bluetooth-4.0-Advertising. Der Zeitdienst ist im Paper beschrieben. |
Die Zeilen sind nach dem angezeigten Zeitwert geordnet. RMS, mittlerer absoluter Fehler, Standardabweichung und mittlere GPIO-Differenz sind unterschiedliche Kennzahlen aus unterschiedlichen Versuchsbedingungen. Die Studien liefern keinen Vergleich der Ausgabegenauigkeit oder des Energiebedarfs unter gleichen Bedingungen. BLE allein definiert keinen standardisierten Zeitdienst.
Messmethoden lesenMit Geräten in der Nähe beginnen. Einen Ersatz-Grandmaster ergänzen, das Netz durch Relais-Uhren erweitern und Zeit über USB in macOS bereitstellen.
Aufbauszenarien erkundenSynchronisiere ESP32-S3-Sensoren per Bluetooth Low Energy ohne GPS oder UTC. Sieh, wie ein SoftPLL den Uhrendrift korrigiert, und starte das Beispiel am Computer.
Ein Einstieg in das Protokoll, die Messungen und die noch offenen Aufgaben.
PToB steht für Precision Time over BLE, also Bluetooth Low Energy. Es ist ein experimentelles, von PTP inspiriertes Protokoll zum Uhrenabgleich zwischen Mikrocontrollern. Empfänger erfassen Funkereignisse mit Zeitstempeln, bestimmen mit ergänzenden Daten deren Sendezeitpunkte und verfolgen Zeitversatz und Drift mit einer Software-Regelschleife (Software PLL). PToB ist ein unabhängiger Vorschlag und kein verabschiedeter Standard der Bluetooth SIG oder des IEEE. Die Zeitarchitektur erkunden.
Im W12-ESP32-S3-Versuch vom 24. Oktober 2026 betrug die Abweichung der ausgegebenen BLE-Uhr gegenüber unabhängig erfassten lokalen PPS-Beobachtungen 60,3 ns RMS einschließlich Bias: 522 von 600 Beobachtungen waren auswertbar, 78 nicht verfügbar; der größte gemessene Fehler betrug 180 ns. Das Ergebnis gilt für diese Hardware, diesen Pfad und diese Population. RMS ist keine garantierte Fehlergrenze; absolute UTC-Genauigkeit und durchgängige Verfügbarkeit sind nicht nachgewiesen. Messungen und Grenzen lesen.
Der experimentelle macOS-Client für Apple-M-Chips empfängt Zeit über eine per USB angeschlossene PToB-Uhr und nutzt eine eigene chrony-Uhr im Benutzerkontext. Die Systemuhr bleibt unverändert. Die berichtete Übereinstimmung mit derselben Quelle ist von unabhängiger UTC-Genauigkeit zu unterscheiden; zurückgehaltene Beobachtungen bleiben Teil der Ergebnisse. Die USB/macOS-Ergebnisse ansehen.
PToB hat einen separaten experimentellen LoRa-Zeitpfad. Die geplante Erweiterung für größere Entfernungen nutzt schmalere Kanäle, kurze Aussendungen, Kanalwechsel und eine Laufzeitkorrektur anhand bekannter Entfernungen bei festen Installationen. Reichweite und ausgegebene Präzision müssen gemessen werden; die BLE-Ergebnisse weisen keine LoRa-Leistung nach. Die LoRa-Entwicklungsrichtung lesen.
Entdecken Sie die Paper, Methoden und Messergebnisse hinter PToB. Im Forschungsportal finden Sie zu jeder Studie eine Zusammenfassung, die Messgrundlage und ihre Grenzen.
Zum Forschungsportal Ergebnisse auf GitHub ansehen (Englisch)Architektur, Messgrundlage und Grenzen eines BLE-Zeitnetzes mit gemeinsamer Zeitquelle.
Wie Quellen, Empfänger und Relais Zeit verteilen und ihren Ursprung nachvollziehbar halten.
Kostengünstige Zeitübertragung mit vorhandenem Starlink, WLAN-Beacons und ESP32-S3: 19,226/8,240 µs RMS in zwei Läufen mit GNSS-Phasenkalibrierung. Übertragbare UTC-Genauigkeit bleibt unqualifiziert.
Jonathan Yantis leitet Hardwareentwicklung, Protokolldesign und Forschung. GPT 6.1 trägt zu Implementierung, Analyse und Dokumentation bei.