RTKLIB + SAPOS + LEA-6T

[laqup]

Hallo GPS-Begeisterte,

seit einiger Zeit lese ich hier sehr interessiert diverse Threads und Beiträge und habe mich nun dazu entschlossen selbst eine Low Cost RTK Lösung zu basteln. Bei der Konfiguration von RTKNavi scheine ich aber irgendetwas grundsätzlich falsch zu machen, vielleicht könnt ihr Experten mir dabei weiterhelfen.

Bestandteile meines Systems sind bisher wie folgt:
- Ublox LEA-6T (Rover)
- Sapos Bayern (Virtuelle Base Station)
- Notebook für die Datenverarbeitung

Glücklicherweise wohne ich in direkter Nähe der Korrekturstation, die Baseline ist lediglich 930m lang, so dass eigentlich gute Ergebnisse zu erwarten sein sollten.

Konfiguration LEA-6T:
- Ausgabe von UBX RXM Raw und UBX RXM SFRB
- Alle anderen Messages deaktiviert

Konfiguration RTKNavi:
http://web2.optinet24.de/uploads/gpsSettings1.jpg

Und so sieht das Resultat aus:
http://web2.optinet24.de/uploads/gpsSettings2.jpg

RTKNavi schluckt die Korrekturdaten nicht (outlier rejected bei allen Satelliten sowie no double differenced residual) und liefert demzufolge auch richtig schlechte Daten. Sofern ich das richtig deute, ist der Empfang eigentlich ganz gut und müsste bessere Ergebnisse zulassen als eine Standardabweichung von 4 Metern.

Vielleicht hat einer von euch die zündende Idee, was an meiner Konfiguration falsch ist. U-Center liefert mir übrigens auch ohne Korrekturdaten deutlich stabilere Daten:
http://web2.optinet24.de/uploads/gpsSettings3.jpg

Und noch eine Frage: Ich habe hier im Forum schon öfter gelesen, dass die Frequenz der ausgehenden Daten des ublox Receivers eingestellt werden kann (1-16Hz), diese Option konnte ich in U-Center aber bisher nicht entdecken, wo finde ich diese?

Danke für dieses Forum, die tollen Anregungen sowie euren Support.

Grüße
Daniel

[archie]

Hallo Daniel,

Vielleicht kann ich ein bischen helfen.
Bei ein virtuelle Basisstation hat mann die Basis immer dichtbei, deswegen will das Referenznetz(Sapos) auch dein Standort wissen.
Bei ein RTCM-protokoll musste mann in RTKnavi unter Options/Positions/Base Station die optie RTCM Antenna Position auswählen.
Die ausgangsfrequenz von der Ublox Empfänger kann in RTKnavi und im Ucenter eingestellt werden.
In Ucenter unter Configuration view/Rates. Nach dem einstellen Konfiguratie dauerhaft speichern.
In RTKnavi mittels ein komando (Input Stream/Rover/Cmd). Fertige kommandos stehen im Data verzeichnis von RTKlib.

Grüße Pieter.

[laqup]

Hallo Pieter,

du hast vollkommen Recht, mit der Einstellung "RTCM Antenna Position" erhalte ich hier testweise zumindest schon einmal eine float-Lösung (befinde mich derzeit nicht auf dem "Testgelände"). Und auch die Umstellung auf 4Hz ist gut gelungen. Danke dir.

Sind denn die anderen Einstellungen plausibel, oder hat jemand von euch bessere Erfahrungen mit anderen Settings gemacht?

Grüße
Daniel

[archie]

Hallo Daniel,
Freut mich das es besser wird. Du sollte mal Settings1/Sbas abhaken, damit auch die Egnos sats benutzt werden.
Unter Settings2/Integer Ambiguity Resolution solltest du eine option auswählen sonst wird es kein Fix geben. Unter
gute Empfangsbedingungen (GDOP<3) dauert es 2 bis 3 minuten bis ein Fix-lösung vorhanden is.
Wenn du dein Rover nicht bewegst wählst du besser Setting1/Positioning Mode/Static.
Viel glück und restliche Einstellungen ausprobieren.

