Genauigkeit relative Streckenmessung

[Roland]

Hallo Günther,

das verteufelte ist, dass meine Suche zum Tripcomputer außer Garmin-Prospekten nicht viel bringt. Was ich sonst fand, waren Angaben auf Bruchteile von Kilometern oder Miles. Wie läuft die zentimetergenaue Bestimmung ab ?

Nehmen wir die Angabe von 15 ns Synchronisationsgenauigkeit von Jörn zum µ-blox Chipsatz (das Original-Prospekt ziehe ich mir mal).
15 ns ergeben schöne 4,5 m Streckengenauigkeit. Das passt in mein verschwommenes GPS-Bild.

Jetzt müsste jemand mit Erfahrung einhaken.
Wo versteckt sich die Fraktion von der "µ-blox-cm-Genauigkeit" ??

Diese 15ns sind doch eine Art Rauschen. Damit wären zwei Empfänger nie genauer als ein paar Meter zu synchronisieren.

Und auch keine besseren Distanzmessungen zu realisieren. Ausmitteln über 10, 20 Minuten könnte helfen.


Grüße Roland

[Deichgraf]

Hi, Roland,
der Trip-Computer startet nach dem Reset im Feld "Odo-Meter" mit 0.00 m.

Aus dem Grunde werden dann Masseinheiten im Zentimeterbereich angezeigt.
Als ich es ausprobiert habe, war ich selbst sehr erstaunt; sonst habe ich immer nur km gelesen.

Zur Genauigkeit kann ich keine Aussage machen, ich habe lediglich an einem Zollstock die Meterstrecke auf dem Tisch abgefahren. So gesehen ist das Ergebnis frappierend.

Ich vermute, dass der Trackwinkel eine große Rolle bei den Messungen im Tripcomputer spielt, weil beim Vista HCx (MTK) die Angaben relativ schlecht sind, zumindest, wenn sehr niedrige Geschwindigkeiten angefallen sind.

Gruß
Günther

[Jörn Weber]

Hallo Roland,

Hallo Günther,
das verteufelte ist, dass meine Suche zum Tripcomputer außer Garmin-Prospekten nicht viel bringt. Was ich sonst fand, waren Angaben auf Bruchteile von Kilometern oder Miles. Wie läuft die zentimetergenaue Bestimmung ab ?

Nehmen wir die Angabe von 15 ns Synchronisationsgenauigkeit von Jörn zum µ-blox Chipsatz (das Original-Prospekt ziehe ich mir mal).
15 ns ergeben schöne 4,5 m Streckengenauigkeit. Das passt in mein verschwommenes GPS-Bild.

Die 15 ns reichen aus damit zwei Empfänger die gleichen Messbedingungen für die Störgrößen Atmosphäre, Bahndaten usw.haben. Sie sind aber nicht für die Messung selber erforderlich. Die extrem genauen Messung im cm-Bereich erfolgen durch Messung der Phasenverschiebung des Trägers.

Fast alle modernen Chipsätze messen intern in der Regel auch die Phasenverschiebung. Das ist notwendig für die "Static Navigation" der 99EUR-Strassen-Navis, damit, wenn das Fahrzeug an der Ampel steht, die Richtung stabil bleibt. Des Weiteren wird die Phasenmessung auch von der Geräte Firmware der Handhelds ausgelesen. Garmin verwendet z.B.- für seinen Tripcomputer die Phasenverschiebung zur Darstellung der Geschwindigkeit. Für die PhaseTrack12-Chipsätze hat Garmin dazu sogar den Firmware-Befehl dokumentiert, mit dem die Daten an die externe RS232-Schnittstelle gesendet werden. Ich gehen davon aus, das Garmin auch für die SiRFStar3 und MTK eine eigene Chipsatz-Firmware verwendet, welche die Phase-Daten an die Geräte-Firmware sendet. Und ich wette das sich die Ingenieure von Garmin auch eine Hintertür aufgelassen haben, diese Daten an die externe Schnittstelle zu senden. Nur ist diese Hintertür bei den SiRFStar3 und MTK-Geräten von Garmin nicht offen gelegt worden. Wie und unter welchen Umständen der Tripcomputer von Garmin welche Genauigkeit besitzt, ist bisher nicht bekannt.

Gruss Joern Weber

[Deichgraf]

Hi, Joern,
Deine Erklärung ist verständlich, aber warum haben insbesondere die SiRF-III-Geräte die Static Navigation eingeschaltet?

Gruß
Günther

[Jörn Weber]

Hallo Günther,

Hi, Joern,
Deine Erklärung ist verständlich, aber warum haben insbesondere die SiRF-III-Geräte die Static Navigation eingeschaltet?

