Ursachenforschung Ergebnisfehler bei Postprocessing

[holgi63]

Ursachenforschung Ergebnisfehler bei Postprocessing

Vorab:
Ein großes Hallo an die Gemeinde in diesem Forum.
Als Neuer möchte ich mich kurz vorstellen.
Mein Name ist Holger, ich wohne in Oberhessen am Nordwestrand des Vogelsberges zwischen Gießen, Bad Hersfeld und Fulda auf ziemlich genau 250m Höhe in einem winzigen Dörfchen mit weniger als 100 Einwohner.

Ausgelöst durch ein externes Ereignis befasse ich mich seit einigen Wochen ein wenig intensiver mit dem Thema GNSS und bin auf der Suche nach Ergebnissen im Subdezimeterbereich.

Auf dem Weg dorthin habe ich derzeit ein recht brauchbares Arsenal an eigenen und leihweise zur Verfügung gestellten Empfängern, darunter ein Hemisphere Crescent, zwei Hemisphere miniEclipse, zwei u-blox Neo-6P, sowie nur für Vergleich und Dokumentation – quasi außer Konkurrenz betrieben – mein „altes“ eTrex H (das ich sehr schätze) und einen Evermore GM-R900 mit Sirf III Star, der allerdings – warum auch immer - nicht in den EGNOS-Betrieb zu zwingen ist - und den ich deshalb gar nicht leiden kann...

Das Thema:
Aktuell befasse ich mich mit dem Thema der Nachbearbeitung, also dem Postprocessing.
Da ich mich einer Technologie immer erst mal gern von unten nähere, erfolgt das mit folgender Ausstattung:

- Datenaufnahme: Empfänger: Neo-6P Antenne: Tallysman TW2010
- Software Aufnahme: U-Center 6.21 auf PC mit XP-SP3,
- Software Konvertierung in RINEX: RTKLIB 2.4.1,
- Software Postprocessing: Ashtech GNSS Solutions 3.71.1

