NMEA-Logger

[roli8888]

Hallo,
ich würde gerne die Daten von NMEA-Logger von Openseamap importieren. ( http://www.openseamap.org/ )
Ich konnte die Daten importieren wenn ich die ersten beiden Spalten lösche.
Beispieldaten bekommt man unter:

http://wkla.dyndns.org/downloader/download.php?ID=65
http://wkla.dyndns.org/mcslog/

Wäre super wenn ich die Daten direkt laden könnte....
Vielen Dank
für das nette Tool ;-)

[routeconverter]

ich würde gerne die Daten von NMEA-Logger von Openseamap importieren. (http://www.openseamap.org/)
Ich konnte die Daten importieren wenn ich die ersten beiden Spalten lösche.

Das ist in der Tat ein seltsames Format. Wofür stehen Zeilen wie

00:00:24.892;I;$POSMGYR,-588, -40, 17824*68
00:00:24.892;I;$POSMACC,-600, -320, 16*6C
00:00:24.890;I;$POSMVCC, 4962*52

?

[roli8888]

ich würde gerne die Daten von NMEA-Logger von Openseamap importieren. (http://www.openseamap.org/)
Ich konnte die Daten importieren wenn ich die ersten beiden Spalten lösche.

Das ist in der Tat ein seltsames Format. Wofür stehen Zeilen wie

00:00:24.892;I;$POSMGYR,-588, -40, 17824*68
00:00:24.892;I;$POSMACC,-600, -320, 16*6C
00:00:24.890;I;$POSMVCC, 4962*52

?

Es scheinen Erweiterungen zu sein um den Lage/Beschleunigung MPU 6050 Sensor loggen zu können.
http://sourceforge.net/mailarchive/forum...ap-develop

[willie68]

Hallo,
darf ich mich kurz vorstellen.
Ich bin der Entwickler von dem Dingen und roli8888 hat mich direkt angesprochen und auf diesen Thread aufmerksam gemacht.
Über kurz oder lang (eher kurz als lang ) möchte ich in meinem Loggerverwaltungsprogramm ebenfalls eine Routenanzeige integrieren. Deswegen finde ich das Tool hier extrem spannend.
Zu Mir:
ich bin Dipl.-Ing., 45, beschäftige mich seit Uhrzeiten mit Softwareentwicklung und bin z.Z. bei der EASY Software AG als Systemarchitekt angestellt. Nebenher habe ich noch ein paar Hobbies, Musik (aktiv, Bass), Modellbau und eben Microconmtrollerprogrammierung. Dort habe ich mich spezialisiert auf die Atmel Controller und bin dort dann beim Arduino gelandet. Vor allem, weil der Werkzeugkasten gerade für Einsteiger interessant ist.
Nebenher versuche ich die Verbindung von Modellbau und Microcontroller anderen zu vermitteln. Und dabei ist auch ein KnowHow-Paket heraus gekommen. Soweit zu mir.

zum Thema:
Der Logger hat aus bestimmten Gründen ein eigenes Format. Allerdings ist das sehr einfach gehalten. Zur Hardware: Der Logger arbeitet mit einem ATMega328, die Software ist mit der Arduino-IDE geschrieben, naja fast jedenfalls, damit die Einarbeitung für weitere Mitstreiter sich recht einfach gestaltet. (Allerdings mußte ich schon mehrfach in die Trickkiste greifen...) Der Logger hat externe 2 Kanäle und einen internen Kanal. Extern können 2 NMEA Geräte angeschlossen werden. Kanal A läßt sich auch auf das Seatalk Protokoll umschalten. Intern werden Daten einer MPU6050, also eines Lage- und Beschleunigungssensors, geloggt. Das ganze wird auf einer SD Karte geschrieben. Erlaubt sind hier beliebige FAT16 und FAT32 Karten. (Bis 32GB) GEloggt wird alles. Eine Filterung, Analyse oder sowas findet nicht statt.
Eine Zeile im Log ist ein Datensatz (Datagram) und besteht aus 3 Teilen. Die TEile werden durch ein ";" getrennt.
1: Zeitstempel, im Format HH:mm:ss.SSS und gibt den Zeitpunkt des Eintreffens des 1. Bytes des Datagramms an. Grundlage ist die Zeit seit dem Start des Loggers. (Eine Zeitsyncronisation mit GPS findet nicht statt)
2: Kanalbezeichnung: Die Kanalbezeichnugn gibt an, auf welchem Kanal die Daten empfangen wurden. Das dient der Datenanalyse und nachträglichen Aufbereitung.
3: Die NMEA Daten.

Zus. definiert der Logger noch ein paar eigene NMEA Datagramme:
Start/Stop Meldungen.
$POSMST,Start NMEA Logger,V 0.1.2*30
$POSMSO,Stop NMEA Logger*3A

Lagedaten (Alle 3 Achsen)
$POSMGYR,1800,7772,13164*5C
Beschleunigungsdaten
$POSMACC,-684,-2145,-7012*7D
Betriebsspannung (Optional)
$POSMVCC,4962*72

Daten von Seatalk
$POSMSK,4AEF4245265E62*72
Da Seatalk ein binäres Format ist, werden die einzelnen Bytes als HEX ausgegeben. NMEA Kennzeichnung ist $POSMSK. Danach folgt eine Kolonne aus HEX Zahlen. Jeweils 2 Ziffern bilden ein Byte.

Alles Nachzulesen auch hier

Die Gyro und Acc Daten werden bei der Tiefenmessung benötigt, wofür das gesamte Projekt eigentlich vorgesehen ist.

Achja, an dem Projekt verdiene ich übrigen fast nix. Firm- und Software ist OpenSource, Hardware wird zum Selbstkostenpreis in China produziert.
Da das mein erstes Posting hier ist, bitte ich um Verständnis falls ich vielleicht aus Unwissenheit Regeln verletzt haben sollte. Ich wollte nur schnell Licht ins Dunkel bringen.
Bis bald.

[routeconverter]

darf ich mich kurz vorstellen.

Wow, das war wahrscheinlich die ausführlichste Vorstellungsmail, die ich bislang gelesen habe

Über kurz oder lang (eher kurz als lang ) möchte ich in meinem Loggerverwaltungsprogramm ebenfalls eine Routenanzeige integrieren. Deswegen finde ich das Tool hier extrem spannend.

Und man will ja das Rad nicht neu erfinden... in RouteConverter steckt inzwischen auch eine Menge Arbeit, viele interessante Features und es ist Open Source.

Der Logger hat aus bestimmten Gründen ein eigenes Format. Allerdings ist das sehr einfach gehalten.

Jetzt wird es spannend.

Eine Zeile im Log ist ein Datensatz (Datagram) und besteht aus 3 Teilen. Die TEile werden durch ein ";" getrennt.
1: Zeitstempel, im Format HH:mm:ss.SSS und gibt den Zeitpunkt des Eintreffens des 1. Bytes des Datagramms an. Grundlage ist die Zeit seit dem Start des Loggers. (Eine Zeitsyncronisation mit GPS findet nicht statt)
2: Kanalbezeichnung: Die Kanalbezeichnugn gibt an, auf welchem Kanal die Daten empfangen wurden. Das dient der Datenanalyse und nachträglichen Aufbereitung.
3: Die NMEA Daten.

Und hier frage ich mich, warum Du so grundlegend von den sonst üblichen NMEA-Logdateien abweichst? Damit verschließt Du Deinem Logger alle Programme, die NMEA lesen können. Das mag gut sein für Konverter-Programme, aber vielleicht läßt sich das vermeiden? Zeitstempel könnte man in RMC, GGA, ZDA oder eigene Sentences stecken. Die Kanäle auch in eigene Sentences, die genau vor den NMEA-Sentences stecken. Das bedeutet sicher etwas mehr Logik für Programme, die die Logs lesen wollen, bringt jedoch deutlich mehr Software, die sofort funktioniert.

RouteConverter hat da z.B. extra Logik an Bord, um aus mehreren NMEA Sentences, die dieselbe Position betreffen oder denselben Zeitstempel haben, eine Position zu machen, damit man sie besser auf der Karte sehen und in andere Formate exportieren kann: Suche nach mergePositions in https://github.com/cpesch/RouteConverter...ormat.java

Zus. definiert der Logger noch ein paar eigene NMEA Datagramme:

Das ist m.E. problemlos, da die meiste Software überliest, was sie nicht kennt.

Achja, an dem Projekt verdiene ich übrigen fast nix. Firm- und Software ist OpenSource, Hardware wird zum Selbstkostenpreis in China produziert.

Da habe ich immer Sympathie für übrig.

Da das mein erstes Posting hier ist, bitte ich um Verständnis falls ich vielleicht aus Unwissenheit Regeln verletzt haben sollte.

Ganz im Gegenteil: willkommen!

[willie68]

Irgendwie ist meine Antwort von heute mrogen verschwunden...

...
Und man will ja das Rad nicht neu erfinden... in RouteConverter steckt inzwischen auch eine Menge Arbeit, viele interessante Features und es ist Open Source.

Richtig, wenn ich dann Fragen hab, meld ich mich...

...
Und hier frage ich mich, warum Du so grundlegend von den sonst üblichen NMEA-Logdateien abweichst? Damit verschließt Du Deinem Logger alle Programme, die NMEA lesen können. Das mag gut sein für Konverter-Programme, aber vielleicht läßt sich das vermeiden? Zeitstempel könnte man in RMC, GGA, ZDA oder eigene Sentences stecken. Die Kanäle auch in eigene Sentences, die genau vor den NMEA-Sentences stecken. Das bedeutet sicher etwas mehr Logik für Programme, die die Logs lesen wollen, bringt jedoch deutlich mehr Software, die sofort funktioniert.

Das sind Anforderungen aus dem OpenSeaMap Projekt. Die brauchen zur Berechnung von Tide und Tiefe einen genauen Zeitstempel. Und das vermehrt die Datenmenge nicht unerheblich. Du mußt bedenken, der Logger soll/muss auch mal 14 Tage am Stück arbeiten können. Weiterhin mußte ich den NMEA Puffer auf 80 Zeichen begrenzen. Eigentlich sollten die NMEA Daten auch nicht länger sein, aber es gibt ansdhceinend ausnahmen. Der Logger teilt dann aber das Datagram in mehrere Teile. Um die dann wieder zusammenfügen zu können brauch ich den Zeitstempel und den Kanal...

...
Ganz im Gegenteil: willkommen!

Danke.
Es gibt übrigens auch noch die Möglichkeit, vor dem Upload die Daten per Batch zu bearbeiten. Da könnte ich einen Konverter reinhängen, der den Zeitstempel und die Kanalkennzeichnung entfernt. Das Zeilen zusammenfassen ist schon drin.

---

So,

die Konvertierung ging schneller als ich dachte. Hab's uahc gleich mit dem RouteConverter getestet und es hat funktioniert...
Jetzt muss ich mir nur noch was einfallen lassen, wie ich den vernünftig anspreche...

[nordlicht]

Die brauchen zur Berechnung von Tide und Tiefe einen genauen Zeitstempel.

Der Zeitstempel ist auf hunderstel Sekunden genau vollständig im RMC-Datensatz enthalten. Warum sind die nicht in der Lage, bereits vorhandene Informationen auszuwerten?

[routeconverter]

Es gibt übrigens auch noch die Möglichkeit, vor dem Upload die Daten per Batch zu bearbeiten. Da könnte ich einen Konverter reinhängen, der den Zeitstempel und die Kanalkennzeichnung entfernt. Das Zeilen zusammenfassen ist schon drin.

---

die Konvertierung ging schneller als ich dachte. Hab's uahc gleich mit dem RouteConverter getestet und es hat funktioniert...

Mit Konvertieren meinst Du das entfernen von Zeitstempel und Kanal?

Jetzt muss ich mir nur noch was einfallen lassen, wie ich den vernünftig anspreche...

Das verstehe ich nicht.

[willie68]

Richtig. Und natürlich auch das Zusammenfassen.

Mein erster Schnellschuss sah vor, daß ich per JavaFX ein HTML Fenster öffne. Allerdings bin ich dann bei der Erstellung einer hybriden JavaFX-Anwendung gestrauchelt. War mir für den Augenblick zu komplex.
Deswegen konvertiere ich nun einfach das ganze in HTML und rufe dann den Systembrowser auf. Geht auch.
Die JavaFX Lösung mach ich dann später...

[willie68]

Die brauchen zur Berechnung von Tide und Tiefe einen genauen Zeitstempel.

Der Zeitstempel ist auf hunderstel Sekunden genau vollständig im RMC-Datensatz enthalten. Warum sind die nicht in der Lage, bereits vorhandene Informationen auszuwerten?

Ja, aber das gilt für den RMC Datensatz selber. Wenn die Echolotdaten kommen haben die keinen Zeitstempel. Und auf die Reihenfolge in der Datei kann man sich eben nicht verlassen. Die ist nicht eindeutig.
d.h. Natürlich kann ich das ganze als RMC Datensatz jeweils vor dem eigentlichen NMEA Datensatz schreiben, das würde aber Datenmenge signifikant erhöhen. Und auch das ist nicht gewünscht.
Es war ein Kompromiss zwischen vielen Faktoren.
- Datenmenge
- Prozessorleistung und damit Verkaufspreis
- Prüfmöglichkeit und Genauigkeit
Rausgekommen ist eben dieses propritäre Format. Weil es für die Anwendung am besten geeignet war. Da die Firmware aber updatebar ist und alles als OpenSource angeboten wird, bis auf die Hardware, kann da jeder, der sich ein bisschen mit Microcontrollerprogrammierung auskennt, sich seine Firmware auch selber stricken...
Aber wie ich auch schon gesagt habe, eine Konvertierung ist bereits im Frontend implementiert...