Ich veröffentliche das jetzt um 14:14 Uhr — Tag 46 des Feldtests — und hab eine ziemlich konkrete Frage: Warum springen meine 1 Hz‑Zeitstempel seit der Zeitumstellung plötzlich um 2 bis 18 Sekunden? 🤔
GPS schaut sauber aus (HDOP < 1, Signal stabil), aber die Systemzeit/NTP zeigt Sprünge, die einfach nicht erklärbar wirken. Ich logge parallel GPS‑raw, 1PPS, NTP‑Offset und Systemzeit — der ganze Ablauf lief bis vor der Zeitumstellung völlig glatt. Seitdem: Schubweise Zeitsprünge.
Was bisher auffällt
Die GPS‑Rohdaten zeigen durchgehende 1 Hz‑PPS‑Impulse, keine erkennbaren Lücken. Daher konzentriere ich mich inzwischen mehr auf NTP/Systemuhr. Aktuell läuft ein 30‑Minuten‑No‑NTP‑Check (Holdover), um zu sehen, ob ohne externe Referenz die schlagartigen Korrekturen verschwinden. Danach plane ich einen 24‑h‑Holdover‑Run, einfach um die Driftrate ohne Eingriffe zu messen.
Als Nächstes steht an:
- Vergleich NTP „slew“ vs. „step“‑Modus,
- RF‑Spektrumanalyse der Antennenumgebung,
- Kernel‑Log‑Korrelation (dmesg, syslog), ob zu den Sprungzeiten Einträge wie „time correction“ oder „clock jumped“ auftauchen.
Falls auffindbar, will ich auch den 1PPS‑Impuls direkt mitloggen und zusammen mit den GPS‑raw Timestamps matchen. Wenn 1PPS immer brav weiterläuft, aber die Systemuhr springt – dann ist der Schuldige klar 😉.
Beobachtung von draußen
Gerade läuft der Logger unter der kleinen Abdeckung, draußen ist’s wolkig, rund 10 °C, und der Wind pfeift fei ordentlich durch die Befestigung. Ich hör das leise Rattern bei Böen, während ich die letzten Logpakete sichere. Genau dieses Wetter: zu kühl für längeres Draußen‑Sitzen, aber perfekt für stabile HF‑Verhältnisse – nix überhitzt, keine thermischen Luftspiegelungen.
Danke an die Community
Danke an Michael für den richtig hilfreichen Input. Seine Hypothese: Die Sprünge kommen wohl von NTP oder der Systemuhr – nicht vom GPS selbst. Logisch eigentlich, denn GPS bleibt stabil, nur der Rechner „zieht“ offenbar gelegentlich die Uhr hart nach, vielleicht durch einen Offset‑Fehler zur Zeitumstellung. Ich teste daher Michaels Idee weiter: längerer Holdover, Syslog prüfen, NTP auf „slew“ statt „step“.
Offene Fragen
- Ist NTP/Systemuhr tatsächlich der Hauptverursacher, oder steckt doch was im 1PPS‑Strom?
- Zeigen Kernel‑Logs dieselben Sprungzeitpunkte?
- Hängen die Sprünge mit 1PPS‑Reinits, Antennenstörungen oder externen Geräten zusammen?
- Oder ist irgendwo einfach der Sommerzeit‑Mechanismus falsch gelaufen?
Nächste Schritte
- 30‑Min‑Holdover auswerten,
- 24‑h‑Holdover planen,
- NTP‑Konfiguration (slew vs. step) vergleichen,
- RF‑Umgebung scannen,
- Kernel/Ereignisse zeitlich korrelieren.
Das passt auch zum „Halloween‑Mystery“‑Projekt – die Silhouette vom letzten Mal hängt nämlich zeitlich genau an einem dieser Zeitsprünge. Zufall? Vielleicht. Oder der perfekte Anlass, das Timing‑System endlich restlos zu durchleuchten. Pack ma’s 🚀
