Um 11:30 sitze ich unterm Carport am Donauufer, Laptop offen, Logger blinkt gleichmäßig. Wolkig, kaum Wind, knapp 11 °C – eigentlich perfekte Testbedingungen. Und dann: plötzlich schlagen die Logs Alarm. Nach der Zeitumstellung springen die Zeitstempel zwischen 2 und 18 Sekunden. GPS‑Fix sauber, HDOP stabil, keine Spur von Positionsdrift. Also warum die Abweichungen gerade jetzt, wo alles konstant aussieht?
Seit rund sechs Wochen laufen die Feldtests mit dem 1‑Hz‑GPS‑Logger, Offline‑Buffer und den 2‑min‑Reconnect‑Zyklen. Heute, an Tag 43, wollte ich nur die Stabilität nach der Umstellung checken. Eigentlich Routine. Aber diese Drifts tauchen genau seit der Zeitumstellung auf – der Unterschied zwischen Systemzeit, GPS‑Zeit und NTP‑Holdover scheint sich seltsam zu verhalten.
Ich vergleiche gerade drei Modi: standard, frequent polling und holdover‑optimiert. Im Prinzip gleicht NTP die lokale Uhr je nach Netzverfügbarkeit unterschiedlich oft ab. Ich logge Paket‑Zyklen, Reconnect‑Events und GPS‑Pulse sekundengenau. Was auffällt: der high‑frequency‑Modus kompensiert die Drift schnell, aber ungleichmäßig – zeitweise mit Sprüngen, die eigentlich ausgeschlossen sein sollten.
Der GPS‑Teil selbst bleibt ungerührt: 1 Hz stabil, konstantes Signal. Also keine Satelliten‑Anomalie. Trotzdem schreibt das System Korrekturen in die Logs, als würde es für kurze Zeit völlig den Halt verlieren.
Offline‑Buffer‑Phase Nummer 5 heute: WLAN kurz getrennt, um zu sehen, ob Timestamp‑Integrität hält. Eigentlich soll der Buffer jeden 2‑min‑Slot fehlerfrei puffern, aber nach zwei Reconnects sehe ich winzige Desync‑Muster. 18 Sekunden Unterschied zu vorher – genug, um Messreihen zu verzerren.
Und dann kam die Halloween‑Minute.
Kurz nach 11:32 taucht im Log ein Sensor‑Name auf, den es gar nicht gibt: ENVX_ghost_03. Drei Sekundeneinträge, dann wieder weg. Gleichzeitig zieht ein Funkrauschen übers Spektrum – mit einem Pattern, das fast wie ein Flüstern klingt (ich schwöre, ich hab Gänsehaut bekommen). Sekunden später fällt mein Blick weg vom Bildschirm: zwischen den Bäumen am Donauufer steht eine dunkle Silhouette. Kein Mensch weit und breit, kein Schatten beweglich. Nur für einen Moment. Als ich genauer hinschaue – nichts mehr da. Vielleicht ein Reflex, vielleicht ein Vorbeigeher… oder einfach mein Hirn, das nach 43 Tagen Logging Geister in den Daten sucht 👻
Ich markiere die Stelle als „Halloween‑Minute“ im Log – technisch für die Analyse, aber auch, weil’s einfach zu gut ins Datum passt.
Zurück zur Realität: ich starte ein Mini‑Experiment. Zwei parallele NTP‑Instanzen – einmal frequent polling, einmal holdover‑optimiert, je zehn Minuten direkt nach einer simulierten Zeitkorrektur. Gleichzeitig variiere ich Paket‑Raten und synchronisiere die Mikrologs. Ziel: erkennen, ob bestimmte Netzzyklen die Drifts provozieren oder abfangen. Alles läuft, die Ergebnisse sind in Echtzeit notiert.
Für die kommenden Tage plane ich, die Daten über mehrere Reconnect‑Zyklen zu korrelieren – NTP‑Request‑Times, GPS‑Puls, Buffer‑Status – und daraus ein Heatmap‑Diagramm zu bauen. Holdover‑Stabilität bleibt Hauptfokus.
Also, falls jemand ähnliche NTP‑Drifts um die Zeitumstellung herum bemerkt hat: Welche Server oder Poll‑Intervalle nutzt ihr? Gibt’s bei euch auch kurze Zeitsprünge trotz stabilem GPS? Schreibt’s mir oder ladet Logs hoch – wär super, wenn wir Muster finden.
Jetzt collected ich noch schnell die Screenshots und markiere die seltsamen Sekunden im Datensatz. 11:41 Uhr – Zeit, das Ganze zu veröffentlichen.
Und vielleicht schau ich nachher nochmal runter zum Ufer… nur um sicherzugehen, dass da wirklich niemand mehr zwischen den Bäumen steht. 😉
Zu diesem Logbucheintrag gibt es zusätzliche Inhalte – im Forum ansehen.
