Anregungen zu NMEA und CSV

[nordlicht]

Hallo Christian,

beim Einlesen von NMEA-Dateien aus einem Ohara-Logger ist mir aufgefallen, daß RC jeden einzelnen NMEA-Satz als eigenständigen Punkt betrachtet, wenn er eine lat/lon-Angaben enthält. Das ergibt eine unnötig aufgeblähte und uneinheitliche Positionsliste sowie ein kammartiges Höhenprofil, da die Höhe nur im Satz GGA enthalten ist.

Eine Musterdatei ist im Anhang, die Zeitstempel der zusammengehörenden RMC- und GGA-Sätze unterscheiden sich oft um 200 ms, vielleicht ist das der Grund für das "detaillierte" Verhalten von RC.

GPS Babel gruppiert dem Anschein nach die NMEA-Sätze und betrachtet jede Gruppe als einen Punkt. Ließe sich das auch in RC umsetzen? Zur Zeit konvertiere ich meine NMEA-Rohdaten erstmal mit GPS Babel nach GPX, bevor ich RC damit füttere.

Darüberhinaus würde ich mich freuen, wenn RC ein weiteres CSV-Format lesen könnte, das GPS Babel bietet und das ich sehr oft brauche: "Universal CSV with field structure in first line".


  Ohara_Muster.zip (Size: 2.46 KB / Downloads: 739)

[routeconverter]

beim Einlesen von NMEA-Dateien aus einem Ohara-Logger ist mir aufgefallen, daß RC jeden einzelnen NMEA-Satz als eigenständigen Punkt betrachtet, wenn er eine lat/lon-Angaben enthält.

Ich habe viel Hirnschmalz investiert, damit genau das nicht passiert: es werden NMEA-Sentences solange zusammengefaßt, bis sich Längen- und Breitengrad unterscheiden.

Das ergibt eine unnötig aufgeblähte und uneinheitliche Positionsliste sowie ein kammartiges Höhenprofil, da die Höhe nur im Satz GGA enthalten ist.

Aus genau den Gründen.

Eine Musterdatei ist im Anhang, die Zeitstempel der zusammengehörenden RMC- und GGA-Sätze unterscheiden sich oft um 200 ms, vielleicht ist das der Grund für das "detaillierte" Verhalten von RC.

Der Grund liegt daran, daß der Ohara-Logger mal GGA und mal RMC in die Datei schreibt. Schau Dir mal den Beginn an.

Das wird die 1. Position in RouteConverter:

Code:

$GPGGA,090248.200,4811.1947,N,00700.6809,E,1,8,1.25,537.7,M,47.9,M,,*5C
$GPRMC,090248.200,A,4811.1947,N,00700.6809,E,26.11,119.77,190512,,,A*5F

Andere Koordinaten, das wird die 2. Position:

Code:

$GPGGA,090250.800,4811.1823,N,00700.7050,E,1,8,1.25,539.1,M,47.9,M,,*51

Andere Koordinaten, das wird die 3. Position:

Code:

$GPRMC,090251.000,A,4811.1810,N,00700.7067,E,31.25,142.37,190512,,,A*5C

Andere Koordinaten, das wird die 4. Position:

Code:

$GPGGA,090253.600,4811.1617,N,00700.7293,E,1,7,1.59,537.6,M,47.9,M,,*55

Andere Koordinaten, das wird die 5. Position:

Code:

$GPRMC,090253.800,A,4811.1601,N,00700.7309,E,34.76,148.36,190512,,,A*5B

Warum der Ohara-Logger mal GGA-Sentences mit Höhenangabe und dann wieder RMC-Sentences ohne Höhenangabe schreibt bleibt das Geheimnis seiner Programmierer. Das ist doch Schrott, oder?

GPS Babel gruppiert dem Anschein nach die NMEA-Sätze und betrachtet jede Gruppe als einen Punkt. Ließe sich das auch in RC umsetzen? Zur Zeit konvertiere ich meine NMEA-Rohdaten erstmal mit GPS Babel nach GPX, bevor ich RC damit füttere.

Das ist bereits umgesetzt, wohlmöglich ist RouteConverter da konservativer, da es nur bei Änderungen an Längen- und Breitengrad zusammenfaßt. Was macht GPSBabel anders?

Darüberhinaus würde ich mich freuen, wenn RC ein weiteres CSV-Format lesen könnte, das GPS Babel bietet und das ich sehr oft brauche: "Universal CSV with field structure in first line".

Das habe ich seit 2 Jahren auf der ToDo-Liste und werde es jetzt angehen - auch wenn das bedeutet, daß ich vorerst keine anderen Formate implementiere.

[nordlicht]

Warum der Ohara-Logger mal GGA-Sentences mit Höhenangabe und dann wieder RMC-Sentences ohne Höhenangabe schreibt bleibt das Geheimnis seiner Programmierer. Das ist doch Schrott, oder?

Der Logger ist konfigurierbar und in diesem Fall so konfiguriert, daß er alle drei Sekunden die Sätze GGA und RMC schreibt, GSA und GSV sind abgeschaltet. Vermutlich greift die Firmware aber für jeden NMEA-Satz neu auf die Ausgabe des Chips zu. Ich habe die Version 3.1.4 dieses Loggers, da ist ein MTK3318 drauf, der intern mit 5Hz Updaterate arbeitet, von daher kommen vermutlich auch die 200ms unterschiedlichen Zeitstempel der eigentlich zusammengehörenden GGA- und RMC-Sätze. GPSBabel übersetzt diese NMEA-Logs aber interessanterweise sauber in GPX-Dateien.

