Vergleich NEO-6P PPP und RTKlib PPP - Problem

Fragen und Hinweise zu Software, die mit dem Thema GPS zu tun hat. Egal ob PC oder Handheld.

Moderator: Roland

Antworten
galilei
Beiträge: 4
Registriert: 08.03.2012 - 17:59

Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von galilei » 23.03.2012 - 11:48

ich habe meinen neuen NEO-6P Stick mit einer einfachen Patchantenne mittig auf dem Autodach platziert auf einem grossen, gefüllten Parkplatz getestet. Die Aufzeichnung der Daten (ca. 6min) erfolgte mit ublox u-center nach jeweils ca. 3min Vorlaufzeit. Es bestand stabiler Empfang mit 7-8 Satelliten und 3D/DGPS fix mit EGNOS. Der zweite Datensatz wurde 24 Stunden später erstellt (andere Parkstelle), dabei war das dynamic modell im NEO-6P auf "Stationery" umgestellt, vorher war es "Portable" bzw "Automotive". Die Rohdaten der ubx Datei wurden mit rtkconv/rtkpost 2.4.1 prozessiert. Für die PPP-Static Lösung wurden Rinex Daten der Euref Station KARL1 verwendet (ca. 70km entfernt). Der erste Datensatz zeigt erfreuliche und für mich als Vermessungslaie konsistente Ergebnisse. Der zweite Datensatz ist von eigentlich noch besserer Qualität, nach der RTKlib Auswertung liegt die dort ermittelte Position aber ca. 4m von der NEO-6P PPP Position entfernt. Für mich ergibt sich jetzt das Problem welcher Position ich eher Glauben schenken darf und warum es zu so einer Abweichung kommen kann. Die RTKplot Bilder sind im Anhang.
Parkplatz.gif
erster Datensatz, RTKlib PPP-Static Lösung
Parkplatz.gif (9.31 KiB) 9506 mal betrachtet
Parkplatz_Vergleich.gif
erster Datensatz, Vergleich mit NEO-6P
Parkplatz_Vergleich.gif (11.7 KiB) 9506 mal betrachtet
Parkplatz3_Vergleich.gif
zweiter Datensatz, Vergleich mit NEO-6P
Parkplatz3_Vergleich.gif (8.33 KiB) 9506 mal betrachtet

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

Re: Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von ssquare_de » 26.03.2012 - 11:40

Hallo,


also ich kenne bislang nur folgende sinnvolle Möglichkeiten mit RTKLIB und dem NEO-6P:

Neo-6P im autonomen Betrieb mit/ohne aktiviertem SBAS.
(wobei ich hier SBAS auch mal auch dem autonomen Betrieb zuordne, obwohl das ja so nicht ganz stimmt, folgt man den üblichen Konventionen!)

Die Rohdaten des Neo-6P mit Hilfe von RTKLIB auswerten
(entweder in Echtzeit, oder auch per Postprozessing)

wobei ich bislang der Meinung war, die PPP-Funktionen, die RTKLIB bisher bietet, sind nur von 2-Frequenzempfängern sinnvoll zu nutzen.?!?
Da bin ich aber etwas unsicher, da ich RTKLIBs PPP noch nicht mit 1-Frequenzempfängern getestet habe.

Eines ist aber klar: mit 1-Frequenz-Empfängern braucht man mindestens 10-15min. Beobachtungszeit, bis vernünftige Resultate angezeigt werden können.
Soll heissen: bei optimalen Randbedingungen wie freie Lage, gute Antenne, wenig-kaum Multipath, kurze Basislinien (möglichst im einstelligen km-Bereich)...
Für den PPP-Betrieb in RTKLIB sind noch viel längere "Einschwing"-zeiten vorzusehen ( bislang in der Grössenordnung von 1-2h, auch mit teueren 2-Frequenzempfängern, um auf besser 10-20cm Genauigkeit zu kommen)

Zudem:
für den PPP-Betrieb wird keine Referenzstation benötigt, genau das zeichnet ja das Verfahren aus!
An Stelle der Referenzstationen muss man bei PPP sehr genaue Bahn- und Uhrdaten verwenden, die RTKLIB übers WWW verfügbar gemacht werden!
Der NEO-6P zieht dafür die SBAS-Korrekturen über den Satelliten-Link heran.
Nicht ganz so genau, aber dafür muss sich der Anwender nicht um zusätzliche Infratrukturen kümmern!
Die SBAS-Sats müssen eben empfangbar sein, und man muss berücksichtigen, dass die Positionen bei Nutzung externer Uhr-und Bahndatenquellen normalerweise in ITRF2000 berechnet werden.
--->
Ich vermute also ganz heftig, dass RTKLIB falsch konfiguriert/eingesetzt wurde.
http://igs.bkg.bund.de/ntrip/ppp
http://igs.bkg.bund.de/ntrip/symp


Stefan

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von Hagen.Felix » 26.03.2012 - 19:28

Vielen Dank, Stefan,

für diese so ausführlichen Erläuterungen zu diesem Problem!

