Hi Mika — cooler Bericht, sehr spannend, dass dein 1-Hz-GPS-Logger nach der Zeitumstellung solche Sprünge macht. Ich hab mir ein paar Gedanken gemacht — hier kommen ein paar konkrete Debug-Tipps, die (hoffentlich) weiterhelfen, ganz ohne Tee- und Kaffeedurst 
:
-–
Was ich als erste Verdächtige sehe
1. NTP-/Systemuhr-Korrekturen
Du hast ja selbst schon die NTP-Synchronisation im Fokus – sehr gut. Der Umstand, dass die Sprünge „nach der Zeitumstellung“ losgingen, spricht zumindest nicht unmittelbar gegen GPS, sondern gegen irgendwas mit „Uhr-Zeit“ oder „Zeitanzeige“ (Systemuhr/NTP).
Wenn dein System durch NTP plötzlich einen Offset korrigiert (z. B. wegen falsch eingeschätzter Driftrate), könnte das genau diese 2-18s Sprünge erzeugen.
2. GPS Raw + 1PPS + Holdover / Buffer
Du hast auch den GPS-1PPS-Impuls und Buffer-Status erwähnt — top. Wenn dein Logger zwar 1 Hz liefert, aber die Systemuhr mitnimmt und diese dann zeitweise „hinterherhinkt“ und plötzlich nachzieht, sind plötzlich große Sprünge möglich.
Auch: Falls dein GPS empfängt, aber der 1PPS-Impuls nicht sauber integriert wird (z. B. unterbrechungsbedingt durch Antennen-Kabel, Störungen oder Reconnects), wird „Zeitstempel = Systemzeit“ unzuverlässig.
3. Zeitumstellung als Trigger
dass der Effekt nach der Zeitumstellung auftritt, kann drei Dinge heißen:
Das System erkennt die Zeitumstellung (z. B. Sommer-/Winterzeit) und korrigiert damit die Uhr — doch bei Loggern mit 1 Hz und Echtzeitgebrauch ist das eher unerwünscht.
Eine Änderung in einer Logik oder Konfiguration (z. B. automatische Sommerzeitkorrektur, NTP-Serverwechsel) wurde zur Zeitumstellung aktiv.
Eventuell ist das Phänomen einfach zufällig zur Zeitumstellung durch gewissen Drift sichtbar geworden — d. h. der Logger war schon instabil, aber erst mit dem Zeitwechsel springt’s so stark auf.
-–
Meine Vorschläge: Was du systematisch prüfen könntest
Keine NTP kämpfen lassen (Holdover Test)
Sehr guter Ansatz mit dem 30-Min-No-NTP-Test. Ich würde zusätzlich vorschlagen: einmal 12 h oder 24 h im Holdover laufen lassen, um zu sehen, wie groß die Driftrate deines Systems ohne externe Zeitquelle ist.
Wenn innerhalb dieses Zeitraums kein großer Sprung passiert → starkes Indiz, dass NTP oder ein externer Eingriff die Ursache ist.
GPS 1PPS direkt ins Log
Falls nicht schon: Mach eine Spalte „1PPS-Impuls“ (ja/nein, Timestamp) und korreliere mit jedem Sprung. Wenn Sprungereignisse fast immer eine 1PPS-Unterbrechung/Reinitialisierung haben → großer Hinweis.
Zusätzlich: Prüfe, ob das Logger-Gehäuse, Antennenstörquellen oder Kabelbewegung zur Zeitumstellung (z. B. Temperaturwechsel) Einfluss haben.
System- und Kernel-Logs auf Zeitänderungen
Check /var/log/syslog oder dmesg auf Einträge wie „time correction of x seconds“ oder „adjtime: clock jumped“ etc., gerade zur Zeitumstellung. Das könnte zeigen, ob das OS intern Zeit sprunghaft korrigiert hat.
NTP-Konfiguration prüfen
Schau dir die Offset- und Drift-Logs von NTP (z. B. ntpq -p, ntpstat, chronyc tracking je nach System). Wenn du z. B. offsets wie ±10s siehst oder viele Re-Synchronisationen => Problem.
Tipp: Setze NTP auf „slew“ statt „step“, damit Zeitkorrekturen langsam passieren statt schlagartig.
Sommer-/Winterzeit‐Handling deaktivieren?
Wenn dein Logger Zeitstempel lokal generiert und nicht nur UTC abspeichert, kann eine automatische Umstellung (z. B. über tzdata) kurzfristig zu Verschiebungen führen. Vielleicht fürs Logging auf UTC ohne Sommerzeit stellen, um solche Zeitsprünge auszuschließen.
Störquellen/RF-Spektrum
Du hast das im Plan — bewusst. Wenn ein großer Sprung immer dann vorkommt, wenn z. B. dein Antennen-Gebäude oder Außenaufbau andere Geräte einschaltet (z. B. Beleuchtung, Pumpen, etc.) könnte ein kurzzeitiger Ausfall oder Verschiebung im Empfang stattgefunden haben.
-–
Hypothese nach meinem Gefühl
Ich würde auf NTP/Systemuhr-Sprünge tippen als Hauptverursacher — weil:
Du sagst „HDOP bleibt < 1, Signal stabil“ → GPS scheint sauber.
Der Zeitpunkt nach der Zeitumstellung spricht gegen „nur GPS“ und mehr für „Zeitreferenz“ oder „Systemuhr“.
Dein geplantes Testverfahren passt exakt zur Reproduktion dieses Fehlers.
Falls ich raten müsste: Dein System hat nach der Zeitumstellung eine automatische Zeitanpassung gemacht, der Logger aber auf „natürliche“ Zeitfortschreibung ohne plötzliche Korrektur eingestellt war → Logger war sozusagen „halb synchron, halb offline“, und liefert deshalb manchmal große Sprünge wenn plötzlich synchronisiert wird.
