Negative Fahrtdauer im Logfile (Idee fuer Verbesserung)

Halllo,
ich kram hier nochmal ein ganz altes Ding raus, naemlich die Logfiles und das Fahrtenbuch. In beidem kommt es bei ueberschreitung der 24 Uhr Grenze waehrend des trips dazu das negative Werte fuer die Fahrtdauer angegeben werden. Zwar bekommt man nie 100% hin die fahrtdauer richtig zu rechnen weil einfach das Datum nicht mitgeloggt wird und so 3 tagesfahrten auch nur 23,59h gedauert haben koennen. Aber die einfachen paar stunden fahrten mit logfileende nach 24 Uhr lassen sich so schonmal richtig speichern.

Logfileausschnitt (anfang...ende)
$Glopus, 130.5,-10:-52:-39,,,
$GPRMC,114249.903,V,,,,,,,011207,,,N*49
....
$GPRMC,005430.302,V,,,,,,,021207,,,N*48
EOF

waehrend des naechsten aufrufens des Fahrtenbuchs erechnet Glopus offenbar die dauer, km etc nur bin ich nicht dahintergestiegen wie, denn auf die -10:-52:-36 h kam ich nie.
reale Fahrtdauer Kopfrechnen durch scharfes hinsehen 13:11:41

(M)ein Weg fuers rechnen war so.
Startzeit in Sekunden wandeln 11h*3600s+42m*60s+49s=42169s
Endzeit in sekunden wandeln
Falls ENDZEITSEKUNDEN<STARTZEITSEKUNDEN ---> ENDZEITSEKUNDEN+1*24*3600s (ohne datum "ein-facher" Uebertrag.)

Bei A habe ich versucht auf die glopus werte zu kommen. Vermute das Glopus die erste zeile nimmt und die letze und aus der zeitdifferenz die dauer ermittelt. Scheint aber nicht ganz zu stimmen? (Fuer den Fall das jede zeile sowieso angefasst wird koennte man natuerlich anhand der "nulldurchgange" den uebertrag ermitteln und so auch 3 tagesfahrten richtig angeben.)
A) 005430 00*3600+54*60+30=3270 --->
3270s-42169s=-38899s ---> -38899/3600=-10,80 (-38899 % 3600)/60=48,31 (-38899 % 3600) % 60 =19
B) 245430 24*3600+54*60+30=89670 --->
89670s-42169s=47501s ---> 47501/3600=13,19 (47501 % 3600)/60=11,68 (47501 % 3600) % 60 =41

guten morgen,

Es stimmt, er wird offenbar (und logischerweise) erst die Zeit des ersten Fixes genommen. Damit haetten sich die fehlenden 4 Minuten angefunden. Bleibt nur noch die Unschoenheit mit den negativen Eintraegen im Fahrtenbuch beim Datumswechsel.
Das Datum steht doch im logfile habe ich gerade gesehen. War wohl gestern etwas spaet das ich das nciht erkannt habe.... Damit muessten selbst 5Tagesfahrten auch richtig angegeben werden koennen. Sofern natuerlich 3Stellige zahlen moeglich sind in der anzeige.

So jetzt nochmal mit den richtigen zahlen und dem naechsten moeglichen loesungsweg. Der berueht auf verzicht von zeitfunktionen. Statt dessen strings zerpfluecken und nem chartoint.

Hier das relevante aus dem logfile. In der $Glopus-Zeile steht die Zeit die im Fahrtenbuch angezeigt wird, falls das noch nicht entdeckt wurde von einigen mtlesern hier.

$Glopus, 130.5,-10:-52:-39,,,
$GPGGA,114705.836,5227.9965,N,01329.6842,E,1,03,30.2,146.4,M,,,,0000*31
$GPRMC,114709.836,A,5227.9642,N,01329.6708,E,0.00,,011207,,,A*79
....
$GPRMC,005425.302,A,5229.3810,N,01327.4552,E,2.51,58.83,021207,,,A*58
$GPGGA,005426.302,5229.3813,N,01327.4562,E,6,00,50.0,87.5,M,,,,0000*04
EOF

Daraus die Rechnung

Datum aus GPRMC (sofern mitgelogt)
011207
021207

(07-07)+(12-12)+(02-01)=1
n=1

Zeit aus GPGGA (GPRMC wuerde natuerich auch gehen AFAIR ist GPGGA aber der standardlog Eintrag)

114705
005426

SEK=26-05 //=21
IF (SEK<0); SEK+=60; UBERTRAGSEK=1;
MIN=54-47-UEBERTRAGSEK //=07m
IF (MIN<0); MIN+=60; UBERTRAGMIN=1;
HOU=00+n*24-11-UEBERTRAGMIN //=13h |n=1

(Wenn kein GPRMC mitlaeuft also alles ohne Datum dann noch
IF (HOU<0); HOU+=24;
Somit sind zumindest viele eintagesfahrten dann nciht merh negativ Mehrtagesfahrten sind dann zwar inzwischen positiv aber (immernoch?) nicht richtig (habe leider kein log mit fix ueber mind 2 Tage))

13:07:21

Wenn es eine evtl verwendete Zeitfunktion unterstuetzt koennen natuerlich bei einer negativen zeit einfach die n*24h dazuaddiert werden.