{"format":"ptob-page","version":1,"canonical":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/","title":"Raspberry Pi time sharing with PToB, PTP and NTP — PToB Blog","description":"Our first Pi 5 M-HAT timing experiment connects BLE to Linux and NTP/PTP services. The results, monitoring tools and next USB and Ethernet bridge experiments.","language":"en","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/blog/raspberry-pi-ptp-ntp-ble/#article","representations":{"application/json":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/?format=json","text/markdown":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/?format=markdown"},"documentation":"https://ptob.dev/agent-formats.json","social":{"openGraph":{"title":"Raspberry Pi time sharing with PToB, PTP and NTP — PToB Blog","description":"Our first Pi 5 M-HAT timing experiment connects BLE to Linux and NTP/PTP services. The results, monitoring tools and next USB and Ethernet bridge experiments.","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/","type":"article","siteName":"PToB","locale":"en_US","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 over BLE feeds a Pi 5 through demonstrated M-HAT PPS, with NTP protocol checks and wired PTP testing distinguished. Dashed paths show proposed external PTP ingress and an ESP32-S31 bridge."}},"twitter":{"card":"summary_large_image","title":"Raspberry Pi time sharing with PToB, PTP and NTP — PToB Blog","description":"Our first Pi 5 M-HAT timing experiment connects BLE to Linux and NTP/PTP services. The results, monitoring tools and next USB and Ethernet bridge experiments.","image":{"url":"https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png","alt":"PToB over BLE feeds a Pi 5 through demonstrated M-HAT PPS, with NTP protocol checks and wired PTP testing distinguished. Dashed paths show proposed external PTP ingress and an ESP32-S31 bridge."}}},"citations":[],"provenance":{"sourceUrl":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/","sourceMediaType":"text/html","sourceSha256":"d41eee00a2fe77be17dceaba87d1c99158c9bd59fd2f893e0a892ba9410f0250","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/blog/raspberry-pi-ptp-ntp-ble/#webpage","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/","name":"Raspberry Pi time sharing with PToB, PTP and NTP — PToB Blog","description":"Our first Pi 5 M-HAT timing experiment connects BLE to Linux and NTP/PTP services. The results, monitoring tools and next USB and Ethernet bridge experiments.","inLanguage":"en","keywords":["Raspberry Pi 5","PTP","NTP","PPS","USB SOF","ESP32-S31","BLE time mesh"],"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/blog/raspberry-pi-ptp-ntp-ble/#breadcrumbs"},"mainEntity":{"@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#article"}},{"@type":"BreadcrumbList","@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#breadcrumbs","itemListElement":[{"@type":"ListItem","position":1,"name":"PToB","item":"https://ptob.dev/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://ptob.dev/blog/"},{"@type":"ListItem","position":3,"name":"Connecting a Raspberry Pi to the time mesh","item":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/"}]},{"@type":"Blog","@id":"https://ptob.dev/blog/#blog","url":"https://ptob.dev/blog/","name":"PToB Blog","description":"Engineering notes on shared time, inexpensive hardware and the experiments behind PToB.","inLanguage":"en","publisher":{"@id":"https://ptob.dev/#jonathan-yantis"},"isPartOf":{"@id":"https://ptob.dev/#website"},"blogPost":[{"@id":"https://ptob.dev/blog/esp32-wireless-softpll/#article"},{"@id":"https://ptob.dev/blog/esp32-clock-fundamentals/#article"},{"@id":"https://ptob.dev/blog/firmware-stability-time-mesh/#article"},{"@id":"https://ptob.dev/blog/lab-sensor-timing-economics/#article"},{"@id":"https://ptob.dev/blog/starlink-local-stratum-1-ntp/#article"},{"@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#article"},{"@id":"https://ptob.dev/blog/gnss-resilient-time-mesh/#article"},{"@id":"https://ptob.dev/blog/passive-lora-channel-hopping/#article"},{"@id":"https://ptob.dev/blog/esp32-sub-microsecond-holdover/#article"},{"@id":"https://ptob.dev/blog/local-time-utc-mesh/#article"},{"@id":"https://ptob.dev/blog/grandmaster-failover-multi-master-ensemble/#article"},{"@id":"https://ptob.dev/blog/ble-clocks-indoor-navigation/#article"},{"@id":"https://ptob.dev/blog/passive-ble-esp32/#article"},{"@id":"https://ptob.dev/blog/why-utc/#article"},{"@id":"https://ptob.dev/blog/why-ptob/#article"}]},{"@type":"BlogPosting","@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#article","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/","headline":"Connecting a Raspberry Pi to the time mesh","description":"Our first Pi 5 M-HAT timing experiment connects BLE to Linux and NTP/PTP services. The results, monitoring tools and next USB and Ethernet bridge experiments.","mainEntityOfPage":{"@id":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#webpage"},"isPartOf":{"@id":"https://ptob.dev/blog/#blog"},"author":{"@id":"https://ptob.dev/#jonathan-yantis"},"publisher":{"@id":"https://ptob.dev/#jonathan-yantis"},"inLanguage":"en","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 clocks and network time bridges","keywords":["Raspberry Pi 5","PTP","NTP","PPS","USB SOF","ESP32-S31","BLE time mesh"],"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":"Connecting a Raspberry Pi to the time mesh","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":2,"text":"From a BLE clock to Linux PPS","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#from-a-ble-clock-to-linux-pps"},{"level":2,"text":"How that compares with other PPS systems","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#how-that-compares-with-other-pps-systems"},{"level":2,"text":"Watching the whole timing path","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#watching-the-whole-timing-path"},{"level":2,"text":"The next experiment uses USB, without the HAT","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#the-next-experiment-uses-usb-without-the-hat"},{"level":2,"text":"Crossing the Pi Ethernet clock","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#crossing-the-pi-ethernet-clock"},{"level":2,"text":"Could an ESP32-S31 make a smaller bridge?","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#could-an-esp32-s31-make-a-smaller-bridge"},{"level":2,"text":"Explore the details","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#related-title"},{"level":3,"text":"Raspberry Pi / M-HAT gateway paper","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":3,"text":"Frame-identified USB transfer to macOS","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":3,"text":"Towards a multi-master ensemble","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#main"},{"level":2,"text":"Sources and further reading","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#sources-title"},{"level":2,"text":"Cite this article","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/#cite-title"}],"links":[{"text":"Jonathan Yantis","url":"https://github.com/yantisj2/PToB/blob/main/CREDITS.md"},{"text":"new seven-page paper","url":"https://ptob.dev/papers/preview/?file=%2Fpapers%2Fpi5-mhat-gateway-20261102.pdf"},{"text":"chrony’s published examples","url":"https://chrony-project.org/examples.html"},{"text":"macOS USB work","url":"https://ptob.dev/research/usb-macos-time-transfer/"},{"text":"datasheet","url":"https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html"},{"text":"Raspberry Pi / M-HAT gateway paper The seven-page draft, complete ten-minute results and proposed USB and reverse PTP paths.","url":"https://ptob.dev/research/pi5-mhat-time-gateway/"},{"text":"Frame-identified USB transfer to macOS The earlier USB experiments that motivate a Linux bridge.","url":"https://ptob.dev/research/usb-macos-time-transfer/"},{"text":"Towards a multi-master ensemble How diverse references could contribute to a flexible time mesh.","url":"https://ptob.dev/blog/grandmaster-failover-multi-master-ensemble/"},{"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/blog/raspberry-pi-ptp-ntp-ble/","url":"https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/"},{"text":"Back to the blog","url":"https://ptob.dev/blog/"},{"text":"Inspect the project evidence","url":"https://github.com/yantisj2/PToB/blob/main/evidence/README.md"}],"text":"# Connecting a Raspberry Pi to the time mesh\n\nThe M-HAT gives us a first working path from BLE time to a Pi clock. USB, wired PTP and a smaller ESP32 bridge give us several directions to explore next.\n\n[Jonathan Yantis](https://github.com/yantisj2/PToB/blob/main/CREDITS.md) 2 November 2026  7 min read\n\n![PToB over BLE feeds a Pi 5 through demonstrated M-HAT PPS, with NTP protocol checks and wired PTP testing distinguished. Dashed paths show proposed external PTP ingress and an ESP32-S31 bridge.](https://ptob.dev/blog/ptob-ptp-ntp-pi5-v2.png)\n\nConcept diagram. BLE-to-Pi PPS transfer is measured; NTP loopback and Wi-Fi PTP egress have protocol checks. Wired endpoint timing, Linux USB/SOF and reverse PTP ingress remain future experiments.\n\nIn this post\n\nA time mesh becomes more useful when it can join the clocks people already run. A workshop might have a Raspberry Pi serving NTP, a wired PTP network and sensors that need shared time without another cable. We want PToB to connect those environments, carrying time over BLE while keeping familiar tools at the network boundary.\n\nOur first experiment uses a **Raspberry Pi 5 with a repurposed Particle M-HAT**. Its nRF52840 receives authenticated PToB timing, produces a hardware pulse per second, and passes that PPS through the HAT connector to Linux. Chrony disciplines the Pi system clock. NTP and PTP services give us the beginnings of a bridge to existing network clients.\n\nThe [new seven-page paper](https://ptob.dev/papers/preview/?file=%2Fpapers%2Fpi5-mhat-gateway-20261102.pdf) records that first working path and its complete results. It also sets up the next question: can an ordinary USB cable make the Pi connection easier?\n\n## From a BLE clock to Linux PPS\n\nThe M-HAT generates its pulse with a hardware timer, so Linux does not have to schedule the edge. PPS reaches Pi GPIO16 through the existing connector; the kernel timestamps it and chrony follows its phase. Network NTP supplies coarse UTC second numbering. The current setup therefore combines a BLE-derived second boundary with a separate source for deciding which UTC second it is.\n\nThe HAT is running receiver firmware. It follows the mesh and emits pulses only while its source and timing map remain permitted. It cannot yet take an external PTP clock and become a mesh grandmaster. That direction needs its own bridge and source implementation.\n\nAfter a 120-second settling period, our final fixed **600.026-second window retained all 600 expected PPS assertions**, with one source cohort, no observed missing pulses and no service restarts. The complete GPIO timestamp population had:\n\n- **872 ns RMS** phase relative to the disciplined Pi system clock.\n- **554 of 600** observations within ±1 µs.\n- **4.809 µs absolute P99**, with a **7.017 µs maximum**.\n\nAll tails remain in those figures. Chrony’s separately sampled tracking RMS estimate had a **72 ns median**, while the HAT’s internal fit RMS had a 54 ns median. These describe different stages of the chain. GPIO phase includes interrupt capture and the clock servo’s own corrections; none of these measurements independently establishes UTC accuracy or electrical PPS accuracy.\n\nFor a first integration, ten continuous minutes is encouraging. The tails also tell us where the next experiments need to concentrate. Keeping the complete delivered path below one microsecond remains our goal.\n\n## How that compares with other PPS systems\n\nPPS can give a Linux system excellent phase information, but the capture path matters. In [chrony’s published examples](https://chrony-project.org/examples.html), a serial-port PPS server reports a tracking RMS of about 489 ns while an independent reference finds the system clock roughly 20 µs off much of the time. Interrupt timestamping delays account for most of that example’s error.\n\nThe same documentation shows a different route: PPS captured directly by an Intel I210 network hardware clock, avoiding interrupt capture. Chrony tracks that reference to about 20 ns, with independent accuracy still requiring a better reference. Those are different machines and measurement arrangements, rather than a matched benchmark against our Pi.\n\nThe useful comparison is architectural. Our sub-microsecond GPIO RMS is promising for an initial system-time experiment, but a small servo estimate can coexist with bias and larger tails. Capturing an event in the clock that timestamps network packets can remove a crossing that a GPIO-to-system-clock route still has to traverse.\n\n## Watching the whole timing path\n\nWe built a read-only monitor so that a low RMS number does not have to stand in for the health of the complete gateway. It shows BLE admission, current PPS, chrony selection and NTP/PTP readiness separately, along with the source grandmaster and immediate radio parent.\n\n[![Repository Pi timing monitor showing BLE admission, GPIO16 PPS, chrony selection and separate NTP/PTP readiness with illustrative example values.](https://ptob.dev/blog/pi5-timing-monitor-overview.jpg)](https://ptob.dev/blog/pi5-timing-monitor-overview.jpg)\n\nThe repository’s timing monitor, rendered with synthetic example data. The stages distinguish an admitted source, selected PPS and network-service readiness; Ethernet link absence remains visible. Open the image for full-size details.\n\nThe history view keeps receiver fit, chrony estimates and raw GPIO phase distinct. It preserves gaps and source changes and exports the selected window as CSV. The screenshots here demonstrate the monitoring interface; the measured population is in the paper.\n\n[![Repository timing history interface with separate clock-offset, RMS, GPIO PPS and receiver-frequency charts using synthetic observations.](https://ptob.dev/blog/pi5-timing-monitor-charts.jpg)](https://ptob.dev/blog/pi5-timing-monitor-charts.jpg)\n\nOffset and RMS history with illustrative synthetic observations, copied unchanged from the repository. Each chart names the part of the timing chain it observes. These plotted values are not the ten-minute experiment.\n\nThe actual post-run checks obtained valid NTP replies on Pi loopback and matched PTP Sync/Follow\\_Up traffic leaving Wi-Fi. **Wired Ethernet was disconnected throughout the measurement.** We have demonstrated the Pi integration and checked protocol operation; remote NTP/PTP timing still needs a peer and an independent reference.\n\n## The next experiment uses USB, without the HAT\n\nOur [macOS USB work](https://ptob.dev/research/usb-macos-time-transfer/) starts from a hardware event rather than the arrival time of a serial message. The receiver captures USB start-of-frame events against its timer. The host matches frame identity to its own clock, then uses the receiver’s source map to translate that event into shared time. A late response can still describe an earlier captured event.\n\nWe want to try that architecture on Linux using a **T096 receiver connected directly to the Pi over USB**, with the M-HAT removed from the timing path. If it works well, sharing mesh time with a Pi could become a cable-and-software job, with no repurposed HAT or GPIO PPS connection.\n\nThe Linux host association is the experiment. Apple’s frame/Mach APIs do not simply transfer to a Pi, and USB completion time does not identify the original frame boundary. Our plan is to:\n\n1. Establish device-to-host frame association in shadow mode, without steering the system clock. Retain ambiguous frames, resets, warmup and expired-source intervals.\n2. Compare fixed windows with the GPIO baseline, including bias, RMS, P99, maximum error, missing observations and behavior under load. Test direct ports, hubs and reconnects separately.\n3. Introduce a chrony feed only after validating the mapping, then measure against an independent physical reference. Chrony remains the sole system-clock owner.\n\nUSB could bypass GPIO interrupt capture and offer more observations. Whether its host-clock association improves the complete Pi result is still open.\n\n## Crossing the Pi Ethernet clock\n\nPTP Ethernet brings another clock into the chain: the NIC’s **PTP hardware clock**, or PHC. In our prepared forward path, chrony owns the system clock, a separate process transfers system time into the PHC, and PTP serves from there. The forthcoming wired tests need to measure that transfer and what an Ethernet peer actually receives, including link loss and recovery.\n\nWe also want the reverse direction: **external PTP → Pi → PToB → BLE devices**. That would let an existing wired timing network extend into places where running Ethernet is inconvenient. The PHC would follow external PTP, then a USB bridge or a suitable HAT/timer connection would associate it with the radio clock.\n\nThe tested Pi PHC exposes no external timestamp inputs or periodic-output pins. Ethernet packet timestamp support alone does not provide that physical bridge. A HAT approach needs suitable timing I/O and a measured clock association; USB needs the Linux SOF work above. Both need explicit source provenance, UTC/TAI handling and withdrawal when their reference disappears. A gateway must also avoid feeding its own exported time back into its source network.\n\n## Could an ESP32-S31 make a smaller bridge?\n\nThe ESP32-S31 is an appealing future target for us because it combines BLE with a **gigabit Ethernet MAC**. Espressif now lists it as available, and its [datasheet](https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html) documents IEEE 1588 support and transmit/receive frame timestamps. Gigabit operation requires an external PHY and suitable board design.\n\nThat gives us concrete PTP support to investigate. We still need to establish how the Ethernet clock connects to a precisely captured BLE event, what the driver exposes, and how both behave under concurrent traffic. Our existing ESP32-S3 timing implementation and results do not automatically carry across to the S31.\n\nIf those pieces work, an S31 board could offer a cheaper, smaller Ethernet-to-BLE bridge than a Pi plus HAT. Total board cost and timing performance remain to be established. An NTP mesh extension is another useful target without first meeting the PTP precision goal: it could receive mesh time and serve local clients, or potentially operate standalone with a GPS receiver supplying PPS **and UTC second labels**. Source-loss behavior, holdover and delivered NTP error would still need testing.\n\nThe M-HAT has given us a practical first route into Linux. USB may make that route easier to deploy; Ethernet clock work may connect existing PTP installations; a smaller MCU may bring the bridge to more places. We want a flexible time mesh that can use whichever connection fits an installation, carrying its source and measured limits along with the time.\n\nEvery timestamp needs a reference.\n**Which event did you capture?**\n\n## Explore the details\n\n[Raspberry Pi / M-HAT gateway paper The seven-page draft, complete ten-minute results and proposed USB and reverse PTP paths.](https://ptob.dev/research/pi5-mhat-time-gateway/)[Frame-identified USB transfer to macOS The earlier USB experiments that motivate a Linux bridge.](https://ptob.dev/research/usb-macos-time-transfer/)[Towards a multi-master ensemble How diverse references could contribute to a flexible time mesh.](https://ptob.dev/blog/grandmaster-failover-multi-master-ensemble/)\n\n## Sources and further reading\n\nPrimary references for the hardware and methods discussed.\n\n1. [chrony · Configuration examples and accuracy](https://chrony-project.org/examples.html)\n\n   Independent system-clock measurements, interrupt-based PPS capture and direct NIC hardware PPS timestamping.\n2. [LinuxPTP · phc2sys](https://www.linuxptp.org/documentation/phc2sys/)\n\n   Transferring time between Linux system clocks and PTP hardware clocks, with explicit direction and timescale handling.\n3. [Linux kernel · USB host-side API](https://docs.kernel.org/driver-api/usb/usb.html)\n\n   Host-controller, frame scheduling and completion semantics for the proposed Linux bridge.\n4. [Espressif · ESP32-S31-WROOM datasheet](https://documentation.espressif.com/esp32-s31-wroom-1_wroom-1u_datasheet_en.html)\n\n   Gigabit Ethernet through an external PHY, IEEE 1588 support and per-frame transmit/receive timestamps.\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 clock configuration and PTP timestamp APIs; these are capabilities to evaluate, not PToB results.\n6. [Espressif · ESP32-S31 production announcement](https://www.espressif.com/en/news/ESP32_S31_Mass_Production)\n\n   Espressif announced production availability on 27 July 2026; the S31 is a future target for this project.\n\n## Cite this article\n\nJonathan Yantis. Connecting a Raspberry Pi to the time mesh PToB Blog. Published 2 November 2026.\n\nArticle permalink: [https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/](https://ptob.dev/blog/raspberry-pi-ptp-ntp-ble/)\n\n[Back to the blog](https://ptob.dev/blog/)[Inspect the project evidence](https://github.com/yantisj2/PToB/blob/main/evidence/README.md)"}}