NMEA: Anzahl der Bogenminuten-Nachkommastellen

Fragen zu GPS-Empfängern und alles was damit zu tun hat.

Moderator: Roland

Antares
Beiträge: 8
Registriert: 21.10.2008 - 12:37

NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Antares » 21.10.2008 - 13:05

Hallo Leute,

ich beschäftige mich gerade mit dem Aufbau eines GPS-Ortungssystems.
Dabei wird ein GPS-Empfänger mit einem µ-Controller verbunden werden, der die aktuellen Positionsdaten des Empfängers ausliest.

Das System soll so-genau-wie-möglich funktionieren. (Es wird eine Art DGPS im Kleinformat aufgebaut, mit einem stationären und einem mobilen Empfänger, die sich über 433MHz-Funk "austauschen".)

Bei der Auswahl des passenden Empfängers taucht immer wieder folgendes Problem auf:

Obwohl es NMEA-"Standard" heißt, gibt es überall verschiedene Angaben zu der Anzahl der Nachkommastellen der Longtitude bzw. Latitude - Werten.

Beispiele:

1)auf dieser Seite (kowoma) ist folgendes angegeben:
GPRMC,191410,A,4735.5634,N,00739.3538,E,0.0,0.0,181102,0.4,E,A*19
mit 47°35,5634' haben wir also 4 Minuten-Nachkommastellen.

2)Auf wikipedia (engl.) steht unter NMEA:
Latitude in degrees/minutes llll.lllll
Longitude in degrees/minutes yyyy.yyyyy

3) Laut folgender Seite: http://www.nmea.de/nmea0183datensaetze.html#rmc
gibt es nur 2 Nachkommastellen.

Ich habe bereits alle Möglichkeiten von 2 bis 5 Nachkommastellen gefunden.

Kann mir Jemand erklären, wie diese Unterschiede zustandekommen, vor allem, wenn man eigentlich davon ausgehen kann dass "Standards" einheitlich sein sollen.

Im schlimmsten Fall brauche ich 4 Nachkommastellen, optimal wären 5.
Falls Jemand einen 5-Nachkommastellen-Empfänger kennt, wäre es nett, den hier anzugeben.

Danke.

XPosition
Beiträge: 214
Registriert: 25.08.2008 - 00:09

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von XPosition » 21.10.2008 - 15:03

Nun, es gibt halt auch schlechte Standards.
Über NMEA haben sich schon viele aufgeregt.
Es ist einfach zu schwammig definiert an manchen Stellen.
Die Nachkommastellen sind wirklich vom Empfänger abhängig.

Aber da du eh dein Gerät selbst baust, kannst du dir ja auch die Daten
im speziellen binären Format des Chip-Herstellers geben lassen.

Und was nützt dir eine Angabe von 5 Nachkommastellen, wenn Sie nicht stimmt ?
Der Empfänger mit 4 könnte z.B. immer noch genauer sein.
Es ist kein Qualitätsmerkmal der empfangenen Genauigkeit.

Benutzeravatar
Jörn Weber
Beiträge: 789
Registriert: 03.02.2007 - 16:11
Wohnort: Jena

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Jörn Weber » 21.10.2008 - 19:59

Hallo,
Antares hat geschrieben: Kann mir Jemand erklären, wie diese Unterschiede zustandekommen, vor allem, wenn man eigentlich davon ausgehen kann dass "Standards" einheitlich sein sollen.
Ich verstehe dein Problem nicht. Die Darstellung des NMEA183 ist ein comma separated format (csv). Dieser ist irgendwo in einem RFC der Internet Community festgeschrieben. Das Trannzeichen ist das Komma, daher kann dir die Anzahl der Stellen beim parsen völlig egal sein. Parsen tut man immer auf erst auf die Kommas, dann ersetzte man in den einzelnen Feldern die Punkte durch Kommas und wandelt dann den String in einen Real-Wert um. Hintergrund ist, das NMEA im Zweifel auch auf einem /-Bit-Kanal mit reinem ASCII laufen muss.

Gruss Joern Weber