Grüße Pieter

[ssquare_de]

Hallo Daniel,

Pieter hat dir ja schon die entscheidenden Tipps gegeben.
Schön!

Du hattest anfangs als Basisstation in RTKLIB die Aschaffenburger SAPOS-Referenzstation eingetragen.
Somit hast du in deiner ersten Konfig. bei den Positionsangaben der Basisstation um rund 930m "geschummelt"...
Mit "RTCM Antenna Position" passts, da liest dann RTKLIB die jeweils korrekte Position der virtuellen Referenzstation aus dem RTCM-Datensatz aus.

SAPOS stellt in deiner Konfiguration ein Netz-RTK dar.
--> Du kannst dich mit deinem Rover frei in Bayern bewegen, über "Transmit NMEA GPGGA to Basestation" wird dem SAPOS-Netzrechner die Position deiner GPS-Antenne mitgeteilt.
Für diesen Antennenstandort wird vom SAPOS-Rechner dann die Datenausgabe einer virtuellen Basisstation berechnet, die ja physikalisch nicht vorhanden ist.
--> wohin du dich auch in Bayern bewegst, deine Basisstation ist schon da.
Vorteile:
- innerhalb Bayerns brauchst du dich nicht um die Basissation zu kümmern
- immer minimale Basislinie --> höchstmögliche Genauigkeit die in kürzester Zeit erreicht wird.
- die Positionslösung aus RTKLIB wird schon im amtlichen Bezugssystem ETRS89 ausgegeben --> keine nachgeschalteten Rechenorgien mehr mit irgendwelchen Transformationen.

Du kannst ja mal versuchen, wie hoch du die Aktualisierungsrate deines ublox-Empfänger treiben kannst, bis die ersten Datenaussetzer kommen.
Da geht dann dem Rechenwerk im ublox-Chip einfach die Puste aus...
Dazu einfach allen überflüssigen Rechenballast über Bord werfen, SBAS komplett deaktivieren, auf minimale Datensätze beschränken(kein ASCII-NMEA),...
Vielleicht schaffst du so auch 5 Hz oder gar 10Hz ?!?
Einfach austesten, wenn du so hohe Update-Raten wirklich brauchst...oder auf den SKYTRAQ umsteigen, der schafft 20Hz, aber eben nur GPS-Rohdaten...

RTKLIB-Einstellungen:
ansonsten alles soweit i.O.
du kannst vielleicht noch in Statistics unter "Code/Carrier-Phase Error Ratio" auf 150 gehen,
in Setting2 unter "Integer Ambiguity Resolution" auf "Fix", wie schon gesagt,
und ansonsten die Einstellungen Setting1, Elevation Mask(°) und Setting2, Min Elev(°) to Fix Ambiguity auf deine Antenne, deinen Antennenstandort (Abdeckungen/Multipath...) feintunen.
Siehe dazu auch Tomoijs "Tuning of Positioning Options"
http://www.rtklib.com/rtklib_beagleboard.htm



Stefan

[laqup]

Hallo Pieter,
Hallo Stefan,

danke für die Tipps und Tricks, das hört sich alles sehr plausibel an und mir ist nun einiges klarer. Dann kann ich mich ja jetzt ans Werk machen, bin ja mal gespannt wie gut das Ganze klappt.

Eine Frage noch zu SBAS/EGNOS, dazu gibt es zwei unterschiedliche Meinungen in diesem Thread. Pieter empfiehlt die Aktivierung, Stefan die Deaktivierung allerdings zum Zweck einer höheren Datenrate. Habt ihr bereits Erfahrungswerte wie sich das Abschalten des EGNOS Dienstes auf die Genauigkeit oder die Zeit bis zum Fix auswirkt? Oder ist das von Fall zu Fall verschieden?