Das ist bereits umgesetzt, wohlmöglich ist RouteConverter da konservativer, da es nur bei Änderungen an Längen- und Breitengrad zusammenfaßt. Was macht GPSBabel anders?

Vielleicht rundet es die Zeitstempel auf volle Sekunden und faßt dann alle Sätze mit gleichem Zeitstempel zusammen? (reine Spekulation... )

Das habe ich seit 2 Jahren auf der ToDo-Liste und werde es jetzt angehen - auch wenn das bedeutet, daß ich vorerst keine anderen Formate implementiere.

Wäre es ein einfacherer Weg, diese Funktionalität über ein externes GPSBabel aufzurufen? Auch wenn es da einen Fallstrick gäbe: den UTC-Parameter. Wenn man den nicht explizit angibt, interpretiert Babel die Zeitstempel in solchen CSV-Dateien als Lokale Zeit.

Schon mal vielen Dank im Voraus für die Mühe, RC wird immer besser!

[routeconverter]

[GPSBabel übersetzt diese NMEA-Logs aber interessanterweise sauber in GPX-Dateien.

Könntest Du mir ein NMEA-Log sowie die dazu erzeugte GPX-Datei zuschicken und die Schritte erklären, die ich mit gpsbabel anstellen muß, um dahinzukommen?

Vielleicht rundet es die Zeitstempel auf volle Sekunden und faßt dann alle Sätze mit gleichem Zeitstempel zusammen? (reine Spekulation... )

Genau das möchte ich herausfinden.

Wäre es ein einfacherer Weg, diese Funktionalität über ein externes GPSBabel aufzurufen?

Du meinst Universal csv with field structure in first line (unicsv)?

Auch wenn es da einen Fallstrick gäbe: den UTC-Parameter.
Wenn man den nicht explizit angibt, interpretiert Babel die Zeitstempel in solchen CSV-Dateien als Lokale Zeit.

Den Fallstrick der fehlenden Zeitzone oder fehlenden Datumsangabe gibt es bei vielen Dateiformaten. Ich habe da glaube bei RouteConverter einen ganz guten Kompromiß gefunden, immer UTC anzunehmen und das Dateidatum hinzuzuziehen, falls es keine Hinweise im Dateiformat gibt. Zumindest gibt es keinerlei Nachfragen

[nordlicht]

Könntest Du mir ein NMEA-Log sowie die dazu erzeugte GPX-Datei zuschicken und die Schritte erklären, die ich mit gpsbabel anstellen muß, um dahinzukommen?

Du hast Post.

Du meinst Universal csv with field structure in first line (unicsv)?

ja.

Ich habe da glaube bei RouteConverter einen ganz guten Kompromiß gefunden, immer UTC anzunehmen und das Dateidatum hinzuzuziehen, falls es keine Hinweise im Dateiformat gibt. Zumindest gibt es keinerlei Nachfragen

Solange UTC aus der Quelldatei auch UTC in der Zieldatei ergibt, ist mir das recht.

[routeconverter]

Könntest Du mir ein NMEA-Log sowie die dazu erzeugte GPX-Datei zuschicken und die Schritte erklären, die ich mit gpsbabel anstellen muß, um dahinzukommen?

Du hast Post.

Interessant: scheinbar verwirft gpsbabel die meisten RMC-Sentences auch wenn dort gprmc=1 steht: aus 9798 Sentences macht gpsbabel 4898 Positionen, während RouteConverter 7739 erhält. Es sieht so aus, als ob gpsbabel alle Sentences innerhalb einer Sekunde zu einer Position zusammenfaßt während RouteConverter konservativer alle Sentences mit denselben Koordinaten zusammenfaßt.

Da es viele Nutzer gibt, die auf akkurate Daten sehr viel Wert legen, bin ich mir unsicher, ob ich da gpsbabel folgen sollte. Könntest Du mit einer versteckten Option leben, die alle Sentences innerhalb einer Sekunde zusammenfaßt?

[nordlicht]

Interessant: scheinbar verwirft gpsbabel die meisten RMC-Sentences auch wenn dort gprmc=1 steht:

GPSBabel liest m.M.n. alle Sätze. RMC muß ausgewertet werden, weil nur dieser Satz das Datum enthält, GGA muß wegen der nur dort enthaltenen Höhe ausgewertet werden. 9798 Sätze gesamt = 4899 RMC + 4899 GGA bei Vollständigkeit, offensichtlich ist ein ungültiger Satz in dem Track.

Könntest Du mit einer versteckten Option leben, die alle Sentences innerhalb einer Sekunde zusammenfaßt?

Ja, und ich kann sogar ohne diese Option leben . Der Logger steht nur auf NMEA-Aufzeichnung, weil er auch Daten für jemanden sammelt, der nicht computeraffin ist und sich mit den zahlreichen Optionen von Babel etwas schwer tut. Er läßt sich umkonfigurieren auf CSV-Ausgabe, die ersten Zeilen sehen dann so aus:

Code:

LATITUDE,LONGITUDE,ALTITUDE,HEADING,SPEED,SAT,PDOP,HDOP,VDOP,FIX,YEAR,MONTH,DAY,HOUR,MIN,SEC,MSEC
50.33119202,12.14863968,621.29,100.66,43.02,10,1.330,0.790,1.080,1,2012,5,28,10,33,33,600,
50.33118438,12.14962006,619.70,83.43,43.83,10,1.330,0.790,1.080,1,2012,5,28,10,33,36,600,
50.33127976,12.15058422,619.29,81.30,45.34,9,1.390,0.850,1.100,1,2012,5,28,10,33,39,600,
....

Insofern wäre das NMEA-Problem keins mehr ab dem Zeitpunkt, wo RC "unicsv" lesen kann.