Benutzeravatar
Taurus
Beiträge: 259
Registriert: 02.09.2007 - 14:36
Wohnort: Germany

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Taurus » 21.10.2008 - 20:53

Hi,

als erstes steige ich mit einem Zitat ein: "Das einzig wirklich standardisierte ist der Tod." *lach* :lol:

Und jetzt zur Geodäsie... wenn ein Empfänger mir auf 4 Nachkommastellen die Position angibt heißt das garnichts. Ganz im Gegenteil... das heißt nur das die Entwickler des Empfängers mal hätten ein bisschen Ausgleichungsrechnung oder Vermessungskunde lernen sollen, anstatt in ihren Nullen und Einsen zu kramen...
Als Beweis eine kleine Berechnung:

Meine Position wird mir auf 0.0001 Sekunden "genau" ( :twisted: ) angegeben...
0.0001 [Sec] = 0.0001 / 60 = 0.0000016 [Deg=Dezimalgrad=°]

Wenn ich das ganze jetzt mal mit dem Erdradius in ein metrisches Maß umrechne:
0.0000016 x PI / 180° x Erdradius = 0.000000029 [rad] x 6371 [km] = 0.0001853 [km] = 18.53 [cm]

Und 18.53 cm sind nicht drin ;-) Da macht dir schon allein das thermische Rauschen im Empfänger einen Strich durch die Rechnung (für Code-Messungen)

Benutzeravatar
KoenigDickBauch
Beiträge: 303
Registriert: 25.01.2007 - 21:59

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von KoenigDickBauch » 21.10.2008 - 22:41

Taurus hat geschrieben:Und 18.53 cm sind nicht drin ;-) Da macht dir schon allein das thermische Rauschen im Empfänger einen Strich durch die Rechnung (für Code-Messungen)
Irgend wo habe ich mal gelesen gelernt, das man so viele Stellen plus 1 angeben sollte wie man wirklich messen kann. Daher begrüße ich es das der OziExplorer zum beispiel alles mit 4 Nachkommastellen angibt.

Gruß
Thomas

XPosition
Beiträge: 214
Registriert: 25.08.2008 - 00:09

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von XPosition » 21.10.2008 - 23:23

Hallo Taurus,
ich glaube die Geodäsie hat sich etwas verrechnet. :)
Soweit ich mich erinnere sind 4 Nachkommastellen im NMEA Format ca 10 Meter.
Bin jetzt aber zu faul das nochmal durchzunudeln.

Es sind ja auch nicht 0.0001 Sekunden, sondern
0° 0001'
also 0 Grad und 0.0001 MINUTEN

Was meinst du mit thermischem Rauschen ?
Meinst du, dass günstige Timer schon zu sehr von der Themparatur abhängig sind ?
Oder falsches Platinen-Layout ?
Naja, keine Ahnung was der Fragesteller für Hardware ausgeben will,
aber mit sehr teurer Hardware kommt man ja schon in den cm Bereich.

Benutzeravatar
Taurus
Beiträge: 259
Registriert: 02.09.2007 - 14:36
Wohnort: Germany

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Taurus » 22.10.2008 - 08:20

Jetzt wo du es sagst XPosition, frag ich mich auch wie ich auf Sekunden komme *am kopf kratz*
Hab es eben nochmal durchgetippt, aber am Ergebnis ändert sich nix...

Wir können es auch anders machen:
0.0001 [Min] = 0.006 [Sek]
wobei eine Bogensekunde ca. 30m auf der Erdoberfläche sind...
30m x 0.006 = 0.18m

Thermisches Rauschen
Das ist im allgemeinen ein Sammelbegriff bei Datenübertragungs-Systemen. Hat aber nix mit Thermik/Thermodynamik zu tun, sondern heißt einfach nur so...
Es fasst die einzelnen Messgrößen zusammen (Signalstärke, Korrelatorabstände,...) und bewirkt das wenn du auch bei theoretisch ständig konstanter Satellitenkonstellation ohne Bewegung dennoch Schwankungen in deiner Position hast...

