Holux M-1000C; falsches Datum der Trackpunkte

Hallo zusammen,

seit gestern bin ich (stolzer) Besitzer des o.g. Loggers.

Also ausgepackt, Bluetooth-Dongle an meinem Windows-XPRechner eingerichtet (hatte bisher noch nix mit BT zu tun) und den Logger eingeschaltet. Nach kurzen Schwierigkeiten, die aber an meiner fehlenden BT-Erfahrung lagen, war die Verbindung hergestellt. Die GPS-Maus-Funktion klappte im Zusammenspiel mit TTQV4 auf Anhieb. Bis dahin also alles bestens.

Nun sollte es an das Auslesen des Trackspeichers gehen. Also noch kurz ums Haus gerannt und dann das mitgelieferte Programm Holux GPS ezTour gestartet. Daten werden ausgelesen - zumindest zeigt ein Fortschrittsbalken das so an - und dann kommt die Meldung "Keine Daten vorhanden". Auch mehrmaliges Probieren brachte keinen Erfolg.

Nach einigem Suchen stieß ich auf das auf Java-Script basierende Tool BT747. Nach kurzer "Einarbeitung" gelang es mir dann, die Logdaten auszulesen. Diese wurden in einer *.bin-Datei abgelegt, wohl ein"spezielles" Format von Holux bzw. dem MTK-Chiphersteller. Beim Umwandeln dieser Datei in das gpx-Format erhielt ich vom Tool BT747 dann die Fehlermeldung (sinngemäß) "Keine gültigen Daten". Also versuchte ich es dann mit GPSBabel und - oh Wunder - es entstand eine gpx-Datei, wie gewünscht.

Diese Datei habe ich dann nach TTQV4 importiert - und nun kommt's: alle Trackpunkte trugen als Datum den 18.10.2028! Die Uhrzeit der Trackpunkte war hingegen korrekt. Daten die ich heute aufgezeichnet habe, wurden mit Datum 19.10.2028 abgelegt. Das falsche, in der Zukunft liegende Datum scheint dem Programm Holux GPS ezTour beim Auslesen die Probleme zu bereiten und beim Umwandeln von *.bin in *.gpx mit BT747 schlägt das Datum ebenfalls zu, wie ich herausfand. Nachdem ich in dem Programm den Datumsfilter auf den 19.10.2028 hochgesetzt hatte, lief hier nun auch die Konvertierung problemlos.

So, das war eine lange Vorrede, aber ich glaube zum besseren Verständnis der folgenden Fragen nötig.

Also:

Wie wird eigentlich das Datum im GPS-Empfänger ermittelt? Wird es im "Klartext" gesendet oder von der Firmware des Loggers errechnet?

Wie kann es überhaupt zu einem solchen Fehler des Loggers kommen und hat jemand ähnliche Erfahrungen gemacht?

Hinzufügen möchte ich noch, dass ich mit dem Logger bei Inbetriebnahme einen sog. Kaltstart gemacht habe, diesen habe ich heute auch nochmal wiederholt. Zu ergänzen wäre auch noch, dass der heute aufgezeichnete Track über mehr als 4 km Fußwanderung äußerst exakt aufgezeichnet und in TTQV4 auch so angezeigt wurde.

Der Verkäufer sagte mir übrigens heute sofortige Ersatzlieferung zu, nachdem ich ihn von diesem komischen Verhalten informiert hatte - es ist übrigens nicht der in einem anderen Beitrag erwähnte Deutschlandvertrieb.

So, und nun bin ich auf Eure Antworten und Vermutungen gespannt.

Gruß

fesi

Zitat von fesi

Diese wurden in einer *.bin-Datei abgelegt, wohl ein"spezielles" Format von Holux bzw. dem MTK-Chiphersteller.

Es ist das Speicherabbild des Loggers.

Zitat

Beim Umwandeln dieser Datei in das gpx-Format erhielt ich vom Tool BT747 dann die Fehlermeldung (sinngemäß) "Keine gültigen Daten". Also versuchte ich es dann mit GPSBabel und - oh Wunder - es entstand eine gpx-Datei, wie gewünscht.