Und noch eine Frage: Bei "Transmit NMEA GPGGA to Basestation" wird ja, zumindest wenn die Option "Latitude/Longitude" gewählt wird, ein fester Wert vorgegeben. Wenn sich mein Rover aber nun durch die Gegend bewegt, ändert sich ja auch dessen Position. Wie wird das in RTKNavi gehandhabt?

Vielen Dank noch mal.

Grüße
Daniel

[ssquare_de]

Hallo Daniel,


wenn du die Positionen mit SAPOS und RTKLIB auf RTK-Niveau bestimmst, wird ein aktiviertes SBAS wohl kaum Unterschiede auf Genauigkeit und Zeitdauer bis zum ersten Fix machen.
Speziell bei SAPOS ist ja die Basislinie, wie schon gesagt, optimal kurz.
RTKLIB nimmt ja für seine Berechnungen aus dem ublox-Empfänger nur die Rohdaten (GPS und SBAS) entgegen und verarbeitet die weiter.
Eine von der ublox-Firmware gesteigerte Genauigkeit auf Grund von SBAS-Korrekturen ist nur in den Positionsausgaben des ublox-Moduls zu erwarten, einen Einfluss auf die Rohdaten gbt es - meines Wissens nach - nicht.

"Transmit NMEA GPGGA to Basestation".
Mit SAPOS in Echtzeit habe ich leider noch keine Versuche durchgeführt.
Da musst du selbst testen.
Ich vermute mal, in der Option "Latitude/Longitude" gibts eine bestimmte Maschenweite, wo dann von einer Zelle auf die andere umgeschaltet wird.
Ist ja im Bezug auf die Länge Basislinie eher unkritisch, ob das 1m ist oder 200m...und die Rechenlast im Sapos-Rechner wird gedrückt....
Denk ich mir jedenfalls...


Stefan

[laqup]

Hallo Stefan,

dann werde ich einfach mal unterschiedliche Einstellungen ausprobieren und auswerten. Danke dir.
Sollte es unerwarteterweise doch einen Unterschied bei aktiviertem SBAS geben werde ich das dokumentieren und hier veröffentlichen.

Grüße
Daniel

[ssquare_de]

Hallo Daniel,


ja, Rückmeldung wäre klasse,
nicht nur wegen der SBAS-Sache, sondern auch ganz allgemein, wie das mit SAPOS, Echtzeit und RTKLIB so läuft.
Zu dieser Konfig. weiss ich nämlich praktisch noch nix, ausser, dass es theoretisch ganz gut funktionieren sollte...


Stefan

[laqup]

Hallo an alle,

heute habe ich mir ein wenig Zeit genommen und ein paar Messungen durchgeführt. Die Antenne war auf dem Dach meines Autos platziert und ich habe in unbewegtem Zustand versucht einen Fixed Status zu bekommen und bin dann ein wenig herumgefahren (Auf einem großen unverdeckten Parkplatz). Leider ist das Ergebnis nicht ganz so wie erhofft. In 10 Testreihen konnte ich gerade einmal 3 mal einen Fixed Status produzieren, obwohl die Bedingungen, soweit ich das beurteilen kann, nahezu optimal waren.

Daher zuerst einmal meine Settings:
http://web2.optinet24.de/uploads/settings01.jpg
http://web2.optinet24.de/uploads/settings02.jpg

Hier 3 Logfiles, Logfile 6 zeigt das beste Ergebnis, hier konnte ich einige Zeit mit Fixed Status herumfahren, Logfile 7 ist exemplarisch für die Versuche bei denen ich keinen Fixed Status erreichen konnte und in Logfile 9 habe ich für wenige Sekunden eine Fixed Lösung, die aber, sobald ich mich bewege, wieder auf Float zurückfällt. Die Float Lösung war in Bezug auf die Qualität der Daten allerdings erstaunlich gut. Ich habe versucht ein und dieselbe Position einige male anzufahren und dies ist auch in den Daten wiederzufinden:

