XAiOX iTrackU unter Linux nutzbar

    Hallo,


    ich habe zwei Perl-Scripts zum Auslesen und Konvertieren der Tracks aus dem XAiOX iTrackU unter Linux geschrieben:


    http://www.schimmelnetz.de/projekte/iTU4l/


    Bisher konnte ich sie nur mit dem Nemerix Chipsatz testen. Das Auslesen sollte auch mit SIRFIII funktionieren, allerdings werden dann wahrscheinlich mindestens die Datumsangaben falsch sein. Bitte schickt mit mal ein DB.sr und ein zugehöriges .csv-File, damit ich das beheben kann (ich habe nur einen Nemerix).


    Weiterhin habe ich bisher nur Daten von der Nordhalbkugel und mit östlicher Länge hier. Bitte sendet mit mal ein DB.sr und ein zugehöriges .csv-File von der Südhalbkugel und mit westlicher Länge zum Testen.


    uwrpft

    Hallo,


    ich habe gerade Dein Script ausprobiert. Das Auslesen funktioniert schon ganz gut. Leider klappt das Löschen (mit der Spezialversion) noch nicht. Ich habe dabei das Programm mit : "./iTU4l.pl -e -a " gestartet. Beim zweiten Versuch hat es leider immer noch runtergeladen...


    Wäre es vielleicht noch möglich zusätzlich einen GPX-Export zu bekommen?


    Ich habe übrigens auch nur den iTracku mit dem Nemerix Chipsatz, und auch nur die Möglichkeit positive Lat und Lon zu testen.



    Dank und Grüße
    Oliver

    Hi zusammen,
    hm, habe glaube ich noch was auf meiner Xaiox iTruckU Sirf III drauf. Werde es mal auslesen und hier reinstellen.
    LG
    Wolfgang

    Hallo Oliver,


    ich denke, das ist ok so. Beim ersten Mal wurde der Inhalt des Speichers gelesen und danach wegen der Option -e gelöscht. Beim zweiten Mal hast Du den einfach den leeren Speicher gelesen. Wenn Du den Speicherdump des ersten und des zweiten Lesevorganges jeweils nach csv konvertierst oder Dir mit der Option print ansiehst, wirst Du (hoffentlich) feststellen, daß der erste Dump Trackdaten enthält, der zweite nicht.


    Hintergrund: Es handelt sich offenbar um NOR-Flash-Speicher im Logger. Ein Löschen des Speichers setzt alle Bits, es steht also hexdezimal in jedem Byte 0xFF drin. Wenn der Logger dann Trackdaten ablegt, setzt er einzelne Bits, so daß aus den 0xFF andere Zahlen werden, die Koordinaten und Datum darstellen. Der Logger kann offenbar nur seinen gesamten Speicherinhalt am Stück ausgeben und stoppt diese Ausgabe nicht, wenn unbeschriebene Speicherbereiche, also nur noch 0xFF-Bytes kommen. Das entgegennehmende Programm am PC kann ihn dabei nicht unterbrechen, wenn es z.B. feststellt, daß nur noch 0xFF kommt. Es muß alle Daten bis zum Ende abnehmen, weil der Logger vorher nicht wieder auf neue Befehle antwortet. Diese Daten landen in der Ausgabedatei.


    Das ist bei der Windows-Software genauso. Die DB.sr entsteht auch, wenn der Logger ausgelesen wird, nachdem er frisch gelöscht ist. Du merkst den Unterschied erst in den csv- oder kml-Dateien.


    Wenn Du bestätigen kannst, daß der zweite Dump leer ist, kann ich die neue Version hochladen.


    GPX: Hast Du eine Beispieldatei on GPX und die gleiche in csv ?



    Hartmut

    Hallo Hartmut,


    Ich hab mal schnell nachgeschaut: in den files ist nur die FF drin. Scheint also zu klappen. Ich habe auch versucht das Programm mit CTRL-C während des download abzubrechen, dann reagiert die Maus aber eine Zeitlang gar nicht mehr (vermutl. sendet die einfach weiter?).


    Für das GPX kann man theoretisch auch gpsbabel zur Konvertierung nehmen. Der csv Import ist aber nicht gerade einfach. Deshalb habe ich Dir mal ein Beispiel aus einem nmea-File angehängt.


    Dank und Grüße
    Oliver

    Zitat

    Original von uwrpft
    Bisher konnte ich sie nur mit dem Nemerix Chipsatz testen. Das Auslesen sollte auch mit SIRFIII funktionieren, allerdings werden dann wahrscheinlich mindestens die Datumsangaben falsch sein.
    uwrpft


    Nicht nur die Datumsanzeige wird falsch sein, auch speichert der Sirf III v1.1 die Hoehe mit.


    Ich hab mal kurz deinen Code ueberflogen: das letzte Byte (meist steht FF darin), welches bei dir mit der Variable $e bezeichnet wird, enthaelt den Tag fuer einen Track, falls man die Funktion angeschalten hat am Geraet.


    Ich habe hier: offene Fragen zur iTrackU-Maus und dem -Tool auch mal eine Auflistung zum Sirf III v1.1 gemacht.


    Leider warte ich auch noch auf Logs aus anderen Himmelsrichtungen und mit dem Datumsformat haut auch noch was nicht hin.


    Gruesse RoXXoR

    @or42:
    Danke. Ja, man kann das Programm zwar mit CRTL-C abbrechen, aber der Logger leert sich trotzdem bis zum Ende aus. GPX als Export ist machbar.


    @RoXXeR:
    Danke, Deinen Thread hatte ich noch nicht gesehen (bin neu in der Szene). Werde das mit dem TAG einpflegen. Kannst Du mir ein SIRFIII-Logfile zum Testen schicken ?


    Hartmut

    Südhalbkugel und westliche Länge im Nemerix-Format entschlüsselt:


    # west lon starts from 0x80000000
    if ( $lon >= 0x80000000 ) {
    $lon -= 0x80000000;
    $lon *= -1;
    }



    # south lat starts from 0x80000000
    if ( $lat >= 0x80000000 ) {
    $lat -= 0x80000000;
    $lat *= -1;
    }



    Bitte bitte bitte sendet mir ein .sr vom SIRFIII.



    Hartmut

    Kann mir nochmal jemand erklären, wie man das mit den Tags bedient ? In der Anleitung habe ich dazu nichts gefunden.

    @Oliver:


    sr2x-pl unterstützt jetzt das GPX-Format. Bitte testen.


    Hartmut

    Hallo Hartmut,


    ging eigentlich ganz gut, bis auf eine Kleinigkeit: Lat und Lon waren vertauscht. (Zeile 494).


    Die Uhrzeiten waren auf GMT. Ist dass immer so?


    Grüße
    Oliver

    iTU4l.pl
    Timing beim Einlesen der Trackdaten vom Router wesentlich verbessert. Bei mit jetzt keinerlei Abbrüche des Einlesevorganges mehr.



    sr2x.pl:
    Option -b / -e hinzu für Datums- und Uhrzeiteinschränkung bei der Ausgabe
    Option -d hinzu für tagweises Splitten der Ausgabedateien



    @Oliver:
    Vielen Dank. lon/lat ist bei gpx jetzt richtig.
    Ja, bisher immer alles in GMT.


    Hartmut

    Es gibt jetzt auch eine Option -z <Differenz> zur Umrechnung von GMT in lokale Zeit.

    Ich hätte hier eine Frage zum XaioX iTrackU (Sirf III):


    ich möchte ganz einfach die NMEA-Daten per serielle Schnittstelle unter Linux ausgeben/auslesen. Unter Windows gehts nullproblemo, unter Linux nimmt er die NMEA-Daten einfach nicht an. Das Zeug mit Modul usbserial laden hab ich gemacht, nur a) weiss ich nicht, wie ich das testen soll und b) wenn ich dann cat /dev/ttyUSB0 mach, kommt überhaupt nix.


    Wenn jemand von euch eine Idee dazu hätte, wärs toll.


    btw, Ubuntu 8.10