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.
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:
1 |
$PMTK335,2019,05,12,12,22,30*3B |
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.
Im Terminal sieht man nach dem Abschicken des Befehls auch die Bestätigung des Loggers darüber:
1 |
$PMTK001,335,3*35 |
Der so behandelte Logger hat brav Daten aufgezeichnet, die dann mit BT747 auch mit dem korrekten Datum exportiert wurden.
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
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
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.
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.
Pingback: GPS PhotoTagger und keine Daten im Gerät *Update* | BlackSeals.net blog
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.
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.
Hi Volker,
könntest du mir die Iblue 747a+ firmware zusenden? Vielleicht passt die auf meinen Iblue 747a+
Viele Grüße
Falco
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
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
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.
Hallo zusammen,
ein kurzer Zwischenbericht:
Leider hat die Anfrage im Openstreetforum nix gebracht.
Es haben zwar 120 User gelesen aber es gab keine Resonanz.
Klaus, ich habe die Firmware für den 747a+ Von dieser Seite,
https://blog.blackseals.net/2019/05/12/gps-phototagger-und-keine-daten-im-geraet/
Wurde auch schon weiter oben angegeben.
Vielleicht hilft dir das weiter.
Grüße Volker
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
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
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!
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.
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.
P.S: I’m sorry There is something wrong and correct.
FullStopWite: $ PMTK 182,1,6,2 * 20
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.
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.
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.
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 */
}
Super Patch! Vielen Dank!
Hallo
@Zoppo13
„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.“
Ich habe das mal versucht und finde das offset (dezimal 1097695) nicht, es gibt nur 109696. Aber in diesem finde ich auch nicht das byte 0x08.
Kannst du bitte helfen?
Hat jemand vielleicht noch eine firmware für den 747+, also nicht pro, und wäre so nett diese hochzuladen.
Vielen Dank
Hallo Jo,
die Datei (das Programm) FlashTools_customer.exe ist 1245184 bytes groß, d.h. offset 1097695 muss existieren. Dort steht im Original eine 08, welche durch eine 09 ersetzt werden muss, damit man mittels FlashTools_customer.exe auch firmware aus dem logger auslesen kann.
Welches Betriebssystem und welches Programm zum patchen verwendest du?
Die originale firmware des i-Blue 747A+ habe ich noch auf meinem Rechner liegen. Ausgelesen habe ich sie mittels der gepatchen FlashTools_customer.exe. Die Frage ist nur wohin ich die firmware hochladen soll.
Hallo Zoppo13,
Danke für Deine Hilfe. Also ich benutze HxD und die FlashTools-Byte Grösse stimmt auch über ein mit deiner Angabe, jedoch ist das offset 1097695 nicht vorhanden. So sieht das aus:
01097664 1 64 20 62 61 63 6B 0A 49 6D 61 67 65 49 6E 64
01097664 65 78 02 01 0A 54 61 62 56 69 73 69 62 6C 65 08
01097696 06 4F 6E 53 68 6F 77 07 0F 74 73 5F 52 65 61 64
Das eigentliche Problem ist das nach dem FirmwareUpdate meines Bt747+ dieser nicht mehr richtig funktioniert. Ein Gps-Fix funktioniert, jedoch das loggen geht überhaupt nicht mehr: die Sat.-LED blinkt andauernd rot und die LED für Bluetooth, die blinkt oder leuchtet gar nicht mehr blau.
Deshalb wollte ich es mit einer anderen (original) Firmware probieren. Kannst du die auf dropbox hochladen? oder ich gib dir meine emailadresse wenn du möchtest?
Besten Dank schon mal!
Da habe ich mich vertippt:
richtig ist das so:
01097664 1 64 20 62 61 63 6B 0A 49 6D 61 67 65 49 6E 64
01097680 65 78 02 01 0A 54 61 62 56 69 73 69 62 6C 65 08
01097696 06 4F 6E 53 68 6F 77 07 0F 74 73 5F 52 65 61 64
Hallo Jo,
ok, ich sehe was da schief läuft.
Entscheidend ist folgende Zeile in HxD:
01097680 65 78 02 01 0A 54 61 62 56 69 73 69 62 6C 65 08 ex…TabVisible.
Jede Zeile enthält 16 bytes (Zeichen) die in der Kopfzeile von HxD von 00 bis 15 durchnummeriert werden. Die Werte in der Spalte Offset beziehen sich immer nur auf das erste byte jeder Zeile und sind Vielfache von 16. Vom ersten byte pro Zeile musst du selber duchzählen. D.h. in obiger Zeile beginnend mit 1097680 für das byte 65 addierst du 1 für jedes weitere byte bis du bei 1097695 bist. Das ist dann genau die 08 am Zeilenende.
Bovor du folgende firmware herunterlädst und vor allen Dingen in deinen logger einspielst, versichere dich bitte, dass du einen iBlue 747A+ besitzt. Bisher hast du immer 747+ geschrieben. Den gibt es meines Wissens nicht. Das ältere Modell nennt sich einfach nur iBlue 747, besitzt den älteren MTK MT3318 GPS Chipsatz und ist nicht kompatibel zu der firmware des iBlue 747A+.
Ich hoffe über folgenden link lässt sich die originale firmware des iBlue 747A+ herunterladen, ich hatte bisher dropbox noch nicht genutzt: https://www.dropbox.com/s/rf143rwkrmynlhs/iBlue_747A%2B_AXN_1.30-B_1.3_C01%2C0004%2CTSI_747A%2B%2C1.0.zip?dl=0
Bei Interesse könnte ich dir auch noch eine gepatchte version der firmware bereitstellen. Der patch ähnelt dem oben beschriebenen patch, wurde von mir aber nochmals verfeinert, weil ich eben doch noch einen kleinen Nebeneffekt gefunden hatte (manuelles Setzen der real time clock ging nicht mehr, was aber nach obigem patch auch nicht mehr unbedingt benötigt wurde).
Wie immer deine Versuche ausgehen, ich würde mich freuen, wenn du berichtest.
Hallo Zoppo13,
vielen Dank für deine Hilfe.
Hab den BT747+
Ja das mit HxD hab ich nach deinem Hinweis jetzt hinbekommen, der Menüpunkt erscheint jetzt 🙂
Das aufspielen der Firmware (Download aus Dropbox hat funktioniert) hat geklappt, jedoch loggen kann ich immer noch nicht. Ich weiss nicht woran das liegt, weil die Bluetooth LED leuchtet ja auch gar nicht; normalerweise leuchtet/blinkt die ja eigentlich blau. Leuchtet die bei dir?
Vielleicht sollte ich mal mit die Endadresse beim formatieren ändern? Was steht denn bei dir? Bei mir steht 0x0005E5FF, vielleicht ist ja der Bereich zu klein und die Firmware wird nicht komplett geschrieben?!
Machst du einen Hacken bei DA:3329 und wählst du die Firmware dort aus oder bei Reserve?
Wird zuerst formatiert dann das Update oder umgekehrt?
Letzter Versuch wäre noch vielleicht mit deiner modifizierten Firmware das nochmal auszuprobieren, wenn Du so nett wärst diese hochzuladen.
Sonst weiss ich auch nicht weiter.
Hallo Jo,
inzischen glaube ich, dass die firmware nicht das Problem ist.
Vermutlich besteht einfach keine Bluetooth-Kopplung zu einem anderen Gerät (in Schalterstellung LOG ist die Bluetooth-Status LED dann komplett aus) und der log-Speicher ist voll (dann leuchtet die GPS Status LED dauerhaft rot, wenn für den Speicher die Betriebsart ‚Speicher nicht überschreiben‘ eingestellt ist, welches die Standardeinstellung ist).
Schaue mal hier in die Bedienungsanleitung:
http://www.wijkamp.com/gps/pdf/um_i-blue747a_de.pdf
Um einen iBlue 747A+ vernünftig konfigurieren und betreiben zu können, sollte man folgende Programme nutzen (die originale Software taugt nichts bzw. bietet nicht alle Möglichkeiten):
1. http://4river.a.la9.jp/gps/file/MtkDLut.htm
2. https://www.bt747.org/
download über https://sourceforge.net/projects/bt747/files/latest/download
Mit beiden Programmen kannst du den log-Speicher löschen, so dass wieder Platz für neue Aufzeichnungen geschaffen wird. Aber Achtung, damit werden alle bisher aufgezeichneten tracks / routen gelöscht. Falls du diese noch benötigst, solltest du sie zuvor herunterladen / sichern.
Was Bluetooth betrifft, müsstest du wahrscheinlich den logger einfach mit dem von dir genutzten Gerät (z.B. Smartphone oder PC) neu koppeln. Das kann nach einem firmware update schon mal notwendig sein.
Ich habe mir ein temporäres EMail-Konto angelegt: zoppo13@tempr.email
Darüber kannst du mich die nächsten 30 Tage erreichen.
Wenn es gar nicht funktioniert können wir auch mal telefonieren oder wenn du keine Bedenken hast kann ich mich mit AnyDesk auf deinen Rechner aufschalten und mit einem der oben genannten Programme deinen logger konfigurieren.
Hallo Jo,
inzwischen glaube ich nicht, dass die firmware das Problem ist.
Vermutlich ist dein logger mit keinerlei Bluetooth-Gerät (Smatphone, PC, …) verbunden. In dem Fall leuchtet die Bluetooth Status LED im ‚LOG‘-Modus (Schalterstellung ‚LOG‘) überhaupt nicht. Abhilfe wäre hier den logger mit dem anderen Gerät neu zu koppeln. In Schalterstellung ‚NAV‘ sollte die blaue LED aber anfangs permanent leuchten (der logger wartet auf eine Bluetooth- Verbindung). Wenn keine Verbindung aufgebaut wird, geht Bluetooth nach wenigen Minuten im ‚NAV‘-Modus in stand-by um Strom zu sparen. Dann blinkt die Bluetooth Status LED langsam.
Des Weiteren ist wahrscheinlich der LOG-Speicher voll. Standardmäßig ist der iBlue 747A+ so konfiguriert, dass bei vollem Speicher die Aufzeichnung gestoppt wird. Dann leuchtet die GPS Status LED permanent rot und es können keine neuen tracks mehr aufgezeichnet werden bis die alten tracks im Speicher gelöscht wurden.
Ich habe meinen 747A+ so konfiguriert, dass er bei vollem Speicher automatisch am Anfang des Speichers weitermacht. Das hat den Vorteil, dass nicht mitten auf einer Wanderung oder Radtour die track-Aufzeichnung beendet wird, wenn der Speicher vollgeschrieben wurde. Der Speicher wird also automatisch zyklisch überschrieben, welches allerdings zu einem Verlust von alten tracks führen kann, wenn man sie noch nicht aus dem logger ausgelesen hat. Ein anderer Nachteil dieses sogenannten Ringspeicher-Modus ist meines Wissens, dass man den Speicher dann (eigentlich) immer komplett auslesen muss, selbst wenn man nur eine kleine Tour gemacht hat die lediglich einen Bruchteil des Speichers belegt. Um diesen Nachteil abzumildern hat das Programm BT747 die Download-Methode ‚Intelligenter Download‘ und man kann zusätzlich den Rest des Auslesens abbrechen, wenn man denkt, dass die Daten der neuen Tour schon vollständig ausgelesen wurden.
Den vollen Speicher deines loggers kannst du mit einem der folgenden Programme löschen:
1. http://4river.a.la9.jp/gps/file/MtkDLut.htm
2. https://www.bt747.org/
download über https://sourceforge.net/projects/bt747/files/latest/download
Es geht natürlich auch mit der originalen Software die dem 747A+ beilag. Die taugt aber nicht viel bzw. kann nicht alle Möglichkeiten des loggers nutzen.
Hier noch ein link auf die Bedienungsanleitung:
http://www.wijkamp.com/gps/pdf/um_i-blue747a_de.pdf
Falls du noch Fragen hast, kannst du eine E-Mail an zoppo13@tempr.email schicken. Das ist ein temporäres E-Mail-Konto, welches in 30 Tagen wieder gelöscht wird.
Wir können dann auch gerne mal telefonieren und wenn du keine Bedenken hast kann ich mich mit AnyDesk auch auf deinen Rechner aufschalten und mit den oben aufgeführten Programmen deinen logger konfigurieren.
Hallo Jo,
ich habe jetzt zwei Mal versucht dir ausführlich zu antworten aber beide Male wurden meine Kommentare hier nicht übernommen. Da kommt Freude auf, wenn die eigegebenen Texte ohne Fehlermeldung verworfen werden …
Schreibe mir doch einfach eine E-Mail an zoppo13@tempr.email
Ich antworte dann per mail.
Deine Kommentare wurden als Spam klassifiziert und geblockt. Da soll es an den vermeintlichen Spammer mit Absicht keine Rückmeldung geben. Ich habe die Kommentare beide freigegeben. Vielen Dank für deine Hilfe.
Hallo Zoppo13,
merci für Deine tollen Hinweise.
Vielleicht war ich etwas ungenau, also den Loggerspeicher habe ich auch komplett gelöscht, aber das hilft alles nichts er loggt einfach nicht.
MTK Download Utility Ver 3.27 kannte ich bisher gar nichts, sondern ich hab immer mit dem Programm BT747 gearbeitet, dort habe ich auch den Loggerspeicher gelöscht. Er zeigt mir auch bei Speichernutzung: 0 Punkte (0%) an im Programm BT747 V.2.2.1
Laut Anleitung soll ja der Logger wenn ich ihn auf NAV stelle, anfangen zu blinken an der Bluetooth LED, dass macht er ja leider nicht. Die Bluetooth-LED leuchtet in keiner Schalterstellung auf. Ich kann aber trotzdem eine Bluetoothverbindung aufbauen.
Ich werde mal paar Screenshots anfertigen und Dir diese auf Deine Emailadresse senden. Vielleicht erkennst Du da ja was.
Hallo Jo,
wenn die Probleme mit der Bluetooth LED und dem loggen direkt nach dem Einspielen einer anderen firmware aufgetreten sind, dann wird es doch an der firmware liegen. Weiter oben im blog gab es ja bereits andere Besitzer eines 747A+ (oder kompatiblen Modells), die sich mit der firmware aus FlashTool_exe_v4.1.0_747Pro.rar ihren logger zerschossen hatten, wohl mit ähnlichen Problemen wie sie dein logger jetzt hat (Bluetooth und log-Funktion kaputt).
Ich habe die firmware aus FlashTool_exe_v4.1.0_747Pro.rar in meinem logger ausprobiert und sie hat prinzipiell funktioniert. Mein 747A+ ‚verkraftet‘ auch die firmware des Qstarz BT-Q1000XT. Ich habe mich dann aber (auch aus Interesse) für einen patch der originalen firmware AXN_1.30-B_1.3_C01,0004,TSI_747A+,1.0 meines 747A+ entschieden, da 747Pro und BT-Q1000XT schon leicht unterschiedliche Hardware zum 747A+ besitzen (z.B. 10 Hz logging und Bewegungssensor).
Es scheint 747A+ mit älterer firmware AXN_1.0-B_1.3_C01 zu geben und ich glaube man darf die firmware AXN_1.0-B_1.3_C01 nicht durch eine AXN_1.30-B_1.3_C01 (wie vom 747Pro oder BT-Q1000XT oder neueren 747A+) ersetzen. Geräte mit der alten firmware haben vermutlich eine andere Hardware um den MTK MT3329 Chip verbaut.
Ich hatte meinen Transystem iBlue 747A+ in 2011 gekauft und er hatte bereits die firmware AXN_1.30-B_1.3_C01. Jetzt wäre es interessant wann du deinen logger gekauft hast und welche firmware er original hatte. Auch könnte man mal die Aufkleber im Batteriefach vergleichen. Schicke mir doch mal ein Bild davon.
Falls dein logger wirklich die AXN_1.0-B_1.3_C01 firmware benötigt, kann ich dir nicht helfen. Stephan scheint sie aber zu besitzen und zwar im Modell 0006. Im Bild oben steht der korrekte Versionsstring (AXN_1.0…), in der Tabelle darunter hat sich dann aber bei Modell 0006 ein Fehler eingeschlichen (AXN_1.30… statt AXN_1.0..)
Gruss
Zoppo13
Hallo Zoppo13,
ich hab dir mal auf deine Emailadresse ein Screenshot vor meiner Firmware vor dem Update geschickt. Hätte ich das mit dem patch zum auslesen der Firmware hinbekommen, hätte ich ja zuvor diese natürich damit gesichert.
Anscheinend kommt es auf die modeltypen noch drauf an. Ich hab ürigends die vom pro747+ auch noch ausprobiert, hier dasselbe wieder gpsfix ja loggen nein.
Es ist zum verrücktwerden 😉
Hallo Zoppo13,
ich denke mal der logger denkt der Speicher sei voll und deswegen loggt er nicht. Vielleicht ist er auch falsch formatiert vom Bereich her?
Anbei meine Werte aus der customer_flash.ini:
[FORM]
DA_StartAddr=0x00000C00
com=3
SerialNo.=0
baudrate=115200
bin=
bin2=
bin3=
bin4=
Series=9999
bb_chip=0
ext_clock=2
brom_start_cmd_retry_count=1
flashitemindex=2
FormatStartAddr=0x00000000
FormatLength=0x00100000
FormatOption=0
[EMI]
bank0_auto=1
bank0_cfg=0x00004102
bank1_auto=1
bank1_cfg=0x00004102
[DOWNLOAD]
file0=
file0_enable=0
[TRANS_OPTION]
packet_length=1024
baudrate_full_sync_count=1
Vielleicht ist ja im Formatbereich ein Fehler oder woanders. Kannst du mal bitte rüberschauen.
Danke
Hallo Jo,
aus dem mir zugeschickten screenshot kann man entnehmen, dass sich dein 747A+ früher als Modell 000F gemeldet hatte.Dieses Modell scheint besonders anfällig für fremde firmware zu sein. Soweit ich das dem Internet entnehmen kann, scheint es meistens (immer?) das Modell 000F zu sein, welches nach dem Einspielen fremder firmware Probleme bereitet.
Du hattest berichtet, dass Bluetooth zwar funktioniert aber nicht die Bluetooth-LED. Ausserdem werden in Schalterstellung REC keine Punkte / tracks aufgezeichnet.
Ich vermute, dass durch die falsche firmware die Schalterstellung REC nicht korrekt erkannt wird und dadurch der logger immer im NAV-Modus arbeitet in dem korrekterweise keine Aufzeichnug stattfindet.
Ohne die originale firmware des Modells 000F wirst du vermutlich deinen logger (wie einige andere Betroffene) nicht mehr vernünftig betreiben können.
Weil ich dir gerne helfen möchte, habe ich nun hier https://forum.openstreetmap.org/viewtopic.php?id=70252 darum gebeten, mir die firmware zuzuschicken. Das hatte letztes Jahr zwar schon mal jemand ohne Erfolg probiert aber er hatte auch keine Anleitung angeboten die das Auslesen der firmware beschreibt. Trotzdem bin ich nicht sonderlich zuversichtlich, dass ich die firmware bekomme werde, weil
1. das Auslesen (trotz meiner Anleitung) ein wenig technisches Wissen erfordert
2. das Modell 000F vermutlich nicht so zahlreich verkauft wurde wie andere Modelle
3. viele inzischen ihr Smartphone statt des loggers nutzen
4. eine gewissen Hilfbereitsschaft erforderlich ist, die nicht direkt entlohnt wird
Falls ich wider Erwarten doch noch die firmware bekomme, sende ich sie dir per E-Mail zu.
Gruss
Klaus
Hallo Zoppo13,
vielen Dank für Deinen großen Einsatz. So eine große hilfsbereitschaft habe ich seit jahrzehnten nicht mehr gesehen, ganz stark
Ja ist wirklich alles merkwürdig, denn die hardware ist ja dieselbe. Da bin ich mal gespannt, ob du was bekommst. Die hoffnung stirbt ja zuzuletzt
Viele grüsse
Ich habe hier eine Firmware Version AXN_1.30-B_1.3_C01 (TSI_747A+) von dem 0004 welches überraschender weise keine Datumsprobleme hat.
Leider ist die Firmware auch nicht mit meinem 747A+ kompatibel, gleiches Problem wie viele hier, kein Logging mehr. Vermutlich hab ich auch das Modell 000F
Vielleicht hilft die 0004 Firmware trotzdem jemanden.
https://www.file-upload.net/download-14301978/fw-BT747A0004.zip.html
Hallo Falco,
vielen Dank für die firmware-Datei vom Modell 0004. Ich selber besitze ja auch einen i-Blue 747A+ Modell 0004 und leider ist mein logger definitiv von dem GPS WNRO Problem betroffen. Ich habe soeben deine firmware mit meiner firmware verglichen und sie sind absolut identisch, was ich auch so erwartet hatte, da beide ja vom selben Modell 0004 stammen. Falls dein logger auch nach dem Entfernen des Akkus (für einige Minuten) nach erneutem Satellitenempfang tatsächlich das korrekte Datum anzeigt, bestätigt das meine Theorie, dass es verschiedene Chargen des MT3329 GPS chips gibt, ältere die lediglich mit dem ersten WNRO klarkommen und neuere deren ROM-Routinen auch den zweiten WNRO korrigieren können. Es wäre dann also nicht unbedingt eine Frage des logger-Modells oder der firmware-Version, ob ein 747A+ das WNRO-Problem aufweist oder nicht, sondern welche Charge des GPS chips verbaut wurde.
Leider habe ich es noch immer nicht geschafft an die firmware des Modells 000F zu gelangen. Ich werde es demnächst aber wohl noch auf GpsPasSion probieren.
Gruss
Zoppo
Good morning
I have received by KS the firmware 000F for the i-bue 747 A+
It is for model 0004 and 0006
https://1fichier.com/?470xihm4npiangwoerkn
regards
please could you reupload it? I was to slow.
Sorry, was my fault. Link didn“t work from italy. I did use an US Proxy to access your file.
Thank you
Hallo
Ich habe seit kurzen nach einem Batteriewechsel auch oben beschriebenes Problem.
ich habe mir eure Beiträge durchgelesen komme jedoch nicht wirklich klar.
Mein Gerät ist ein I-Blue 747A+
$PMTK705;AXN_1.30-B_1.3_C01,000F;Tsi_747A+;1.0*33
ausgelesen mit MtkDLut Ver3.29
Setzt diese Programm jetzt das Datum in meinem Logger ?
(damit er jetzt wieder mit dem Aktuellen Datum Aufzeichnet)
Falls ich mit meiner Firmware Helfen Kann bitte ich um eine genaue beschreibung wie ich diese Auslese
Danke Gruß Martin
Hallo Martin,
es wäre super, wenn du mir die firmware 000F deines loggers zuschicken könntest. Unter https://www.dropbox.com/s/qz5fs5b1yfonh3k/MT3329%20logger%20firmware%20auslesen.pdf?dl=0 habe ich eine Beschreibung erstellt, wie das Auslesen funktioniert. Falls du noch Fragen dazu hast, kannst du mich unter ks.mail@freenet.de per E-Mail erreichen.
Damit dein logger wieder mit dem korrekten Datum arbeitet gibt es prinzipiell 3 Möglichkeiten:
1. die real time clock (RTC) wie von Stephan oben beschrieben neu setzen. Damit stellst du wieder den Zustand her, der vor dem Akkuwechsel bestand. Nachteil: Nach jedem Akkuwechsel (Stromausfall) oder Kaltstart muss man die RTC wieder neu setzen. Vorteil: Man kann damit nichts kaputt machen.
2. Modifikation der logger firmware so wie ich es oben für das Modell 0004 beschrieben und bei meinem logger durchgeführt habe. Vorteil: Sobald der logger nach einem Akkuwechsel oder Kaltstart wieder Satellitenempfang hat, wird das Datum wieder ‚automatisch‘ korrekt eingestellt. Nachteil: Obige Modifikation gilt so nur für das Modell 0004 und müsste für das Modell 000F angepasst werden. Das erfordert ein tiefes technischen Verständnis und falls man einen Fehler macht, kann man seinen logger vermutlich unwiederbringlich unbrauchbar machen.
3. Einspielen einer ‚fremden‘ firmware eines anderen MT3329-basierten loggeres von der man weiß, dass der Hersteller dort das WNRO-Problem behoben hat (z.B. bei verschiedenen loggern von Qstarz). Nachteil: Diese Methode führt beim Modell 000F meines Wissens immer zu einem unbrauchbaren logger und scheidet für dich daher komplett aus.
Guten Gewissens kann ich dir somit nur Methode 1 empfehlen. Hier sei noch angemerkt, dass man während der Prozedur dafür sorgen sollte, dass der logger KEINEN Satellitenempfang hat und am Ende der Prozedur der logger per Schalter aus- und wieder eingeschaltet werden muss, bevor das neu gesetzte Datum verwendet wird.
Gruß
Zoppo13
Es hat lange gedauert aber nun bin ich dank Martin an die firmware des i-Blue 747A+ Modell 000F gelangt. Das ist das Modell welches nach dem Einspielen einer fremden firmware praktisch unbrauchbar wird. Wer sich vorher kein backup der orginalen 000F firmware gemacht hatte, konnte seinen logger nicht mehr nutzen.
Für solche Modell 000F logger gibt es nun Rettung:
Einfach die 000F firmware von hier https://www.dropbox.com/s/e26h9pjm7i9k5o2/AXN_1.30-B_1.3_C01%2C000F%2CTSI_747A%2B%2C1.0.bin?dl=0 herunterladen und in den logger einspielen. Danach sollte der logger wieder funktionieren, hat aber natürlich weiterhin Probleme mit dem WNRO (week number roll over). Mittels MtkDLut kan man jedoch sehr einfach die RTC (real time clock) des loggers setzen, sodass der logger zumindest bis zum nächsten Akkuwechsel (Stromausfall) mit dem korrekten Datum arbeitet.
Gruß
Zoppo13
Hallo, ich habe einen GPS Logger mit dem Namen „Travel Honey“. Den habe ich auch schon von der Bauform her mit anderen Namen gefunden, ich weiß aber nicht was da im Inneren arbeitet. Dieses Teil hat auch das Datum Problem. GPS Aufzeichnungen sind OK, halt nur Datum und Uhrzeit stimmen nicht. Ein Firmware Update gibt es sicherlich auch nicht dafür.
Was hätte ich für Möglichkeiten damit?
Ich hatte folgende Überlegung, da ja nur das Datum u. die Uhrzeit in der GPS Daten nicht stimmen, kann man diese nicht im Nachgang an Hand einer Formel korrigieren (berechnen)?
Gruß
JK
Du kannst einfach auf das Datum die fehlenden 1024 Wochen addieren. Ob das die Auslese-Software auch kann hängt davon ab, welche du verwenden musst. Welchen Chipsatz verwendet denn der GPS Logger? Ich hatte mal einen der ähnlich ausgesehen hat. Da war ein SkyTraq Venus 6 drin.
Versuche mal GPSBabel, das sollte auch per Parameter die GPS-Woche korrigieren können. Dann ist das Datum in den ausgelesenen Daten wieder korrekt. Der Link oben zeigt direkt zur Seite mit den passenden parametern.
Ich hatte zu GPSBabel mit SkyTraq auch schon mal was geschrieben: GT-750 Bluetooth GPS Logger
Hallo, danke für die Info. Ich habe das Teil mal aufgemacht, leider ist auf dem Chip nichts mehr zu lesen. Mit GPSBabel und deiner Beschreibung komme ich auch nicht auf das Teil. Auslesen geht ja noch über die PhotoTagger Software, die leider auch die Google Maps nicht mehr anzeigt. Es wären dann zwei Schritte nötig um korrekte GPX Daten zu bekommen. (Mit PhotoTagger runterladen, als GPX speichern und mit GPSBabel umwandeln).
Gruß
JK