http://web2.optinet24.de/uploads/0006.log
http://web2.optinet24.de/uploads/0007.log
http://web2.optinet24.de/uploads/0009.log

Und hier noch zwei Screenshots während des Betriebs mit der typischen Fehlermeldung (ambiguity validation failed):
http://web2.optinet24.de/uploads/result01.jpg
http://web2.optinet24.de/uploads/result02.jpg

Vielleicht habt ihr noch ein paar Tricks auf Lager, wie ich ein besseres Ergebnis erzielen kann. Oder vielleicht könnt ihr anhand der Daten und Screenshots abschätzen, ob es normal ist, dass ich so selten einen Fixed Status erreichen konnte. Danke im Voraus.

Grüße
Daniel

[archie]

hallo Daniel,

Wie gross ist der Parkplatz und stehen vielleicht höhere Bäumen rundum?
du benutzt wahrscheinlich das EVK lea-6t von ublox mit das duza geliferte Antenne. Wenn dem so sind die Resultaten in ordnung.
Mit das mitgelieferte Pachantenne ann-ms sind kaum bessere Ergebnisse möglich.
Um Fix-lösungen zu kriegen mußt du ein richtig gute Antenne haben, am besten ein Novatel oder ein Chokering antenne.
Auch mit der Trimble Bullet III wird es nicht viel besser.

Grüße Pieter

[ssquare_de]

Hallo Daniel, hallo Pieter,



ich hab beispielsweise den "Tatort" von Log7 mal in Google Earth abgebildet:

Log7

Log7.jpg (133.28 KiB) 26862 mal betrachtet

Kurze Erklärung für die noch nicht RTKLIB-Profis:
Die roten Punkte zeigen sogenannte "Stand-Alone"-Lösungen zu Beginn des Logs, darauf die ersten gelben "FLOAT"-Lösungen, auf einer Linie aufgereiht, die Genauigkeit verbessert sich dabei schnell durch Iteration in RTKLIB, dann die erste grüne "FIX"-Lösung, realistische Genauigkeit < 3-5cm, später dann wieder die gelben "FLOATS", die Genauigkeiten bleiben aber ziemlich gut, (kein sprungartiger Versatz in der Trackaufzeichnung).
Man sieht das auch schön an den Stellen, an denen das Fahrzeug zwischenzeitlich angehalten wurde. --> keine grossflächigen Punktwolken, sondern ziemlich gut verdichtet...
Die Genauigkeit scheint soweit in Ordnung zu sein, auch die Floatlösungen streuen bei Fahrzeugstillstand nur um wenige cm.

Wegen den Fix-Lösungen, bzw. der Antenne:
Daniel, kannst du mal ein Bild der auf dem Autodach montierten Antenne hier reinstellen( also komplettes Dach+ Antenne), vielleicht kann man da noch etwas optimieren.

Setting2: probier mal für !deinen speziellen! mobilen Einsatz unter "Elevation to Fix Ambiguity" anstelle von 10° höhere Werte (20-30°)
Dauert vielleicht ein bischen länger für den ersten Fix, der wird dann aber besser gehalten.
--> Horiziontale Genauigkeit verschlechtert sich nur minimal, die Höhenangaben werden nicht mehr ganz so gut
Mit dem Auto kannst du vielleicht noch unter Setting1 "Rec Dynamics" auf "ON" stellen.

Toll wäre, wenn du mir die beiden Input-Streams in RTKLIB, also Basis(SAPOS) und Rover(ublox) zukommen lassen könntest.
Dann kann ich mich damit mal näher auseinandersetzen.

Allgemein zur Qualität von FIX- und Float-Lösungen:
Die Float-Lösungen müssen nicht viel schlechter sein, als die FIX-Lösungen.
Bei einer FIX unter "realistischen" Voraussetzungen kann man sich halt sehr hoher Genauigkeit sicher sein.




Stefan

