WSG 1000 Logpunkte teilweise doppelt, dafür fehlen am Ende Logpunkte

Beim Auslesen des Logs erhielt ich heute einen Timeoutfehler, siehe dieses Thema TMX LOG auslesen Time Out Fehler

Der Logger enthielt ca. 12.000 Trackpunkte. Ich hatte 2 "alte" Tracks drauf, die ich bereits ausgelesen hatte. Es kam dann ein 3. Track dazu. Dieser enthält die Fehler. Die anderen beiden Tracks, die ja erneut ausgelesen wurden, sind in Ordnung.

Wie man auf dem Bild sieht, setzen spätere Logpunkte Logpunkte früher wieder ein oder anders ausgedrückt. Im Punkt 1095 war es 13:15 Uhr, im nächsten Punkt, also 1096 war es 13:11 Uhr. Laut dem Log bin ich in der Zeit zurückgereist und die selbe Strecke nochmal abgefahren. Dieses "Zurückspringen" erkennt man an dem dünnen Strich in der Auswertegrafik. Es sind 257 Sekunden, wie man in der Grafik erkennen kann.
Gegen Ende des Logs bin ich wieder gesprungen, diesesmal nach vorne. Diesesmal beträgt der Sprung 260 Sekunden. Ich vermute dass ich genau die Anzahl an Wegepunkten übersprungen bin, die ich oben "doppelt" abgefahren bin. Ein paar wenige Wegepunkte, bevor ich mein Ziel erreiche, sind noch im Track vorhanden, aber wie gesagt eine Menge an Wegepunkten fehlt.
Hattet ihr schonmal etwas ähnliches? Besteht eine Möglichkeit den Track zu retten? (Vielleicht muss nur irgendein Fehler in der TK1-Datei korrigiert werden. AVWSG macht jedenfalls denselben kaputten Track aus der TK1-Datei)
Was genau ist hier passiert?

Das Problem hat sich mittlerweile geklärt. Heute trat dieses Strecken doppelt abfahren und das Springen am Ende wieder auf.
Es lag an einem Timeout-Fehler beim Logauslesen. Ich hatte heute diesen Scheiß schon wieder. Ich habe die Wegepunkte erneut ausgelesen, diesesmal ohne Timeout Fehler und siehe da, der Track passte.
Sehr seltsam ist nur, das er meldete die Prüfsumme (checksum) erfolgreich verifiziert zu haben. Die Checksumme scheint nutzlos zu sein.
Der Timeout Fehler wird hier TMX LOG auslesen Time Out Fehler bereits diskutiert.

Ich möchte aus aktuellem Anlass dieses Thema nochmal aufnehmen....

Sehe ich das richtig, dass der von Dir beschriebene Fehler mit den verwurschtelten Logpunkten nachdem ein Timeout aufgetreten war, immer nur mit der TMX Software aufgetreten ist? Oder hat auch AVWSG solche Logs erzeugt?

Hintergrund ist, dass ich beim Debuggen des Problems gesehen habe, dass nachdem ein Timeout aufgetreten ist, die Firmware einen falschen Block mit Logpunkten liefert. Er liefert dann immer den letzten Block und nicht den Block, den ich angefordert habe.

Wenn die Checksumme für den Block geschickt wird, wird auch die Startadresse des Blocks mitgeschickt. Diese ist natürlich dann nicht richtig, da es ja der letzte und nicht der aktuelle Block ist.

Glücklicherweise kann man deshalb auch erkennen, dass die Firmware einen Fehler macht und AVWSG erkennt die Situation auch und fordert den aktuellen Block erneut an. Diesemal wird auch der richtige Block und die richtige Checksumme geliefert und alles ist OK. Nur beim nächsten Block startet der ganze Mist wieder von vorn. Es wird wieder der letzte und nicht der aktuelle Block geliefert und es muss der aktuelle Block erneut angefordert werden.