ssquare_de
Beiträge: 671
Registriert: 07.10.2006 - 16:23

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von ssquare_de » 22.10.2008 - 09:57

Hallo,


ich würde empfehlen, mich bei der Programmierung von Software an Joerns Anmerkungen zu halten und das Progamm nicht, nur wegen unerwarteten Nachkommastellen, abschmieren zu lassen...oder auch den Infogehalt unausgewertet zu lassen...

Ihr dürft ja nicht vergessen, dass über das NMEA-Format auch hochgenaue Positionsdaten ausgetauscht werden, die im Millimeterbereich und darunter auflaufen.

Sirf und Garmin sind nicht alleine da draussen... :)


Stefan


P.S. Ein Antaris von u-blox gibt im NMEA-Teil 5 Nachkommastellen bei LAT-und LONG-Angaben aus. Sirf/MTK-Chipsätze sicher auch.
Das sagt aber nichts über die Genauigkeit der berechneten Position aus!

Antares
Beiträge: 8
Registriert: 21.10.2008 - 12:37

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Antares » 23.10.2008 - 15:46

Hallo Leute.

Erstmal Vielen Dank an Alle für die vielen Antworten, und sorry, dass ich erst jetzt wieder da bin, aber bei mir hat die Grippe zugeschlagen.

Xposition hat geschrieben: Aber da du eh dein Gerät selbst baust, kannst du dir ja auch die Daten
im speziellen binären Format des Chip-Herstellers geben lassen.
Ich würde gerne beim NMEA bleiben, da es sein könnte, dass ich beim nächsten Projekt aus noch unvorhersehbaren Gründen auf einen anderen Chip-Hersteller zurückgreifen muss.
Dann wäre die Umstellung einfacher.


Jörn Weber hat geschrieben: Ich verstehe dein Problem nicht. Die Darstellung des NMEA183 ist ein comma separated format (csv). Dieser ist irgendwo in einem RFC der Internet Community festgeschrieben. Das Trannzeichen ist das Komma, daher kann dir die Anzahl der Stellen beim parsen völlig egal sein. Parsen tut man immer auf erst auf die Kommas, dann ersetzte man in den einzelnen Feldern die Punkte durch Kommas und wandelt dann den String in einen Real-Wert um. Hintergrund ist, das NMEA im Zweifel auch auf einem /-Bit-Kanal mit reinem ASCII laufen muss.
Mir gehst es nicht um die Kommata als Trennzeichen der einzelnen Angaben. Das Parsen ist im Mom. noch kein Thema.
Was ich meinte ist folgendes:
Bei der NMEA-Ausgabe werden die Latitude-, bzw. Longtitude-Werte so ausgegeben:
ddmm.mmmm bzw. dddmm.mmmm
Es geht also um die Anzahl der m-Stellen nach dem Punkt. (Der Punkt trennt ja die Minuten-Vorkomma-stellen und die Minuten-Nachkommastellen.) Manchmal sind es 2, 3, 4, 5.


Taurus hat geschrieben: als erstes steige ich mit einem Zitat ein: "Das einzig wirklich standardisierte ist der Tod."
Den Spruch sollte ich mir mal merken. Danke :D


Taurus hat geschrieben: wenn ein Empfänger mir auf 4 Nachkommastellen die Position angibt heißt das garnichts. Ganz im Gegenteil... das heißt nur das die Entwickler des Empfängers mal hätten ein bisschen Ausgleichungsrechnung oder Vermessungskunde lernen sollen, anstatt in ihren Nullen und Einsen zu kramen...
Als Beweis eine kleine Berechnung:
Meine Position wird mir auf 0.0001 Sekunden "genau" angegeben...
0.0001 [Sec] = 0.0001 / 60 = 0.0000016 [Deg=Dezimalgrad=°]
Wenn ich das ganze jetzt mal mit dem Erdradius in ein metrisches Maß umrechne:
0.0000016 x PI / 180° x Erdradius = 0.000000029 [rad] x 6371 [km] = 0.0001853 [km] = 18.53 [cm]
Und 18.53 cm sind nicht drin. Da macht dir schon allein das thermische Rauschen im Empfänger einen Strich durch die Rechnung (für Code-Messungen)


