{"format":"ptob-page","version":1,"canonical":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","title":"Zeit auf dem Raspberry Pi mit PToB, PTP und NTP — PToB-Blog","description":"Unser erstes Pi-5-/M-HAT-Zeitexperiment verbindet BLE mit Linux und NTP/PTP-Diensten. Ergebnisse, Überwachung und die nächsten Experimente mit USB- und Ethernet-Brücken.","language":"de","robots":"index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1","dates":{"published":"2026-11-02T00:00:00.000Z","modified":"2026-11-02T00:00:00.000Z"},"authors":["Jonathan Yantis"],"mainEntity":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#article","representations":{"application/json":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/?format=json","text/markdown":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/?format=markdown"},"documentation":"https://ptob.dev/agent-formats.json","social":{"openGraph":{"title":"Zeit auf dem Raspberry Pi mit PToB, PTP und NTP — PToB-Blog","description":"Unser erstes Pi-5-/M-HAT-Zeitexperiment verbindet BLE mit Linux und NTP/PTP-Diensten. Ergebnisse, Überwachung und die nächsten Experimente mit USB- und Ethernet-Brücken.","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","type":"article","siteName":"PToB","locale":"de_DE","image":{"url":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","secureUrl":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","type":"image/png","width":"1586","height":"992","alt":"PToB über BLE versorgt einen Pi 5 über den nachgewiesenen M-HAT-PPS-Pfad. NTP-Protokollprüfungen und ausstehende kabelgebundene PTP-Messungen bleiben getrennt. Gestrichelte Pfade zeigen den geplanten externen PTP-Eingang und eine ESP32-S31-Brücke."}},"twitter":{"card":"summary_large_image","title":"Zeit auf dem Raspberry Pi mit PToB, PTP und NTP — PToB-Blog","description":"Unser erstes Pi-5-/M-HAT-Zeitexperiment verbindet BLE mit Linux und NTP/PTP-Diensten. Ergebnisse, Überwachung und die nächsten Experimente mit USB- und Ethernet-Brücken.","image":{"url":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","alt":"PToB über BLE versorgt einen Pi 5 über den nachgewiesenen M-HAT-PPS-Pfad. NTP-Protokollprüfungen und ausstehende kabelgebundene PTP-Messungen bleiben getrennt. Gestrichelte Pfade zeigen den geplanten externen PTP-Eingang und eine ESP32-S31-Brücke."}}},"citations":[],"provenance":{"sourceUrl":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","sourceMediaType":"text/html","sourceSha256":"64aea89d92a88852195f694159c748d7e4d28cd200100ffff20096e63f28b2b0","rightsUrl":"https://github.com/yantisj2/PToB/blob/main/LICENSING.md"},"contentUsage":{"aiTrain":true,"search":true,"aiInput":true,"reason":"summary-or-introduction"},"structuredData":[{"@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/raspberry-pi-ptp-ntp-ble/#webpage","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","name":"Zeit auf dem Raspberry Pi mit PToB, PTP und NTP — PToB-Blog","description":"Unser erstes Pi-5-/M-HAT-Zeitexperiment verbindet BLE mit Linux und NTP/PTP-Diensten. Ergebnisse, Überwachung und die nächsten Experimente mit USB- und Ethernet-Brücken.","inLanguage":"de","keywords":["Raspberry Pi 5","PTP","NTP","PPS","USB SOF","ESP32-S31","BLE-Zeitmesh"],"isPartOf":{"@id":"https://ptob.dev/#website"},"author":{"@id":"https://ptob.dev/#jonathan-yantis"},"about":{"@id":"https://ptob.dev/#protocol"},"dateModified":"2026-11-02T00:00:00.000Z","image":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","breadcrumb":{"@id":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#breadcrumbs"},"mainEntity":{"@id":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#article"},"translationOfWork":{"@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#webpage"}},{"@type":"BreadcrumbList","@id":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#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":"Einen Raspberry Pi mit dem Zeitmesh verbinden","item":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/"}]},{"@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/raspberry-pi-ptp-ntp-ble/#article","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","headline":"Einen Raspberry Pi mit dem Zeitmesh verbinden","description":"Unser erstes Pi-5-/M-HAT-Zeitexperiment verbindet BLE mit Linux und NTP/PTP-Diensten. Ergebnisse, Überwachung und die nächsten Experimente mit USB- und Ethernet-Brücken.","mainEntityOfPage":{"@id":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#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-02T00:00:00.000Z","dateModified":"2026-11-02T00:00:00.000Z","datePublished":"2026-11-02T00:00:00.000Z","image":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","articleSection":"Linux-Uhren und Brücken zur Netzwerkzeit","keywords":["Raspberry Pi 5","PTP","NTP","PPS","USB SOF","ESP32-S31","BLE-Zeitmesh"],"wordCount":1504,"citation":[{"@type":"CreativeWork","name":"chrony · Configuration examples and accuracy","url":"https://chrony-project.org/examples.html"},{"@type":"CreativeWork","name":"LinuxPTP · phc2sys","url":"https://www.linuxptp.org/documentation/phc2sys/"},{"@type":"CreativeWork","name":"Linux kernel · USB host-side API","url":"https://docs.kernel.org/driver-api/usb/usb.html"},{"@type":"CreativeWork","name":"Espressif · ESP32-S31-WROOM datasheet","url":"https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html"},{"@type":"CreativeWork","name":"Espressif · ESP32-S31 Ethernet driver","url":"https://docs.espressif.com/projects/esp-idf/en/latest/esp32s31/api-reference/network/esp_eth.html"},{"@type":"CreativeWork","name":"Espressif · ESP32-S31 production announcement","url":"https://www.espressif.com/en/news/ESP32_S31_Mass_Production"}],"about":{"@id":"https://ptob.dev/#protocol"}}]}],"content":{"mediaType":"text/markdown","headings":[{"level":1,"text":"Einen Raspberry Pi mit dem Zeitmesh verbinden","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":2,"text":"Von der BLE-Uhr zu Linux-PPS","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#from-a-ble-clock-to-linux-pps"},{"level":2,"text":"Der Vergleich mit anderen PPS-Systemen","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#how-that-compares-with-other-pps-systems"},{"level":2,"text":"Den gesamten Zeitpfad beobachten","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#watching-the-whole-timing-path"},{"level":2,"text":"Das nächste Experiment nutzt USB, ohne HAT","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#the-next-experiment-uses-usb-without-the-hat"},{"level":2,"text":"Die Ethernet-Uhr des Pi einbeziehen","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#crossing-the-pi-ethernet-clock"},{"level":2,"text":"Könnte der ESP32-S31 eine kleinere Brücke ermöglichen?","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#could-an-esp32-s31-make-a-smaller-bridge"},{"level":2,"text":"Die Einzelheiten erkunden","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#related-title"},{"level":3,"text":"Paper zum Raspberry-Pi-/M-HAT-Gateway","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":3,"text":"USB-Zeitübertragung mit eindeutiger Frame-Zuordnung zu macOS","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":3,"text":"Auf dem Weg zum Multi-Master-Ensemble","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":2,"text":"Quellen und weitere Lektüre","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#sources-title"},{"level":2,"text":"Diesen Beitrag zitieren","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/#cite-title"}],"links":[{"text":"Jonathan Yantis","url":"https://github.com/yantisj2/PToB/blob/main/CREDITS.md"},{"text":"neue siebenseitige Paper","url":"https://ptob.dev/de/papers/preview/?file=%2Fpapers%2Fpi5-mhat-gateway-20261102.pdf"},{"text":"chronys veröffentlichten Beispielen","url":"https://chrony-project.org/examples.html"},{"text":"macOS-USB-Arbeit","url":"https://ptob.dev/de/forschung/usb-macos-zeituebertragung/"},{"text":"Datenblatt","url":"https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html"},{"text":"Paper zum Raspberry-Pi-/M-HAT-Gateway Der siebenseitige Entwurf, die vollständigen zehnminütigen Ergebnisse sowie die vorgeschlagenen USB- und umgekehrten PTP-Pfade.","url":"https://ptob.dev/de/forschung/pi5-mhat-zeitgateway/"},{"text":"USB-Zeitübertragung mit eindeutiger Frame-Zuordnung zu macOS Die früheren USB-Experimente als Ausgangspunkt für eine Linux-Brücke.","url":"https://ptob.dev/de/forschung/usb-macos-zeituebertragung/"},{"text":"Auf dem Weg zum Multi-Master-Ensemble Wie unterschiedliche Referenzen zu einem flexiblen Zeitmesh beitragen könnten.","url":"https://ptob.dev/de/blog/grandmaster-ausfall-und-uhrenensemble/"},{"text":"chrony · Configuration examples and accuracy","url":"https://chrony-project.org/examples.html"},{"text":"LinuxPTP · phc2sys","url":"https://www.linuxptp.org/documentation/phc2sys/"},{"text":"Linux kernel · USB host-side API","url":"https://docs.kernel.org/driver-api/usb/usb.html"},{"text":"Espressif · ESP32-S31-WROOM datasheet","url":"https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html"},{"text":"Espressif · ESP32-S31 Ethernet driver","url":"https://docs.espressif.com/projects/esp-idf/en/latest/esp32s31/api-reference/network/esp_eth.html"},{"text":"Espressif · ESP32-S31 production announcement","url":"https://www.espressif.com/en/news/ESP32_S31_Mass_Production"},{"text":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/","url":"https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/"},{"text":"Zurück zum Blog","url":"https://ptob.dev/de/blog/"},{"text":"Messnachweise des Projekts ansehen","url":"https://github.com/yantisj2/PToB/blob/main/evidence/README.md"}],"text":"# Einen Raspberry Pi mit dem Zeitmesh verbinden\n\nDer M-HAT bietet uns einen ersten funktionierenden Pfad von BLE-Zeit zur Pi-Uhr. USB, kabelgebundenes PTP und eine kleinere ESP32-Brücke eröffnen die nächsten Experimente.\n\n[Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 2. November 2026  7 Min. Lesezeit\n\n![PToB über BLE versorgt einen Pi 5 über den nachgewiesenen M-HAT-PPS-Pfad. NTP-Protokollprüfungen und ausstehende kabelgebundene PTP-Messungen bleiben getrennt. Gestrichelte Pfade zeigen den geplanten externen PTP-Eingang und eine ESP32-S31-Brücke.](https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png)\n\nKonzeptdiagramm. Die PPS-Übertragung von BLE zum Pi ist vermessen; Loopback-NTP und ausgehendes WLAN-PTP wurden auf Protokollebene geprüft. Zeitübertragung zu kabelgebundenen Endpunkten, Linux-USB/SOF und umgekehrter PTP-Eingang bleiben künftige Experimente.\n\nIn diesem Beitrag\n\nEin 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.\n\nUnser 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.\n\nDas [neue siebenseitige Paper](https://ptob.dev/de/papers/preview/?file=%2Fpapers%2Fpi5-mhat-gateway-20261102.pdf) 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?\n\n## Von der BLE-Uhr zu Linux-PPS\n\nDer 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.\n\nAuf 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.\n\nNach 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:\n\n- **872 ns RMS** der Phase relativ zur nachgeführten Pi-Systemuhr.\n- **554 von 600** Beobachtungen innerhalb von ±1 µs.\n- **4,809 µs absolutes P99** bei einem **Maximum von 7,017 µs**.\n\nAlle 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.\n\nFü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.\n\n## Der Vergleich mit anderen PPS-Systemen\n\nPPS kann einem Linux-System sehr gute Phaseninformation liefern, doch der Erfassungspfad ist entscheidend. In [chronys veröffentlichten Beispielen](https://chrony-project.org/examples.html) 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.\n\nDieselbe 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.\n\nDer 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.\n\n## Den gesamten Zeitpfad beobachten\n\nWir 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.\n\n[![Pi-Zeitmonitor aus dem Repository mit BLE-Zulassung, GPIO16-PPS, chrony-Auswahl und separater NTP/PTP-Bereitschaft anhand beispielhafter Werte.](https://ptob.dev/blog/pi5-timing-monitor-overview.jpg)](https://ptob.dev/blog/pi5-timing-monitor-overview.jpg)\n\nDer Zeitmonitor aus dem Repository, dargestellt mit synthetischen Beispieldaten. Die Stufen unterscheiden zugelassene Quelle, ausgewähltes PPS und Bereitschaft der Netzwerkdienste; die fehlende Ethernet-Verbindung bleibt sichtbar. Für Details in voller Größe das Bild öffnen.\n\nDie 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.\n\n[![Zeitverlaufsansicht aus dem Repository mit separaten Diagrammen für Uhrenoffset, RMS, GPIO-PPS und Empfängerfrequenz anhand synthetischer Beobachtungen.](https://ptob.dev/blog/pi5-timing-monitor-charts.jpg)](https://ptob.dev/blog/pi5-timing-monitor-charts.jpg)\n\nOffset- und RMS-Verläufe mit beispielhaften synthetischen Beobachtungen, unverändert aus dem Repository übernommen. Jedes Diagramm benennt die beobachtete Stufe der Zeitkette. Diese dargestellten Werte stammen nicht aus dem zehnminütigen Experiment.\n\nDie 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.\n\n## Das nächste Experiment nutzt USB, ohne HAT\n\nUnsere [macOS-USB-Arbeit](https://ptob.dev/de/forschung/usb-macos-zeituebertragung/) 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.\n\nWir 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.\n\nDie 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:\n\n1. 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.\n2. 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.\n3. 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.\n\nUSB könnte die GPIO-Interrupt-Erfassung umgehen und mehr Beobachtungen liefern. Ob seine Zuordnung zur Hostuhr das Gesamtergebnis auf dem Pi verbessert, bleibt offen.\n\n## Die Ethernet-Uhr des Pi einbeziehen\n\nPTP ü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.\n\nWir 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.\n\nDie 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.\n\n## Könnte der ESP32-S31 eine kleinere Brücke ermöglichen?\n\nDer 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](https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html) dokumentiert IEEE-1588-Unterstützung sowie Sende- und Empfangszeitstempel für Frames. Gigabit-Betrieb erfordert einen externen PHY und ein geeignetes Platinendesign.\n\nDamit 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.\n\nWenn 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.\n\nDer 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.\n\nJeder Zeitstempel braucht eine Referenz.\n**Welches Ereignis wurde erfasst?**\n\n## Die Einzelheiten erkunden\n\n[Paper zum Raspberry-Pi-/M-HAT-Gateway Der siebenseitige Entwurf, die vollständigen zehnminütigen Ergebnisse sowie die vorgeschlagenen USB- und umgekehrten PTP-Pfade.](https://ptob.dev/de/forschung/pi5-mhat-zeitgateway/)[USB-Zeitübertragung mit eindeutiger Frame-Zuordnung zu macOS Die früheren USB-Experimente als Ausgangspunkt für eine Linux-Brücke.](https://ptob.dev/de/forschung/usb-macos-zeituebertragung/)[Auf dem Weg zum Multi-Master-Ensemble Wie unterschiedliche Referenzen zu einem flexiblen Zeitmesh beitragen könnten.](https://ptob.dev/de/blog/grandmaster-ausfall-und-uhrenensemble/)\n\n## Quellen und weitere Lektüre\n\nPrimärquellen zu den besprochenen Geräten und Methoden.\n\n1. [chrony · Configuration examples and accuracy](https://chrony-project.org/examples.html)\n\n   Unabhängige Systemuhrmessungen, interruptbasierte PPS-Erfassung und direkte PPS-Hardwarezeitstempelung in einer Netzwerkschnittstelle.\n2. [LinuxPTP · phc2sys](https://www.linuxptp.org/documentation/phc2sys/)\n\n   Zeitübertragung zwischen Linux-Systemuhren und PTP-Hardwareuhren mit expliziter Übertragungsrichtung und Behandlung der Zeitskalen.\n3. [Linux kernel · USB host-side API](https://docs.kernel.org/driver-api/usb/usb.html)\n\n   Hostcontroller, Frame-Zeitplanung und Abschlusssemantik für die vorgeschlagene Linux-Brücke.\n4. [Espressif · ESP32-S31-WROOM datasheet](https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html)\n\n   Gigabit-Ethernet über einen externen PHY, IEEE-1588-Unterstützung und Sende-/Empfangszeitstempel pro Frame.\n5. [Espressif · ESP32-S31 Ethernet driver](https://docs.espressif.com/projects/esp-idf/en/latest/esp32s31/api-reference/network/esp_eth.html)\n\n   RGMII, Ethernet-Taktkonfiguration und PTP-Zeitstempel-APIs. Dies sind zu prüfende Fähigkeiten, keine PToB-Ergebnisse.\n6. [Espressif · ESP32-S31 production announcement](https://www.espressif.com/en/news/ESP32_S31_Mass_Production)\n\n   Espressif gab die Produktionsverfügbarkeit am 27. Juli 2026 bekannt; der S31 ist ein künftiges Ziel dieses Projekts.\n\n## Diesen Beitrag zitieren\n\nJonathan Yantis. Einen Raspberry Pi mit dem Zeitmesh verbinden PToB-Blog. Veröffentlicht am 2. November 2026.\n\nDauerhafter Artikellink: [https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/](https://ptob.dev/de/blog/raspberry-pi-ptp-ntp-ble/)\n\n[Zurück zum Blog](https://ptob.dev/de/blog/)[Messnachweise des Projekts ansehen](https://github.com/yantisj2/PToB/blob/main/evidence/README.md)"}}