Einen Raspberry Pi mit dem Zeitmesh verbinden

Ein Zeitmesh wird nützlicher, wenn es die bereits vorhandenen Uhren einbinden kann. In einer Werkstatt könnten ein Raspberry Pi als NTP-Server, ein kabelgebundenes PTP-Netz und Sensoren stehen, die ohne zusätzliches Kabel eine gemeinsame Zeit benötigen. Wir möchten diese Umgebungen mit PToB verbinden: Zeit über BLE übertragen und an der Netzwerkgrenze vertraute Werkzeuge weiterverwenden.

Unser erstes Experiment verwendet einen Raspberry Pi 5 mit einem umfunktionierten Particle M-HAT. Dessen nRF52840 empfängt authentifizierte PToB-Zeit, erzeugt jede Sekunde einen Hardwarepuls und leitet dieses PPS über den HAT-Stecker an Linux weiter. Chrony führt die Pi-Systemuhr nach. NTP- und PTP-Dienste bilden den Anfang einer Brücke zu vorhandenen Netzwerkclients.

Das neue siebenseitige Paper dokumentiert diesen ersten funktionierenden Pfad mit allen Ergebnissen. Es führt auch zur nächsten Frage: Kann ein gewöhnliches USB-Kabel die Anbindung des Pi vereinfachen?

Von der BLE-Uhr zu Linux-PPS

Der M-HAT erzeugt seinen Puls mit einem Hardwaretimer; Linux muss die Flanke daher nicht zeitlich auslösen. PPS erreicht Pi-GPIO16 über den vorhandenen Stecker. Der Kernel versieht es mit einem Zeitstempel, und chrony folgt seiner Phase. Netzwerk-NTP liefert die grobe UTC-Sekundenzuordnung. Der aktuelle Aufbau kombiniert somit eine aus BLE abgeleitete Sekundengrenze mit einer separaten Quelle, die bestimmt, welche UTC-Sekunde gemeint ist.

Auf dem HAT läuft Empfängerfirmware. Sie folgt dem Mesh und gibt nur dann Pulse aus, wenn Quelle und Zeitabbildung weiterhin gültig und zugelassen sind. Externes PTP kann sie noch nicht übernehmen, um damit zum Mesh-Grandmaster zu werden. Diese Richtung erfordert eine eigene Brücke und eine neue Quellenimplementierung.

Nach einer Einschwingzeit von 120 Sekunden enthielt unser abschließendes festes 600,026-Sekunden-Fenster alle 600 erwarteten PPS-Flanken: eine unveränderte Quellkohorte, keine beobachteten fehlenden Pulse und keine Dienstneustarts. Die vollständige Population der GPIO-Zeitstempel ergab:

• 872 ns RMS der Phase relativ zur nachgeführten Pi-Systemuhr.
• 554 von 600 Beobachtungen innerhalb von ±1 µs.
• 4,809 µs absolutes P99 bei einem Maximum von 7,017 µs.

Alle größeren Abweichungen sind in diesen Zahlen enthalten. Die separat abgetastete chrony-Tracking-RMS-Schätzung hatte einen Median von 72 ns; der interne Fit-RMS des HAT hatte einen Median von 54 ns. Diese Größen beschreiben unterschiedliche Stufen der Kette. Die GPIO-Phase enthält die Interrupt-Erfassung und die Korrekturen der Uhrenregelung selbst. Keine dieser Messungen belegt unabhängig die UTC-Genauigkeit oder die Genauigkeit des elektrischen PPS-Signals.

Für eine erste Integration sind zehn durchgehende Minuten ermutigend. Die größeren Abweichungen zeigen zugleich, worauf sich die nächsten Experimente konzentrieren müssen. Den gesamten Übertragungspfad unter einer Mikrosekunde zu halten, bleibt unser Ziel.

Der Vergleich mit anderen PPS-Systemen

PPS kann einem Linux-System sehr gute Phaseninformation liefern, doch der Erfassungspfad ist entscheidend. In chronys veröffentlichten Beispielen meldet ein PPS-Server mit serieller Schnittstelle etwa 489 ns Tracking-RMS. Eine unabhängige Referenz zeigt dagegen, dass die Systemuhr die meiste Zeit ungefähr 20 µs abweicht. Verzögerungen bei der Interrupt-Zeitstempelung erklären den Großteil des Fehlers in diesem Beispiel.