Zunächst war ich ja doch etwas erschrocken und dann auch ziemlich ratlos, als ich diese so stark voneinander abweichenden "Punktwölkchen" zu Gesicht bekam ... :shock:

In Zukunft wird es ja voraussichtlich noch einige Vergleichsdaten zwischen autonomem PPP (im NEO-6P) und RTK (SAPOS) geben, das wird sicher auch noch mal recht spannend ... :o

Bis denne,
Hagen
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

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

Re: Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von ssquare_de » 26.03.2012 - 20:31

Hallo Hagen,


dass mit den Low-Cost-Empfängern in Verbindung mit RTKLIB und natürlich auch mit anderen kommerziellen Softwarepaketen zuverlässig Genauigkeiten bis in den Subdezimeter-Bereich hinein erzielt werden können, ist mittlerweile fast schon
Allgemeingut geworden.
Zumindest in diesem Forum. :wink:

Hier die letzten Ausführungen zu dem Thema:
http://users.tkk.fi/~coandrei/pdf/enc20 ... tation.pdf
http://users.tkk.fi/~coandrei/pdf/esa2011_poster.pdf

Zu galilei s Messungen nochmal:

Im autonomen Betrieb des NEO-6P (und auch allen anderen ublox-Empfängern) würde ich für die Positionsbestimmung das "stationary"-Modell normalerweise nicht auswählen.
Höchstens für >>24h-Logs!
Denn bei Kurzzeit-Logs kann einem die hübsche Deviations-Map einen bösen Streich spielen, indem sie Genauigkeiten vorspielt, die so nicht vorhanden sind.
Das "stationary"-Modell sollte in erster Linie die Timing-Funktion der T-Modelle von ublox verbessern.

Für eine Rohdatenauswertung mit RTKLIB o.ä. ist die Einstellung jedoch belanglos, da sie sich nur auf Positionsberechnungen auswirkt, die vom Navigationsrechnerteil des ublox-Moduls ausgegeben wird.
( im .ubx- oder auch .NMEA-Messageformat)

Mehrere Meter Abweichung gibts nur bei Datumsproblemen, oder auch, wenn vergleichsweise lange Basislinien (70km) auf sehr kurze Beobachtungszeiten (< 10min.) treffen.
Selbst 50-70km Basislinien sind mit 1-Frequenzlern von ublox meiner Erfahrung nach gut zu bewältigen.
Da loggt man dann einfach 24h.
Für einmalige Positionsbestimmungen ist das meiner Meinung nach gut hinnehmbar.
Führt man die 24h-Logs samt Auswertung mehrere Male durch, hat man eine gewisse Kontrolle, dass die Position auch wirklich gut passt.

Ansonsten passt galilei s Ansatz schon.
Mit RTKLIB und einer Referenzstation im Postprozessing seinen eigenen Referenzpunkt schaffen, an dem dann die Echtzeitleistung des GPS-Moduls zuverlässig geprüft werden kann.
Dabei natürlich auf das jeweilige Datum achten!
http://www.epncb.oma.be/_trackingnetwor ... /index.php
http://www.epncb.oma.be/_dataproducts/coord_trans/


Stefan

galilei
Beiträge: 4
Registriert: 08.03.2012 - 17:59

Re: Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von galilei » 27.03.2012 - 09:50

Hallo Stefan,

vielen Dank für die Antworten. Ich habe den Daten ja selbst nicht getraut und deshalb gefragt. Demnächst werde ich an einem Festpunkt in meiner Nähe ausführliche Messungen machen. Zwei Fragen hätte ich noch. Wo bekommt man die erwähnten hochgenauen Daten für das PPP Postprocessing her? Jetzt habe ich Daten von ftp://igs.bkg.bund.de/EUREF/ verwendet. In den Beispielszenarien sehe ich immer nur die Echtzeitanwendungen mit Ntrip Streams. Bringt es was eine höhere Messfrequenz als 1Hz zu verwenden oder ist einzig die Beobachtungsdauer entscheidend?

Markus

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

Re: Vergleich NEO-6P PPP und RTKlib PPP - Problem

Beitrag von ssquare_de » 27.03.2012 - 11:42

Hallo Markus,


Messfrequenz ist hier egal, die Beobachtungsdauer (Länge des Logs) macht den Unterschied!
Jetzt müsste ich nur noch wissen, was genau du machen möchtest? :wink:
Ich vermute mal, du willst die Echtzeitgenauigkeit deines NEO-6Ps überprüfen, einmal mit aktiviertem SBAS, einmal ohne SBAS?!?

Wenn es so ist:
idealerweise hast du einen zugänglichen Lagefestpunkt in deiner Umgebung zur Verfügung, dessen Position schon amtlicherseits mit GNSS-Verfahren festgestellt wurde.
Das ist wichtig, denn so fallen alle Ungenauigkeiten, die bei der Transformation, (gleich, welcher Art!) z.B. aus dem "alten" GK, zwangsläufig mit ins Boot kommen, schon mal weg!
Dann liegt diese Position normalerweise in ETRS89 vor.
--> Schön für dich, die Genauigkeit hat "Garantie", zudem erspart es dir jede Menge Arbeit. :)

