Zeitübertragung unter einer Mikrosekunde auf ESP32 mit passivem BLE
Das richtige Ereignis erfassen, Uhrendrift verfolgen und Vorhersagen prüfen: So erreichte passive BLE-Zeitübertragung auf einem gemessenen ESP32-S3-Pfad RMS-Werte im Bereich einiger zehn Nanosekunden.
Eine preiswerte ESP32-Platine kann einer Funkquelle allein durch Zuhören überraschend genau folgen. Unsere jüngsten PToB-Messungen auf ESP32-S3 W12 ergaben 60,3 ns relativen Zeitfehler als RMS bei 522 auswertbaren von 600 protokollierten Beobachtungen. Der größte auswertbare Fehler betrug 180 ns, deutlich unter einer Mikrosekunde beziehungsweise 1.000 ns. Die übrigen 78 Beobachtungen waren beim Quellenwechsel nicht verfügbar und bleiben Teil des Ergebnisses.
Die Zeit kommt durch passiven BLE-Empfang. Der Empfänger hört ausgesendete Zeitpakete und ihre späteren Korrekturen und führt seine eigene Uhr zwischen Aktualisierungen weiter. Nicht jede Zeitmessung braucht einen Anfrage-Antwort-Austausch.
Dafür mussten wir die Grenzen einer Architektur überwinden, die Pakete bequem an Anwendungen liefern soll. Präzise Zeitübertragung stellt eine anspruchsvollere Frage: Wann genau fand das relevante Ereignis statt?
Warum passiver Empfang interessant ist
Eine Aussendung kann viele Empfänger versorgen. Ein weiterer Empfänger verlangt keinen eigenen Zeitaustausch mit der Quelle. Das ist eine reizvolle Grundlage für Sensoren und Instrumente, die über einen Raum oder ein lokales Mesh hinweg eine gemeinsame Zeit brauchen.
Passiv beschreibt hier, wie der Empfänger seine Zeitbeobachtungen gewinnt. PToB hat auch authentifizierten Zulassungs- und Erneuerungsverkehr; ein Relais sendet seinen eigenen Zeitstrom. Die Aussage betrifft den ausgesendeten Zeitpfad und verspricht nicht, dass jedes Gerät sein ganzes Leben funkstill bleibt.
Diese Architektur vermeidet individuelle Zeitantworten je Empfänger. Künftige Kapazität und Energiebedarf müssen weiterhin gemessen werden; auch ein ständig empfangender Funkchip hat seinen Preis.
Der Callback kommt nach dem Ereignis
Naheliegend wäre, die lokale Uhr zu lesen, sobald der Bluetooth-Stack ein Paket meldet. Das erfasst, wann Software die Nachricht verarbeitet. Funkverarbeitung, Interrupts, Warteschlangen und andere Arbeit können zwischen Empfang und Callback liegen. Ihre Verzögerungen schwanken.
Außerdem gibt es im Chip mehrere Uhren. Der Bluetooth-Controller plant Funkaktivität in einem Koordinatensystem, lokale Peripherie zählt in einem anderen. Zwei Abfragen können beide präzise sein und dennoch verschiedene Momente beschreiben. Gleichzeitig läuft der Empfängeroszillator etwas schneller oder langsamer als die Quelle; eine einmalige Korrektur veraltet deshalb bald.
Diese Effekte werden erheblich, wenn das gesamte Fehlerbudget nur einen Bruchteil einer Mikrosekunde beträgt. Mehr Nachkommastellen holen unterwegs verlorene Zeitinformation nicht zurück.
Das Ereignis erfassen und das Paket zuordnen
Unser feiner Empfangspfad erfasst eine Flanke der Funk-Empfangsaktivität mit einer Hardwareperipherie gegen einen kontinuierlichen 80-MHz-Zähler. Software kann den gespeicherten Zählerstand später abholen. Die 12,5-ns-Takte geben ein feines Messraster; sie garantieren keine Genauigkeit von 12,5 ns.
Als Nächstes muss diese Flanke dem richtigen Paket zugeordnet werden. BLE-Verkehr kann Wiederholungen, verschiedene Kanäle und fremde Aktivität enthalten. Wir behalten die Paketinformationen und verlangen eindeutige Zuordnung. Fehlt sie oder ist sie mehrdeutig, bleibt die Beobachtung nicht verfügbar, statt einen plausibel aussehenden Zeitstempel zu erzeugen.
Auch die erfasste Marke braucht eine feste Beziehung zur Zeitkonvention des Pakets. Wir nutzen eine paketspezifische empirische Anpassung. Exakter HF-Bezugspunkt und physische Verzögerung bleiben unqualifiziert; das ist bei der Übertragung auf andere Platinen oder Paketformate entscheidend.
Die Uhren verbunden halten
Der Empfänger modelliert, wie sein Zähler zur Quellenuhr steht: Wie weit geht er vor oder nach, und wie schnell ändert sich diese Differenz? Das übernimmt die Software-Regelschleife, die Software PLL. Wiederholte Beobachtungen halten die Beziehung aktuell; kontrollierte Anpassungen führen die ausgegebene Uhr nach.
Auch Kanalunterschiede brauchen Aufmerksamkeit. Hat ein BLE-Kanal einen etwas anderen Zeitversatz, soll eine veränderte Kanalmischung nicht wie ein plötzlich schneller laufender Oszillator aussehen. Der Schätzer berücksichtigt diese Unterscheidung beim Lernen der Uhrenrate.
Ebenso sorgfältig müssen Übergänge zwischen internen Uhren behandelt werden. Wir schließen eine Uhrenabfrage mit zwei lokalen Zählererfassungen ein, halten das Intervall kurz und protokollieren seine Breite. Kritische Befehle laufen aus internem RAM, um Schwankungen durch Flashzugriffe zu verringern. So entsteht eine vermessene Uhrenbrücke, statt zwei Softwareabfragen einfach für gleichzeitig zu halten.
Das Implementierungspaper (Englisch) behandelt Zählerüberläufe, Erfassungszuordnung, Uhrenbrücken und Anpassungsgleichungen. Die Architekturidee ist überschaubar: Das ursprüngliche Ereignis erhalten, sorgfältig zwischen Uhren umrechnen und die Drift weiterverfolgen.
Die tatsächlich verfügbare Uhr prüfen
Ein Zeitmodell kann hervorragend aussehen, wenn es erst aus einer Beobachtung lernen und sich dann gegen sie bewerten darf. Wir behalten die bei der Erfassung verfügbare Vorhersage und bewerten sie, bevor die spätere Korrektur das Modell aktualisiert.
Für die Prüfung der ausgegebenen Uhr dient ein physisches GNSS-Sekundenimpulssignal als Referenz. Bei jedem erfassten Impuls fragen wir die zuvor verfügbare BLE-Uhr ab. Die Referenz trainiert sie nicht. So prüfen wir die ausgegebene relative Empfängerzeit über die interne Anpassungskennzahl des Schätzers hinaus.
Die aktuelle Basis vom 24. Oktober enthält zwei festgelegte Fünfminutenfenster nach zwei Minuten Warmlauf. Empirische Anpassungen waren vorher eingefroren; weder wurde am letzten Fenster neu angepasst noch wurden große Fehler entfernt.
| Beobachtung | Auswertbar / protokolliert | RMS | Größter Fehler |
|---|---|---|---|
| W12, beide Fenster | 522 / 600 | 60,3 ns | 180 ns |
| W12, stabiles zweites Fenster | 300 / 300 | 38,3 ns | 121 ns |
| Über das W12-Relais | 451 / 600 | 61,9 ns | 211 ns |
RMS fasst die Fehler der auswertbaren Beobachtungen einschließlich eines bleibenden Versatzes zusammen. Das Maximum ist der größte beobachtete Fehlerbetrag; keine der Größen garantiert eine Grenze für den nächsten Lauf.
Das erste Fenster wechselte die Quelle und behielt 78 nicht verfügbare W12-Beobachtungen. Die nachgelagerte Messung hat eigene 149 nicht auswertbare Einträge. Präzision unter einer Mikrosekunde bei gültiger Uhr und durchgängige Verfügbarkeit sind getrennte Entwicklungsziele.
Dies sind relative PPS-Messungen auf den getesteten Pfaden. Kalibrierte UTC-Genauigkeit, physische Ausgangspinzeit und Übertragbarkeit auf andere Geräte bleiben offen. Das Implementierungspaper behält frühere Versuche; die spätere Basis oben hat eigene öffentliche Nachweise und Messzeilen.
Der Vergleich mit aktivem Wi-Fi FTM
Ein beeindruckender Vergleich ist Alexandre Bezroutchkos Fine-Time-Sync-Projekt. Es nutzt Wi-Fi Fine Timing Measurement, kurz FTM, um ESP32-Uhren in Beziehung zu setzen und Hardwaretimer nachzuführen. Das Projekt berichtet Ausgabejitter unter 100 ns bei einer Timer-Stellschrittweite von 25 ns.
Diese hervorgehobene Ausgabezahl ist etwas kleiner als der maximale relative Fehler von 121 ns in unserem stabilen BLE-Empfangsfenster. Die Messungen betreffen unterschiedliche Endpunkte: FTS berichtet Hardwareimpulsjitter; unser Ergebnis vergleicht eine ausgegebene Uhr mit erfassten PPS. Sie zeigen eine ähnliche Größenordnung der Zeitmessleistung und keine kontrollierte Rangfolge der Uhrengenauigkeit.
Die Architektur unterscheidet sich deutlich. FTM tauscht Frames in beide Richtungen aus und erfasst Sende- und Empfangszeit in Hardware. Die Hin-und-Rückweg-Beobachtungen liefern Informationen zur Verbindungsverzögerung; der FTS-Entwurf baut damit eine Uhrenbeziehung auf und richtet Timerereignisse aus.
Unser BLE-Empfänger gewinnt Zeit aus dem ausgesendeten Strom der Quelle. Eine entsprechende Laufzeitmessung in beide Richtungen je Beobachtung fehlt; Signallaufzeit und feste Funkverzögerungen bleiben daher Teil der Unsicherheit und empirischen Pfadanpassung. Dafür können mehrere Empfänger denselben Strom nutzen, ohne jeweils einen eigenen Zeitaustausch auszuhandeln.
Aktives FTM ist ein starker Weg zu synchronisierten Hardwareimpulsen. Passives BLE bietet eine andere Verteilarchitektur, deren gemessene relative Zeit bereits in derselben breiten Größenordnung unter einer Mikrosekunde liegt. Interessant ist, wie viel Präzision sorgfältiges Zuhören erschließen kann.
Was als Nächstes folgt
Noch müssen wir diese Präzision über Quellenwechsel, weitere Platinen und längere Beobachtungen zuverlässig machen. Die Relais-Sendezeit wird weiter aus Controllerplanung und Uhrenabbildungen geschätzt; ein verifizierter physischer Sendezeitstempel wäre eine festere Grundlage. Referenzverzögerungen, Temperatur, Last und Kalibrierungsübertragbarkeit brauchen ebenfalls eigene Messungen.
Bisher hat ein ESP32-S3 mit unserer Fine-Capture-Firmware relative Zeit mit RMS im Bereich einiger zehn Nanosekunden über passiven BLE-Empfang gezeigt. Das Forschungspaper (Englisch) erklärt die Mechanik; die aktuellen Ergebnisse halten Fehler und Lücken neben den hervorgehobenen Zahlen sichtbar.