Dieselbe Dokumentation zeigt einen anderen Weg: Ein Intel-I210-Netzwerk-Hardwaretakt erfasst PPS direkt und umgeht damit die Interrupt-Erfassung. Chrony folgt dieser Referenz mit etwa 20 ns; um die Genauigkeit unabhängig zu bestimmen, ist weiterhin eine bessere Referenz nötig. Es handelt sich um andere Rechner und Messanordnungen, nicht um einen direkten Vergleich unter gleichen Bedingungen mit unserem Pi.

Der nützliche Vergleich betrifft die Architektur. Unser GPIO-RMS unter einer Mikrosekunde ist für ein erstes Experiment mit der Systemzeit vielversprechend. Eine kleine Regelschätzung kann jedoch gleichzeitig mit systematischem Versatz und größeren Abweichungen auftreten. Wird ein Ereignis in derselben Uhr erfasst, die Netzwerkpakete mit Zeitstempeln versieht, kann ein Übergang entfallen, den der Pfad von GPIO zur Systemuhr weiterhin durchlaufen muss.

Den gesamten Zeitpfad beobachten

Wir haben einen Monitor mit rein lesendem Zugriff entwickelt, damit eine niedrige RMS-Zahl nicht als Ersatz für den Zustand des gesamten Gateways dienen muss. Er zeigt BLE-Zulassung, aktuelles PPS, chrony-Auswahl und NTP/PTP-Bereitschaft getrennt an, ebenso den Quell-Grandmaster und den direkten Funk-Parent.

Die Verlaufsansicht trennt Empfänger-Fit, chrony-Schätzungen und rohe GPIO-Phase. Sie erhält Lücken und Quellenwechsel und exportiert das gewählte Fenster als CSV. Die Screenshots zeigen die Bedienoberfläche des Monitors; die gemessene Population steht im Paper.

Die tatsächlichen Prüfungen nach dem Lauf erhielten gültige NTP-Antworten über den Pi-Loopback und zueinander passende ausgehende PTP-Sync/Follow_Up-Nachrichten über WLAN. Kabelgebundenes Ethernet war während der gesamten Messung nicht verbunden. Wir haben die Pi-Integration demonstriert und die Protokollfunktion geprüft. Für die Zeitübertragung per NTP/PTP zu entfernten Clients fehlen noch ein Gegenüber und eine unabhängige Referenz.

Das nächste Experiment nutzt USB, ohne HAT

Unsere macOS-USB-Arbeit geht von einem Hardwareereignis aus, nicht vom Empfangszeitpunkt einer seriellen Nachricht. Der Empfänger erfasst USB-Start-of-Frame-Ereignisse relativ zu seinem Timer. Der Host ordnet den jeweiligen Frame seiner eigenen Uhr zu und übersetzt das Ereignis mithilfe der Quellenabbildung des Empfängers in gemeinsame Zeit. Eine verspätete Antwort kann daher weiterhin ein früher erfasstes Ereignis beschreiben.

Wir möchten diese Architektur unter Linux mit einem direkt per USB an den Pi angeschlossenen T096-Empfänger erproben; der M-HAT entfällt dabei aus dem Zeitpfad. Wenn das gut funktioniert, könnte zum Teilen der Mesh-Zeit mit einem Pi ein Kabel samt Software genügen, ohne umfunktionierten HAT oder GPIO-PPS-Verbindung.

Die Zuordnung zur Linux-Hostuhr ist das Experiment. Apples Frame-/Mach-APIs lassen sich nicht einfach auf einen Pi übertragen, und der Abschluss eines USB-Transfers identifiziert nicht die ursprüngliche Frame-Grenze. Unser Plan:

1. Die Frame-Zuordnung zwischen Gerät und Host im Schattenbetrieb aufbauen, ohne die Systemuhr nachzuführen. Mehrdeutige Frames, Resets, Aufwärmzeit und Intervalle mit abgelaufener Quellenberechtigung bleiben dokumentiert.
2. Feste Fenster mit der GPIO-Basis vergleichen, einschließlich systematischem Versatz, RMS, P99, maximalem Fehler, fehlenden Beobachtungen und Verhalten unter Last. Direkte Ports, Hubs und erneutes Verbinden getrennt testen.
3. Erst nach validierter Zuordnung einen chrony-Eingang einführen und dann gegen eine unabhängige physikalische Referenz messen. Chrony bleibt allein für die Systemuhr zuständig.