Was ist daran ein Wunder? Das Tool dürfte auch funktionieren: http://homepage2.nifty.com/k8/gps/#006

Zitat

Wie wird eigentlich das Datum im GPS-Empfänger ermittelt? Wird es im "Klartext" gesendet oder von der Firmware des Loggers errechnet?

Was sagt der Support des Herstellers dazu?

Das Datum wird von den Satelliten empfange. Die Ursache deines Problems, liegt in der Software, die Holux als OEM dem Bundel beigelegt hat. Verwende GPSbabel zum Download, dann hast Du den Stress nicht.

Zitat

Wie kann es überhaupt zu einem solchen Fehler des Loggers kommen und hat jemand ähnliche Erfahrungen gemacht?

Der Logger hat keinen Fehler. Das Modul ist bei Transystem gefertigt und funktioniert hervorragend. Das Kernproblem ist, das Holux sein Bundel etwas lieblos zusammengestelt hat.

Zitat

Hinzufügen möchte ich noch, dass ich mit dem Logger bei Inbetriebnahme einen sog. Kaltstart gemacht habe, diesen habe ich heute auch nochmal wiederholt.

Wie kommst Du darauf? Wie lande dauerte der Start des Empfängers? Normaler Weise wäre ein Warmstart von ca. 30-40 Sekunden üblich. Schneller würde es mit AGPS funktionieren, aber dazu war Holux zu geizig, obwohl es die Hardware es hergeben würde. Wenn das Gerät tatsächlich länger als ein Minute benötigt, dann ist der Goldcap Kondensator defekt und das Gerät ist zu reklamieren.

Zitat

Der Verkäufer sagte mir übrigens heute sofortige Ersatzlieferung zu,

Ob das hilft? Der neue Logger wird das selber Verhalten bezüglich Datum zeigen.

Gruss Joern Weber

Hallo Joern,

zunächst vielen Dank für Deine Antwort.

Den von Dir genannten Link habe ich mir eben kurz angeschaut. Ich werde mir das Tool noch heute herunterladen und ausprobieren.

Du fragst, warum ich erstaunt gewesen sei, dass das Herunterladen und Umwandeln in eine GPX-Datei mit GPSBabel letztlich funktioniert hat: Nun, nachdem ich geraume Zeit mit der beigefügten Software von Holux experimentiert hatte, hatte ich eigentlich nicht mehr mit einem solchen Erfolg gerechnet. Zumal mir vom Support des Lieferanten gesagt worden ist, dass das Herunterladen der Log-Daten sowieso nicht über die Bluetooth-Schnittstelle, sondern nur mit dem "besonderen" USB-Kabel ginge, welches meiner Lieferung versehentlich nicht beigelegen hatte. Inzwischen bin ich schlauer - natürlich geht es über BT.

Nun könnte ich natürlich auf die mitgelieferte Software verzichten und den Logger immer mit GPSBabel auslesen. Allerdings liefert auch GPSBabel mir das falsche, in der Zukunft liegende Datum. Ich muß dann beim Erstellen der GPX-Datei mit dem Timeshift arbeiten und das gelieferte Datum um genau 7.168 Tage verringern, dann passt es. Habe ich heute ausprobiert. Aber das ist mir eigentlich zu sackig, schließlich handelt es sich um ein Neugerät, das nicht das tut, was es eigentlich sollte - nämlich korrekte Daten liefern. Meiner Einschätzung nach handelt es sich um einen Fehler in der Firmware des Loggers, denn das Datum wird ja schon im Logger falsch abgelegt. Angeblich kann man die Firmware ja updaten, aber dazu müsste man erstmal die neue Firmware finden.

Viel Hoffnung habe ich ehrlich gesagt auch nicht, dass das Ersatzgerät diesen Fehler nicht mehr aufweist, aber Mitte nächster Woche weiß ich mehr.

Zu dem von mir (vermeintlich) durchgeführten Kaltstart muß ich nach Deinem Hinweis sagen, dass es sich wohl bei der Erstinbetriebnahme doch nur um einen Warmstart gehandelt hat (ca. 30 Sekunden). Ich nahm nur an, dass, wenn das Gerät längere Zeit ohne Akku war, nach Einlegen des Akku immer ein Kaltstart gemacht würde.

