Commit Graph

2 Commits

Author SHA1 Message Date
tobias d6e27666a3 Verschlafene Kilometer am Fahrtanfang zurueckholen
Der Dongle wacht nach dem Motorstart erst nach 28 s bis 19,5 min auf; was in
der Zeit gefahren wird, zeichnet er nicht auf. Die Kilometer holt das
Screening jetzt aus dem Endkilometerstand der Vorgaengerin zurueck und haelt
in luecke_km fest, wie viel davon betroffen ist.

Keine Sperre der GNSS-Verfeinerung, sondern eine Zerlegung: verschlafener
Anfang in ganzen Kilometern, aufgezeichneter Rest metergenau. Sonst waere die
feine Zahl systematisch zu klein und wuerde bei kleinen Luecken die Korrektur
stillschweigend wieder kassieren.

Zwei Schutzgitter, beide am Bestand gelernt: LUECKE_MAX_KM = 50 gegen
Differenzen, die keine Weckverzoegerung mehr sein koennen, und ein Rueckfall,
wenn _vollstaendig() die Werte daraufhin verwerfen wuerde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-06 16:56:14 +02:00
tobias 7f386d19ea Geraetezeit statt Ankunftszeit - die Wurzel hinter der 3-km-Fahrt (2026.9.4.1)
Das Fahrtfenster stand seit dem 01.09. in der Gerätezeit, der Verlauf war nach
Ankunftszeit sortiert. Zwei Uhren, und das Gerät puffert: was verspätet ankam,
fiel aus einem Fenster heraus, in dem es der Sache nach lag. Am 03.09. hat das
eine Fahrt gekostet - 26 von 48 GPS-Punkten und 3,0 statt 7 km.

verlauf_lesen() stempelt jeden Punkt jetzt mit der Gerätezeit seines
Datensatzes. Eine Stelle, an der alle Verbraucher vorbeikommen. Dazu zwei
Riegel aus derselben Untersuchung: ein Rückschritt von 43 Metern ist keine
Zählerrücksetzung mehr (aus 87 Metern wurden vorher 13,7 km), und das
Fahrtende wird auf das letzte Lebenszeichen des Geräts geklemmt - der Nachlauf
ist eine Rechnung, kein Messwert.

Am echten Recorder nachgerechnet: Tacho 3,0 -> 7,0 km, GNSS 2,952 -> 6,877 km,
Route 26 -> 47 Punkte, Ende 23:21:57 -> 23:17:48. Beim ersten Lauf haben zwei
Fahrten eine Strecke bekommen, die vorher gar keine hatten.

Nicht das Gerät war schuld: es hat lückenlos aufgezeichnet. Die zehn Minuten
Funkstille waren eine offene, aber tote TCP-Sitzung (flespi-Log: 703 s, 16
Nachrichten) - kein Funkloch. Begründung und die Empfehlung fürs Gerät stehen
in AGENTS.md, Abschnitt CB.

Dazu die neun Paritätsbefunde, alle Richtung Panel gelöst - darunter ein
unmaskierter Punkt in beiden Codebasen, der aus "vor 3 Tage" ein "vor 3 Tag"
machte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 02:18:12 +02:00