c099-f9p Versatz

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

Moderator: Roland

Antworten
asui
Beiträge: 3
Registriert: 21.08.2020 - 12:08

c099-f9p Versatz

Beitrag von asui » 28.08.2020 - 23:53

Hallo zusammen,
bin neu hier im Forum und auch neu in der gesamten Thematik.
Euer Forum hat mir bei meiner Re­cher­che bereits extrem geholfen (schon paar Monate her) & ich hoffe, dass ihr mir auch jetzt weiterhelfen koennt.

Fuer die Vermessung von Baustellen stand ich ploetzlich vor der Anforderung, verschiedene Einmaßpunkte digital zu erfassen.
Als Referenzgeraet wurde mir ein Leica gezeigt, welches jedoch ~15.000 Euro kostet.
Im Forum wurde dagegen der U-Blox F9P Receiver als Hardware der Wahl vorgestellt.

Das bisherige Setup ist wie Folgt: ein C099-F9P + SAPOS-HEPS + Android Handy mit dem NTRIP client von lefebure.
Die Inbetriebnahme hat ohne probleme Funktioniert, jedoch ist mir beim Testen aufgefallen, dass die gelieferten Positionen nicht praezise sind.

Dies wurde herausgefunden indem
a) die Positionsangabe des C099-F9P mit einer Positionierung des Leica Referenzgeraetes verglichen wurde:
gemessene Position (F9P mit SAPOS-HEPS)
Gaus-Krueger Rechtswert *63.832521975
Gaus-Krueger Hochwert *99.965220837

Leica-Messung:
Gaus-Krueger Rechtswert *67.179
Gaus-Krueger Hochwert *97.701



b) die Position mit einem staatlichen Vermessungspunkt verglichen wurde (siehe Anhang):
gemessene Position (F9P mit SAPOS-HEPS korrektur)
Gaus-Krueger Rechtswert 3473 461.8103320803
Gaus-Krueger Hochwert 5358 572.732823042
latitude 48.36441002
longitude 8.640878803333333
vermessungspunkt.jpg
vermessungspunkt.jpg (220.5 KiB) 286 mal betrachtet
Die gemessenen GPS-Daten lassen mich darauf schliessen, dass wohl eine falsche GPS-Positionierung geschickt wird & der Fehler nicht in meiner Umrechnung nach Gaus-Krueger liegt?


Nun bin ich extrem Ratlos, woher diese Differenz kommt und wie sie zu beseitigen ist :(.
Vielleicht durch eine andere Konfiguration der Antenne mit u-center?
Koennt ihr mir ein paar Tipps geben, in welche Richtung ich weiter forschen muss, um die gewuenschte Genauigkeit von ~1-2cm in der Lage zu erhalten?

Bisher wurde beim C099-F9P folgendes getan:
1) bootloader flashen: ODIN-W2-BOOT-v0.8.2.bin
1) firmware flashen: ODIN-W26X-SW-7.1.0-020.bin
1) mit S-center die Konfig aufspielen: https://github.com/u-blox/ublox-C099_F9 ... 0Rover.txt
1) Jumper OE3 setzen

Verbindungsaufbau:
1) Android geraet mit C099-F9P koppeln
1) NTIP Client auf Bluetooth empfaenger setzen und ODIN-W2-xxxx waehlen
1) Im NTRIP Client die SAPOS-HEPS Zugangsdaten hinterlegen und Stream waehlen
1) Mock Location aktivieren und NTRIP Client als Mock-Location Application auswaehlen
=> Verbinden und warten bis DGPS ueber FloatingRTK zu RTK wird

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

Re: c099-f9p Versatz

Beitrag von Hagen.Felix » 01.09.2020 - 12:25

Der Stein liegt im DHDN, SAPOS hingegen ist schon europäisiert. :wink:
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)

asui
Beiträge: 3
Registriert: 21.08.2020 - 12:08

Re: c099-f9p Versatz

Beitrag von asui » 03.09.2020 - 19:59

So ganz werd ich aus der Antwort nicht schlau.
Hab mich etwas mit den verschiedenen Bezugssystemen auseinander gesetzt und verschiedene Umrechnungen versucht.
(Da die Daten als Gaus-Kreuger gewuenscht sind & das gebiet von Zone 3 abgedeckt wird, gehe ich von WGS84 und EPSG:31467 aus)