Postprocessing erst mal über die frei verfügbaren Referenzstationen ffmj, ptbb, titz und leij (bis auf Frankfurt leider alle nahezu 200km bzw. sogar etwas weiter entfernt).
Messung erfolgt unter nicht sehr günstigen Verhältnissen, innerorts, Antenne 3m vom Haus entfernt (Haus relativ hoch, Firstrichtung etwa „halb 2 Uhr“, Messung östlich des Hauses, dadurch aber freie Sicht auf 3 EGNOS-Sats, ausreichend NAVSTAR-Sats (meist zwischen 7 bis 10) und beide Messzyklen D-GPS-fix. Uhrzeit der Messungen nachmittags um 17:00 bis 18:00 Uhr, also kein nennenswerter HDOP.

Das Problem:
2 an identischer Stelle an zwei aufeinanderfolgenden Tagen aufgenommene Punktwolken wurden am jeweiligen Folgetag über GNSS postprozessiert. Das Ergebnis des ersten PP lautete auf eine Unsicherheit von ca. +/-0,5m, das des Folgetages auf +/-0,3m
Aber: Der Ergebnispunkt des ersten PP liegt nahezu 4 Meter vom Ergebnispunkt des zweiten PP entfernt.

Die Frage:
Kann man der Fehlerangabe der (einer) PP-Software vertrauen?

Mir fällt nichts ein, weshalb man das nicht können sollte, denn eine PP-Software hat ja die Aufgabe, am Ende eine Fehlerwahrscheinlichkeit auszuspucken, der man dann vertrauen kann.
Mit steigender Entfernung zu den Referenzstationen steigt logischerweise der Fehlerradius, aber es gibt keinen mir erkennbaren Grund über diesen Fehlerradius hinaus, der innnerhalb der PP-Software zu suchen sein sollte.

Wenn das so ist, dann dürften die Ergebnispunkte aber nur max. 0,8m auseinanderliegen, mit hoher Wahrscheinlichkeit aber eher um 0,5m.

Wenn die Ergebnispunkte hier aber tatsächlich 4m voneinander abweichen, dann muss die Ursache nach meinem derzeitigen Kenntnisstand außerhalb der Software zu suchen sein...


und dann fällt mir als einzige Ursache Multipath ein.

Was meinen die Fachleute dazu?

FG
Holger

[ssquare_de]

Hallo Holger,


Vorweg:
4m Abweichung ist meiner Meinung nach definitiv zu viel.

Du wirst im Ashtech-Paket sicherlich die Möglichkeit der VRS (virtuellen Referenzstation) genutzt haben, die dann ja in < 5m-10m Abstand von der Roverantenne berechnet wird?
Beide Male exakt den selben Berechnungsweg eingehalten?
Beide Male identische (Koordinaten-) Bezugssysteme?

Mir kommen auch die jeweiligen Unsicherheiten vergleichsweise gross vor, angesichts der doch sehr kurzen Basislinien.
Aber unmöglich ist ja fast nichts...

Multipath ist angesichts des Antennenstandorts sicher ein Thema, aber wie schon gesagt, 4m sind heftig, eigentlich zu heftig.


Stefan

[holgi63]

Hallo Stefan,

Danke für Deinen Beitrag!
Die Messungen wurden ohne VRS gemacht und einer der beiden Messzyklen war auch wahrscheinlich etwas zu kurz, nur einige Minuten.
Grund für den Verzicht auf VRS war, dass der kurze Messzyklus keinen ausreichend entfernten VRS-Stützpunkt definieren konnte. VRS und Messpunkt waren zu dicht beieinander. Inzwischen habe ich gelernt, dass das an dem zu kurzen Messzyklus lag.

Die zweite Messung hingegen sollte mit 17 Minuten lange genug sein.
Heute werde ich noch mal eine weitere Messung machen, die etwa die gleiche Dauer hat.
Für präziseste Ergebnisse sind Messzyklen von einer Stunde sicher besser, aber bei 15 Minuten darf keine Abweichung von 4m herauskommen, auch keine Abweichung, die größer ist, als die Summe der beiden postprozessierten Fehlerradien.

Dann werde ich auch beide Messungen mal mit und mal ohne VRS machen. Melde mich, sobald die Ergebnisse da sind.

Alles andere war so, wie Du schreibst, gleiche Referenzstationen, gleiches Bezugssystem, exakt gleicher Ort der Antenne (+/-2cm).

Morgen weiß ich mehr!

FG
Holger

[ssquare_de]

Hallo Holger,


als Daumenregel kann man rund 10-15min. Beobachtungsdauer für L1-Empfänger ansetzen, bis unter vergleichsweise guten Umständen (Antennenqualität, Antennenmontage, Antennenstandort, Basislinienlänge...) mit einiger Sicherheit die Mehrdeutigkeiten korrekt festgelegt werden. (Fixed Solution)
Das Ergebnis liegt dann in Zentimetergenauigkeit vor. (relativ zur Basisstation!)

Verkürzt wird die Initialisierungszeitspanne besonders auch durch möglichst viele von Basis u. Rover gleichzeitig beobachteten Sats.
--> Rein rechnerisch/theoretisch sind mit 11-12 "guten" (qualitativ einwandfreie Trägerphasenmessungen ohne cycle slips ) Sats auch bei L1-Empfängern "sofort" (innerhalb wenige Sekunden!) Zentimetergenauigkeiten möglich.
DER grosse Vorteil der Multi-GNSS-L1-Empfänger, die neben GPS auch GLONASS nutzen können.

Fertige also mindestens 20 min.-Logs an.
Du kannst ja für deine Versuche dann auch im nachhinein die Beobachtungszeiten beschneiden.


Stefan

[holgi63]

Hallo Stefan, hallo die Anderen,

um den Thread abzuschließen: der Fehler ist gefunden. Die Software gibt zwei Positionen aus, nur eine davon ist richtig.

Ashtech GNSS Solutions besitzt zwei (eigentlich sogar drei) Wege, eine Referenzstation in ein PostProcessing einzubinden:
1.)
Holen des Rover-RINEX, sofortiges "Addieren" des BASE-RINEX via Internet (IGS-Station) , beides importieren = Richtige Positionsdaten der BASE-Station
2.)
Holen des Rover-RINEX, importieren desselben und Holen des BASE-RINEX via Internet (IGS) über die linke Spalte = Richtige Positionsdaten der BASE-Station
3.)
Holen des Rover-RINEX, importieren desselben und Holen des BASE-RINEX via Internet (IGS) über den Vermessungsbildschirm durch Doppelklick auf den Icon der Base-Station = Falsches Ergebnis! (Ca. 2m versetzt, daher für Präzisions-PostProc. nicht zu gebrauchen).

Die Begründung vom Hersteller ist :

Dear Sir,

In fact there are two ways to download reference station through Gnss Solution.
In the case where you are creating a new project and then download Raw data from Internet you will read the position header of the Rinex file which in approximate position, so it can be few meters from the real position. In that case you have to enter the known position of the control point.
In the other case, by double clicking directly on the station (triangle icon on the Survey View workspace) you will read the real position of the reference station according to station list file ( C:\Program Files (x86)\GNSS Solutions\RefStations) which is written in the ITRF system.

Best Regards

Fakt ist, dass ein Postprocessing mit Methode 1 und 2 zu stimmigen Ergebnissen führt, Methode 3 liegt daneben.
Probiert es selber aus.

FG
Holger