XaioX iTrackU Sirf3 >255 mph

    Ich habe mir die Maus auch zugelegt. Bei der Auswertung der Logs aus dem Urlaub musste ich feststellen, dass Geschwindigkeiten größer 255 Meilen/Stunde nicht ausgegeben werden. Es geht einfach wieder mit 1 mph weiter. Gut, mit Excel kein Problem. Da das Flugzeug nur einmal diese Grenze über- und auch nur einmal wieder unterschritten hat, konnte man das Problem ganz einfach beheben.


    In der Dokumentation des Empfängers steht geschrieben, dass Geschwindigkeiten kleiner 515 m/s (= 1854 km/h) bewältigen kann. Liegt die falsche Geschwindigkeitsangabe an dem Tool? Das originale konnte ich übrigens nicht dazu bewegen, irgendwelche lesbaren Geschwindigkeiten auszuspucken. So konnte ich auch nicht testen, ob es an der Software liegt.


    Die Daten sind noch auf dem Empfänger gespeichert. Ich möchte sie aber bald löschen.


    Gruß
    Jo

    Hi,


    mit welchem Tool hast Du denn ausgewertet, und in welchem Format gespeichert?


    Die Maus speichert eh nur Position, Höhe, und Zeit. Daraus errechnet dann ein Tool die Geschwindigkeit.

    Zitat

    Original von Holger Issle
    mit welchem Tool hast Du denn ausgewertet, und in welchem Format gespeichert?


    Wie ich schon geschrieben habe: mit dem iTrackU-Tool (hier aus dem Forum www.dealcat.de/download/itracku.zip)


    Zitat

    Original von Holger Issle
    Die Maus speichert eh nur Position, Höhe, und Zeit. Daraus errechnet dann ein Tool die Geschwindigkeit.


    Falsch. Im Protokoll werden alle nötigen Daten geliefert. Inkl. Datum, Uhrzeit, Position, Höhe, Satelliten usw. Das sieht dann so aus (der Sprung der Geschwindigkeiten ist hier schön zu sehen):

    $GPGGA,072908.000,2804.8424,N,03426.3553,E,1,08,00.0,986.0,M,00.0,M,,*60
    $GPRMC,072908.000,A,2804.8424,N,03426.3553,E,246.00,0.00,030807,,*0C
    $GPGGA,072911.000,2805.0443,N,03426.4130,E,1,08,00.0,1002.0,M,00.0,M,,*52
    $GPRMC,072911.000,A,2805.0443,N,03426.4130,E,249.00,0.00,030807,,*05
    $GPGGA,072915.000,2805.3174,N,03426.4910,E,1,08,00.0,1028.0,M,00.0,M,,*56
    $GPRMC,072915.000,A,2805.3174,N,03426.4910,E,253.00,0.00,030807,,*02
    $GPGGA,072918.000,2805.5242,N,03426.5494,E,1,08,00.0,1048.0,M,00.0,M,,*5D
    $GPRMC,072918.000,A,2805.5242,N,03426.5494,E,255.00,0.00,030807,,*09
    $GPGGA,072921.000,2805.7331,N,03426.6091,E,1,08,00.0,1072.0,M,00.0,M,,*5B
    $GPRMC,072921.000,A,2805.7331,N,03426.6091,E,1.00,0.00,030807,,*05
    $GPGGA,072925.000,2806.0131,N,03426.6888,E,1,08,00.0,1114.0,M,00.0,M,,*58
    $GPRMC,072925.000,A,2806.0131,N,03426.6888,E,2.00,0.00,030807,,*04
    $GPGGA,072928.000,2806.2240,N,03426.7495,E,1,08,00.0,1149.0,M,00.0,M,,*5B
    $GPRMC,072928.000,A,2806.2240,N,03426.7495,E,3.00,0.00,030807,,*0E
    $GPGGA,072932.000,2806.5059,N,03426.8293,E,1,08,00.0,1191.0,M,00.0,M,,*57
    $GPRMC,072932.000,A,2806.5059,N,03426.8293,E,5.00,0.00,030807,,*01


    Gruß
    Jo

    Zitat

    Original von jorilla
    Wie ich schon geschrieben habe: mit dem iTrackU-Tool (hier aus dem Forum www.dealcat.de/download/itracku.zip)


    Ah ok, also Ingo's tool. Wo hattest Du das geschrieben? Ich sehe es nicht. Hilf einem alten Mann bitte mal auf die Sprünge...
    Damit ist Dir das eigentliche Datenformat der Maus verborgen geblieben.


    Zitat

    Original von jorilla


    Falsch. Im Protokoll werden alle nötigen Daten geliefert.


    Tja, hier hast Du leider nicht lange genug gesurft. Die Maus speichert intern die Daten binär. Ingo's tool liest das aus und löscht es danach wieder. Nimm mal die Xiaox-Tools von der CD, da bleibt die Datenbank erhalten.



    Und hier wirds nun lächerlich. Lies bitte mal nach, was in den Sätzen enthalten ist. Tipp: http://www.kh-gps.de/nmea-faq.htm
    GGA = Global Positioning System Fix Data
    RMC = Recommended Minimum Specific GPS/TRANSIT Data


    Da steht die Geschwindigkeit in Knoten drin und die Anzahl der Sats in use. Schau doch mal, ob im 7ten Feld des GGA-Satzes was anderes als 8 steht.


    Wenn Du jetzt nochmals hier im Board ein wenig suchst, dann findest Du die Entschlüsselung des Binärformates. und damit die Tatsache, daß die Geschwindigkeit nicht mit gespeichert, sondern nur nachträglich aus Position und Zeitdifferenz errechnet wurde.


    So, ich hab das jetzt mal mit TTQV analysiert... und dabei ergibt sich ein mitgeloggter Start in Kairo, am 3.8. um (hiesiger Zeit) 9:30. Und jetzt dann auch mal mit der richtigen Geschwindigkeit. Wer mag kann sich das Ergebnis in beiliegender Textdatei angucken.

    Zitat

    Original von Holger Issle
    Ah ok, also Ingo's tool. Wo hattest Du das geschrieben? Ich sehe es nicht. Hilf einem alten Mann bitte mal auf die Sprünge...
    Damit ist Dir das eigentliche Datenformat der Maus verborgen geblieben.


    Soweit ich weiß, gibt es für die Maus nur 2 Tools zum auslesen, die originale "Dump_Log_Data.exe" und das "iTrackU-Tool" von Ingo. Zumindest gibt es kein zweites "iTrackU-Tool" ;)



    Zitat

    Original von Holger Issle


    Tja, hier hast Du leider nicht lange genug gesurft. Die Maus speichert intern die Daten binär. Ingo's tool liest das aus und löscht es danach wieder. Nimm mal die Xiaox-Tools von der CD, da bleibt die Datenbank erhalten.


    Also es sind noch alle (?) Daten auf der Maus vorhanden. Ich kann jederzeit die Daten neu auslesen. Das würde wohl nicht gehen, wenn das Tool die Grundlage dafür löschen würde, oder?
    Das mit dem binären Speichern stimmt, habe nie was anderes behauptet. Das originale Tool gibt ja auch (und das hatte ich bisher übersehen) mit "Build Output Raw Data File" die gleichen Daten wie das Tool von Ingo heraus. Dort stehen die gleichen Geschwindigkeiten (mit dem gleichen Sprung), wie ich oben beschrieben habe.



    Wer lesen kann ... ;)
    Die Geschwindigkeit steht in der RMC-Protokollzeile.
    Eine 8 in der GGA-Protokollzeile an dieser Stelle existiert nicht.
    Ok, in einem hast du Recht: die Geschwindigkeit wird in Knoten und nicht in Meilen protokolliert.


    Zitat

    Original von Holger Issle
    So, ich hab das jetzt mal mit TTQV analysiert... und dabei ergibt sich ein mitgeloggter Start in Kairo, am 3.8. um (hiesiger Zeit) 9:30. Und jetzt dann auch mal mit der richtigen Geschwindigkeit. Wer mag kann sich das Ergebnis in beiliegender Textdatei angucken.


    Gestartet bin ich in Sharm el Sheikh. Kurz danach hatten wir eine Geschwindigkeit, die 255 Knoten überschritten hat. Deshalb der Auszug des Logs an dieser Stelle.
    In welcher Einheit sind denn deine Geschwindigkeiten dargestellt? - Ok selbst erkannt: kmh
    Aber dass ich sie ohne probleme per Hand (oder Excel) selber errechnen kann, hatte ich ja schon geschrieben.



    Gruß
    Jo


    PS: Bitte nicht ganz so persönlich. Danke :love2

    2 Mal editiert, zuletzt von jorilla ()

    >ich weiß, gibt es für die Maus nur 2 Tools zum auslesen, die originale "Dump_Log_Data.exe" und das "iTrackU-Tool" von Ingo. Zumindest gibt es kein zweites "iTrackU-Tool" ;)


    Du hast nur von "Tool" geschrieben.


    >Das würde wohl nicht gehen, wenn das Tool die Grundlage dafür löschen würde, oder?


    Es löscht die binärablage am PC, nicht in der Maus.


    >Das mit dem binären Speichern stimmt, habe nie was anderes behauptet. Das originale Tool gibt ja auch (und das hatte ich bisher übersehen) mit "Build Output Raw Data File" die gleichen Daten wie das Tool von Ingo heraus. Dort stehen die gleichen Geschwindigkeiten (mit dem gleichen Sprung), wie ich oben beschrieben habe.


    Dann schau Dir die 4MB große Binärdatei an. Die ist ein Abbild des Speichers in der Maus. Alle anderen Formate errechnet das jeweilige Tool. Und die haben wohl einen Fehler, nicht aber die Maus. Denn die speichert die Geschwindigkeit gar ned ab.



    $GPGGA,072908.000,2804.8424,N,03426.3553,E,1,08,00.0,986.0,M,00.0,M,,*60
    $GPRMC,072908.000,A,2804.8424,N,03426.3553,E,246.00,0.00,030807,,*0C


    >Eine 8 in der GGA-Protokollzeile an dieser Stelle existiert nicht.


    Stimmt, da steht 08. Siehe genau hin, ich habs extra fett gemacht.


    Für mich ist hier EOT da mir scheint daß es Dich eh ned interessiert was ich schreibe.

    Doch, es interessiert mich.
    Mit dem "Tool" hast du Recht.
    Ok, das Löschen im PC ist dann wohl nicht wirklich für das Verständnis der Funktionsweise nötig.


    Mit der Geschwindigkeit liegst du immer noch falsch. Zitat aus deinem Link:

    $GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh
    GGA = Global Positioning System Fix Data
    1 = UTC of Position
    2 = Latitude
    3 = N or S
    4 = Longitude
    5 = E or W
    6 = GPS quality indicator (0=invalid; 1=GPS fix; 2=Diff. GPS fix)
    7 = Number of satellites in use [not those in view]
    8 = Horizontal dilution of position
    9 = Antenna altitude above/below mean sea level (geoid)
    10 = Meters (Antenna height unit)
    11 = Geoidal separation (Diff. between WGS-84 earth ellipsoid and
    mean sea level. -=geoid is below WGS-84 ellipsoid)
    12 = Meters (Units of geoidal separation)
    13 = Age in seconds since last update from diff. reference station
    14 = Diff. reference station ID#
    15 = Checksum



    $GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh
    RMC = Recommended Minimum Specific GPS/TRANSIT Data
    1 = UTC of position fix
    2 = Data status (V=navigation receiver warning)
    3 = Latitude of fix
    4 = N or S
    5 = Longitude of fix
    6 = E or W
    7 = Speed over ground in knots
    8 = Track made good in degrees True
    9 = UT date
    10 = Magnetic variation degrees (Easterly var. subtracts from true course)
    11 = E or W
    12 = Checksum


    Auf folgender Seite auf deutsch und besser - weil mit Erklärungen - beschrieben: Das NMEA-0183 Datenformat



    Meine eigentliche Frage ist damit aber immer noch nicht beantwortet:
    Warum gibt die Maus (auch nicht das originale Tool von der CD) nicht die korrekten Geschwindigkeiten in Knoten aus?


    Lt. technischen Details kann sie bis 515 m/s (= 1854 km/h oder 1000 Knoten) mithalten. Sie gibt sie nur nicht korrekt aus.


    Meine Frage ist ernst gemeint. Mein Wissen in Bezug auf die GPS-Protokolle beruht im Wesentlichen auf den zitierten Seiten (und noch einigen anderen) und ist bei Weitem nicht vollkommen. Einige Detail bringe ich auch schon mal durcheineinder. Ich möchte damit niemanden angreifen, erwarte aber auch, nicht dumm angemacht zu werden. Also, wer ersthaft weiter diskutieren möchte, ist gerne eingeladen.


    Gruß
    Jo


    PS:
    >Eine 8 in der GGA-Protokollzeile an dieser Stelle existiert nicht.
    Stimmt, da steht 08. Siehe genau hin, ich habs extra fett gemacht.


    Du beschreibst die Satteliten in use.
    Ich war in der Zeile verrutscht und bei der Qualität der Messung gelandet. Die hat die möglichen Werte 0, 1, 2 und 6. Mein Fehler : drink

    Einmal editiert, zuletzt von jorilla ()

    Zitat

    Original von jorilla
    ...
    Meine eigentliche Frage ist damit aber immer noch nicht beantwortet:
    Warum gibt die Maus (auch nicht das originale Tool von der CD) nicht die korrekten Geschwindigkeiten in Knoten aus?


    Lt. technischen Details kann sie bis 515 m/s (= 1854 km/h oder 1000 Knoten) mithalten. Sie gibt sie nur nicht korrekt aus.
    ...


    Hallo jorilla


    Vorab:
    Ich habe keinen solchen Empfaenger und kann daher nicht mit praktischen Beispielen dienen.



    Ich denke das hier der Kern der unterschiedlichen Meinungen aufgrund zweier Stellen besteht.
    1.) Interne Datenaufzeichnung
    2.) Ausgabe an das Naviprogramm



    1.)
    Wenn ich die bisherigen Threads zum Empfaenger richtig verstanden habe, dann speichert der Empfaenger inten die Daten im Binaerformat ab. Bei diesen Daten ist aber keine vollstaendige NMEA-Protokollierung vorhanden, sondern es werden Uhrzeit, Position, Hoehe, ..., aber keine Geschwindigkeit. Die Geschwindigkeit kann aber, wenn es sich um zeitzyklische Aufzeichnungen geht, leicht aus den Zeitunterschieden der Positionsdaten errechnet werden. Genau das scheint hier auch der Fall zu sein. Wenn das so stimmt, dann ist der falsche Geschwindigkeitswert aber kein Problem des Empfaenegrs, sondern der Software die aus den binaeren Daten die Geschwindigkeit rechnet.


    2.)
    Unabhaengig von Punkt 1, werden natuerlich Daten an das Naviprogramm gegeben. Hier werden aber bestimmt die NMEA-Protokolle ausgegeben. Das waere jetzt der ideale Zeitpunkt gewesen fuer ein externes LogFile. Damit haette man sehr schoen sehen koennen, was der Empfaenger ans Navi liefert. Also, ob auch hier die Geschwindigkeit gekappt wird.
    Hast Du zufaellig eins gemacht?



    Das geschriebene basiert darauf das ich das mit der internen Abspeicherung der Daten bisher richtig verstanden habe.

    Hi Alfred,


    >

    Zitat

    Ich denke das hier der Kern der unterschiedlichen Meinungen aufgrund zweier Stellen besteht.


    Ja!


    Zitat

    Wenn ich die bisherigen Threads zum Empfaenger richtig verstanden habe, dann speichert der Empfaenger inten die Daten im Binaerformat ab.


    Korrekt, genau wie Deine Schlußfolgerung.


    Zitat

    Unabhaengig von Punkt 1, werden natuerlich Daten an das Naviprogramm gegeben. Hier werden aber bestimmt die NMEA-Protokolle ausgegeben.


    Logfile folgt morgen. Ich hab eines gemacht. In dem ist aber das Geschwindigkeits-Feld vom RMC leer, und ich habe den VTG-Satz nicht gespeichert (falls er überhaupt geliefert wird). Das will ich heut abend noch mal prüfen.


    Sicher ist aber, daß das Tool, das die Daten aus dem Binärformat der Maus in das sogenannte RAW oder NMEA-Format wandelt, leider fehlerhaft ist.

    Kann es sein, daß beide Auswertungsprogramme bei der Geschwindigkeit auf 8 bit beschränkt sind ?


    2 hoch 8 macht 256, das reicht dann bei ganzzahliger Darstellung für 0 ... 255 Knoten.

    Kaum bist mal kurz weg sieht alles gleich ganz anders aus ??

    Zitat

    Original von jorilla
    Meine eigentliche Frage ist damit aber immer noch nicht beantwortet:
    Warum gibt die Maus (auch nicht das originale Tool von der CD) nicht die korrekten Geschwindigkeiten in Knoten aus?


    Lt. technischen Details kann sie bis 515 m/s (= 1854 km/h oder 1000 Knoten) mithalten. Sie gibt sie nur nicht korrekt aus.


    Also nochmal: Die Maus speichert keine Geschwindigkeit! Nimm BITTE das original-Dump-Tool. Schau mal nach der 4MB großen Datei die dabei erzeugt wird. Nimm einen Hex-Editor und schau den Inhalt an. Da ist keine Geschwindigkeit drin. Wenn die doch da drin ist, zeige sie uns.


    Lies bitte mal Seite 2 der Diskussion "Xaiox iTruck U mit Sirf III Chip", speziell die Beiträge von honx: Xaiox iTruck U mit Sirf III Chip


    So, wenn jetzt beide tools die Geschwindigkeit gleich falsch ausgeben, denke ich daß Ingo da eine Bibliothek zum dekodieren des Binärformates nutzt, die auch vom Dump-Tool genutzt wird, und einen Fehler hat. Anders kann ich mir das nicht vorstellen.

    Einmal editiert, zuletzt von Holger Issle ()

    Zitat

    Original von Holger Issle
    ...
    Logfile folgt morgen. Ich hab eines gemacht. In dem ist aber das Geschwindigkeits-Feld vom RMC leer, und ich habe den VTG-Satz nicht gespeichert (falls er überhaupt geliefert wird). Das will ich heut abend noch mal prüfen.
    ...


    Hallo Holger


    Also mal schnell ein LogFile erstellen bei dem eine Geschwindigkeit groesser als 255mph gefahren wurde. Das ist bei Deinem Moped moeglich?
    :] :] :]


    Nein, wieder ernsthaft. Ich denke, das wenn das Problem ueberhaupt auftreten sollte, das nach der Beschreibung erst jenseits dieser 255mph liegen sollte.

    Zitat

    Original von 900SS-97
    2.)
    ... Das waere jetzt der ideale Zeitpunkt gewesen fuer ein externes LogFile.
    ...
    Hast Du zufaellig eins gemacht?


    Nein, habe ich leider nicht. Bluetooth ist im Flieger nicht erlaubt. Dadurch konnte ich auch die Daten nicht live im Naviprogramm sehen, sondern erst hinterher am Computer.


    Zitat

    Bogi100
    Kann es sein, daß beide Auswertungsprogramme bei der Geschwindigkeit auf 8 bit beschränkt sind ?


    2 hoch 8 macht 256, das reicht dann bei ganzzahliger Darstellung für 0 ... 255 Knoten.


    Das ist die wahrscheinlichste Ursache. Eine manuelle Erhöhung der Werte ist ja möglich und es ergibt sich eine kontinuierliche Steigerung der Geschwindigkeit.


    Gruß
    Jo

    Zitat

    Original von Holger Issle
    Lies bitte mal Seite 2 der Diskussion "Xaiox iTruck U mit Sirf III Chip", speziell die Beiträge von honx: Xaiox iTruck U mit Sirf III Chip


    Ok, habs nochmal gelesen. Das "Detail" hatte ich nach 14 Tagen und tausenden folgenden Beiträgen schon wieder vergessen.


    Das erklärt übrigens einiges. Hättest du schon früher mal genauer erklärt, was du mit "binär" meinst, dann hätten wir nicht ständig aneinander vorbei geredet. Man könnte auch binär wesentlich mehr Daten speichern. Hat man aber leider nicht.


    Hier noch mal zum Nachvollziehen:


    Gut, die Höhe scheint mittlerweile dazu gekommen zu sein.


    Das erklärt auch deine 8 Satelliten (habe mich bisher immer gewundert, warum du auf der 8 herumhackst). ;D
    Die wurden anscheinend nur pro forma ins Protokoll eingefügt.


    Und mit einem Hex-Editor kann ich die Daten auch nicht entschlüsseln. Ich erkenne dort einfach nichts. Wenn du es kannst, dann fühle dich bitte genötigt, uns teilhaben zu lassen.



    Fazit 1:
    Es werden nur die absolut notwendigen Daten geloggt.
    Damit kommt man auf die werbewirksame große Anzahl von 249.856 Wegpunkten (Speicherkapazität).
    Da bin ich dann doch auf eine Werbebotschaft hereingefallen :-D)


    Fazit 2:
    Zumindest die Geschwindigkeit wird durch die Auswerteprogramme auf 8bit beschränkt. Daher die "falsche" Geschwindigkeit im Flugzeug. Zumindest in den Log-Dateien.
    Ausgabe im Naviprogramm wahrscheinlich richtig, da dort auch die richtigen SatInUse angezeigt werden, also die Protokolle komplett übermittelt werden.


    Gruß
    Jo
    :love2

    Mir ist der Sachverhalt bisher nicht aufgefallen, weil ja offensichtlich die Auswertprogramme, die ich benutze (z.B. Gartrip) die Geschwindigkeit aus Zeit und Position selbst errechnen. Zum Beispiel war ich zu folgendem Zeitpunkt laut Gartrip mit 823 km/h unterwegs:


    $GPRMC,130000.000,A,4215.2520,N,02213.7855,E,188.00,0.00,190707,,*02


    Also ist dieser offensichtliche Fehler kein Problem für mich. Gott sei Dank, einmal kein Problem!