TTQV präzises Tracking mit DGPS

Hallo all,

um mit TTQV einen Track mit einer Genauigkeit von ca. 2 Meter aufzuzeichnen ist folgendes erforderlich :idea: :

1. Internetzugang

2. Ein Ntrip-Client
Beispielsweise ist der "GNSS Internet Radio" Client des BKG http://igs.ifag.de/index_ntrip.htm geeignet. Achtung! Für die Datei GNSS.ini sind Schreibrechte erforderlich, andernfalls stürzt die GNSS.exe ab.

3. NTrip-Broadcaster

Momentan steht ein offner Test-Server des BKG in Frankfurt zu Verfügung. Er ist unter der URL http://www.euref-ip.net und Port 2101 zu erreichen. Als Stream bzw. Mountpoint ist "Frankfurt/DGPS/Test" zu verwenden. Ebenfalls ist es möglich sich für akademische und Test-Zwecke beim BKG für das EUREF und/oder IGS-Netz zu registrieren.

4. Ein DGPS-tauglicher Empfänger. Einige Garmin-Handhelds mit serieller Schnittstelle gehören dazu. Ich habe einen Geko 201 an die COM1 eines PC angekoppelt. Dieser Garmin-Empfänger ist in der Lage RTCM - Daten der RTCM-Protikoll 2.1 und 2.3 zu verarbeiten. Die Version 3 des RTCM-Protokolls kann nicht verwendet werden.

5. COM-Port - Splitter.
Nach einem Hinweis aus dem Forum verwende ich XPort. http://curioustech.home.insightbb.com/xport.html Eine hardware-Bastellösung mit eine gesplitteten seriellen Kabel wäre auch möglich. Der COM-Portsplitter ermöglicht das der NTrip-Client gleichzeitig DGPS-Daten an den GPS-Empfänger senden kann, wären TTQV die Positionsdaten aus dem Empfänger erhält. XPort erfordert zur Ausführung Administrator-Rechte, da es als virtueller Treiber funktioniert. Als ersten virtuellen Port habe ich COM2 für den NTrip-Client eingerichtet. Als zweiten virtuellen Port habe COM4 für TTQV eingerichtet. Auf COM5 habe ich zur Kontrolle VisualGPS mitlaufen lassen. Als Schnittstellengeschwindigkeit verwende ich 4800 bps um den Treiber und die Hardware nicht zu sehr zu belasten.

Der Erfolg hat sich eingestellt wenn TTQV "NMEA DIFF OK" anzeigt. Ein Garmin-GPS-Empfänger zeigt mit einem "D" im Status-Balken auf der Satelliten-Seite an, ob er für den jeweiligen Satelliten Korrekturdaten verwendet. Zusätzlich sollte der Fix mit "DIFF" statt mit "3D" oder "2D" bezeichnet sein. Der Geko schätzt die Genauigkeit dann auf 2-3 Meter. Der HDOP-Wert liegt bei guten Empfang bei 1.

Weitere Infos unter http://igs.ifag.de/index_ntrip.htm 8-O

Fragen?

Gruss Joern Weber

Zitat von "wulf"

Hallo,

....die Worte hör ich wohl, allein mir fehlt der Glaube....

Dann probiere es selber, und frage mich hier wenn Du nicht weiter kommst.

Zitat

Warum nicht Egnos, zumal man hier aus dem TESTBED-Stadium wohl heraus ist und der GEKO 201 das können müßte?

1. EGNOS ist immer noch nicht stabiel.

2. EGNOS ist für Luftfahrzeuge konzipiert und nicht für Bodenanwendungen. Die geostationären Satelliten stehen daher zu tief über dem Horizont. Für ein Luftfahrzeug oder in südlichen Breiten ist das weniger ein Problem. In nördlichen Breiten ist EGNOS quasi unbrauchbar. Selbst in unseren mittleren Breiten ist es nicht zuverlässige verfügbar, weder im Wald noch in Strassenschluchten. Das Internet ist inzwischen auch Mobil über GSM/UMTS verfügbar. Es wäre aber dann die nächste Stufe dieses mit einem PDA zu erkunden gibt. Wer wirft den ersten Stein und testet Pathway mit DGPS? Bis jetzt hat mir ein Laptop genügt. Denn würde ich aber nur eingeschränkt als Mobil bezeichnen. Für ernsthafte Anwendungen müsste mindestens ein Tablett PC her.

Zitat von "Joern_Weber"

Der HDOP-Wert liegt bei guten Empfang bei 1.

Zitat

Das bedeutet doch, 60% aller Werte liegen +/- 1m vom ausgegebenem ab, läßt sich dies im dynamischen Betrieb reproduzierbar einhalten?