Die SIRF3 Chipsätze sind vom Hersteller für Strassen-Navis optimiert und werden in fast allen Strassen-Navis verwendet. Deshalb ist die GSW3 Firmware der SIRFStar3 ist per default auf Strassen-Navigation eingestellt. Dazu gehört eben auch Static Navigation. Andernfalls würde sich eine in Fahrtrichtung ausgerichtete Karte an der nächsten Ampel wild im Kreise drehen, da durch die Positions-Drift sich dann ständig die aktuelle Bewegungsrichtung ändern würde.


Gruss Joern Weber

[Roland]

Hallo,


erst dachte ich, dass mit der Phasenmessung auf Massenchips kann doch nicht sein. Ich meine auch "Static Navigation" müsste mit einer einfachen Geschwindigkeitsschwelle zu erzielen sein.

Leica/Trimble/Topcon haben oder hatten doch als Vermessungsempfänger-Produzenten und "Phasenauswerter" extra eigene Chiphersteller ?!
Dann fiel mir ein Linkverweis von s_square wieder ein
http://tu-dresden.de/die_tu_dresden/fak ... vw4906.pdf
Und gleich noch einer mit den drei Chips SiRFIII, u-blox LEA-4T, Fastrax iTrax03
http://www.fig.net/pub/monthly_articles ... wieger.pdf mit der Bestätigung:

"One additional important development has to be noticed: the phase data is part of the internal processing and, in any case for some of the chip set providers, part of the output data too."

Bzgl. des Zugriffs auf Phasendaten heißt es allerdings einschränkend
"SiRFStarIII only with special agreement"

Da staune ich. Tja, das Kowoma-Forum bringt’s


Grüße Roland

[Jörn Weber]

Hallo Roland,

Leica/Trimble/Topcon haben oder hatten doch als Vermessungsempfänger-Produzenten und "Phasenauswerter" extra eigene Chiphersteller ?!

Ja, Motorolas GPS-Sparte mit dem M12M. Die wurden aber inzwischen von SiRF gekauft. Ich liebäugle momentan damit:

http://www.synergy-gps.com/images/stori ... %20v11.pdf
http://www.synergy-gps.com/component/pa ... Itemid,76/

Das Teil liefert DGPS-Korrekturdaten via Motorala-Binary-Protokoll von Hause aus an der RS232 ab, taugt also aus dem Stand heraus für eine Referenzstation. Außerdem funktioniert das Board noch bei -40° und 7,7 g Vibration und 4g Stoßbelastung.

Beim SiRFStar3 kann im laufen Betrieb via SiRFBinary die Firmware nachgeladen und ausgetauscht werden.


Gruss Joern Weber

[ssquare_de]

Hallo Jörn,


ich hab nur schnell drübergeschaut über deinen Favoriten und vielleicht täusche ich mich auch, aber das ist doch das "alte" Motorola-Board?

Die Verwendung als Reference-station ist zwar schön, doch das ganze Empfängerdesign hat schon ein paar Jahre auf dem Buckel. (von 2003 oder 2004, erzielbare Genauigkeiten... )
Mit der Base-Station Funktion fällt mir aus dem Stegreif derzeit nur das Superstar II von Novatel ein...kostet aber...ca. 1KiloDollar "schwer"...
( ohne Base-Station Funktion nur 115Dollar, aber beide Versionen mit Trägerphasenausgabe)
und dann wäre da noch ein sehr leistungsfähiges Board für ca. 250 Dollar
Crescent OEM Module
http://www.hemispheregps.com/BusinessGr ... fault.aspx
Zwei von den Board können sich Korrekturdaten, leider nur in einem propriätärem Format zuschieben, Echtzeitgenauigkeit des Rover so um 25-30 cm.
Diese Funktion muss aber in der Firmware freigeschaltet werden, was das kostet? Keine Ahnung! Da müsste man mal nachfragen.

Oder 2 u-blox-Boards liefern Echtzeitgenauigkeiten im niedrigen cm-Bereich...dazu brauchts dann RTK-Software von Novatel. Und die haut finanziell so richtig rein.
Aber die Hardware ist günstig und die Gesamtlösung ist ready to use...die Software kann die u-blox-Rohdaten direkt in Echtzeit verwerten...
Software-Manual: http://www.novatel.com/Documents/Manual ... 000107.pdf



Stefan
http://www.novatel.com/products/waypoint_rts.htm

[ssquare_de]

Nachtrag:

Aber der Dollar ist ja gerade unterirdisch schwach.


Stefan

[Jörn Weber]

Hallo Stefan,