USB könnte die GPIO-Interrupt-Erfassung umgehen und mehr Beobachtungen liefern. Ob seine Zuordnung zur Hostuhr das Gesamtergebnis auf dem Pi verbessert, bleibt offen.

Die Ethernet-Uhr des Pi einbeziehen

PTP über Ethernet bringt eine weitere Uhr in die Kette: die PTP-Hardwareuhr der Netzwerkschnittstelle, kurz PHC. In unserem vorbereiteten Vorwärtspfad führt chrony die Systemuhr nach, ein separater Prozess überträgt die Systemzeit auf die PHC, und von dort wird PTP bereitgestellt. Die kommenden kabelgebundenen Tests müssen diese Übertragung und die tatsächlich beim Ethernet-Gegenüber ankommende Zeit messen, einschließlich Verbindungsausfall und Wiederherstellung.

Wir möchten auch die Gegenrichtung: externes PTP → Pi → PToB → BLE-Geräte. Damit ließe sich ein bestehendes kabelgebundenes Zeitnetz auf Bereiche erweitern, in denen Ethernet-Kabel unpraktisch sind. Die PHC würde externem PTP folgen. Anschließend würde eine USB-Brücke oder eine geeignete HAT-/Timer-Verbindung die PHC der Funkuhr zuordnen.

Die getestete Pi-PHC bietet weder externe Zeitstempeleingänge noch Pins für periodische Ausgaben. Unterstützung für Ethernet-Paketzeitstempel allein schafft diese physikalische Brücke nicht. Eine HAT-Lösung benötigt geeignete Timing-Ein- und Ausgänge sowie eine vermessene Uhrenzuordnung; USB benötigt die oben beschriebene Linux-SOF-Arbeit. Beide brauchen eine eindeutige Herkunft der Quelle, korrekte UTC/TAI-Behandlung und die Rücknahme der Zeitfreigabe, wenn ihre Referenz ausfällt. Ein Gateway muss außerdem verhindern, dass es seine selbst ausgegebene Zeit über das Quellnetz wieder als Eingang übernimmt.

Könnte der ESP32-S31 eine kleinere Brücke ermöglichen?

Der ESP32-S31 ist für uns ein reizvolles künftiges Ziel, weil er BLE mit einem Gigabit-Ethernet-MAC kombiniert. Espressif führt ihn inzwischen als verfügbar; sein Datenblatt dokumentiert IEEE-1588-Unterstützung sowie Sende- und Empfangszeitstempel für Frames. Gigabit-Betrieb erfordert einen externen PHY und ein geeignetes Platinendesign.

Damit gibt es konkrete PTP-Funktionen zu untersuchen. Wir müssen noch klären, wie die Ethernet-Uhr mit einem präzise erfassten BLE-Ereignis verbunden wird, was der Treiber bereitstellt und wie sich beides bei gleichzeitigem Datenverkehr verhält. Unsere vorhandene ESP32-S3-Zeitimplementierung und ihre Ergebnisse lassen sich nicht automatisch auf den S31 übertragen.

Wenn diese Teile funktionieren, könnte eine S31-Platine eine günstigere, kleinere Ethernet-zu-BLE-Brücke ermöglichen als Pi plus HAT. Gesamtkosten der Platine und Zeitübertragungsleistung sind noch zu bestimmen. Eine NTP-Erweiterung des Meshs wäre ein weiteres nützliches Ziel, auch bevor die PTP-Präzisionsanforderung erreicht ist: Sie könnte Mesh-Zeit empfangen und lokale Clients versorgen oder gegebenenfalls eigenständig mit einem GPS-Empfänger arbeiten, der PPS und UTC-Sekundenlabels liefert. Verhalten bei Quellenverlust, Holdover und der beim Client ankommende NTP-Fehler müssten weiterhin getestet werden.

Der M-HAT hat uns einen praktischen ersten Weg nach Linux eröffnet. USB könnte diesen Weg einfacher einsetzbar machen; die Arbeit an Ethernet-Uhren könnte vorhandene PTP-Installationen anbinden; ein kleinerer Mikrocontroller könnte die Brücke an weitere Orte bringen. Wir möchten ein flexibles Zeitmesh, das die jeweils passende Verbindung nutzen kann und dabei die Herkunft und die gemessenen Grenzen zusammen mit der Zeit weitergibt.