Auf die 18.53cm bin ich auch gekommen, aber mit folgender Rechnung:
Erddurchmesser (Äquator): 40030,17359km = 40030173,59m
Aufteilung in 360° ergibt: 40030173,59m / 360 = 111194,9266m (Also ein Grad entspricht 111194,9266 metern)
In jedem Grad sind 60 min. also 111194,9266m / 60 = 1853,2481m
bei 4 Nachkommastellen sind es: 1853,2481m * 0,0001 = 0,1853m = 18,53 cm.
Das nur so nebenbei. ;-)

Zu der Genauigkeit allgemein:
Dann würde ja dann bedeuten, dass 5 Nachkommastellen (die zumindest lt. Wikipedia möglich sind) eine Riesen-Lachnummer sind. Damit kämen wir ja dann auf (theoretisch) 1,85 cm.

Ich hab nur gelesen, dass man mit DGPS, nachdem man die Atmosphärischen Fehler mit Hilfe eines 2. Empfängers eliminiert hat, wirklich auf 1cm kommt. Genauigkeit kommen kann (z.B. SAPOS).
Ich baue ja mit einem mobilen Empfänger und einer Referenzstation etwas ähnliches. Aber ich merke auch, dass ich die Genauigkeit nicht erreichen werde.
Zumal ich damit nur die atmosphärischen Fehler zu einem gewissen Grad heraus filtern kann.
Aber die Aufgabe lautet erstmal einfach: „ Kriegen Sie es so genau wie möglich hin“.


KoenigDickBauch hat geschrieben: Irgend wo habe ich mal gelesen gelernt, das man so viele Stellen plus 1 angeben sollte wie man wirklich messen kann.
Das habe ich auch mal gelesen, und eigentlich ist das recht auch allgemein gültig. (Auch für andere Sensoren, usw.)


Xposition hat geschrieben: Naja, keine Ahnung was der Fragesteller für Hardware ausgeben will,
aber mit sehr teurer Hardware kommt man ja schon in den cm Bereich.
Die meisten Chips, die mein Kollege und ich gefunden haben, bewegen sich so im 100-200€-Bereich.
In dem Bereich wäre das auch ok. Wird von der Fachhochschule bezahlt.
Darf ich fragen, was du mit "sehr teuer" meinst?

ssquare_de hat geschrieben: P.S. Ein Antaris von u-blox gibt im NMEA-Teil 5 Nachkommastellen bei LAT-und LONG-Angaben aus. Sirf/MTK-Chipsätze sicher auch.
Die sind mir auch bereits aufgefallen, leider fällt deren Beschreibung immer so spärlich aus, zumindest auf deren Webseiten.


ssquare_de hat geschrieben: Das sagt aber nichts über die Genauigkeit der berechneten Position aus!
Ja, leider.



Falls ich irgendwo Unsinn geschrieben habe, bitte ich das zu entschuldigen. Wir haben erst vor ein Paar Wochen angefangen uns damit zu beschäftigen, und werden wohl noch etwas Zeit brauchen, um da halbwegs durchzublicken.

ssquare_de
Beiträge: 671
Registriert: 07.10.2006 - 16:23

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von ssquare_de » 23.10.2008 - 16:20

Hallo Antares,


na komm schon, ne bessere Doku gibts doch garnicht... :)
http://www.u-blox.de/customersupport/index.html

Und da speziell schaust du ( für deine Zwecke ) nach dem LEA-4T ( Antaris 4 )
http://www.u-blox.de/customersupport/antaris4_doc.html
Protokolldoku:
http://www.u-blox.de/customersupport/gp ... 002%29.chm

Da ist doch wirklich alles da, von was Studenten in Dauerterminstress nicht mal zu träumen wagen.... :D :D

(Mist, jetzt muss ich eingestehen, dass ich hier mitlese :wink:
Habe den letzten Link korrigiert, man muss ihn am besten speichern und dann entzippen.
Roland 23.10.08)