Mit 2 ns ist die Sysnchronisationsgenauigkeit des M12M deutlich besser als die des LEK-4T mit seinen 15ns. Zudem besitzt das Evalution Board des M12M einen stabileren Ozzilator als das des u-blox. Ok, das Design ist etwas älter, aber nicht veraltet, solange der u-Blox nicht seine Galileo-Tauglichkeit ausspielen kann. Dafür ist das Evalution-Kit des M12M beim derzeitigen Dollar-Kurz bezahlbar und außerdem klimafest, da es für militärische Zwecke ausgelegt ist.

Gruss Joern Weber

[ssquare_de]

Hallo Jörn,


da muss man nun genau darauf achten, wie und für was man die Empfänger einsetzen will:
Nutzt man RTCM für Navigations/Positionierungszwecke, verwendet man ( in der hier angesprochenen Liga u-blox, Garmin, Sirf, Motorola... ) normalerweise nur die Pseudorange-Korrekturen( <5m-Submetergenauigkeiten). Hierbei ist die Synchronisierungsgenauigkeit unkritisch. Das Alter der Korrekturdaten darf mehrer Sekunden bis mehrere 10 Sekunden betragen, bevor die Positionierungsgenauigkeit abfällt.
Ganz anders bei den Phasenkorrekturen. ( Dezimeter/Centimeter/Millimeter-Genauigkeiten ) Da möchte man gerne schon auf der Hardwareseite in den 1ms-Bereich und darunter.
Auf der anderen Seite ist leistungsfähige Postprocessing-oder RTK-Software in der Lage, aus den Rinex-Dateien, und da speziell, Messzeitpunkt, Dopplermesswerte und Phasenmesswerte, von Basis und Rover auf genau gleiche gemeinsame Messzeitpunkte zu interpolieren...
Das heisst: geringe Messzeitpunktdifferenzen ( im niedrigen ms-Bereich ) zwischen Rover und Basis werden von der Software egalisiert. Geringe Differenzen erleichtern der Software natürlich die Arbeit, zum Beispiel sinkt die Beobachtungsdauer, bis die Mehrdeutigkeiten korrekt fixiert werden können, oder/und die Genauigkeit und die Zuverlässigkeit der Lösungen wird erhöht, auch bei vielleicht längeren Basislinien...

Die wirklich sehr guten Timingwerte des gepflegten Motorola kommen, so sehe ich s wenigstens, wirklich nur bei Timingaufgaben zum Tragen...
Aber bedenke: ich bin auch nur ein GPS-Laie, der sich das aus den Fingern saugt...


Stefan

P.S. Auf der u-blox Website
http://www.u-blox.de/customersupport/ublox5_doc.html
sind seit einigen Stunden:-) die Protokoll-Spezifikationen des u-blox5 einzusehen...keine Rohdaten, kein RTCM-Eingang für DGPS-Korrekturdaten......ich hoffe, es liegt noch und nur an der frühzeitigen Veröffentlichung...

[Jörn Weber]

Hallo Stefan,

da muss man nun genau darauf achten, wie und für was man die Empfänger einsetzen will:
Nutzt man RTCM für Navigations/Positionierungszwecke, verwendet man ( in der hier angesprochenen Liga u-blox, Garmin, Sirf, Motorola... ) normalerweise nur die Pseudorange-Korrekturen( <5m-Submetergenauigkeiten). Hierbei ist die Synchronisierungsgenauigkeit unkritisch. Das Alter der Korrekturdaten darf mehrer Sekunden bis mehrere 10 Sekunden betragen, bevor die Positionierungsgenauigkeit abfällt.

Damit bin ich dank deiner Hilfe mit durch. Wenn ich in den Submeterbereich will, brauche ich Phasekorrekturen.

P.S. Auf der u-blox Website
http://www.u-blox.de/customersupport/ublox5_doc.html
sind seit einigen Stunden:-) die Protokoll-Spezifikationen des u-blox5 einzusehen...keine Rohdaten, kein RTCM-Eingang für DGPS-Korrekturdaten......ich hoffe, es liegt noch und nur an der frühzeitigen Veröffentlichung...

Da steht ja auch noch nichts von einem LEK-5T. Schauen wir mal, wann denn der erste marketing getriebene Galileo-taugliche GPS-Receiver auf dem Markt kommt. Denn der wäre damit ja jetzt möglich.


Gruss Joern Weber

[ssquare_de]

Servus Jörn,


...."Wenn ich in den Submeterbereich will, brauche ich Phasekorrekturen. "...
Genau so iss es.
Ich hab mir die Protokoll-Doku deines Favoriten noch nicht reingezogen, aber werden da als Korrekturdaten auch Phasendaten, erstmal egal, ob korrigierte oder unkorrigierte Phasendaten, an der Schnittstelle ausgespuckt?
Kann ich mir nicht vorstellen aber klasse wäre das.
An dem RTCM-Format als solchem liegts nicht, das unterstützt und überträgt auch in den entsprechenden Messages Phasenmesswerte und es gibt Hardware, die das macht, das sind aber die High-End-Geräte, von denen wir nur träumen dürfen...