Sollten meine weiteren Versuche mit dem Ersatzgerät ebenfalls scheitern, werde ich von meinem Rückgaberecht Gebrauch machen und den Kauf stornieren. Aber was dann kaufen, gibt es einen Favoriten unter den Loggern, vielleicht den QStarz BT-Q1000X?

Viele Grüße

fesi

Hallo zusammen,

nach Urlaub und einer Testphase des Austauschgerätes kann ich nun berichten, dass der Logger Holux M-1000C problemlos funktioniert, insbesondere wird nun auch das richtige Datum geliefert.

Das Auslesen der Daten klappt am Besten mit der beigefügten Software Holux GPS ezTour, denn beim anschließenden Export ins NMEA-Format und der Weiterbearbeitung in TTQV4 sind alle gewünschten Daten (Koordinaten, Datum, Uhrzeit, Geschwindigkeit und Höhe) vorhanden. Die Höhendaten müssen allerdings um die Höhenangabe bei "Geoid" (bei mir -47m) korrigiert werden.

Lese ich die Daten hingegen mit BT747 oder GPSBabel aus und konvertiere sie nach NMEA bzw. GPX, erhalte ich in den Feldern Höhe und Geschwindigkeit keine bzw. falsche Angaben.

Ein Auslesen mit MtkDLut, dass ich eigentlich wegen seiner Kompaktheit am liebsten nutzen würde, funktioniert leider überhaupt nicht. Wenn ich den Hinweis in der Readme-Datei richtig verstehe, muss ich den Logger - da er dem Programm nicht bekannt ist - in der Datei MTKDLut.ini nachtragen:
.
.
.
[GPS_Data]
Unknown=Unknown,8002003F,0,0,1,,
M-core=Unknown,0002003F,0,0,1,,
B-core=Unknown,8002003F,0,0,1,,
M-91=V-900 is inapplicable.
TSI_821=i-Blue821,8002003F,0,2,1,,"$PTSI999,IAMAP"
01017-00D=M-241 Ver1.11,8000001D,1,2,1,,"$HOLUX241,6"
01017-00E=M-241,8000001D,1,2,1,,"$HOLUX241,6"
QST1300=BT-Q1300,8002003F,0,1,0,28,
TSI_747A+=i-Blue747A+,0002003F,0,1,2,28,
QST1000=BT-Q1000X,0002003F,0,1,2,28,

Aber irgendwie weiß ich da nicht so recht, wie ich das machen soll. Weiß jemand welche Angaben da rein müssen?

Würde mich über Hilfe freuen.

Gruß

fesi

Zitat von fesi

Das Auslesen der Daten klappt am Besten mit der beigefügten Software Holux GPS ezTour, denn beim anschließenden Export ins NMEA-Format und der Weiterbearbeitung in TTQV4 sind alle gewünschten Daten (Koordinaten, Datum, Uhrzeit, Geschwindigkeit und Höhe) vorhanden. Die Höhendaten müssen allerdings um die Höhenangabe bei "Geoid" (bei mir -47m) korrigiert werden.

hallo fesi,

kannst du mal mit TTQV überprüfen ob es sich bei den Geschwindigkeiten im NMEA-Datensatz um die tatsächlichen Geschwindigkeiten oder um nachträglich aus v = ds / dt berechnete Geschwindigkeiten handelt. Dazu brauchst du nur den Track in TTQV kopieren und bei der Kopie die Geschwindigkeit aus v = ds / dt neu berechnen lassen. Wenn die Werte identisch sind dann ist auch in der NMEA-Datei nur die nachträglich berechnete Geschwindigkeit enthalten.

Grüsse - Anton

Zitat von fesi

Ein Auslesen mit MtkDLut, dass ich eigentlich wegen seiner Kompaktheit am liebsten nutzen würde, funktioniert leider überhaupt nicht.

Was funktioniert nicht? Fehlermeldung? Welche Versionsnummern zeigen MTKDlut und BT747 an?
Hast Du den Autor schon in englischer Sprache informiert?

Gruss Joern Weber

Hallo Anton,