Stefan


P.S. Vielleicht magst du uns noch ein wenig mehr erzählen, was genau dein/euer DGPS können soll.
Gibts schon ein vorläufes Lastenheft ?!?
Bestückt ihr notfalls auch Platinen, oder bleibts mehr softwareseitig?

Was hier schon geschrieben wurde und für dich von Interesse sein könnte:
http://www.kowoma.de/gpsforum/viewtopic.php?f=2&t=1728
http://www.kowoma.de/gpsforum/viewtopic.php?f=4&t=1672
http://www.kowoma.de/gpsforum/viewtopic.php?f=4&t=1509
http://www.kowoma.de/gpsforum/viewtopic.php?f=3&t=1925
http://www.kowoma.de/gpsforum/viewtopic.php?f=3&t=1936

...und gute Besserung !!! :D

Benutzeravatar
Taurus
Beiträge: 259
Registriert: 02.09.2007 - 14:36
Wohnort: Germany

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Taurus » 23.10.2008 - 17:46

Also genau genommen hast du das selbe gerechnet wie ich ;-) @Antares

Aber was ich mich gerade Frage... wenn ich es richtig verstanden habe, nehmt ihr die NMEA-Position und wollt dann mit DGPS die Position verbessern, oder ?
Solltet ihr das wirklich vorhaben muss ich euch aber enttäuschen... weil das klappt so nicht. Dazu bräuchtet ihr dann die Roh-Daten der Empfänger...
(Solltet ihr es nicht so machen, streich alles aus deinem Gedächtnis was ich eben gesagt hab.)

Da ich im moment selbst gerade an meiner Diplomarbeit arbeite, stecke ich recht gut drin in der DGPS-Thematik... daher zu den atmosphärischen und ionosphärischen Fehlern: je weiter die Empfänger voneinander entfernt sind, desto ungenauer wird deine DGPS-Lösung.
Ich arbeite gerade über eine 3m-Basislinie... da hab ich eigentlich keine nennenswerten Fehler drin.

Welchen Zweck soll das System denn haben ?
Wenn es z.B. Fahrzeugortung ist, brauchst du nicht den Zentimeter, schließlich ist das zu überwachende Objekt selbst 1,80x2,50m groß ;-)
Ich hab nur gelesen, dass man mit DGPS, nachdem man die Atmosphärischen Fehler mit Hilfe eines 2. Empfängers eliminiert hat, wirklich auf 1cm kommt.
...die Rechnung funktioniert nur auf dem Papier. Du hast ja mindestens noch Multipath drin... und noch dazu kommen die Empfängeruhr-Fehler (Wobei die je nach dem Grad der Differenz deiner DGPS-Lösung auch verschwinden)

Antares
Beiträge: 8
Registriert: 21.10.2008 - 12:37

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Antares » 23.10.2008 - 20:37

Hallo,

@ Stefan:
Danke für die Links. Stimmt, auf u-blox.de ist es gut beschrieben. Da haben wir ne Menge zu lesen.

ssquare_de hat geschrieben: Vielleicht magst du uns noch ein wenig mehr erzählen, was genau dein/euer DGPS können soll.
Allgemein haben wir Folgendes aus allen Infos, die bisher gesammelt wurden, so verstanden: (korrigiert mich, wenn ich was falsch verstanden habe):
Bei der Positionsbestimmung mittels GPS gibt es ja Positionsbestimmungsfehler, die unter anderem dadurch entstehen, dass das Satelliten-Signal durch die Atmosphären-Schichten gestört wird.
Dieser Atmosphären-bedingter Fehler ist an 2 nicht weit voneinander entfernten stellen weitgehend gleich.

Projekt:
Wenn also eine Referenzstation aufgestellt wird, deren tatsächliche (korrekte) Position bekannt ist, dann kann sie doch die Differenz zu ihrer eigenen gemessenen (fehlerhaften) Position bestimmen und dem mobilen System, diese Differenz zusenden, damit die dann den (atmosphärenbedingten) Fehler „herausrechnen“ kann.

