Hallo zusammen, Ich suche nun schon ein paar Tage das Netz durch und habe diverses hier im Forum gelesen... Aber ich scheine irgenwie Tomaten auf den Augen zu haben: Ich suche einen kleinen NMEA Parser, dem ich eigentlich nurnoch die Bytes vom GPS Empfänger hin werfen muss und mir dann ein Struct mit daten wie Position, Geschwindikeit, Kurs etc füllt und zur Verfügung stellt. Aber obwohl hier sehr viele Leute mit GPS am Avr arbeiten, hat keiner eine einfache Lib parat, die diese Aufgabe erfüllt. Super wäre ein relativ schlankes System, als OpenSource. Hat jemand vielleicht einen guten Tipp für mich? Mein Sensor spricht reines NMEA 183, kein Sirf oder ähnliches. Vielen Dank und viele Grüße, Timo
Timo Birnschein schrieb: > Ich suche nun schon ein paar Tage das Netz durch In der Zeit hättest du das mindestens 5 mal selbst geschrieben. Und dabei sogar noch was gelernt (höchst wahrscheinlich). Das ist Textver- und bearbeitung auf einfachstem Niveau.
Timo Birnschein schrieb: > etc Was verstehst du darunter? Für viele Aufgaben reicht es den $GPRMC Sentence auszuwerten oder brauchst du auch Routenplanung und Wegpunkt-ansteuerdaten?
>Ich suche nun schon ein paar Tage das Netz durch...
Die Anzahl Google Anfragen um nichts zu NMEA zu finden belaeuft sich auf
exakt Null. Zeit einem El-Schlaffo einen Tritt zu geben.
Gib mir mal ein bsp. NMEA String und sag wie deine "Ziel" Struct aussehen soll. Dann zeig ich dir, wie das geht
Hi >Gib mir mal ein bsp. NMEA String und sag wie deine "Ziel" Struct >aussehen soll. Dann zeig ich dir, wie das geht http://www.olajedatos.com/documentos/MN000315E_NMEA_ref_manual.pdf Z.B. GGA oder RMC. MfG Spess
http://www.procyonengineering.com/embedded/avr/avrlib/ der Link ist besser, musst aber auf die Lizenz achten soweit ich weis.
>Hi >>Gib mir mal ein bsp. NMEA String und sag wie deine "Ziel" Struct >>aussehen soll. Dann zeig ich dir, wie das geht >http://www.olajedatos.com/documentos/MN000315E_NME... >Z.B. GGA Da widerspricht sich was: GGA Latitude: (Seite5) Das Beispiel ist : .. ,3723.2475, .. und in der Tabelle steht: dddmm.mmmm Das Bsp hat nur vier Stellen vor dem Punkt..
Hi >Da widerspricht sich was: >GGA Latitude: (Seite5) >Das Beispiel ist : .. ,3723.2475, .. >und in der Tabelle steht: dddmm.mmmm >Das Bsp hat nur vier Stellen vor dem Punkt.. Es gibt keine führenden Nullen. MfG Spess
>Es gibt keine führenden Nullen.
Warum nicht? Woran soll man erkennen, was das Bedeutet?
In dem selben Beispiel, bei sattelites used, gibt es die doch auch.
Oder Beispiel:
Uhrzeit: 12345.123
WIe spät ist es?
1:23:45
12:03:45
12:34:05
???
EDIT:
Weiter, Latitude: 102.9876
ergibt?
10° 2.9876'
1° 02.9876'
???
Hm, meine Frage war scheinbar blöd formuliert. Ich kann durchaus programmieren, allerdings ist die Anzahl an Komponenten die mein Projekt umfasst (quatrokopter und andere Fluggeräte) zu groß um sich um jede Standard Kompontente im Detail zu kümmern. Ich habe die letzten Tage Informatione über alles gesammelt. Insbesondere viel über Antennendesign und GPS grundsätzlich gelesen und nebenbei versucht einen Parser zu finden, der die Aufgabe erledigen kann. Die Stanfort Lib beispielsweise läuft bei mir nicht! es werden schlicht die Zahlen aus dem Beispiel-Teststring nicht erkannt, und das obwohl ich sie testweise am PC implementiet habe. Viele GPS Logger hier im Forum und im Wiki arbeiten nicht mit einem Parser, sonder speichern lediglich den kompletten Stream auf eine SD Karte. Damit ist das auch nicht was ich will... Danke an Chris für die beiden Links! Speziel den unteren kannte ich noch nicht. Ich werde da mal rein schauen und wenn das auch nicht geht, schreib ich das Ding halt selbst. Schade, dass man das Rad manchmal doch neu erfinden darf. Danke nochmal und Gruß Timo
>Ganz einfach: vom Punkt nach vorn parsen.
Daswiderspricht sich mit field type aus der Tabelle.
lös doch mal bitte meine Beispiele auf..
Hi
>lös doch mal bitte meine Beispiele auf..
Uhrzeit: 12345.123
WIe spät ist es?
1:23:45
Weiter, Latitude: 102.9876
ergibt?
1° 02.9876'
MfG Spess
>1° 02.9876'
Ich denke es gibt keine führenden Nullen?
Wie wird die Uhrzeit Mitternacht dargestellt?
0 ?
000 ?
000000 ?
Oder eine Minute und eine Sekunde nach Mitternacht?
11 ?
011 ?
Hi >1° 02.9876' >Ich denke es gibt keine führenden Nullen? Es steht doch auch keine Null am Anfang des Strings. Du musst z.B. 'dddmm.mmmm' wie eine Maske über den String legen so das der Punkt übereinstimmt. Ein String mit dem Field Type dddmm.mmmm fängt nicht mit einer Null an, außer dddmm ist Null. Der Punkt ist immer vorhanden. mmmm hört nicht mit einer Null auf, außer mmmm ist Null. >Wie wird die Uhrzeit Mitternacht dargestellt? 0.0. MfG Spess
Also wenn das mm von 'mm.mmmm' Null ist, dann sieht das so aus:
falls d>0 : (d)d00.xxxx d: Grad
sonst 0.xxxx
???
>0.0.
Keine Std und keine Min, weil Null?
Warum dann führende Nullen bei sattelites used und bei station id ?
Oder anders formuliert: hhmmss ist eigentlich eine Zahl, gebildet durch 10000h + 100m + s und das ohne führende Nullen. Genauso das dddmm: 100d + m wobei hier noch zusätzlich gilt: m<60 ???
Ist es nicht schon offensichtlich geworden - und das ohne mein Zutun - warum das nicht einfachste Textverarbeitung ist... ;)
Hi Vergiss meine Aussagen. War Müll. In dem von mir verlinktem Dokument ist ein Fehler. Die Latitude hat nicht das Format dddmm.mmmm sondern ddmm.mmmm (0..90°). Und diese Strings haben eine konstante Länge. MfG Spess
Timo Birnschein schrieb: > Ist es nicht schon offensichtlich geworden - und das ohne mein Zutun - > warum das nicht einfachste Textverarbeitung ist... ;) Ja. Ich greif mir die ganze Zeit an den Kopf. Warum dieser sinnlose Aufwand, die Nullen zu unterdrücken. Diese fehlenden Stellen erzeugen dann wieder jede Menge Aufwand beim zurückrechnen.. Man kann nur den Kopf schütteln
>Vergiss meine Aussagen. War Müll. In dem von mir verlinktem Dokument ist >ein Fehler. Die Latitude hat nicht das Format dddmm.mmmm sondern >ddmm.mmmm (0..90°). Und diese Strings haben eine konstante Länge. Puh. Gott sei Dank. Also ist Mitternacht 000000.0000 und die geogr. Position 0/0 wird als 0000.0000 LAT und 00000.0000 LON dargestellt? (bitte ein ja ;-)
Timo Birnschein schrieb: > warum das nicht einfachste Textverarbeitung ist... Doch, das ist es. Nur das Spess und Mathias sich jetzt die Arbeit machen das Protokoll zu analysieren, obwohl du das besser machen solltest. Schau doch mal hier rein, da steht eigentlich alles drin: http://git.savannah.gnu.org/cgit/gpsd.git/tree/driver_nmea0183.c
Das hab ich gerade noch gesehen: http://www.maartenlamers.com/nmea/ was? schrieb: > Mathias Sorry, Matthias.
Hi
>(bitte ein ja ;-)
Ja. Enschuldige nochmals die Konfusion. Mein Eigenbau-GPS ist schon 7
Jahre her.
MfG Spess
>Sorry, Matthias. Warum? >Das hab ich gerade noch gesehen: >http://www.maartenlamers.com/nmea/ Da steht: >>$GPGGA,082804.683,5205.9421,N,00506.4368,E,1,03,3.0,0.3,M,,,,0000*01 >>$GPRMC,082804.683,A,5205.9421,N,00506.4368,E,0.02,146.61,190408,,*0C >>$GPBDG,082804.683,A,52.09904,5.10728,0.02,146.61,1,190408,*73 Das sieht eindeutig nach führenden Nullen, also konstanter Länge aus. Oder das Feld ist leer. Somit sollte der Ansatz im ANhang funktionieren. Und sogar schneller sein als die vielen String/real Funktionen hier: >http://git.savannah.gnu.org/cgit/gpsd.git/tree/dri...
Matthias Lipinsky schrieb: > Warum? Zumindest Namen sollte man doch noch richtig abschreiben können. ;) Matthias Lipinsky schrieb: > Und sogar schneller > sein als die vielen String/real Funktionen hier: >>http://git.savannah.gnu.org/cgit/gpsd.git/tree/dri... Was hat sich der gute, alte Eric S. Raymond dabei nur gedacht. :P
Moin! Das hier ist ein Test-Datensatz aus der lib hier: http://nmea.sourceforge.net
1 | const char *buff[] = { |
2 | "$GPRMC,173843,A,3349.896,N,11808.521,W,000.0,360.0,230108,013.4,E*69\r\n", |
3 | "$GPGGA,111609.14,5001.27,N,3613.06,E,3,08,0.0,10.2,M,0.0,M,0.0,0000*70\r\n", |
4 | "$GPGSV,2,1,08,01,05,005,80,02,05,050,80,03,05,095,80,04,05,140,80*7f\r\n", |
5 | "$GPGSV,2,2,08,05,05,185,80,06,05,230,80,07,05,275,80,08,05,320,80*71\r\n", |
6 | "$GPGSA,A,3,01,02,03,04,05,06,07,08,00,00,00,00,0.0,0.0,0.0*3a\r\n", |
7 | "$GPRMC,111609.14,A,5001.27,N,3613.06,E,11.2,0.0,261206,0.0,E*50\r\n", |
8 | "$GPVTG,217.5,T,208.8,M,000.00,N,000.01,K*4C\r\n" |
9 | };
|
Da sind durchaus auch führende Nullen zu finden. Allerdings schmiss der Parser bei mir komische Zahlen raus, die ich aber auch falsch interpretiert haben könnte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.