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.

34 Gedanken zu „GPS Rollover zerstört GPS Logger

  1. Hallo,
    ich habe bei mir leider ebenfalls festgestellt, dass die Datumsanzeige fehlerhaft ist.
    Ich nutze einen Blumax 4044, baugleich mit dem Iblue 747a+. Do wird er auch im BT 747 angezeigt.
    ABweichend zu den ANgaben 0002, 0004 sowie 0006 wird bei mir 000F angezeigt.
    Die Firmware ist identisch mit der im Blog angegebenen.
    Nun würde ich gern die oben empfolene Änderung auch bei meinem Tracker durchführen.
    Ich bin aber nicht ganz so sattelfest in diesem Bereich und den aufgezeigten Weg kann ich schlecht nachvollziehen.
    Gibt es mittlerweile eine Einfachere Lösung oder eine genauere Beschreibung der erforderlichen Schritte?
    Für Hilfe wäre ich sehr dankbar
    Grüße Volker

  2. Hallo Ich noch einmal,
    ich habe bisher das Program Tera term installiert, die Verbindung zum Logger hergestellt und den Befehl nebst nmea Prüfsumme erstellt.
    Nur wie bekomme ich diesen Befehl an den Logger gesendet?
    Habe schon einiges Versucht aber bisher erfolglos.
    Wie komme ich nun weiter?
    Für eine Hilfe wäre ich sehr dankbar.
    Grüße Volker

  3. Schon wieder ich! 😉
    Nun habe ich es “geschafft” den Trecker in einen 747pro zu verwandeln aber mit enttäuschendem Ergebniss.
    Ich habe eine ANleitung nebst Software gefunden, die das Problem mit dem Datum beheben sollte. Hat aber leider keinen Erfolg gehabt und die Firmware ist nun die eines 747pro. Natürlich funktioniert die Datenaufzeichnung, auslesen nicht mehr.
    Verbinden kann ich den Tracker aber noch über BT747 und das Flashtool für MKT.
    In dem obrigen Block habe ich gelesen, dass die Firmware auf einen anderen Logger aufgespielt wurde. Wäre es möglich diese Firmware zu bekommen, damit ich wenigstens wieder den Originalzustand des Loggers herstellen kann?
    Ich hoffe auf positive Antworten! 😉
    Grüße Volker

    • Hallo Volker,
      mit dieser Software konnte ich die Firmware auslesen, bzw. eine neue aufspielen. Hast du deine alte Firmware gesichert?
      https://github.com/dimhoff/mt333x-fw-utils

      Es hilft sicher auch wenn du jemanden findest der einen baugleichen Logger hat der sich als Model “000F” meldet. Dann kannst du diese Firmware auslesen und bei Dir aufspielen. Ob die Firmware eines anderen Loggers funktioniert hängt von vielen Faktoren ab. Das lässt sich so nicht vorhersagen. Ein Model 0004 in 0002 umwandeln hat hier funktioniert.

      Du musst irgendwie zu einer funktionierenden Firmware zurück.
      Offiziell gibt es Firmware nur vom Hersteller. Ob sie für “uralte” Logger nochmal eine neue Firmware bauen lässt sich nicht sagen. Zumindest für den 747pro haben sie es getan. Der wird aber auch noch aktuell von ihnen verkauft. Die ganzen anderen alten Logger nicht mehr.

  4. Hallo Stephan,
    Ich bedanke mich für deine schnelle Antwort!
    Selbstverständlich habe ich meine alte Firmware NICHT gesichert!
    Von der Möglichkeit hatte ich nicht gewusst und die Seite mit deinem Link kannte ich nicht.
    Den richtigen mtk downloadagenten hatte ich bereits zum aufspielen der nun nicht funktionierenden Firmware genutzt.
    Da mein Logger nun eh schon zerschossen ist, würde ich als letzten Versuch gern eine firmware aufspielen die annähernd dem Original entspricht.
    Ich denke es ist relativ unwahrscheinlich jemanden zu finden der die 000f firmware
    hat und mir zukommen lässt.
    Vielleicht habe ich ja mit der 0002 oder 0004 ebenfalls Glück!??
    Wäre es möglich mir diese zukommen zu lassen?
    Grüße Volker

    • Habe über einen Kommentar durch Stephan Knauß diesen Artikel gefunden. Dabei habe ich kurz den Kommentarverlauf durchgelesen…

      Sicher dass Blumax 4044 baugleich mit iBlue 747A+ ist? Ich habe auf meinem Blog einen Artikel für den Firmwareupdate für 747A+/747Pro von Transsystem beschrieben. Ebenso via Kommentar mittlerweile eine Quelle für die Firmware vom 747ProS erhalten. Keine Ahnung ob man mit einem dieser, dein Gerät wiederbeleben kann?

      Der erwähnte Artikel: https://blog.blackseals.net/2019/05/12/gps-phototagger-und-keine-daten-im-geraet/

      Leider werden die 747A+, 747Pro und 747ProS seit langem nicht mehr produziert. Damit ist der aktive Support ebenfalls seit längerem dahin. Transystem hat sogar die Produktpalette der GPS Datenlogger eingestellt. Aufgrund des Alters scheint es für Blumax ähnlich, wenn nicht sogar schlechter zu sein. Da konnte ich überhaupt keinen Download finden…

      Da ich viele Anfragen und Rückmeldungen erhalten habe, kann ich mal nachfragen ob darunter ein Blumax war.

      • Der pro hat doch einen Erschütterungssensor. Das hat der 747A+ nicht. Wichtig wäre jetzt ein möglichst ähnliches Gerät zu identifizieren. Bei OpenStreetMap waren diese Logger mal sehr beliebt. Eventuell im Forum oder der Mailingliste anfragen. Ich bin recht sicher, dass der Logger wieder repariert werden kann. Ich versuche mal die Zeitsynchronisation in bt747 einzubauen. Sollte dann für die meisten Anwendungen ausreichen.

        • Oh, interessant zu wissen. Bislang hatte ich vermutet beide GPS Datenlogger sind sehr ähnlich und nur im Detail unterschiedlich, da in der Vergangenheit schon einmal ein Firmware-Update für beide Systeme gültig war.

          Das mit bt747 klingt gut und würde vielen ohne dauerhafter Firmware wesentlich leichter weiterhelfen.

  5. Pingback: GPS PhotoTagger und keine Daten im Gerät *Update* | BlackSeals.net blog

  6. Hallo zusammen,
    sorry, dass ich mich erst jetzt wieder melde aber ich war ein paar Tage on Tour.

    Andyt- Beim Auslesen über bt747 wurde mein Blumax 4044 als 747A+ angezeigt.
    Die Firmware war identisch mit der von Stephan aufgelisteten nur die Modelbezeichnung war mit 000f unterschiedlich.
    Zu deinem Link zu Blog/ Blackseals- genau mit dieser Software habe ich den Logger zerschossen.
    Ich war auch in der Annahme, dass es das Problem beheben würde da ja auch explizit der 747A+ mit angegeben wurde.
    Ich werde dann mal mein Glück auf der von Stephan genannten Seite versuchen.
    Vielleicht habe ich ja dort glück eine Firmware zu bekommen.

    Mittlerweile habe ich mich auch anderweitig verändert und günstig einen Qstarz BT 1000xt gekauft.
    Hier wird auch ein Update angeboten der das Rollup Problem löst.

    Trotz alledem möchte ich gern den treuen 747A+ wieder zum Leben erwecken! 😉

    Ich halte Euch auf dem Laufenden.

    Grüße Volker
    Leider hat es nicht funktioniert.

    • Oh, verstehe. Ich nehme an, bt747 hat das korrekt ausgelesen. Dann wundert mich schon dass es nicht klappt. Scheinbar hat der Blumax 4044 zum 747A+ doch mehr Unterschiede?

      Ich habe das zwar in meinem Artikel erwähnt, aber nicht näher beschrieben. Im beigefügten PDF aus dem Paket von Transystem waren noch Zusatzschritte angeführt. Ich habe diese bei mir nicht durchführen müssen, aber vielleicht fehlt das bei deinem Modell. Über eine Kontaktanfrage weiß ich, dass der Schritt mit dem Rücksetzen in einem Fall notwendig war. In der Zwischenzeit bis zu einer Antwort von der genannten Seite ist es ein möglicher Versuch für die Verwendung.

      Daneben was mich zurzeit noch interessieren würde? Es wurde angegeben, der Logger arbeitet normal, aber das Auslesen klappt nicht? Wurde dies nur mit bt747 probiert? War da Original eine andere Software dabei? Da funktioniert es ebenso nicht?

      Ich selbst nutze GPS Photo Tagger, das original bei meinem GPS Tracker dabei war. Mit bt747 habe ich es nach dem Firmwareupdate noch nicht probiert. Ein Versuch damit wäre in der Zwischenzeit ebenso denkbar.

      • BT747 erkennt das Modell nur rudimentär. Die Nummer mit der Modellbezeichnujng oder am String aus der Firmware. Siehe im SourceCode BT747Constants.java::modelName().

        Die aktuelle Version von BT747 kann automatisch das Datum um eine GPS Epoche verschieben. Das ist als Workaround auch ganz OK denke ich. Passendes Datum wie im Blog beschrieben dürfte für AGPS erforderlich sein.

  7. Hallo,
    eine kurze Zwischeninfo!
    Bisher hatte ich noch keine Zeit um Stephans Tip mit Openstreetmap zu folgen und dort eine Suchanfrage zu stellen.
    Ganz unverhofft habe ich dann gestern von einem “Unbekannten” die Firmware für den Iblue 747a+ zugeschickt bekommen.
    Ich vermute mal von Dir Stephan!??
    Betsen Dank dafür!
    Ich habe mich heute Morgen auch gleich daran gemacht und versucht sie zu installieren.
    So richtig hat es anscheinend nicht geklappt.
    In BT747 wird nun wieder Iblue 747a+ angezeigt und auch Koordinaten werden erkannt.Modell 002
    Ebenso in MTKutility mit BT.
    Eine Kopplung mit LocusMaps als BT Maus, schlug leider fehl.
    Leider sind auch die Anzeigen der LED am Tracker noch verwirrend und nicht im Ursprungszustand der Funktionsanzeige.
    Ich wollte vor dem Installieren noch den Speicher des Loggers formatieren aber es wurde die Verbindung unterbrochen und error Com 7 angezeigt.
    Leider muß ich nun wieder zur Schicht und muß weitere Versuche abbrechen.
    Sobald ich wieder Neuigkeiten habe melde ich mich wieder.
    Grüße Volker

    • Je nach Hersteller kann verschiedene Peripherie verbaut sein. Der Flash Speicher muss vielleicht anders angesprochen werden, ist größer oder kleiner, oder, oder, oder.
      Wie oben geschrieben wäre es am besten wenn du jemanden findest der den gleichen Logger hat. Die LED cycles können in der Firmware eigestellt werden. Vielleicht sind sie beim Modell “0002” etwas anders. Bluetooth hatte ich nie ausprobiert, da ich die Geräte als reine Logger verwende. Haben die Logger eine valide aussehende BT Adresse? Diese Config müsste beim Logger auch irgendwo stehen. BT747 kann das auslesen.

  8. Hallo,
    jetzt habe ich es geschafft und im Forum Opensreetmap einen Beitrag geschaltet.
    Stephan, du hast offensichtlich recht damit,dass die Modelle sich doch mehr unterscheiden als von mir angenommen.
    Die LEDs werden unterschiedlich angespochen und eine Speicherung ist ebenfalls nicht möglich.
    Ich melde mich wieder wenn sich etwas Neues ergibt!
    Ich bedanke mich aber schon jetzt einmal für die bisher erhaltene Hilfe!
    Grüße Volker

  9. Hallo Volker,
    ich kann dir zwar nicht helfen, aber du mir vielleicht?
    Ich habe ein 747A+ und konnte die Firmware
    747ProJP_A1.30E_20190419_747PRO GPS_TSI_747PROj_0005_9029807012E.bin
    aufspielen aber Loggen tut er nicht wirklich.
    Köntest du mir Deine
    Firmware AXN_1.30-B_1.3_C01 (TSI_747A+) V1.39
    zukommen lassen eventuell kann ich dann mein Recorder teilweise nutzen.
    Danke
    Gruß Klaus

  10. I am using the MTK 747A +. April 2019 We upgraded firmware to 747Pro to solve GPS Week-Rollover issue.

    After the firmware upgrade, the reception date is normally received but it is not recorded. Also, the LED does not seem to work as it was originally. So I want to restore the original firmware (AXN_1.0-B_1.3_CO1,000B, TSI_747A +, 1.0) or higher firmware.

    If you have a firmware file I want, please send it to me by e – mail.

    me: jngwoo@gmail.com

    Thank you ~!

    • I solved the problem as follows:

      I own a GPS741 (Ascen Korea) and,
      Original firmware was “AXN_1.0-B_1.3_CO1,000B (8?), TSI_747A +, 1.0”.

      Due to the “GPS Week Number Rollover” issue that occurred on April 7, 2019, I updated the firmware to “747ProJP_A1.30E_20190419_747PRO GPS_TSI_747PROj_0005_9029807012E.bin”. However, I had a problem that GPS signal reception was good but not recorded like others.

      In addition, I regarded my model as the same model as “QStarz BT-Q1000XT”, so I updated to the “Star-Q1000XT” firmware of the QStarz company which solved the issue, but also experienced the same problem.

      https://qws.qstarz.com/WNRO/
      https://qstarz.s3.amazonaws.com/public/BT-Q1000XT/firmware/Upgrade201903.zip

      Probably because of the same chipset, it was caused by different internal logger programs that handle button click events for each model.

      My solution:

      1. Visit QStarz’s “GPS WEEK NUMBER ROLLOVER (WNRO)” page.
      2. Download the “BT-Q818XT” firmware update file.
      3. Update the firmware.
      4. I encountered the same problem as a result of the firmware update, but found some other possibilities.
      5. That is, the “Bluetooth Address” was correctly displayed and was actually recorded when the “Start Log” command was sent (the previous command was ignored).

      6. The GPS control program I used is
      [Desktop PC]
      a. GpsView v2.0.19.exe: “GPSView”
      b. MtkDLut.exe: “MTK GPS Logger download Utility”.

      1. The “GpsView v2.0.19.exe” program can be obtained from http://www.transystem.com.tw/www/product.php?b=G&m=pe&cid=4&id=85.

      2. The “MtkDLut.exe” program is available from “http://4river.a.la9.jp/gps/index.htm”.

      [Android]
      1. “MTKutility”: control of all common functions (Google Play Store)
      2. “SerialBluetooth”: smartphone terminal program for sending commands to Bluetooth (Google Play Store)

      You can send a “Start Log” command to the “MTKutility” program on your PC. Initiated log commands are retained even if the power is turned off, unless a stop command is sent.

      However, the “MTKutility” program was able to control all the functions, but when deleting the log or changing some log options, it is in the “stop log” state, so it is inconvenient to reconnect to the PC and send the “start log” command. .

      This inconvenience in the open air can always be solved by sending a “Start Log / Stop Log” command from your smartphone.

      The “SerialBluetooth” installed on the smartphone is responsible for this function.

      The following is a terminal command.
      Start Log: $ PMTK182,4 * 21
      Stop Log: $ PMTK182,5 * 20
      Erase Log: $ PMTK182,6,1 * 3E
      My question is my own answer.

      I am simply sending the command by assigning the above command to each button as a macro function.

      If your model has the “MTK3329 chipset”, it’s all possible, but not sure.

      Good luck to everyone.

  11. Danke Volker, die Firmware hatte ich schon aufgespielt, passt nicht
    jetzt Speichert der 747A+ gar nichts mehr.
    Firmware vom anderen 747A+ auslesen mit
    mt333x-fw-utils klappt nicht (bei mir) mit Python 2.7

    • Hallo Klaus,
      welchen Fehler gibt es denn beim Auslesen? Ist schon etwas länger her, aber ich glaube ich hatte auch ein Problem. Bin mir nicht mehr so sicher was ich gemacht hatte.
      Stephan

  12. Hallo Stephan
    erst mal einen Dank an all denen die anderen Helfen
    mit der 32 Bit Version von Python 2.7 bin ich zwar weiter gekommen. Aber……
    so sieht es jetzt aus
    —————–
    C:\>C:\Python27\mt333x-fw-utils\mt333x_fw_dump.py COM5 axn.bin
    Traceback (most recent call last):
    File “C:\Python27\mt333x-fw-utils\mt333x_fw_dump.py”, line 146, in
    main()
    File “C:\Python27\mt333x-fw-utils\mt333x_fw_dump.py”, line 87, in main
    brom.start()
    File “C:\Python27\mt333x-fw-utils\mt333x_helpers.py”, line 88, in start
    self._ser.apply_settings({
    AttributeError: ‘Serial’ object has no attribute ‘apply_settings’

    C:\>
    —————–
    88 self._ser.apply_settings({
    89 ‘baudrate’: self._baud,
    90 ‘timeout’: 0.005
    91 })
    —————–
    Danke hat Zeit
    Klaus

  13. Hi Stephan!
    Zunächst einmal: Dank & Anerkennung für Deinen Blog!!
    Leider muß ich Dich kontaktieren, weil mit Deinen Hinweisen alleine ich nicht zum Durchbruch komme: Es hakt anscheinend bei dem Schritt der Befehlsübermittlung mit Tera Term.
    Der Reihe nach: Bei mir geht es um einen blumax 4043, laut BT747 Model 0007(iBlue 747), Firmware B-care_1.1 (TSI 747CD), SW V1.38.
    Ich habe immerhin hinbekommen, ihn mit Tera Term zu verbinden, auch der Schritt der Umstellung des Befehlabschlusses auf CR+LF sowie die Erstellung des Befehl selbers mit Checksumme ist nicht das Problem – doch vorher hakt es schon (vermutlich aufgrund meiner Unerfahrenheit): Ich hätte vermutet, daß in Tera Term die Kommunikation mit dem Logger innerhalb des Hauptfensters vonstatten geht, ein Terminal halt, wo man den Befehl eingeben kann und dann hoffentlich wie von Dir beschrieben die Bestätigung / Response vom Logger bekommt – doch sobald ich den Logger einschalte (und ohne Einschalten kann ich ihn nicht verbinden) wird der Bildschirm andauernd mit einem Zeichensalat (viele chinesische Zeichen dabei) vollgeschrieben; außerdem ist mir es nie gelungen, selber etwas in den Bildschirm zu schreiben, auch einfügen o.ä. funktioniert nicht. Was mache ich falsch?
    Dieser von Dir vorgeschlagene Workaround scheint mir mit Abstand die beste Lösung, aber ist vielleicht zu kompliziert für mich. Letztlich reichte es mir schon, könnte ich den Zeitraum um 1024 Wochen verschieben, wie ferner als Lösung von Dir mittels BT747 beschrieben, aber das Laden dort endet ohne angezeigte Daten, genau wie in der Software vom Hersteller.
    Wäre toll, könntest Du mir weiterhelfen!

  14. I solved the problem as follows:

    I own a GPS741 (Ascen Korea) and,
    Original firmware was “AXN_1.0-B_1.3_CO1,000B (8?), TSI_747A +, 1.0”.

    Due to the “GPS Week Number Rollover” issue that occurred on April 7, 2019, I updated the firmware to “747ProJP_A1.30E_20190419_747PRO GPS_TSI_747PROj_0005_9029807012E.bin”. However, I had a problem that GPS signal reception was good but not recorded like others.

    In addition, I regarded my model as the same model as “QStarz BT-Q1000XT”, so I updated to the “Star-Q1000XT” firmware of the QStarz company which solved the issue, but also experienced the same problem.

    https://qws.qstarz.com/WNRO/
    https://qstarz.s3.amazonaws.com/public/BT-Q1000XT/firmware/Upgrade201903.zip

    Probably because of the same chipset, it was caused by different internal logger programs that handle button click events for each model.

    My solution:

    1. Visit QStarz’s “GPS WEEK NUMBER ROLLOVER (WNRO)” page.
    2. Download the “BT-Q818XT” firmware update file.
    3. Update the firmware.
    4. I encountered the same problem as a result of the firmware update, but found some other possibilities.
    5. That is, the “Bluetooth Address” was correctly displayed and was actually recorded when the “Start Log” command was sent (the previous command was ignored).

    6. The GPS control program I used is
    [Desktop PC]
    a. GpsView v2.0.19.exe: “GPSView”
    b. MtkDLut.exe: “MTK GPS Logger download Utility”.

    1. The “GpsView v2.0.19.exe” program can be obtained from http://www.transystem.com.tw/www/product.php?b=G&m=pe&cid=4&id=85.

    2. The “MtkDLut.exe” program is available from “http://4river.a.la9.jp/gps/index.htm”.

    [Android]
    1. “MTKutility”: control of all common functions (Google Play Store)
    2. “SerialBluetooth”: smartphone terminal program for sending commands to Bluetooth (Google Play Store)

    You can send a “Start Log” command to the “MTKutility” program on your PC. Initiated log commands are retained even if the power is turned off, unless a stop command is sent.

    However, the “MTKutility” program was able to control all the functions, but when deleting the log or changing some log options, it is in the “stop log” state, so it is inconvenient to reconnect to the PC and send the “start log” command. .

    This inconvenience in the open air can always be solved by sending a “Start Log / Stop Log” command from your smartphone.

    The “SerialBluetooth” installed on the smartphone is responsible for this function.

    The following is a terminal command.
    Start Log: $ PMTK182,4 * 21
    Stop Log: $ PMTK182,5 * 20
    Erase Log: $ PMTK182,6,1 * 3E

    I am simply sending the command by assigning the above command to each button as a macro function.

    If your model has the “MTK3329 chipset”, it’s all possible, but not sure.

    Good luck to everyone.

    • P.S:
      FullOverWrite: $ PMTK182,1,6,1 * 23
      FullStopWite: $ PMTK 182,1,6,2 * 20

      * But there seems to be one problem.
      If you are not receiving GPS signal from other devices such as PC Com Port or Bluetooth connection, it seems to be in Idle state.
      However, if you connect your smartphone’s “Bluetooth GPS (Google Play Stored)” app in idle mode, it will start recording again.
      If you find a solution to this problem, please write it here.

  15. I solved the problem as follows:

    I own a GPS741 (Ascen Korea) and,
    Original firmware was “AXN_1.0-B_1.3_CO1,000B (8?), TSI_747A +, 1.0”.

    Due to the “GPS Week Number Rollover” issue that occurred on April 7, 2019, I updated the firmware to “747ProJP_A1.30E_20190419_747PRO GPS_TSI_747PROj_0005_9029807012E.bin”. However, I had a problem that GPS signal reception was good but not recorded like others.

    In addition, I regarded my model as the same model as “QStarz BT-Q1000XT”, so I updated to the “Star-Q1000XT” firmware of the QStarz company which solved the issue, but also experienced the same problem.

    https://qws.qstarz.com/WNRO/
    https://qstarz.s3.amazonaws.com/public/BT-Q1000XT/firmware/Upgrade201903.zip

    Probably because of the same chipset, it was caused by different internal logger programs that handle button click events for each model.

    My solution:

    1. Visit QStarz’s “GPS WEEK NUMBER ROLLOVER (WNRO)” page.
    2. Download the “BT-Q818XT” firmware update file.
    3. Update the firmware.
    4. I encountered the same problem as a result of the firmware update, but found some other possibilities.
    5. That is, the “Bluetooth Address” was correctly displayed and was actually recorded when the “Start Log” command was sent (the previous write command did not work).
    6. GPS control program I used

    [Desktop PC]
    a. GpsView v2.0.19.exe: “GPSView”: (http://www.transystem.com.tw/www/product.php?b=G&m=pe&cid=4&id=85)
    b. MtkDLut.exe: “MTK GPS Logger download Utility”: (http://4river.a.la9.jp/gps/index.htm)

    [Android]
    1. “MTKutility”: control of all common functions (Google Play Store)
    2. “SerialBluetooth”: smartphone terminal program for sending commands to Bluetooth (Google Play Store)

    You can send a “Start Log” command to the “MTKutility” program on your PC. Initiated log commands are retained even if the power is turned off unless a “stop log” command is sent.
    However, the “MTKutility” program was able to control all the functions, but when deleting the log or changing some log options, it is in the “stop log” state, so it is inconvenient to connect to the PC and send the “start log” command again. .

    This inconvenience in the open air can always be solved by sending a “Start Log / Stop Log” command from your smartphone.
    The “SerialBluetooth (Google Play Store)” installed on the smartphone is responsible for this function.

    The following is a terminal command.

    Start Log: $ PMTK182,4 * 21
    Stop Log: $ PMTK182,5 * 20
    Erase Log: $ PMTK182,6,1 * 3E
    FullOverWrite: $ PMTK182,1,6,1 * 23
    FullStopWrite: $ PMTK182,1,6,1 * 23

    I am simply sending the command by assigning the above command to each button as a macro function.
    If your model has the “MTK3329 chipset”, it’s all possible, but not sure.

    Good luck to everyone.

    P.S: But there seems to be one problem.
    If you are not receiving GPS signal from other devices such as PC Com Port or Bluetooth connection, it seems to be in Idle state.
    However, if you connect your smartphone’s “Bluetooth GPS (Google Play Stored)” app in idle mode, it will start recording again.
    If you find a solution to this problem, please write it here.

  16. Hallo,
    ich habe das mit dem Datumsupdate durchgeführt.
    Mein Blumax 4044 nimmt den Befehl, er Quittiert auch wie beschrieben, aber ändern tut sich nichts.
    Die Verbindung steht mit Tera Term (VT100), die Signale kommen im Sekunden Tagt rein, man sieht auch in dem Abschnitt das Datum (300400).
    Ändert sich nach der Befehlseingabe nicht.
    Mache ich dort was falsch oder geht es mit dem Model nicht?
    vielen Dank.

  17. Hallo,
    habe inzwischen einen 747A+ bekommen und konnte diesen Erfolgreich updaten.
    Das mit dem temporären Datum hat bei dem 747A+ mit Tera Term nicht funktioniert.

  18. Hallo,
    ich habe einen iBlue747 (wahrscheinlich ohne + oder Pro, FW M-core_1.94, Logger-SW 1.33) – natürlich auch mit falschem Datum – wie es ja auch ganz oben in der Tabelle schon von Stephan gelistet wurde.
    Ohne Firmware-Update (und ohne Terminal 🙂 ) geht es mit dem Tool “MTK GPS Logger download Utility” unter http://4river.a.la9.jp/gps/index.htm#006 ganz einfach: Das Tool setzt das Datum im Gerät nach dem Erkennen automatisch richtig. So ist es zumindest bis zum nächsten leeren Akku korrrekt.
    Vielleicht kann jemand die Option zu Datumskorrektur im Gerät bei BT747 auch implementieren, wenn die Befehle doch bekannt sind?

    By the way: Hat jemand mal einen Versuch gemacht, die QSTARZ Firmware https://qws.qstarz.com/WNRO/
    https://qstarz.s3.amazonaws.com/public/BT-Q1000XT/firmware/Upgrade201903.zip auf dem iBlue747 zu flashen?

    • Danke für den Link. Die Dokumentation klingt so, als ob das Tool den von mir beschriebenen Fix anwendet und die Uhrzeit im Logger setzt. Ich wollte zu BT747 einen Patch einreichen, habe das aber bislang noch nicht gemacht, weil ich im Vergleich zu Github keine schöne Möglichkeit gesehen habe einen Patch zu schicken. Ich glaube aber, dass BT747 in der aktuellen Version zumindest das Datum der Downloads anpassen kann. Möglicherweise funktioniert ohne gesetzte Zeit AGPS auf dem Logger nicht, da die Wochennummern nicht stimmen.

      Ich rate dringend davon ab eine Firmware eines anderen Loggers zu flashen. Und wenn, dann wenigstens vorher die eigene Firmware sichern. Wie das geht habe ich ja auch erwähnt.

  19. Mit der nachfolgenden Beschreibung kann man vermutlich bei jedem MTK3329-basierten logger das GPS week number rollover (WNRO) Problem beheben, falls der Hersteller keine aktualisierte firmware mehr anbietet. Ausprobiert habe ich es aber nur an meinem i-Blue 747A+ mit firmware AXN_1.30-B_1.3_C01,0004,TSI_747A+,1.0

    Alle gemachten Aussagen beruhen auf eigenen Analysen, Beobachtungen und Annahmen. Für deren Korrektheit kann ich nicht garantieren.

    1. Firmware-Paket für 747Pro von https://www.dropbox.com/s/xujny3zw5vqppgh/FlashTool_exe_v4.1.0_747Pro.rar?dl=0 herunterladen und z.B. nach C:\Temp entpacken. Die firmware-Datei 747ProJP_A1.30E_20190419_747PRO GPS_TSI_747PROj_0005_9029807012E.bin am besten gleich löschen, es sei denn man besitzt einen 747Pro. In dem Fall benötigt man die folgende Modifikation aber ohnehin nicht.

    2. ‘Read back’ tab durch patchen von FlashTools_customer.exe freischalten. In FlashTools_customer.exe muss dazu mit einem HEX-Editor (z.B. HxD Hex Editor) an offset 0x10BFDF (dezimal 1097695) das byte 0x08 durch 0x09 überschrieben und alles in eine neue Datei FlashTools_Mod.exe gespeichert werden.

    3. Originale logger firmware mittels FlashTools_Mod.exe und ‘Read back’ tab sichern.

    file: C:\Temp\FlashTool_exe_v4.1.0\ROM_0.orig
    Start Address: 0x00000000
    Lenght: 0x0005E800

    Hier muss darauf geachtet werden, dass die Länge der firmware je nach logger-Modell und firmware-Version unterschiedlich sein kann und Length ausreichend groß gewählt wird.

    Bei meinem i-Blue 747A+ mit firmware AXN_1.30-B_1.3_C01,0004,TSI_747A+,1.0 reichte die oben angegebene Länge von 0x0005E800 (dezimal 387072) bytes, um die firmware vollständig zu sichern.

    Da man die tatsächliche Länge der firmware vor dem Sichern nicht kennt, sollte man lieber zu viel (z.B. 0x00080000) als zu wenig flash Speicher sichern. Wenn am Ende der Sicherungsdatei (ROM_0.orig) nur noch seitenweise 0xFF bytes stehen, hat man (mehr als) genug gesichert. Prüfen kann man das mit Hilfe des HxD Hex Editor.

    Im Dialog ‘Open Download Agent File’ die Datei MTK_AllInOne_DA_MT3329_v4.02.bin auswählen. Dieser Dilog erscheint nur, wenn man den Download Agent unter dem tab ‘Download’ noch nicht angegeben hat.

    4. Originale logger firmware modifizieren. Ein sauberer patch direkt in der firmware wäre aufwändig. Deshalb habe ich es mit einem workaround probiert, der bisher alle Tests bestanden hat.

    Nebeneffekte kann ich allerdings nicht komplett ausschliessen, da der patch nicht die Berechnung der Anzahl der seit 06.01.1980 verstrichenen Wochen korrigiert, sondern lediglich in die Funktion eingreift, die für die Berechnung der UNIX-Zeit in Sekunden verantwortlich ist.

    Das mit Ghidra erstellte Dekompilat der Funktion sieht folgendermassen aus:

    int FUN_00048a30(int param_1, int param_2, int param_3)
    {
    return ((0x93a80 * param_1 + param_2) – param_3) + 0x12d53d80;
    }

    0x93a80: eine Woche in Sekunden (60 * 60 * 24 * 7 = 604800 oder hexadezimal 0x93a80)
    param_1: Anzahl verstrichene Wochen seit dem Start des GPS-Wochenzählers am 06.01.1980 (Anzahl_WNRO * 1024 + GPS_Woche). Eine firmware, die nur einen WNRO brücksichtigt, übergibt hier seit dem zweiten WNRO einen um 1024 zu kleinen Wert
    param_2: Anzahl Sekunden seit Beginn der aktuellen GPS-Woche
    param_3: Dem logger aktuell bekannte Anzahl von Schaltsekunden seit 06.01.1980
    0x12d53d80: Beginn des GPS-Wochenzählers als Unix-Zeit in verstrichenen Sekunden seit dem 01.01.1970 00:00:00 UTC

    Für das Ergebnis der Funktion ist es unerheblich, ob param_1 vor dem Aufruf um 1024 oder die Konstante 0x12d53d80 in der Funktion um 1024 Wochen in Sekunden erhöht wird. Da das Erhöhen der Konstante jedoch viel einfacher umzusetzen ist, habe ich mich dafür entschieden.

    Beginn GPS-Wochenzähler als Unix-Zeit in Sekunden berechnen (unter Cygwin oder Linux):
    date -u -d “1980-01-06 00:00:00” +%s
    315964800

    Darauf 1024 Wochen in Sekunden addieren:

    315964800 Beginn GPS-Wochenzähler als Unix-Zeit in Sekunden (hexadezimal: 0x12D53D80)
    + 619315200 1024 Wochen in Sekunden (60 x 60 x 24 x 7 x 1024)
    ———–
    935280000 in hexadezimaler Schreibweise 0x37BF3D80

    Obwohl seit Beginn der GPS-Wochenzählung bereits 2 WNRO aufgetreten sind, müssen nur zusätzliche 1024 Wochen addiert werden, da der erste GPS week number rollover bereits durch die originale logger firmware abgedeckt wird.

    Nun in der originalen firmware (Datei ROM_0.orig) mit dem HEX-Editor die byte-Folge 803DD512 (little endian Darstellung von 0x12D53D80) suchen, diese durch 803DBF37 (little endian Darstellung von 0x37BF3D80) ersetzen und alles in die neue Datei C:\Temp\FlashTool_exe_v4.1.0\ROM_0.mod speichern.

    5. Modifizierte firmware mittels FlashTools_Mod.exe und tab ‘Download’ in den logger flash Speicher schreiben.

    DA:3329 : C:\Temp\FlashTool_exe_v4.1.0\MTK_AllInOne_DA_MT3329_v4.02.bin
    region address: 0x00000000
    begin address : 0x00000000
    end address : 0x0005E7FF
    location : C:\Temp\FlashTool_exe_v4.1.0\ROM_0.mod

    6. Erster Test mittels MtkDLut 2.06 (eine alte Version ohne automatische Korrektur der logger real time clock (RTC). Die Programme GpsView und ‘EB View’ von Transystem sind für diesen Test nicht geeignet, da sie versuchen das über NMEA empfangene Datum (210899, also 21.08.1999) zu korrigieren und dabei sowohl vor als auch nach der Modifikation der logger firmware völliger Unsinn herauskommt (nämlich 22.08.2030).

    Bekannte Daten:
    06.01.1980 00:00:00 UTC Beginn GPS-Wochenzähler
    21.08.1999 23:59:47 UTC Datum und Uhrzeit des ersten week number rollover
    06.04.2019 23:59:42 UTC Datum und Uhrzeit des zweiten week number rollover

    Vom logger ausgegebene Daten:
    05.01.1980 23:59:45 UTC logger Datum und Zeit nach zweitem WNRO direkt nach factory reset mit originaler firmware
    21.08.1999 23:59:45 UTC logger Datum und Zeit nach zweitem WNRO direkt nach factory reset mit modifizierter firmware

    An den Testdaten kann man erkennen, dass erstens der patch wie gewünscht funktioniert und zweitens der logger 3 neu hinzugekommene Schaltsekunden nicht berücksichtigt. Die initiale logger Zeit ist 23:59:45 statt 23:59:42.

    Ich habe mich früher gewundert, weshalb der logger trotz guten Satellitenempfangs oft wenige Sekunden Abweichug zur realen Zeit anzeigte. Das liegt daran, dass er standardmäßig von lediglich 15 Schaltsekunden ausgeht, obwohl seit dem 06.01.1980 inzwischen tatsächlich 18 Schaltsekunden eingefügt wurden. Der logger korrigiert diese Abweichung irgendwann, wenn er Satellitenempfang hat (die empfangenen GPS-Daten enthalten die korrekte Anzahl von Schaltsekunden). Allerdings kann das nach meinen Beobachtungen durchaus eine Weile dauern.

    Achtung, wer wie ich auch die falsche Anzahl von Schaltsekunden korrigieren möchte, sollte sich etwas mit reverse engineering, dem ARM THUMB2 assembler und little endian Maschinencode auskennen. Alle anderen sollten folgende firmware-Modifikation besser nicht durchführen und sich mit der oben beschriebenen Modifikation zufriedengeben.

    Was jetzt folgt darf ohne Anpassungen nur genau für den i-Blue 747A+ mit firmware AXN_1.30-B_1.3_C01,0004,TSI_747A+,1.0 durchgeführt werden. Andernfalls zerstört man die firmware des loggers und es wird schwierig bis unmöglich den logger wiederzubeleben!

    Da mir Kenntnisse über den ARM-Prozessor fehlten, hatte ich mich an dieser Stelle erstmal mit dem ARM instruction set und dem ‘Online Assembler and Disassembler’ (http://shell-storm.org/online/Online-Assembler-and-Disassembler/) beschäftigt und anschliessend überlegt an welcher Stelle die Modifikation am einfachsten durchzuführen ist.

    Theoretisch könnte man die falsche Anzahl von Schaltsekunden beheben, in dem man 0x37BF3D7D statt 0x37BF3D80 für den Beginn der GPS-Wochenzählung beim oben beschriebenen patch verwendet. Allerdings korrigiert der logger die Abweichung ja früher oder später selbständig, welches dann zu einer doppelten Korrektur und Nachgehen der logger Zeit um 3 Sekunden gegenüber der realen Zeit führen würde.

    Auch konnte ich nicht zweifelsfrei herausfinden woher die 15 Schaltsekunden genau stammen aber es sieht danach aus als seien sie im ROM des MTK3329 chip (also nicht in der firmware des loggers) hart codiert. Auf diesen Bereich kann ich leider weder lesend und schon gar nicht (für einen patch) schreibend zugreifen.

    Deshalb kam mir die Idee code in die Funktion zur Berechnung der UNIX-Zeit einzufügen. Immer wenn der Funktion über param_3 eine 15 übergeben wird, soll stattdessen eine 18 verwendet werden. Das coding für diesen patch ist trivial, allerdings ist im Umfeld der Funktion FUN_00048a30 keinerlei Platz, um die wenigen bytes Maschinencode einfügen zu können.

    Hier das assembler listing der oben modifizierten Funktion, die für die Berechnung der UNIX-Zeit verantwortlich ist:

    FUN_00048a30:
    00048a30 03 4b ldr r3,[DAT_00048a40]
    00048a32 58 43 mul param_1,r3
    00048a34 40 18 add param_1,param_1,param_2
    00048a36 03 49 ldr param_2,[DAT_00048a44]
    00048a38 80 1a sub param_1,param_1,param_3
    00048a3a 40 18 add param_1,param_1,param_2
    00048a3c 70 47 bx lr

    00048a3e 00 00 align align(2)

    DAT_00048a40:
    00048a40 80 3a 09 00 int 00093A80h

    DAT_00048a44:
    00048a44 80 3d bf 37 int 37BF3D80h

    Letzendlich habe ich mich dazu entschlossen die Funktion an das Ende der logger firmware zu kopieren und den patch dort einzufügen. Hier ist noch viel Platz für Modifikationen. Der flash Speicher des i-Blue 747A+ ist meines Wissen 1 Mbyte groß und nur ein Bruchteil davon wird von der firmware belegt.

    FUN_0005e5d0:
    0005e5d0 0f 2a cmp param_3,#0xf @ vergleiche param_3 (Anzahl Schaltsekunden) mit 15
    0005e5d2 00 d1 bne LAB_0005e5d6 @ springe zu Adresse 0x5e5d6, falls param_3 ungleich 15 ist
    0005e5d4 12 22 mov param_3,#0x12 @ weise param_3 andernfalls den Wert 18 zu

    LAB_0005e5d6:
    0005e5d6 03 4b ldr r3,[DAT_0005e5e4] @ lade 0x93a80 (1 Woche in Sekunden) von Adresse 0x5e5e4
    0005e5d8 58 43 mul param_1,r3 @ multipliziere param_1 (Anzahl Wochen seit 06.01.1980 – 1024) mit 0x93a80
    0005e5da 40 18 add param_1,param_1,param_2 @ addiere param_2 (Anzahl Sekunden seit Beginn der aktuellen GPS-Woche)
    0005e5dc 02 49 ldr param_2,[DAT_0005e5e8] @ lade 0x37bf3d80 (Beginn GPS-Wochenzähler als Unix-Zeit in Sekunden + 1024 Wochen in Sekunden) von Adresse 0x5e5e8
    0005e5de 80 1a sub param_1,param_1,param_3 @ subtrahiere die Anzahl von Schaltsekunden
    0005e5e0 40 18 add param_1,param_1,param_2 @ addiere 0x37bf3d80
    0005e5e2 70 47 bx lr @ zurück zur aufrufenden Funktion

    DAT_0005e5e4:
    0005e5e4 80 3a 09 00 int 00093A80h

    DAT_0005e5e8:
    0005e5e8 80 3d bf 37 int 37BF3D80h

    Jetzt fehlte nur noch eine Modifikation der originalen Funktion FUN_00048a30, sodass diese nichts anderes tut als die neue Funktion FUN_0005e5d0 aufzurufen:

    FUN_00048a30:
    00048a30 00 b5 push { lr } @ sichere das link register auf dem stack
    00048a32 15 f0 cd fd bl FUN_0005e5d0 @ rufe die neue Funktion FUN_0005e5d0 auf
    00048a36 00 bd pop { pc } @ zurück zur aufrufenden Funktion

    00048a38 00 00 00 align align(8)
    00 00 00
    00 00

    Hier noch einige Erkenntnisse, die ich bei meinen Analysen gewonnen habe. Sie haben mit den obigen Modifikationen nicht direkt etwas zu tun und sind einfach nur als Information für diejenigen gedacht, die sich für das Thema GPS und die logger firmware interessieren.

    1. Die firmware des i-Blue 747A+ ruft zur Berechnung der Anzahl seit 06.01.1980 verstrichenen Wochen eine ROM-Funktion des MTK3329 chips auf (thunk_EXT_FUN_a0004b1c). Hier ein Stelle im Dekompilat der firmware:


    if ((uVar2 != 0) &&
    ((FUN_0003ffd6(&uStack124,(undefined4 *)(iVar1 + 0x218)), *(int *)(iVar1 + 0x218) != 0 ||
    (*param_3 == 0)))) {
    iVar3 = thunk_EXT_FUN_a0004b1c(param_3[1]);

    Wie bereits oben geschrieben, habe ich keinen Zugriff auf das ROM des MTK3329 und weiss deshalb nicht genau wie die Funktion aussieht. Sie kommt aber im Fall meines loggers nicht mit dem zweiten GPS week number rollover klar und berechnet einen um 1024 zu geringen Wert.

    Es scheint allerdings i-Blue 747A+ logger zu geben, die die selbe firmware besitzen wie mein fehlerhafteter i-Blue 747A+ aber trotzdem kein Problem mit dem zweiten WNRO haben. Dies kann ich mir nur dadurch erklären, dass es verschiedene Chargen des MTK3329 GPS chips mit leicht unterschiedlichem ROM gibt.

    Aus diesem Grund bringt es wohl auch nichts die firmware eines funktionierenden i-Blue 747A+ in einen mit dem WNRO-Problem zu kopieren. Die fehlerhafte MTK3329 ROM-Funktion wird dadurch nicht korrigiert.

    2. In der neuen firmware des 747Pro wurde an der in Punkt 1 aufgeführten Stelle (und weiteren Stellen) der Aufruf der MTK3329 ROM-Funktion durch eine Funktion der logger firmware (FUN_0000b0a0) ersetzt:


    if ((uVar2 != 0) &&
    ((FUN_0003feaa(&uStack124,(undefined4 *)(iVar1 + 0x218)), *(int *)(iVar1 + 0x218) != 0 ||
    (*param_3 == 0)))) {
    iVar3 = FUN_0000b0a0(param_3[1]);

    Das Dekompilat dieser Funktion sieht folgendermaßen aus:

    int FUN_0000b0a0(int param_1)
    {
    short sVar1;
    uint uVar2;

    sVar1 = 0x400; /* 1024 Wochen für einen WNRO */
    uVar2 = 0x7FA; /* firmware-Datum in Anzahl Wochen seit 06.01.1980 */

    do { /* firmware-Datum in Anzahl Wochen seit 06.01.1980 modulo 1024 berechnen */
    uVar2 = uVar2 – 0x400;
    } while (0x400 < uVar2);

    if ((uint)(param_1 <> 0x16 < uVar2) { /* aktuelle GPS-Woche (bits 14 bis 23 von param_1) < GPS-Woche der firmware */
    sVar1 = 0x800; /* 2048 Wochen für zwei WNRO */
    }
    return (int)(short)((ushort)((uint)(param_1 <> 0x16) + sVar1); /* aktuelle GPS-Woche + Wert in sVar1 */
    }

Schreibe einen Kommentar

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

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

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