Also soll die Referenzstation aus einem GPS-Empfänger, einem 433MHz-Sender und einem µ-Controller bestehen.
Und die mobile Einheit aus einem GPS-Empfänger, einem 433MHz-Empfänger und einem µ-Controller.
(Natürlich kommen noch die Spannungsversorgung usw. hinzu,


ssquare_de hat geschrieben: Bestückt ihr notfalls auch Platinen, oder bleibts mehr softwareseitig?
Es wird sowohl Hard- als auch Software erstellt.


ssquare_de hat geschrieben: Gibts schon ein vorläufes Lastenheft ?!?
Noch nicht, diese Arbeit soll erstmal dazu dienen, das o.g. System aufzubauen und rauszufinden, was für eine Genauigkeit möglich ist.
Und dann in den nachfolgenden Dipl.- und Projektarbeiten werden diese Erkenntnisse für reale Systeme eingesetzt.


ssquare_de hat geschrieben: ...und gute Besserung !!!
Danke, heute geht’s wider halbwegs. :-)


Taurus hat geschrieben: Aber was ich mich gerade Frage... wenn ich es richtig verstanden habe, nehmt ihr die NMEA-Position und wollt dann mit DGPS die Position verbessern, oder ?
Solltet ihr das wirklich vorhaben muss ich euch aber enttäuschen... weil das klappt so nicht. Dazu bräuchtet ihr dann die Roh-Daten der Empfänger...
Ja. Darf ich fragen: wieso darf die NMEA-Position nicht verwendet werden?


Taurus hat geschrieben: Da ich im moment selbst gerade an meiner Diplomarbeit arbeite, stecke ich recht gut drin in der DGPS-Thematik... daher zu den atmosphärischen und ionosphärischen Fehlern: je weiter die Empfänger voneinander entfernt sind, desto ungenauer wird deine DGPS-Lösung.
Der mobile Empfänger und die Referenzstation sollten in einem Bereich von 0- ca. 200 m. Arbeiten, und natürlich werden wir dann ausmessen müssen, wie sich der Fehler zu der Entfernung der beiden verhält. Uns interssiert aber im Mom. weniger eine bestimmte Genauigkeit, sonder mehr: was möglich ist.


Taurus hat geschrieben: Welchen Zweck soll das System denn haben ?
Wenn es z.B. Fahrzeugortung ist, brauchst du nicht den Zentimeter, schließlich ist das zu überwachende Objekt selbst 1,80x2,50m groß
Eine der Visionen wäre z.B. eine landwirtsch. Maschine autonom über ein Feld fahren zu lassen.
Das Objekt ist groß. Noch größer als 1,80x2,50m.
Aber wenn der Traktor z.B. heute das Feld besprüht (und damit in seinen Spurrillen den Weizen platt macht), und morgen beim Unkraut jäten 25 cm. Versetzt (zu den Spurrillen des Vortages) fährt, dann vernichtet er unnötig eine Fläche von 25cm * 2 (Radseiten) * Länge seiner gefahrener Strecke.
(Ist nur ein Beispiel, ich bin nicht sicher, dass auf einem Weizenfeld Unkraut gejätet wird, es geht nur um den technischen Teil.)

Aber nach Abschluss dieser einer Arbeit sollen vor allem 2 Platinen fertig sein, mit denen Messungen angestellt werden sollen.

Benutzeravatar
Taurus
Beiträge: 259
Registriert: 02.09.2007 - 14:36
Wohnort: Germany

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Taurus » 23.10.2008 - 21:53

Ok, das mit dem Traktor macht Sinn... da wäre cm-Genauigkeit schon angebracht.

Zur DGPS-Problematik
Die DGPS-Korrekturen werden im Regelfall auf die Pseudoranges angerechnet. Das heißt also das die Korrekturen angebracht werden, bevor die Position berechnet wird.
Nochmal zur Klarheit was DGPS-Korrekturen sind: Troposphären-Fehler, Ionosphären-Fehler, Uhr-Fehler
Bei 200m kannst du ohne weiteres den Troposphären- und Ionosphären-UNTERSCHIED (!!!) zwischen Basis und Rover vernachlässigen.