Ja, solange Internetempfang besteht. Das wiederaufinden von Satelliten nach einer Unterbrechung geht extrem schnell, da DGPS deren exakten Bahndaten ständig anliefert. Ich hatte 100% aller Werte innerhalb eines Meßzyklus von 15 Minuten unterhalb von 2 Meter. Allerdings hatte ich auf völlig freien Empfang geachtet. Eine dynamische Bewegung spielt keine Rolle, solange man sich nicht mit einem schnellen Flieger oder mit einer Rakete bewegt.

Zitat

Es soll ja nicht nur eine Position sondern ein Track auf 2m genau entstehen. Der GEKO 201 mit seiner Einbauantenne dürfte da so seine Schwierigkeiten haben.

Nö eigentlich nicht, wenn man den Geko intelligent lagert. Das Ding ist wetterfest und kann z.B. ausserhalb des Fahrzeuges befestigt werden. Lasse dir was einfallen. Für experientelle Zwecke reichen Kabelbinder aus um das Gerätin geeigneter Haltung am Holm für eines Dachgepäckträger zu befestigen. Ok, für Genauigkeiten besser als 1 Meter braucht man eine exakte Antenne. Die Mini-Antenne des Geko hat aber wegen ihrer geringen Abmessung auch Vorteile.

Gruss Joern Weber

Hallo,

Zitat von "wulf"

..aber leider meistens nicht für alle "getrackten" SVs, wenn doch zuweilen, dann ist der Effekt sehr bemerkenswert.

Bei meinem Geko habe ich inzwischen auch ein stabiles Signal, allerdings fehlen mir auch hin und wieder einzelne SV's. Warum weiß ich noch nicht.

Zitat

Viel weiter werde ich mit der Holux Maus allerdings nicht kommen; ich habe den Eindruck, da ist eine Softwaremacke in der Kalmann-Filterung.

Die Beschaffbarkeit eines Firmwareupdates hast Du sicherlich geprüft?

Gruss Joern Weber

Zitat von "wulf"

Mir scheint, Du beobachtest da die gleichen Erscheinungen wie ich auch:

Gut möglich, ich verwende ein Dachfenster zu Positionieren des Geko.

Zitat

Ich habe da auf dem Fensterbrett liegen eine TomTOm, eine GNS-9810 im NMEA-Modus, ein Garmin II+, eine Nemerix GPS-201, alle ohne SBAS,
und die Holux GM-210 mit SBAS ein oder aus, alle laufen mehr oder weniger gleichzeitig. Die Nemerix trackt 8-9 SV's als Beste, die Holux 3-4 SV's als Schlechteste, die anderen liegen mit 4-6 SV's dazwischen, obwohl das Signal/Rausch-Verhältnis (S/N) mit über 30db für alle GPS durchaus zureichen müßte.
Auch zeigen deutlich sich Mehrwegempfangsprobleme; ein Verschieben um ein paar Zentimeter insbesondere der Holux verändert die "getrackten" Satelliten gravierend.
Mein These: Die Holux hat einen verkürzten Dekodierungsalgorithmus zugunsten der zusätzlichen SBAS-Dekodierung (zu kleines Firmware-Rom?).

Die unterschiedlich programmierten Kalmann-Filter können schon einen Einfluss haben. Senderseitige Probleme, wie ein gesetztes "Don't use" Flag kann ich ausschließen, da ich per SISNET Zugriff auf die Daten habe, mit denen die EGNOS-Satelliten gefüttert werden.

Zitat

Für Dein Garmin dürfte das aber das letztere kaum zutreffen, wohl aber die Multipath-Probleme.

Beim Geko ist der heutige SBAS-Algorithmus auch erst per Software-Update nachgerüstet worden. Die ersten Geko's besassen nur einen primitiven WAAS-Algorithmus ohne Ranging. Allerdings, gehe ich eher davon aus, dass das Problem bei den Filtern zu suchen ist. Allerdings macht mich stutzig, das mir auch auf exponierten Bergen einige SV's fehlen. Ich war vor paar Tagen erst auf dem Wöllaner Nock und konnte dabei auch das Problem beobachten. Eventuell gibt es selbst in exponierten Lagen noch Probleme mit dem Multipath-Empfang.

Einen Multipath-Empfang kann man theoretisch per Software erkennen und ausfiltern. Denn hat man ersteinmal einen provisorischen Fix, kann man aus mehren Paths den kürzesten heraussuchen und dann mit dem provisorischen Fix vergleichen. Genauso ist das Thema Kalmann-Filter noch nicht ausgekocht. Das war lange Zeit ein gut gehütetes Staatsgeheimniss der Supermächte. Technisch zum Durchbruch kam der Kalmann-Algorithmus erst mit den ADSL-Modems Mitte der 90ziger Jahre. Es gab damals massiven Widerstand von Seiten der US-Regierung gegen die Offenlegung dieser Technologie. Genauso stammt von daher die technische Lösung, die Korrelatoren in Hardware zu giessen. Je mehr Korrelationen ein Chipsatz parallel prüfen kann des so schneller ist er. Es kann daher durchaus sein, das der eine Firmware-Hersteller für die GPS-Chipsätze mehr Wissen hat als ein Anderer. Siehe Garmin vs. SIRF und U-Blox.