[laqup]

Hallo an euch beide,

vielen Dank für die Antworten und die tolle Visualisierung.

Da ich den Vergleich mit professionellen Systemen kenne (Genesys ADMA), kann ich sagen: Die Location müsste sich sehr gut für solche Versuche eignen, das angesprochene System verliert dort eigentlich nie die RTK-Lösung. Daher sollten die tatsächlich vorhandenen Bäume eigentlich vernachlässigbar sein. Dass die Antenne dagegen einfach keine besseren Ergebnisse zulässt, klingt einleuchtend. Auch muss ich zugeben, dass der "Einbauort" der Antenne wohl nicht optimal war. Ich habe das gute Stück dank Magnetfuß einfach mittig auf dem Dach platziert. Bei der nächsten Versuchsreihe werde ich die von Stefan erwähnten Settings ausprobieren und die Antenne mit einem Querträger auf der Dachreling befestigen. Vielleicht gelingt es mir sogar eine hochwertige Antenne zum Vergleich heranzuziehen, dies wird aber wohl erst wieder nächste Woche möglich sein.

Leider habe ich vergessen die Rohdaten aufzuzeichnen, daher kann ich keine Logfiles dazu anbieten, dies werde ich ebenfalls in der neuen Messreihe berücksichtigen.

Euren Ausführungen entnehme ich weiterhin, dass die Nachrichten unter "Error/Warnings" (ambiguity validation failed) also auch ganz normal sind. Ich werde euch auf dem Laufenden halten, sobald ich neue Messwerte zur Verfügung habe, diesmal auch mit Rohdatenstreams.

Grüße
Daniel

[ssquare_de]

Hallo Daniel,


der Versuchsort ist ziemlich gut, das kann man schön in Google Earth abschätzen.
Tja, das von dir benannte Referenzsystem spielt natürlich mit seinem 2-Frequenzempfänger (vielleicht sogar mit angepasster Firmware) , viel besseren Antenne und Auswertesoftware auch in einer ganz anderen Liga.

Die Darstellung der Lösung in Google Earth geht mit den in RTKLIB enthaltenen Bordmitteln ziemlich easy und fix:

Ich habe deine oben verlinkte Logdatei im Textformat abgespeichert, in RTKLIB das Postprozessingprogramm "RTKPOST.EXE" (RTKPOST_mkl.EXE läuft auf den meisten Rechnern ebenso) gestartet
-> darin den "To KML"- Button klicken und im darauf sich öffnenden Converter mit dem "..."-Button den Pfad zur Logdatei von oben eintragen...fertig!
Ist Google Earth auch auf dem Rechner installiert, nur noch einen Klick auf den Button unten links...und schon ist man im Bilde...

Wenn du das nächste Mal beide Input-Streams loggst, kannst du die daheim ins Postprozessing-Programm einlesen lassen und so sehr bequem mit verschiedenen Einstellungen probieren und diese optimieren....
Du kannst praktischerweise mit beiden geloggten Streams und RTKPOST in beliebig vielen Durchgängen die optimalen Einstellungen für die Echtzeitanwendung RTKNAVI ermitteln...


Stefan

P.S. hatte dein Versuchsauto metallene Relingträger und die Antenne sass da dazwischen ?
Das könnte schon für böse Multipath-Effekte sorgen, die LowCost-Antennen sind sehr anfällig dafür, gute ( und damit meist auch um einiges teuerere ) Antennen können diese Störungen viel besser ausgleichen.

[laqup]

Hallo Stefan,

das sind super wertvolle Informationen die du hier lieferst. Danke dir. Dann steht der Suche nach den optimalen Settings inklusive anschließender Visualisierung ja nichts mehr im Wege.

Und ja du hast Recht, die Antenne saß mittig zwischen den Relingträgern, wobei diese nicht sonderlich hoch sind. Aber ich werde es sicherheitshalber noch einmal mit Querträger probieren.

Grüße
Daniel