Du kannst dir diesen Referenzpunkt aber aus den Rohdaten des NEO-6P und RTKLIB auch leicht selbst schaffen.
Idealerweise mit einer FIXED-Solution im Postprozessing. ---> diese Fixed-Lösung bräuchte aber viel kürzere Basislängen als die erwähnten 70km!
Erfahrungsgemäss kannst du dir sehr gut damit behelfen, indem du dich mit einer FLOAT-Lösung zufrieden gibst, die aber aus einem 24h-Log gewonnen wird.
Wie gesagt, meiner Erfahrung nach sind auch diese Langzeit-Floats äusserst genau. (Im 1-2 cm-Bereich)
Wenn du die 24h-Logs 2-3 mal an absolut gleicher Position ( mit unveränderter Orientierung der Antenne!, am besten, du belässt sie während der 2-3 Tage unberührt !) erstellen kannst, wirst du sehen, wie nahe die beieinander liegen.
Das ist eine ziemlich starke Versicherung zur Güte der Position!

Die Koordinaten der Basisstation, die du in RTKLIB unter Options---> Position einträgst, sind verständlicherweise höchst sensibel, denn im Postprozessing wird ja nur der Vektor von der Basissationsantenne zu deiner Roverantenne berechnet, also Länge und Richtung. Deswegen wird ja beim Postprozessing auch von einem relativen Verfahren gesprochen, also dein Rover relativ zur Basisstation!
Fehler z.B. durch falsches Datum, falsche Lagerung...schlagen folglich 1:1 auf deine Roverposition durch!

Du hattest die Station KARL1 erwähnt:
Hier sind die relevanten Stationskoordinaten aufgeführt:
http://www.epncb.oma.be/_trackingnetwor ... ation=KARL
Ganz unten auf der Seite findest du sie unter
5. POSITIONS PUBLISHED BY THE COUNTRY im amtlichen ETRS89 gelagert
X = 4146524.655
Y = 613137.828
Z = 4791516.971
Dein so geschaffener Referenzpunkt liegt dann also auch in ETRS89 vor.

Wenn du nun aber diesen Punkt mit dem autonomen NEO-6P beobachtest, gibt dieser seine Lösungen mit deaktiviertem SBAS im WGS84 (G1150) aus, schaltest du SBAS an, liegen die Positionen in ITRS 2000 vor.
Entscheidend sind die Bahnkoordinaten, die jeweils verwendet werden.
Im autonomen GPS-Betrieb werden die sogenannten "Broadcast"-Bahn- und Uhrdaten verwendet, die sich auf das WGS (G1150) beziehen,
im SBAS-Betrieb werden Bahn- und Uhrkorrekturen verwendet, die abweichend zu oben im ITRF 2000 gelagert sind.

Nimmt man es ganz genau, müssen da teilweise auch Transformationen vorgenommen werden.
http://www.epncb.oma.be/_dataproducts/coord_trans/
Die Daten für die jeweilig verwendete Basisstation entnimmt man wiederum:
http://www.epncb.oma.be/_trackingnetwor ... /index.php

Ergänzend dazu sei auch noch auf diesen Beitrag verwiesen:
http://www.kowoma.de/gpsforum/viewtopic ... 33f#p14645
und hier:
http://www.gib.uni-bonn.de/mitarbeiter/ ... er_web.pdf
http://earth-info.nga.mil/GandG/publica ... 8350.2.pdf

oder auch das:
http://www.killetsoft.de/t_1009_d.htm

:wink:
====================================================================

Wichtiger Ergänzungslink:
http://www.sxbluegps.com/world-about-datum.html

daraus:
"Both GPS and SBAS are based on the ITRF 2000 reference frame, with the following difference:
• GPS has fixed the epoch in January 2002 (in other words, for GPS, the crustal motion of the earth has stopped since 2002 and until the next revision)
•SBAS (WAAS, EGNOS, MSAS, etc) on the other end, recalculate the location of the ground stations on a regular basis (almost every year) and predict (or project) the velocities a few months in the future or to the middle of the following year.

und weiter:

When using a GPS receiver in autonomous mode (with no differential correction), the coordinates output are in WGS 84 (G1150), the current GPS reference frame. When using differential corrections from:
•SBAS: coordinates output by a GPS receiver are in ITRF 2000 (current epoch)

---> so fasse ich es für mich zusammen:
WGS84 (G1150) = ITRF 2000 (epoch 02)
SBAS = ITRF 2000 (aktuelle Epoche = Jahr der Datenaufzeichnung)


Ziemlich mühsam, das Ganze!
Das sind wohl die Schattenseiten der Globalisierung der Vermessung.
Aber Ok, das braucht man wohl alles nicht, wenn man sich nur zum nächstgelegenen Drive-in einer Burger-Kette lotsen lassen will...
:)



Stefan

Antworten