Es ist jetz das zweite mal das ich mich mit dem parsing, von seriel (vom Receiver)"empfangenen", gps NMEA bzw. RAWX Strings auseinandersetzte. Beim ersten mal hab ich nur NMEA Strings geparsed und dabei für lat und lon immer längere doubles erhalten aber immer ohne Kommastellen, das war aber nicht wirklich ein Problem weil ich ja ungefähr wusste an welcher Stelle bei uns in De. das Komma stehen sollte. Jetzt arbeite ich aber mit dem Raw output von nem Receiver(neo m8t) der mehr oder weniger reine GPS alanac/ ephemeris/ observation (ubx-rawx, ubx-rawsfrbx)Daten ausspuckt. Aber die auch ohne Kommastelle, nur leider kann ich die bei solchen Werten nicht erraten :/. Zum auslesen der rohen Seriellen Daten benutzte ich die wiringpi(wiringPiSerial) lib., den gelesenen byte passe ich dann in RTK lib (ne C lib zum dekodieren von solchen Daten), aber die spuckt dann auch wieder nur Zahlen ohne komma aus... Hat jemand ne Idee? Scheint ja nicht wirklich vom code abhängig zu sein sondern irgendwie nen Denkfehler von meiner Seite. Grüße luick
Yellow D. schrieb: > Hat jemand ne Idee? Niemand braucht float für Zahlen mit Komma, man liest Integer z.B. bei Geldbeträgen nicht EUR sondern cent, bei lat/lang nicht Grad sondern Bogensekunden. Das Komma beachtet man bloss wenn unterschiedlich viele Nachkommaziffern folgen könnten - um mit 0 aufzufüllen oder bei nicht mehr interessanten Ziffern aufhören zu können.
MaWin schrieb: > Yellow D. schrieb: >> Hat jemand ne Idee? > > Niemand braucht float für Zahlen mit Komma, man liest Integer z.B. bei > Geldbeträgen nicht EUR sondern cent, bei lat/lang nicht Grad sondern > Bogensekunden. > Das Komma beachtet man bloss wenn unterschiedlich viele Nachkommaziffern > folgen könnten - um mit 0 aufzufüllen oder bei nicht mehr interessanten > Ziffern aufhören zu können. Aha danke, das erklärt schonmal ne Menge, aber was ist z.B. mit Metern wenn, ich eine Pseudo Range(Abstand Erdoberfläche zu Sat) von 26023200 habe, dann könnten das wirklich 26023200 m sein(was unrealistisch ist)oder, was wahrscheinlicher ist 26023.20, was wahrscheinlicher ist....
Soso ... beim ubx-rawx kommen also Daten raus, bei denen man die Kommastelle erraten muss. Geht ja echt niemanden etwas an. Die sollen das IC kaufen, ansonsten die Klappe halten. Ich denk, da solltest du nochmal bei der Doku anfangen, bevor du dir irgendwelche Konvertierungen zusammenbastelst.
Nick M. schrieb: > Soso ... beim ubx-rawx kommen also Daten raus, bei denen man die > Kommastelle erraten muss. Geht ja echt niemanden etwas an. Die sollen > das IC kaufen, ansonsten die Klappe halten. > Ich denk, da solltest du nochmal bei der Doku anfangen, bevor du dir > irgendwelche Konvertierungen zusammenbastelst. mirt ist schon klar das dass nen Denkfehler von meiner Seite ist, aber ich hab die 400 Seiten Interface Doku jezt schon durch aber künnte nix wirklich hilfreiches finden lol.
Yellow D. schrieb: > Beim ersten mal hab ich nur NMEA Strings geparsed und dabei für lat und > lon immer längere doubles erhalten aber immer ohne Kommastellen, das war > aber nicht wirklich ein Problem weil ich ja ungefähr wusste an welcher > Stelle bei uns in De. das Komma stehen sollte. Das ist doch alles bestens dokumentiert, da muss man nix erraten…
Yellow D. schrieb: > aber ich hab die 400 Seiten Interface Doku jezt schon durch OK, das kann ublox: Zu viel Doku die nur noch verwirrt. Lass dich nicht verleiten von der 100sten zur 1000sten Detailbeschreibung zu springen. Lies nur den Teil mit ubx-rawBlaBla. Das muss doch zu verstehen sein (hab das nie verwendet). EInfacher ist halt NMEA, da gibt es tausende Beispiele. Ich hab zwei verschiedene ublox GPS-Module verwendet und beide Male hat es prima geklappt. SO ein NMEA-String ist ja nicht unendlich schwer zu parsen.
Hallo, Also ich verwende ausschließlich ubx. Für mich hat und den Vorteil einfacher zu dekodieren als nmea. Ich definiere eine struct mit der entsprechenden Struktur und Weise den Puffer zu. Fertig. Durch die gleiche endianess brauchst du auch nix drehen. Wenn du willst, kann ich auch etwas Code liefern ..... Grüße, Adib.
Kann gpsd mit deinem Receiver umgehen? Damit wären viele Probleme bereits gelöst, wenn du keine Spezialitäten brauchst.
adib schrieb: > Hallo, > Also ich verwende ausschließlich ubx. > Für mich hat und den Vorteil einfacher zu dekodieren als nmea. > Ich definiere eine struct mit der entsprechenden Struktur und Weise den > Puffer zu. Fertig. > Durch die gleiche endianess brauchst du auch nix drehen. > Wenn du willst, kann ich auch etwas Code liefern ..... > > Grüße, Adib. ja, das wäre großartig, nur als Inspiration. Übernehme nix direkt, mich interessiert nur schwehr wie ich aus meiner Pseuod Range was Sinnvolles machen kann. Denn rtklib gibt mir für die Pseudo Range nur einen double zurück aber ohne Information wo ich das "Komma" setzten muss, weil der double hat ja noch ne genauigkeit und der Abstand zum Satelliten wird ja nicht ne Zahl mit 16 Stellen sein, das wäre eher der Abstand zum Mond.... Grüße
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.