Na, wenn aber in der u-blox Doku die Rohdaten...garnicht erwähnt werden?!? Das lässt schlimmes befürchten, sollte die Protokolldoku doch für alle Modelle alle Funktionen abdecken, so wie es bislang von u-blox gehandhabt wurde....

Mal sehen, wie sich die Dinge entwickeln.


Stefan

P.S. Wie ( welche Genauigkeit ) sind denn deine bisherigen Versuche geendet ?
So was interessiert mich immer...
Nur ganz kurz, wenn du möchtest...

[Jörn Weber]

...."Wenn ich in den Submeterbereich will, brauche ich Phasekorrekturen. "...
Genau so iss es.
Ich hab mir die Protokoll-Doku deines Favoriten noch nicht reingezogen, aber werden da als Korrekturdaten auch Phasendaten, erstmal egal, ob korrigierte oder unkorrigierte Phasendaten, an der Schnittstelle ausgespuckt?

Ich habe mich erst ein mal nach einer stabilen Zeitbasis umgeschaut und recherchiert, woraus die die professionellen Zeitnormale gebaut werden. Ich kam bisher dabei nicht sehr viel weiter als Du mit dem u-Blox schon recherchiert hattest. Dann schickte mir jemand diesen Link:

http://199.211.133.239/ptti/ptti2002/paper9.pdf

Kann ich mir nicht vorstellen aber klasse wäre das.

Das muss ich mir auch noch mal genauer anschauen, ich habe nur flüchtig etwas von Doppel-Werte im Motorola-Binary gelesen.

http://www.synergy-gps.com/images/stori ... rguide.pdf
[/qoute]

Sollten sich die Phasedaten nicht extrahieren lassen müssen, diese separat ermittelt werden und der M12 dient dann "nur" zu Synchronisation. Das die Langzeitstabilität des u-blox nur zweite Wahl ist sollte ja inzwischen klar sein. Sie dürfte nicht ausreichen um in den Subdezimeterbereich zu kommen.

P.S. Wie ( welche Genauigkeit ) sind denn deine bisherigen Versuche geendet ?

Es gibt zwei Ergebnisse:

1. Geko 201 via RTCM 2.x mit den Korrekturdaten einer BKG Referenzstation ca. 80 km entfernt gefüttert, ergibt ca. 1 m Genauigkeit bei idealen Bedingungen wie voller Rundumsicht, eingeschwungene Filter und so weiter. Die Lösung ist mit einem PDA-Telefon mobil realisierbar. Ähnliches wäre mit Beacon nach IALA-Standart zu erwarten. Daher wäre das eigentlich eine ideale Variante für Consumer-Geräte. Warum zum Teufel hat Garmin seinen 200$ Beacon-Empfänger eingestellt.

1a. Geko 201 mit den via RTCM mit den Korrekturdaten des
EGNOS gefüttert ergibt nur entäuschende 2 Meter Genauigkeit.


2. Postprozessing von RAW-Daten aus dem Garmin-Empfänger, den Referenzdaten von mehren ca. 200-300 km entfernten Referenzstationen und hochgenauen Bahndaten der Satelliten bringt eine Genauigkeit von knapp unter 1 Meter bis 1,5 Meter. Vom Standort Jena aus habe ich die Daten der Referenzstationen in Frankfurt/M, Leipzig, Dresden und Prag via NTrip angezapft und im Rinex-Format aufgezeichnet. Die Bahndaten habe ich ebenfalls vom BKG. Sie lagen auf irgend einem Server der NASA herum. Anschließend habe ich die Daten mit der Magellan-Software verarbeitet. Paar Zentimeter könnte man noch durch Berücksichtigung der EGNOS-Daten am Standort Jena, Antennenkalibration und der unterschiedlichen Wichtung der Referenzstation herausquetschen, aber dazu fehlt die Software. Kernproblem ist sowie so die Software, es hat ewig gedauert bis ich einen auswertbaren zeitlich zusammenpassenden Datensatz zusammen hatte. Wenn jemand eine geeignete Software für einen PDA schreiben würde könnte man daraus sogar eine mobile Lösung machen.

Gruss Joern Weber

[Roland]

Hallo,


mit einem Hinweis auf
http://www.navilock.de/produkte/gruppen ... und_Module kann ich wohl nicht mehr punkten
Denke immer noch, ich werde da mal vorbeischaun. Aber das dachte ich schon voriges Jahr. Und auch nächstes Jahr.

Grüße Roland