GPS Rollover zerstört GPS Logger

Am 6. April 2019 gab es einen GPS Week-Rollover. Davon scheinen einige GPS Logger wie der beliebte Transystem i-Blue 747 mit dem Chipsatz MT3318 oder MT3329 betroffen zu sein.

Was ist der Week-Rollover genau?

Im GPS Signal wird das Datum nur in einer verkürzten Form übermittelt. Es werden die Wochen “seit Beginn der GPS Zeitrechnung” am 6. Januar 1980 gezählt, sowie die Sekunden in der aktuellen Woche.
Aus diesen beiden Angaben kann der GPS Empfänger dann das absolute Datum berechnen.

Das Problem entsteht nun dadurch, dass um Platz zu sparen nur 10 Bit für den Wochenzähler vorgesehen wurden. Somit kann es nur 1024 verschiedene Wochen geben, danach fängt die Zählung wieder von vorn an.

Und genau so ein Überlauf von Woche 1023 zu Woche 0 ist jetzt am 6. April passiert.

Was sind die Folgen?

Ein GPS Empfänger der mit dieser Situation nicht umgehen kann wird jetzt ein Problem haben das korrekte Datum zu berechnen.
Vor allem wenn keine alternative Zeitquelle zur Verfügung steht hat es ein GPS Empfänger recht schwer zu wissen wo genau die GPS Wochen begonnen haben. Entweder Januar 1980, August 1999 oder April 2019.

Kann man das Problem lösen?

Eine einfache Möglichkeit für die Entwickler war es, das Datum der Firmware des Loggers zu kennen. Das aktuelle Datum muss immer nach dem Datum der Firmware liegen.

Beispielsweise kann ein Logger mit einer Firmware mit Herstellungsdatum vom 16. September 2005 davon ausgehen, dass das aktuelle Datum danach ist. Der 16. September 2005 entspricht der GPS Woche 316.
Wird nun eine GPS Woche empfangen, die kleiner als 316 ist, so kann sich der Logger sicher sein, dass diese Woche NACH dem Rollover vom 6. April 2019 stattgefunden hat. Das Datum kann also entsprechend angepasst werden.

Die GPS Empfänger von u-Blox und Mediatek haben genau diesen Weg gewählt und können so 20 Jahre nach dem Herstellungsdatum das GPS Datum berechnen.

Für die Modelle MT3303, MT3332, MT3333, MT3336, MT3337, MT3339 hat Mediatek das bestätigt:

Does MTK solution suffer from GPS Week Number Rollover Issue?

Yes, but we can cover the first rollover after the firmware build date.

In other words, the firmware will work properly in the next 20 years after it is built.

Und andere Modelle?

Da wird es etwas komplizierter. Ich habe Tests mit verschiedenen Modellen aus der beliebten Transystem iBlue 747 Modellreihe gemacht und auch baugleiche Modelle getestet.

BT747 zeigt Details zu dem genauen Modell (hier Transystem iBlue 747 A+), sowie zur enthaltenen Firmware an

Einige Logger funktionieren wie erwartet, andere springen auf den September 1999. Die gemeldete Firmware ist dabei identisch. Ich versuche noch die genauen technischen Details zu bekommen und werde dann diesen Artikel entsprechend anpassen.

Model Firmware Logger SW Datum OK?
001D (747/Q1000/BGL-32) M-core_1.94 V1.31 Nein
0005 (Qstarz BT-1000P) B-core_1.1 (QST1000P) V1.38 Nein
0004 (iBlue 747 A+) AXN_1.30-B_1.3_C01 (TSI_747A+) V1.39 Nein
0002 (iBlue 747A+) AXN_1.30-B_1.3_C01 (TSI_747A+) V1.39 Ja
0006 (iBlue 747A+) AXN_1.30-B_1.3_C01 (TSI_747A+) V1.39 Ja

Gibt es einen Weg das zu reparieren?

Das schönste wäre wenn die Firmware mit dem Build-Datum die GPS Woche korrigieren kann. Dazu müsste die Firmware des Loggers aktualisiert werden. Das ist ein technisch riskanter Weg bei dem der Logger auch komplett zerstört werden kann. Dafür wäre die Reparatur aber am nachhaltigsten.

Ein anderer Weg wäre beim auslesen der Daten und konvertieren in GPX einen ähnlichen Filter auf das Datum anzuwenden. Ein Datum vor einem (einstellbaren) Grenzwert wird dann als Datum nach eben diesem Grenzwert interpretiert.

Meine Versuche

Ich habe aus einem funktionierenden Logger (gemeldet als Model 0002) die Firmware ausgelesen. Diese habe ich dann auf einen Blumax eingespielt, das sich bislang als Model 0004 gemeldet hat. Die Firmwarebezeichnung und Logger-SW wie von BT747 angezeigt war dabei identisch.

Der Logger funktioniert danach immer noch, meldet sich jetzt allerdings als Model 0002 im BT747. Die schlechte Nachricht: Das Problem mit dem Datum besteht weiterhin.

Die Lösung für das Problem

Beim Suchen nach Informationsmaterial zum MT3329 Chipsatz habe ich auch verschiedene Dokumentationen zum unterstützten Befehlssatz gefunden, die alle etwas unterschiedliche Befehle dokumentieren.

Der NMEA Befehl PMTK335 erschien mit dann sehr vielversprechend. Damit lässt sich die RTC (Real-Time-Clock) des Loggers von außen einstellen. Dadurch kann der Logger schneller eine Position bestimmen. Und als kleiner Nebeneffekt stimmt hinterher auch die Datumsberechnung wieder.

Ich erwarte, dass die eingestellte Uhrzeit so lange gültig bleibt wie der Logger durch den Akku mit Strom versorgt wird. Laut Dokumentation sollte sich die Uhrzeit im Betrieb selbsttätig nachjustieren.

Nach dem Befehl kommt Jahr, Monat, Tag, Stunde, Minute, Sekunde in UTC. Nach dem Stern die NMEA Prüfsumme, die man auch online berechnen kann.

Die Zeit sollte möglichst genau eingestellt werden. Bei mir war es dann:

Zum Abschicken des Befehls habe ich den Logger an USB angeschlossen und den Virtuellen Comport mit einem Terminalprogramm geöffnet. Ich hatte Tera Term verwendet, aber es funktioniert im Prinzip jedes andere Programm auch.

Wichtig ist, dass nach dem NMEA Befehl ein Carriage-Return und Line-Feed geschickt wird.

Wichtig ist die Einstellung für das Line-End beim Senden. Das muss CR+LF sein.

Im Terminal sieht man nach dem Abschicken des Befehls auch die Bestätigung des Loggers darüber:

Der so behandelte Logger hat brav Daten aufgezeichnet, die dann mit BT747 auch mit dem korrekten Datum exportiert wurden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.