Bei deinem Ansatz mit der Ablage von den Referenzkoordinaten wir die Position auch verbessert, jedoch musst du damit rechnen, dass jeder Fehler in der Ablage an der Referenzstation auch auf den oder die anderen Empfänger übetragen wird. Und das kann dir bei Multipath-Einfluß ganz schnell einen ganzen Meter Probleme einbringen.
Ein weiteres Problem ist auch, dass du das ja in Echtzeit betreiben willst... mit Post-Processing wäre das garnicht so dramatisch.

Ich werd kommende Woche mit meinen Messungen beginnen, hab aber den Vorteil das an meiner Uni nicht aufs Geld geguckt wird und ich deshalb zum Messen aus 8 Empfängertypen wählen konnte...
Hab mich für zwei Novatel PowerPak-4-RT2 entschieden, welche aber glaube ich den finanziellen Rahmen an der FH sprengen *grins*

Benutzeravatar
Jörn Weber
Beiträge: 789
Registriert: 03.02.2007 - 16:11
Wohnort: Jena

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Jörn Weber » 24.10.2008 - 19:51

Hallo Taurus,
Taurus hat geschrieben: Ich werd kommende Woche mit meinen Messungen beginnen, hab aber den Vorteil das an meiner Uni nicht aufs Geld geguckt wird und ich deshalb zum Messen aus 8 Empfängertypen wählen konnte...
Ich muss dich noch einmal inquisitorisch fragen: Ist überhaupt die Grundlagen-Frage geklärt, ob eine Messung der Phasedaten bei einem bewegten System machbar ist? Und wenn ja, wie genau muss die schwankende Eigenbewegung des Rovers erfasst und berücksichtigt werden. Welche CPU-Kapazität ist für die Echtzeitberechnung der Position erforderlich. Reichen hier PDA's aus oder muss ein remote Supercomputer her?

Gruss Joern Weber

Benutzeravatar
Jörn Weber
Beiträge: 789
Registriert: 03.02.2007 - 16:11
Wohnort: Jena

Re: NMEA: Anzahl der Bogenminuten-Nachkommastellen

Beitrag von Jörn Weber » 24.10.2008 - 20:09

Hallo Antares und Taurus,
Antares hat geschrieben: Ja. Darf ich fragen: wieso darf die NMEA-Position nicht verwendet werden?
Die NMEA-Daten müssen bereits korrigiert sein, bevor der Empfänger sie ausspuckt. Diese Korrektur funktioniert auch mit einem Empfänger der nur Pseudoranges verwendet. Der Empfänger muss hierzu in der Lage sein RTCM einer Referenzstation zu verarbeiten. Phasetrack12 und spezielle Antaris4 Empfänger sind dazu in der Lage. Die erreichbare Genauigkeit bei der Verwendung von Pseudoranges beträgt maximal 50 cm. Als DGPS-Quellen können IALA-Sender (Genauigkeit >1Meter) oder Internetdienste der Landvermessung Genauigkeit >50cm) verwendet werden. Wenn du für einen Ackerschlepper gösere Genauigkeiten haben möchtest, müssen die Phasedaten verwendet werden. Um diese für einen bewegten Rover berechnen zu können, muss die Eigenbewegung des Rovers bekannt sein, und zwar in allen drei Achsen. Hintergrund ist, das die Eigenbewegung aus der von den Satelliten verursachten Phasenverschiebung heraus gerechnet werden muss. Ich vermute das schon für einen Genauigkeit im Subdezimeterbereich eine extreme Rechenleistung erforderlich ist, da die deutsche Landvermessung schon für statische Messungen hierfür remote Computer verwendet. Bevor Ihr experimentell loslegt würde ich euch erst einmal zu einer theoretischen Machbarkeitsstudie raten, wenn ihr in den Genauigkeitsbereich unter 50 cm vordringen wollt.

Gruss Joern Weber

Antworten