PToB Viability: Rooted BLE Timing Meshes for Heterogeneous Edge Networks
Gesamtschau zu quellengebundenen BLE-Uhren, kausalen Ereignisabbildungen, heterogenen Relais, USB/macOS und Holdover-Stichproben, mit getrennten Nachweisen und Grenzen.
Forschung zur Bluetooth-
Zeitübertragung.
PToB erforscht Zeitübertragung zwischen Bluetooth-Geräten, USB-Clients und Linux-Gateways sowie mit Starlink über WLAN. Entdecken Sie die Hardware, die Versuchsergebnisse und deren Bedeutung für Ihren Aufbau.
Mit dem Gesamtsystem beginnen.
Der aktualisierte Viability-Preprint vom 30. Oktober verbindet quellengebundene Uhren, Zeitmesh, Hardware, USB/macOS und Holdover-Stichproben. Diese 17-seitige Gesamtschau führt in die Forschung und ihre Abwägungen ein.
Überblick lesenKostengünstige Zeitübertragung mit Ihrem Starlink
Starlink und WLAN sind schon vorhanden? Erfahren Sie, wie ein ESP32-S3 Terminal-NTP mit WLAN-Beacons kombiniert. Zwei Läufe erreichten nach vorheriger GNSS-Phasenkalibrierung 19,226 µs und 8,240 µs RMS; übertragbare UTC-Genauigkeit bleibt unqualifiziert.
Starlink-Zeitübertragung über WLAN erkundenPaper und Lesewege
Mit den Grundlagen beginnen, einer Implementierung folgen oder eine vorgeschlagene Anwendung erkunden. Jedes Paper hat eine HTML-Zusammenfassung, Angaben zum Aussagebereich und das englische Original-PDF.
Grundlagen
Das System verstehen, dann Protokoll und Messgrundlage untersuchen.
Passive Precision Time over BLE: V14 Service and Profile Release Candidate
Der V14 Release Candidate beschreibt BLE-Paketaufbau und Authentifizierung, Grandmaster-Nachfolge, Zeitübertragung über Relais, Empfängerzulassung und Angaben zur Ortszeit.
Passive Precision Time over BLE: V14 Boundary Clocks, Causal Timestamping, and Prospective One-Relay Validation
Der Weg zu V14, PPS-Vergleiche über ein Relais, Grenzen der Hardwarezeitmessung und noch ausstehende Validierung.
Implementierung und Zeitübertragung
Erkunden Sie Starlink-Zeitübertragung über WLAN, verbessern Sie die Ereigniserfassung mit Zephyr und ESP32-S3 und verfolgen Sie die Zeitübertragung zu macOS sowie einem Raspberry-Pi-NTP/PTP-Gateway.
Gepaarte Zeitübertragung von Starlink über WLAN: Kausale Filterung, Drift und GNSS-Schattenvalidierung
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.
Verlässliche Hardware-Zeitstempel in Zephyr: Ereigniszuordnung, Uhrenkontinuität und Dienstverfügbarkeit
Praktische Schnittstellenverträge und Fehlertests für Zephyr-Entwickler: Hardwareereignisse zuordnen, Zählerkontinuität erhalten und frische Quelldaten bewerten, ohne Ablaufregeln aufzuweichen.
Low-Level Timing on ESP32-S3: Event Capture, Clock Bridges, and Causal Validation
Siebenseitige Anleitung zu kontinuierlicher Hardwareerfassung, kurzen IRAM-Uhrenbrücken, kausaler Anpassung, GNSS-Beobachtung und geschätztem TX, mit klaren Kalibrierungsgrenzen.
Reducing Timing Tails and Multipath Sensitivity in an Operating BLE Precision Mesh
BLE-Zeitabweichungen und Mehrwegeausbreitung: Erfassung, Uhrenmechanismen, historische Nachweise und Validierungsplan. Kein neuer HF-Versuch, keine nachgewiesene Mehrwegeursache.
Ein Raspberry-Pi-Zeitserver am Rand eines BLE-Zeitmeshs: Gemessene M-HAT-PPS-Übertragung und Perspektiven für USB- und umgekehrte PTP-Gateways
Pi-5-/M-HAT-PPS-Übertragung: 600/600 Pulse, 872 ns RMS der GPIO-Phase und maximal 7,017 µs. NTP/PTP-Protokollprüfungen; kabelgebundener Ausgang, Linux-USB und umgekehrtes PTP bleiben ungemessen.
Beyond USB Packet Arrival: Frame-Identified Time Transfer to macOS
Fester 180-s-Vergleich von RC/DC am selben Bus: 190/267 ns kausaler USB-Vorhersage-RMS und 326/345 ns Übereinstimmung von Uhren mit gemeinsamer Quelle. Zurückgehaltene Beobachtungen bleiben enthalten.
Empirical Sub-Microsecond Holdover on BLE-Trained Software Clocks
W12-Versuche mit eingefrorenen Uhren: 64-s-Gerätegrenze in Stichproben, separate feste Kohorte mit 75 s. Spätere 24-s-Fenster, Fehlschläge und Beobachtungslücken bleiben erhalten.
Precision Bluetooth Timing on ESP32-S3: Causal Clock Discipline and Hardware Event Capture
Die ESP32-S3-Folgeuntersuchung vom 22. Oktober: 166,590 ns RMS im relativen PPS-Vergleich über 657/660 Einträge, mit separater Übertragung auf eine zweite Platine und erhaltenen großen Abweichungen.
How Much Timing Information Is Enough? Awake Hardware Evidence and Wake/Listen Energy Models for PToB
Sechs Zeitmess-Pilotläufe im Wachzustand und hypothetische Energiemodelle für Aufwachen/Empfang. 42 erneuerte von 120 Fenstern und unvollständige BLE-Beobachtungsabdeckung bleiben ausgewiesen.
Anwendungen und künftige Hardware
Vorgeschlagene Anwendungen und ihre noch nötige Validierung erkunden.
PToB-IPS: Toward GNSS-like Indoor Positioning with Surveyed BLE Timing Beacons
Vorgeschlagene Indoor-Navigationsreferenz für Roboter und Drohnen mit eingemessenen BLE-Uhren und Modellen zu Zeit, Geometrie und Bewegung. Positionsgenauigkeit noch ungemessen.
A Shared Time Base for Robotic gPTP and TSN Systems
PToB am Rand kabelgebundener Roboter-Zeitnetze: eine vorgeschlagene gemeinsame Zeitbasis, Kompatibilitätsgrenzen und ein stufenweiser Validierungsplan.
From Virtual Clock Discipline to Physical Synchronization: White Rabbit Lessons for PToB and Future Tunable Targets
Was PToB bereits implementiert, welche Kalibrierungslücken bestehen und wie ein von White Rabbit inspirierter Weg zu abstimmbaren Oszillatoren und physischer Uhrenregelung aussehen könnte.
A Shared Time Base for Indoor PNT: PToB Sensor Fusion, Selective UWB Augmentation, and a Validation Programme
Vorgeschlagene Ereigniszeitschicht für Indoor-Sensorfusion mit gezieltem UWB-Einsatz, getrennten Bewegungs-/Entfernungsbudgets und einem widerlegbaren Validierungsplan.
A Shared Time Base for Bluetooth Timecode Ecosystems: PToB Architecture, Compatibility Boundaries, and a Validation Programme
Vorgeschlagener gemeinsamer Vertrag zu Zeit, Qualität und Ereignissen für Medienadapter mit exakter Frame-/Sample-Zuordnung und ausdrücklich benannten Grenzen kommerzieller Kompatibilität.
Was die Versuche zeigen
Diese Datensätze messen unterschiedliche Uhren, Pfade und Referenzen. Jede Fehlerkennzahl zusammen mit Beobachtungszahl und Methode lesen; die Ergebnisse sind kein gemeinsamer Benchmark.
Starlink über WLAN: Was die gepaarten Läufe zeigen
Zwei Läufe nutzten jeweils 900 Sekunden Training und anschließend 900 Sekunden Auswertung. Beide Verfahren wurden pro Lauf mit denselben 900 künftigen PPS-Referenzpulsen verglichen (GNSS, ein Puls pro Sekunde); sämtliche großen Abweichungen bleiben enthalten.
Nur NTP bezeichnet die AP-freie NTP/lokale WLS900-Kontrollschätzung; NTP + WLAN bezeichnet das vorab benannte robuste AP-Modell.
| Lauf / Verfahren | RMS (µs) | Abs. P99 (µs) | Ausgewertete PPS |
|---|---|---|---|
| R1 · nur NTP | 37,180 | 67,329 | 900/900 |
| R1 · NTP + WLAN | 19,226 | 43,079 | 900/900 |
| R2 · nur NTP | 35,662 | 54,767 | 900/900 |
| R2 · NTP + WLAN | 8,240 | 20,069 | 900/900 |
Das Beacon-gestützte Ergebnis verwendet den vorab benannten robusten Filter. Jedes Verfahren hat eine eigene, vor der Validierung festgelegte GNSS-Phasenkorrektur; GNSS trainiert niemals die Frequenz. Ohne diese Korrektur bleibt der RMS-Wert der Rohphase über 200 µs. Im ersten Lauf verbessert sich der Bias, während die zentrierte Streuung leicht zunimmt; im zweiten verbessern sich beide. Andere Beacon-Fits und Servos liefern gemischte Ergebnisse.
Eine vollständige Validierungsabdeckung von 900/900 belegt keine kontinuierliche Zeitverfügbarkeit. Bei nativ nicht verfügbarer AP-Zeit bleibt das Ergebnis unbekannt.
Der getestete Aufbau nutzt eine vorhandene Antenne samt Access Point und einen ESP32-S3 W12 mit WLAN-Empfangszeitstempeln sowie GNSS zur Phasenkalibrierung und Validierung. Diese Vergleiche am PPS-Eingang belegen weder übertragbare UTC-Genauigkeit ohne GNSS noch vermessene Ausgangszeitpunkte. Frühere Fehlschläge, unvollständige Verläufe und eingefrorene Holdover-Modelle bleiben getrennt.
Ansatz und benötigte Ausrüstung ansehenPi 5: von M-HAT-PPS zur Linux-Zeit
Das feste Messfenster vom dauerte 600,026 Sekunden nach 120,041 Sekunden Aufwärmzeit. Es enthielt 600/600 neue PPS-Flanken aus derselben Quellkohorte, ohne beobachtete Pulslücken oder Dienstneustarts. Die GPIO-Phase hatte 872,002 ns RMS, ein absolutes P99 von 4,809 µs und maximal 7,017 µs; 46/600 Beobachtungen überschritten 1 µs. Alle Ausreißer bleiben enthalten.
Dies sind GPIO-IRQ-Zeitstempel relativ zu derselben Pi-Systemuhr, die chrony nachführt. Der separat abgetastete Median der chrony-Tracking-RMS-Schätzung betrug 72 ns; keine der beiden Größen misst unabhängig die UTC- oder elektrische Ausgangsgenauigkeit. Loopback-NTP und ausgehendes WLAN-PTP bestanden separate Protokollprüfungen. Ethernet war nicht verbunden; kabelgebundene Endpunkt-Zeitmessung, Linux-USB/SOF und umgekehrter PTP-Eingang bleiben ungemessen.
W12-Holdover unter einer Mikrosekunde in Stichproben
· W12 v0.2.33. Eingefrorene Uhrenmodelle werden gegen spätere authentifizierte BLE-Beobachtungen geprüft. P99 wird über den jeweils größten gemessenen Fehler jedes Laufpräfixes gebildet.
Längste vollständig nachgerechnete Geräte-Grenze
- Dauer mit P99 <1 µs in Stichproben
- 64 s
- Laufpräfixe
- 128
- P99 / größter Stichprobenfehler
- 760 / 879 ns
Diese gleitende C-1-Population ist vollständig aus akzeptierten Paaren rekonstruiert. Sie ist die längste nachgerechnete Grenze im Geräteraster und nicht der Endwert jedes Fensters.
Separate feste Kohorte ausgereifter Läufe
- Letztes bestandenes / erstes gescheitertes Alter
- 75 / 76 s
- Feste Laufpräfixe
- 128
- P99 beim bestandenen / gescheiterten Alter
- 983 / 1.028 ns
Die Nachrechnung in Sekundenschritten hält die Kohorte fest. Sie ersetzt nicht die gleitende Gerätehistorie. Spätere Fenster am Aufnahmeende beider W12-Geräte enden bei 24 Sekunden; Fehlschläge, Unbekannte und unvollständige Läufe bleiben in den Nachweisen.
Vier endliche Aufnahmen behalten 25.639 akzeptierte Paare und 10.450 numerisch nachgerechnete START/END-Paare bei. Ihre Beobachtungslücken über 250 ms zählen 212 / 338 / 292 / 213, mit Maxima von 1,688 / 1,375 / 2,188 / 1,000 s. Das Lückeninnere ist ungemessen. Temperatur bleibt reine Beobachtung; dies sind BLE-relative Fehler in Stichproben ohne durchgängige Grenze, kalibrierte UTC-/Ausgabegenauigkeit oder Qualifizierung physischer GM-Übergänge.
CoreSE: Uhren- und Beobachtungsdiagnostik
CoreSE 0.1.30 berichtet separat P99 <1 µs HOLD ≥1,75 s in Stichproben über 128 Versuche mit einem unbekannten Ausgang. Bei einem Alter des eingefrorenen Laufs von 103,4 s haben seine jüngsten 128 BLE-Beobachtungen P95/P99/MAX von 909/936/948 ns. Die 165 Beobachtungslücken über 250 ms lassen ihr Inneres ungemessen; das Modellalter ist keine Dauer durchgängiger Genauigkeit.
Precision Clock, Ansichten und Spezifikationen erkundenESP32-S3-Zeitübertragung auf W12
· Nordic-Quelle → W12-Empfänger / geschätztes Relais → T096-Referenz. Zwei 300-Sekunden-Fenster nach 120 Sekunden Warmlauf, mit W12 0.2.10 und T096 0.15.169. Empfangs- und Relaisanpassungen waren vor der Validierung eingefroren.
W12 · ausgegebene Uhr an GNSS-PPS
- Relativer PPS-RMS einschließlich Bias
- 60,3 ns
- Auswertbare / protokollierte Beobachtungen
- 522 / 600 · 87,0 %
- Mittelwert / Standardabweichung
- +40,7 / 44,5 ns
- P95 / P99 / Maximum des Betrags
- 122 / 156 / 180 ns
Alle 78 Einträge ohne verfügbare Quelle bleiben erhalten. Das erste Fenster enthält einen Quellenwechsel; das stabile zweite Fenster maß separat 38,3 ns RMS bei 300/300 Beobachtungen und 121 ns Maximum. Über beide Fenster liegen 466/522 auswertbare Fehler strikt unter 100 ns und alle 522 unter 200 ns.
Hinter dem W12-Relais · nachgelagerte T096-PPS
- Relativer PPS-RMS einschließlich Bias
- 61,9 ns
- Auswertbare / protokollierte Beobachtungen
- 451 / 600 · 75,2 %
- Mittelwert / Standardabweichung
- −5,5 / 61,7 ns
- P99 / Maximum des Betrags
- 154 / 211 ns
109 Einträge ohne Abbildung, 36 abgelaufene und vier mit ungeeigneter Referenz bleiben nicht auswertbar. Ein auswertbarer Fehler erreicht oder überschreitet 200 ns.
Sendezeitstichprobe · am nachgelagerten RX gemessen
- RMS empfangener Ausgabe einschließlich Bias
- 108,3 ns
- Bewertete / ausgewählte Sendungen
- 58 / 120 · 48,3 %
- Mittelwert / Standardabweichung
- +13,9 / 107,4 ns
- P99 / Maximum des Betrags
- 226 / 226 ns
61 ausgewählte Sendungen haben keinen passenden späteren Korrektureintrag; einer fehlen einschließende PPS-Marken. Drei bewertete Fehler erreichen oder überschreiten 200 ns. Dieser Stichprobenpfad enthält die bestehende nachgelagerte Empfangskorrektur und isoliert keine HF-Sendeverzögerung.
Die UTC-Basisreparatur erhält Nanosekundenphase: Alle 522 auswertbaren W12-Einträge haben identische relative und UTC-Bruchteilsphasen. Das separate GNSS-Vorhersagemodell maß 35,2 ns rohen / 41,9 ns abgebildeten RMS über 600/600 Vorhersagen; es prüft sein eigenes vorheriges Modell und misst keine ausgegebene BLE-Genauigkeit.
Die vollständige Zeitqualifizierung bleibt offen wegen Verfügbarkeitslücken, großer nachgelagerter Fehler und unbekannter GNSS-, GPIO-/Kabel-, HF- und absoluter UTC-Grenzen. Physische W12-Ausgabezeit und GM-Betrieb sind unqualifiziert. Diese Messungen zertifizieren keine anderen Geräte oder Profile.
W12-PPS-Stichproben (CSV) · Nachgelagerte PPS (CSV) · Alle ausgewählten TX (CSV) · GNSS-Vorhersagen (CSV) · Vollständige Ergebnisse (JSON) · Herkunft und Offline-Prüfer (Englisch)
Die Implementierung verstehen
Kontinuierliche Hardwareerfassung, Uhrenbrücken und kausale Anpassung werden in der siebenseitigen hardwarenahen Anleitung erklärt, mit Zählerarithmetik, Pseudocode und Validierungsfolge.
Zusammenfassung der ESP32-S3-Implementierung lesen Hardwarenahe Zeitanleitung lesen (PDF, 7 Seiten, Englisch) LaTeX-Quelle und Implementierungsreferenzen (Englisch)Präzise Zeit über ein T096-Relais
Ein T096-Relais führte seine eigene Uhr anhand des GMs nach und erzeugte dann einen neuen Zeitstrom für einen zweiten T096-Empfänger. An diesem Empfänger prüfte eine separat erfasste lokale PPS die an der Flanke bereits verfügbare Uhrenabbildung.
- T096-GMQuellenreferenz
- T096-RelaisNeu erzeugte Zeitdaten
- T096-EmpfängerAusgegebene UhrLokale PPS → Beobachtungsabfrage
Nur Validierung
- RMS einschließlich Bias
- 62,504 ns
- Vorzeichenbehafteter Mittelwert / Jitter ohne Mittelwert
- −18,417 / 59,729 ns
- P95 / P99 / Maximum des Betrags
- 123,25 / 160,25 / 191 ns
- Auswertbare / erwartete Grenzen
- 436 / 602 · 72,425 %
- Beobachtete PPS-Flanken / Aufnahmedauer
- 504 / 601.576 s
12. Oktober 2026 · nativer Stand 0.14.43. Gemessen wird die Phase innerhalb der Sekunde am Empfänger, mit vorher separat trainierter und eingefrorener Kalibrierung je Verbindung. Dies weist weder kalibrierte absolute UTC-Genauigkeit, Fehlergrenze am Ausgangspin, durchgängige Verfügbarkeit noch physische Präzision über zwei Relais nach.
Beobachtungslücken und Kalibrierung
Die vollständige Bilanz lautet 602 = 436 gültige kausale Vergleiche + 65 Beobachtungen mit ungültiger Referenz + 3 Flanken mit gültiger Referenz, aber abgelaufenen Abbildungen + 98 konservativ als unbeobachtet erfasste Gelegenheiten. Die längste beobachtete Referenzlücke betrug 59,017 s. Ausschläge bei ungültiger Referenz bleiben eine eigene Population; fehlende Intervalle werden nicht interpoliert.
Eine Empfangskorrektur von +10.543 ns je BLE-Verbindung wurde separat trainiert und vor diesem Lauf eingefroren. Die PPS-Beobachtung liefert weder Rückführung noch GNSS-Ausweichpfad für die BLE-Uhr. Separat erfasste Zähler behielten sechs Relais- und elf Endempfänger-Episoden mit Abbildungsablauf und Wiederkehr bei.
USB-Zeitübertragung zu einer macOS-Benutzeruhr
Das feste gleichzeitige 180-s-Fenster am selben Bus vom vergleicht einen BLE-versorgten RC und einen direkten GNSS-DC-USB-Pfad. Der kausale RC/DC-Vorhersage-RMS beträgt 190,050/267,448 ns bei 5.054/5.370 Vorhersagen. Die gleichzeitige Übereinstimmung bei gemeinsamer Quelle beträgt 325,545/344,546 ns bei 145/119 Vergleichen.
Ausgabestatus-Stichproben: 147/177 für RC und 119/177 für DC, bei 30/58 zurückgehaltenen Werten. Die Pfade nutzen getrennte GNSS-Ketten; der Bus war gemeinsam, verlängerte Versuche waren zu diesem Stichtag unvollständig. Interne Tracking-Schätzungen, kausale Vorhersage und Übereinstimmung bei gemeinsamer Quelle bleiben verschiedene Kennzahlen. Absolute UTC und durchgängige Ausgabe sind nicht qualifiziert.
Das separate Fünfminutenergebnis vom 15. Oktober bleibt verfügbar: 23–339 ns eingeschwungener Schätzer-RMS, 414 ns Übereinstimmung bei 182/236 Vergleichen und 328 ns kausaler Vorhersage-RMS. Startphase und zurückgehaltene Stichproben bleiben diesem datierten Versuch zugeordnet.
Frühere Direktmessungen nach Gerät und Referenz
· Diese drei ursprünglichen Konfigurationen behalten ihren eigenen Nachweisstichtag. Insbesondere die frühere interne ESP32-S3-Vorhersage misst etwas anderes als das aktuelle Ergebnis der ausgegebenen W12-Uhr im PPS-Vergleich.
Nordic nRF52840 · Vorwärtsvalidierung nach Warmlauf
- Nicht zentrierter RMS
- 70,197 ns
- Auswertbare / physische Beobachtungen
- 600 / 600
- Mittlerer absoluter Fehler
- 57,263 ns
- P99 / Maximum des Betrags
- 158 / 192 ns
Abfrage der bereits veröffentlichten BLE-Uhr an einer separat erfassten Referenzflanke auf demselben lokalen Hardwarezähler. Gemeinsame Flankenkorrektur von 10.516 ns separat trainiert und vor der Validierung eingefroren; kein Empfänger-GPS-Training, keine erneute Anpassung an Validierungsdaten, Zentrierung oder Ausreißerentfernung.
Nordic nRF52840 · Rückwärtsvalidierung nach Warmlauf
- Nicht zentrierter RMS
- 76,359 ns
- Auswertbare / physische Beobachtungen
- 598 / 599
- Mittlerer absoluter Fehler
- 60,376 ns
- P99 / Maximum des Betrags
- 219 / 257 ns
Abfrage der bereits veröffentlichten BLE-Uhr an einer separat erfassten Referenzflanke auf demselben lokalen Hardwarezähler. Dieselbe separat trainierte, eingefrorene Flankenkorrektur von 10.516 ns; eine nicht auswertbare kausale Abfrage bleibt im Nenner.
Espressif ESP32-S3 · Normaler 600-s-Lauf
- RMS interner veröffentlichter Vorhersagen
- 319,5 ns
- Auswertbare / physische Beobachtungen
- 359 / 359
- Mittlerer absoluter Fehler
- 244,5 ns
- P99 / Maximum des Betrags
- 930 / 1010 ns
Interne kausale Vorhersage an physischen Zielereignissen, ausgewertet mit dem zuvor veröffentlichten Uhrenmodell. Controller-Timer-Abbildung.
Feine / grobe / nicht verfügbare Uhrenansichten: 1.123 / 18 / 57 von 1.198 Stichproben. Genauigkeit an bewerteten Ereignissen belegt keine durchgängige Uhrenverfügbarkeit.
Ein Zeitergebnis richtig lesen
Was misst der PPS-Vergleich?
Eine PPS-Beobachtungsabfrage wertet die bereits veröffentlichte BLE-Uhr an einer separat erfassten Sekundenimpuls-Referenzflanke auf demselben lokalen Hardwarezähler aus. Die Referenz prüft die BLE-Uhr und trainiert sie nicht. T096-RMS enthält Bias; die Validierungsdaten wurden weder zentriert noch neu angepasst.
Welche Uhr wird geprüft?
Die aktuelle W12-Basis misst ausgegebene BLE-Zeit an GNSS-PPS-Flanken. Nachgelagerte PPS, Sendezeitstichproben und GNSS-Vorhersage bleiben getrennt. Das frühere W12-Ergebnis misst interne veröffentlichte Vorhersagen. Ein macOS-Schätzer und ein Vergleich gegen seine eigene Quelle beantworten wiederum andere Fragen.
Warum nicht verfügbare Beobachtungen behalten?
Fehlerstatistiken beschreiben die auswertbaren Beobachtungen. Die Abdeckung zeigt, wie oft der Vergleich möglich war. Fehlende Einträge und abgelaufene Abbildungen bleiben erhalten; kleiner RMS behauptet daher nie ununterbrochene Präzision.
Was noch nicht nachgewiesen ist
- RMS beschreibt die angegebene Population; er ist keine garantierte Fehlergrenze.
- Diese Messungen weisen weder unabhängig kalibrierte absolute UTC-Genauigkeit noch unabhängige elektrische GPIO-Ausgabegenauigkeit nach.
- W12 behält 78/600 nicht verfügbare PPS-Einträge; nachgelagert bleiben 149/600 nicht auswertbare Einträge und eine große Abweichung von 211 ns. Die TX-Stichprobe bewertet 58/120 bei 226 ns Maximum. Die vollständige Zeitqualifizierung bleibt offen.
- Holdover-Dauern beschreiben BLE-relative Fehler in Stichproben angegebener Populationen; Lückeninneres, durchgängige Genauigkeit, Temperaturkompensation und Qualifizierung physischer GM-Übergänge bleiben ungemessen.
- Ergebnisse gelten für die benannten getesteten Konfigurationen und Profile, nicht für jeden BLE-Mikrocontroller oder Mehrhop-Meshpfad.
- RMS, MAE, Standardabweichung und GPIO-Mittelwerte verschiedener Studien nutzen andere Referenzen und Bedingungen; sie sind kein Vergleich von Ausgabegenauigkeit oder Energie unter gleichen Bedingungen.
PToB ist ein experimenteller Protokollvorschlag, kein verabschiedeter Standard der Bluetooth SIG oder des IEEE. Indoor-Positionierung, gPTP-/TSN-Integration, medizinische Validierung, Broadcast-Genlock, kontinuierliches Holdover und physische Energiequalifizierung brauchen eigene Nachweise.
Frühere Arbeiten und öffentliche Quellen
Frühere Ausgaben bleiben unter ihren ursprünglichen URLs verfügbar. Für Zitate die passende datierte Population verwenden; ein neueres Paper verändert keinen früheren Versuch.
Früheres Viability-Paper
16. Oktober 2026 · PDF
Die ursprüngliche 15-seitige Gesamtschau vor dem aktualisierten Preprint vom 30. Oktober.
Ursprüngliches Bluetooth-Forschungspaper
2. Oktober 2026 · PDF
Direkte T096-PPS-Beobachtungen und W12-Versuche zu internen Vorhersagen.
Ursprünglicher Protokollvorschlag
2. Oktober 2026 · PDF
Der frühere Vorschlag vor der V14-Ausgabe.
Frühere USB-/macOS-Untersuchung
15. Oktober 2026 · PDF
Die separate 600-s-Untersuchung vor dem abschließenden chrony-Versuch.
Frühere fünfminütige USB-/chrony-Untersuchung
15. Oktober 2026 · PDF
Die separate Untersuchung über 300,065 s vor dem RC/DC-Vergleich am selben Bus.
Früherer V14-Protokollentwurf
30. Oktober 2026 · PDF (Englisch)
Die Fassung zur Autorenprüfung vor dem Release Candidate vom 6. November.
Früherer V14-RC1-Protokollvorschlag
12. Oktober 2026 · PDF
Die unveränderte historische Fassung, auf der der Paketexplorer beruht.