Mir ist heute aufgefallen, dass die Benennung der Tracks (also der Dateiname) falsch zu sein scheint.
Also der heutige Track heißt nicht 2022-03-26 am Anfang, sondern 2022-03-12.
Das ist das Datum meiner letzten Fahrt mit Sensor.
Der Track der mit heutigem Datum hat nur ein paar Meßpunkte vom Start.
Hat das noch jemand beobachtet?
Kann sich das mal jemand ansehen?
2 „Gefällt mir“
Hallo @nofkabu, das Problem mit der falschen Benennung von Tracks ist bekannt und auf fehlerhafte GPS Zeiten zurückgeführt, hier gibt es einen Thread zum Thema, in dem das genauer untersucht wird und in dem du deine Beobachtung einbringen könntest.
Was ich nicht genau verstanden habe ist, ob dein ganzer Track heute in den Trackpunkten das Datum des Tracks vom 12.3. geführt hat, oder ob die Datei die heute für den 12.3. geschrieben wurde großteils Punkte mit Datum von heute enthält. Auch ist mir nicht ganz klar geworden ob du für heute zwei Dateien hast, und wenn es zwei sind ob du sicher bist dass die mit dem Datum von heute am Anfang und nicht am Ende der Fahrt geschrieben wurde (als mutmaßlich die GPS-Zeit stimmte).
Spannend, denn ich lasse das Rad vor der Garage stehen, bis ich einen stabilen Satelliten Fix habe. Die Wartezeit sehe ich auch in dem Track vom 26. Sind nur drei oder vier gestreute Punkte.
Wenn ich dann losfahre, wird das aber scheinbar in die letzte Datei vom 12. geschrieben.
Ich sehe mir gleich mal den Inhalt der beiden Dateien an.
1 „Gefällt mir“
Bisher ging ich davon aus, dass das falsche Datum aufgrund einer falschen GPS-Wochen Zuordnung die vom GPS Modul kommt entsteht. Ein Bezug zur letzten Fahrt wäre ein hilfreicher neuer Hinweis. Kannst Du mir die Dateien (gerne direkt) zukommen lassen?
Ist das bei dir ein generelles oder einmaliges Problem?
Sodele. Der Inhalt der 2022-03-12 beginnt mit einem Daystamp vom 12.3. Die Zeit scheint valide und läuft sauber hoch.
Nach ca. 4 Minuten kommt dann der Sprung zum aktuellen Datum.
Sieht ein bisschen nach GPS Signal aus. Ich meine, hier wird ähnlich wie im DCF erst Sekunden, Minuten und Stunden gesynced. Könnte also durchaus sein, dass der Fix als okay angezeigt wird, obwohl das Datum noch nicht da ist.
Damit steht dann wohl zuerst das Datum aus der vorherigen ALP Datei da.
Der Timestamp läuft dann bis 13:20 Uhr. Das ist ungefähr die Zeit zu der ich wieder am Abfahrtspunkt war.
Die Datei 2022-03-26 fängt dann um 13:34 neu an.
Wie kann ich dir die Dateien zukommen lassen?
2 „Gefällt mir“
Ich hab die Daten bekommen, werd aber etwas Zeit brauchen bis ich sie anschauen kann. Danke dir.
Edit: Ich habe auch In raw cases time sent by GPS is not initially correct which leads to wrong filename and hard track rendering · Issue #294 · openbikesensor/OpenBikeSensorFirmware · GitHub angelegt. Eventuell muss ich erst mal etwas mehr ausgaben zum analysieren einbauen. Eventuell hilft es im Testportal nach weiteren solcher Zeitsprünge zu suchen.
Ich werde nachher eine v0.15.x vor-release veröffentlichen. In der Version wird das GPS Datum bereits etwas später gesetzt. Zusätzlicher wird eine Änderung in der GPS Woche aber auch extra erfasst und ins CSV geschrieben. Es wird bisher nichts unternommen, die Datei nochmal umzubenennen, dazu will ich erst etwas genauer wissen, wie das passiert.
Also bitte v0.15.x Runterladen und mir die CSVs zur Auswertung zukommen lassen. Interessant sind insbesondere CSVs mit dem Datumssprung oder mit mehreren gps week changed Einträgen (einer ist normal).
Mir fiel gerade das Problem auch auf. Wir haben allerdings noch Version 0.12.720 laufen. In meiner Datei ist auch ein Datumssprung. Nur zur Info. Muss wohl mal wieder updaten, aber soweit ich im Release-Log sehen konnte, gibt es da noch keinen Fix?
Ja bitte updaten. Und ja, einen Fix für dieses Problem gibt es noch nicht.
1 „Gefällt mir“