Zitat

Ich habe seit Wochen mit allen Tricks,aber erfolglos gesucht; Sirf scheint irgendwie vernagelt zu sein.

Selbstverständlich, machen die Chipsätze nur das, wo für sie hergestellt worden sind. Die Hardware ist dabei Peanuts, diese könnte wesentlich mehr als momentan möglich ist. Der wirkliche Wert steckt in der Firmware. Und hier gibt es ganz wenige Leute, die da Zugang haben. Und es gibt massive wirtschaftliche und politische Interessen, dass das weiterhin so bleibt. Es ist aber gut möglich das die USA auf Grund ihrer eigenen Geheimhaltung klassisch auf die Nase fallen und technologisch ins Hintertreffen geraten. Jedenfalls müssen Firmen wie Gamin und Trimble momentan technologisch massiv gegen die Europäer ankämpfen. Alle nenneneswerten Veröffentlichenung im Internet zu Thema Genauigkeitsverbesserung bei Navigatiossystemen stammen aus Europa.

Richtig spannend wird es erst, wenn man selber mit einer eigenen Firmware einsteigen kann. Sowohl der SiRF als auch der Antaris sind dafür vorbereitet. Zumindestens von u-blox, als auch von Leadtek gibt es dafür Developer-Kits. Allerdings werden die dir auch nicht fertige Firmware-Baukästen liefern. Denn im Kern verdienen Firmen wie Trimble nur deswegen ernorme Summen mit den Profi-Geräten, weil sie die Chipsatz-Firmware so aufrüsten, dass sie sowohl die Korrekturdaten im RTCM-Format direkt verarbeiten, als auch die Rohdaten nach Aussen über einen Schnittstelle raus lassen um sie extern verarbeiten zu können. Ich habe aber momentan nicht die Zeit mich intensiver mit dem Thema zu befassen.

Zitat

Stattdessen bin ich gerade dabei, ein U-Blox Modul mit Mikrolöterei aufzurüsten, die Firmware-Situation insgesamt scheint mir hier besser zu sein.

Was gibt es da zu löten. Willst Du den Zeittakt nach aussen ziehen?

Gruss Joern Weber

Hallo Wolfgang,

Zitat von "wollinger"

Hallo,
1. Kann ich das mit meinem Garmin GPS 60 über den USB Port machen? Im Menü des Garmin unter Schnittstelle gibt es zumindest einen Eintrag "Garmin DGPS"

Nein, es ist eine serielle Schnittstelle erforderlich.

Gruss Joern Weber

Zitat von "wollinger"

Hallo,

könntest Du bitte beschreiben wie ich XPort konfigurieren muss? Ich blicke da nicht wirklich durch.

Nicht wirklich, aus der Ferne ist das schlecht machbar. Dem realen Com-Port des Empfängers müssen zwei virtuelle Ports zugewiesen werden.

Gruss Joern Weber

Hallo,

Zitat von "wollinger"

vielleicht auch noch exakt welche Einstellungen im GPS (RTCM Eingang/NMEA Out?) und ob man was in GNSS beachten muss.

Genau "RTMC in/NMEA out" muss verwendet werden. Die Datren müssen im RTMC 2.1 oder 2.3 Format an den Empfänger gesendet werden. RAW oder RTMC 3.0 sind nicht verwendbar.

Gruss Joern Weber

Zitat von "wollinger"

Hallo,
dann hatte ich das meiste schon richtig eingestellt. Das Problem scheint zu sein, dass das GNSS Internet Radio als Info zum Frankfurter Server das Format RAW anzeigt. Dann kann es ja nicht klappen.

Verwende den Server in Prag GOPE0 zum testen und bitte dann das IFAG um einen kostenlosen nichtkommerziellen Zugang zum IGS-Netzwerk.

Gruss Joern Weber

Hallo Wolfgang,

Zitat von "wollinger"

Ist das Endresultat besser wenn ich einen Ortsnahen Server verwende oder senden diese die gleichen Korrekturdaten?

Ja, wegen der ortsbezogenen Korrekturdaten für die Atmosphäre. Um so ortsnäher die Daten des so teurer. Frage mal beim IfaG oder ascos wegen einem kostenlosen Zugang an.

Gruss Joern Weber