Mir ist schon bewusst, dass die Systeme nicht 1:1 umrechenbar sind, jedoch stelle ich mir die Annaehrungen genauer vor als meine Abweichung.
Weiter unten auf dem Stein sind zum Vergleich auch ETRS89 Koordinaten angegeben.

Wenn die gemessenen WGS84 Daten nach EPSG:31467 (Gaus-krueger Zone 3) umgewandelt werden, sollten diese doch ebenfalls im DHDN liegen?


Zur Umrechnung/Annaeherung nutze ich Proj4 mit folgenden Eigenschaften:
+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +datum=potsdam +units=m +no_defs

Andere Quellen geben fuer die Umrechnung nach EPSG:31467 definieren folgende Eigenschaften (welche schon etwas genauere Werte liefert):
+proj=tmerc +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs


Allerdings bin ich mir immernoch unsicher, ob die gemessenen WGS84 Werte korrekt sind oder es bei der Umrechnung scheitert.
Wenn es lediglich an der Umrechnung scheitert, vermute ich dass der "towgs84" Parameter entsprechend der aktuellen Position angepasst werden muss.
Welches Transformationsgitter muss dann als Grundlage fuer diesen Parameter genutzt werden und woher kann dieses bezogen werden?

Oder bin ich grad voll auf dem Holzweg :? :?:

asui
Beiträge: 3
Registriert: 21.08.2020 - 12:08

Re: c099-f9p Versatz

Beitrag von asui » 04.09.2020 - 22:37

Nach vielen Versuchen und annaehernder Verzweiflung hab ich letztendlich gechecked,
dass die Messung ziemlich gut ist & nur meine Bedienung von Proj4 ziemlich schlecht war.

Die Richtigen parameter um VON wgs84 NACH epsg:31467 zu projezieren sind:
cs2cs -f %.9f +init=epsg:4326 +to +init=epsg:31467

@Hagen: Vielen Dank fuer den schups in die richtige Richtung :)

//Edit: ist auf jedenfall sehr interessant, dass irgendwie jede Bibliothek & verschiedene online Services unterschiedliche Ergebnisse liefern.
cs2cs mit den oben genannten settings kommt zumindest auf das selbe Ergebnis wie das Leica Produkt.

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

Re: c099-f9p Versatz

Beitrag von Hagen.Felix » 17.09.2020 - 12:19

asui hat geschrieben:
04.09.2020 - 22:37
... sehr interessant, dass irgendwie jede Bibliothek & verschiedene online Services unterschiedliche Ergebnisse liefern. ...
Vermutlich dürften in vergangenen Jahren doch etliche Software-Entwickler unter Verwendung von Proj4 (bzw. diverser darauf beruhender Bibliotheken oder Halbfertigprodukte) recht tückische Fallgruben hinterlassen haben, in denen dann ihre nichtsahnend-gutgläubigen Endanwender schließlich in den Genuss der heftigsten Umrechnungsfehler gekommen sind, die man sich nur vorstellen kann ... :shock:

Vielleicht nur einige Dezimeter, vielleicht auch mehrere Meter, nicht selten jedenfalls noch nicht so deutlich weit weg, dass man sich nicht auch irgendeine Fehlmessung der GNSS- bzw. RTK-Hardware selbst vorstellen könnte.

Im Vergleich zu einer solchen Grauzone erscheint es ja geradezu wünschenswert, nach einer Fehltransformation gleich so viele Kilometer daneben zu liegen, dass jedem Beteiligten sofort klar ist, diese Ergebnisse keineswegs verwenden zu dürfen.

Ich selbst bin vor einigen Jahren auch schon mal in dieses Fettnäpfchen gestolpert, als ich noch glaubte, eine "x-beliebige" Proj4-Bibliothek einfach nur mit den EPSG-Zahlen von Start und Ziel der jeweils gewünschten Umrechnung füttern zu müssen ... :roll:

Im Idealfall sollte dies natürlich möglich sein, aber wann ist denn schon mal irgendwas ideal? :wink:

Gleichwohl können wir alle nur dankbar bleiben für eine Welt, in der es solche Geschenke wie RTKLIB oder eben Proj4 gibt, nicht wahr?

Man stelle sich nur mal kurz vor, es gäbe lediglich Endanwender-Softwareprodukte mit komplett geschlossener "Motorhaube" ...
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)

Antworten