Ich habe nun die Vermutung, das TMX nicht die Blockadresse beim Empfang der Prüfsumme auswertet, da sich das Programm darauf verlässt, das alles OK ist, wenn die Prüfsumme auf den empfangenen Block passt. Da aber nicht der angeforderte Block, sondern der letze Block geschickt wurde und auch die Prüfsumme für den letzten Block geschickt wurde, passt für TMX alles zusammen. Leider vergisst das Programm dann, die Blockadresse, die mit der Prüfsumme kommt daraufhin zu untersuchen, ob sie auch mit der aktuellen Blockadresse übereinstimmt. Wie gesagt, AVWSG macht dies!

Was für diese Annahme spricht ist das Beispiel von Leckeressen: der Log wurde mit 1Hz aufgenommen und wie man sehen kann ist die Zeitdifferenz zwischen Punkt 1095 und 1096 genau 257 Sekunden. Das macht 256 Trackpunkte mal 16 Byte pro Punkt = 4096 Bytes. Das ist genau ein Block im Protokoll zum Lesen des Trackspeichers!!

Wenn es diese Logdreher nicht mit AVWSG gab, wäre mit großer Sicherheit geklärt, wie es zu diesen Logdrehern kommt - es passt alles so gut zusammen.

Fazit: falls es beim Auslesen mit TMX zu Timeout-Fehler kommt, dann ist, wenn die Vermutung stimmt, die TK1 Datei Schrott. Das Problem dabei dürfte aber sein, dass ihr gar nicht unbedingt erkennen könnt, ob ein Timeoutfehler aufgetreten ist, da TMX bei einem Timeout stillschweigend die Anforderung wiederholt (nehme ich jedenfalls an).

Nach meinen bisherigen Erkenntnissen kann ich nur die Warnung ausgeben, nicht mit TMX größere Mengen des Log-Speichers auszulesen!!

Ich habe heute eine Mail an Al geschickt und ihm das Problem geschildert. Mal sehen, was er sagt.

Grüße

Andreas

Ich hatte bis jetzt immer nur mit TMX die Logs ausgelesen.
Diesesmal hatte ich es über 20 mal probiert das Log ohne TimeOut auszulesen, was nicht geklappt hatte. Ich habe mir dann manuell die TK2 Dateien (bzw. deren KML-Form) durchgesehen um einen Track zu finden, der gut ist.
Einmal sah der Track so aus, als wäre auf ca. 2 km Länge kein Fix gewesen, ein anderes mal dauerte die Fahrt über 12 Stunden (bei realen 1,5 Stunden). Ich habe es dann immer weiter probiert, bis der Track gut war.
D.h. man sollte seine Tracks immer kontrollieren bevor man die Logs löscht und solange auslesen, bis der Track vernünftig ist. Ein vermeintlich nicht vorhandener Fix kann also genauso gut ein Problem beim Auslesen sein.

Zitat

Das Problem dabei dürfte aber sein, dass ihr gar nicht unbedingt erkennen könnt, ob ein Timeoutfehler aufgetreten ist, da TMX bei einem Timeout stillschweigend die Anforderung wiederholt (nehme ich jedenfalls an).

Also es kommt schon jedesmal die Meldung Time-Out und man muss OK klicken, bevor er mit dem Auslesen weiter macht.

Ich habe Kontakt mit Al und er hat bestätigt, dass meine Vermutung bezüglich TMX stimmt und das die Firmware ein Problem hat.
D.h. meine Analyse und was ich zu diesem Thema gesagt habe ist tatsächlich richtig.

Er ist gerade dabei TMX und die Firmware zu korrigieren.

Bis es einen neue TMX Version gibt muss man davon ausgehen, dass TMX bis einschließlich zur Version 2.7.1 kaputte TK1 Dateien erstellt wenn ein Timeout beim Auslesen auftrat.

Nur nebenbei bemerkt: GPSbabel macht es genauso falsch und erzeugt kaputte TK1 Dateien falls ein Timeout beim Auslesen auftrat.

Bis eine korrigierte Version von TMX verfügbar ist, sollte man AVWSG zum Auslesen verwenden, da AVWSG dieses Problem nicht hat.

Ich denke, ich werde einen extra Warnthread erstellen, damit die Anderen gewarnt sind.

Grüße

Andreas

Vielen Dank für deine große Mühe.