also TTQV übernimmt die Geschwindigkeit direkt aus dem NMEA-Satz mit der Satzkennung GPRMC. Nach der NMEA-Spezifikation ist die Geschwindigkeit dort allerdings in Knoten angegeben (1 kn = 1,852 km/h), d.h. TTQV rechnet diese Angaben in km/h um.

Abweichend von Deinem Vorschlag habe ich das getestet, in dem ich in 2 entsprechende NMEA-Datensätze von Hand geänderte (falsche) Geschwindigkeitsangaben eingestellt und die Datei dann erneut in TTQV eingelesen habe. Das ergibt zwar eine Warnung in TTQV wegen falscher Prüfsummen aber in dem erzeugten Track finden sich genau diese von mir eingegebenen Geschwindigkeitsangaben wieder. Somit ist bewiesen, das TTQV nicht neu berechnet sondern die im entsprechenden NMEA-Datensatz enthaltene Geschwindigkeit von Knoten in km/h umrechnet und dann so abspeichert.

Hoffe geholfen zu haben.

Gruß

fesi

hallo fesi,

wie TTQV arbeitet ist mir bekannt
meine Frage war ob die Geschwindigkeiten in den NMEA-Dateien bereits berechnete Geschwindigkeiten nach v = ds / dt sind.

Grüsse - Anton

Hallo Joern,

Zitat von Joern_Weber

Was funktioniert nicht?

Nun, wie ich schon schrieb, funktioniert das Auslesen der Daten nicht.

MtkDLut fängt zwar mit dem Auslesen an, d.h. es durchläuft den Ausleseprozess mehrfach, wie an dem Fortschrittsbalken zu erkennen ist.

Zitat

Fehlermeldung?

Nach jedem Durchlauf zeigt das Programm die Meldung "Error SKIP: n" an, wobei "n" für die Anzahl der Durchläufe steht.

Mein Logger enthält z. Zt. 35.718 Datensätze, MtkDLut macht hier 12 Durchläufe (Versuche) die Daten auszulesen.

Zum Abschluss will das Programm dann die Daten speichern (bei mir im CSV-Format), aber die so erzeugte Datei ist bis auf die Titelzeile mit den Spaltenangaben leer.

Zitat

Welche Versionsnummern zeigen MTKDlut und BT747 an?

MtkDLut Version 1.14
BT747 Version 1.68.6

Zitat

Hast Du den Autor schon in englischer Sprache informiert?

Nein, noch nicht, aber das wird mein nächster Schritt sein.

Gruss

fesi

Hallo Anton,

Zitat von macnetz

wie TTQV arbeitet ist mir bekannt
meine Frage war ob die Geschwindigkeiten in den NMEA-Dateien bereits berechnete Geschwindigkeiten nach v = ds / dt sind.

Ja, wer lesen kann ist klar im Vorteil!

Nun habe ich begriffen, was Du wolltest. Es gab da ja schon mal eine Diskussion über dieses Thema.

Also ich habe es eben probiert und siehe da, im NMEA-Satz scheinen die tatsächlichen Geschwindigkeiten angegeben zu sein. Berechne ich sie in TTQV neu, bekomme ich andere Ergebnisse.

Gruß

fesi

Zitat von fesi

Nach jedem Durchlauf zeigt das Programm die Meldung "Error SKIP: n" an, wobei "n" für die Anzahl der Durchläufe steht.

Das ist ein Timing-Fehler. MTKDlut muss dann auf die Firmware des des 1000C angepasst werden. MTKDlut erkennt die Geräte an der Firmware-Version. Welche Firmware meldet der Logger? Diese Info benötigt der Autor des Programms um dir helfen zu können.

Gruss Joern Weber

Zitat von Joern_Weber

... Welche Firmware meldet der Logger? ...

Es handelt sich um die Firmwareversion AXN_1.0-B_1.3_C01
Die Flash-ID (C22016C2) dürfte ebenfalls wichtig sein - so verstehe ich den Hinweis in der Readme-Datei.

Werde mich heute oder morgen mal daran machen, mit dem Programmautor Verbindung aufzunehmen. Ich halte euch auf dem Laufenden.

Gruß

fesi