Rohdaten-Anwendungen mit dem NVS NV08C-CSM

[ssquare_de]

Hallo Josef,



damit hast du das angehängte PDF gut zusammengefasst!
( Punkt 4, "Möglichkeiten zur Reduzierung des Mehrwegeeinflusses" )

http://dgk.badw.de/fileadmin/docs/c-665.pdf


Stefan

[B14]

Täglich 0,1 Milliardstel Sekunde????

Hmm, das Licht legt in der Zeit wohl eine Strecke zurück (~3cm, wenn ich nichts falsch gerechnet habe), die wir hier als Ungenauigkeit berücksichtigen sollten. In Wettzell geht es um den Millimeter/Zentimeterbereich. Lassen wir es jetzt aber lieber, mit dem NVS hat das jetzt wirklich nichts mehr zu tun

Gruss
Bernd

[B14]

Hallo zusammen,

ich möchte hier wieder mal über meine Erfahrungen mit dem NVS-Empfänger und der TW2410-Antenne berichten. Meine bisherigen Erfahrungen im statischen RTK-Betrieb waren ja sehr positiv. Diesmal wollte ich die Möglichkeiten im dynamischen RTK-Bereich testen. Hierzu habe ich diverse Empfänger gleichzeitig bei einer Autofahrt mitschreiben lassen. Die Strecke führte durch urbane und bewaldete Bereiche. Die TW2410 war auf dem Autodach angebracht und hatte dadurch leichte Vorteile gegenüber den anderen Empfängern, die sich mit einem Platz hinter der Windschutzscheibe begnügen mussten. Die Tracks der folgenden Systeme sind im Bild (copyright http://vermessung.bayern.de/) dargestellt:

grün, 860E, MTK32, extrem kleiner Logger (GPS)
braun, NVS/TW, NV08C-CSM, Kinematic RTKLIB (GPS/Glonass) Base ERLA
türkis, NVS/TW, NV08C-CSM, Single RTKLIB (GPS/Glonass)
lila, Galaxy S3, BCM47511, Smartphone (GPS/Glonass)
rosa, Vista HCx, MTK32, Garmin Outdoor (GPS)
blau, WBT202, Ublox5, Wintec GPS Mouse/Logger (GPS)

GPS_Tracks.png (103.92 KiB) 30574 mal betrachtet

Man kann erkennen, dass die NVS-Tracks in bewaldeten Bereichen sehr „zappelig“ werden. Das zusätzliche Glonass und die bessere Antenne (auch Postion) scheinen hier keinen Vorteil zu bringen. Die Ausreiser von der WBT202 bin ich so nicht gewohnt, setzte sie aber auch nur beim Joggen ein, und hier im Auto waren es höhere Geschwindigkeiten. Das Samsung Galaxy S3 schneidet „gefühlt“ am besten ab. Das obige Bild zeigt nur einen Teilausschnitt, der wesentlich längeren Fahrt, die nachfolgend dargestellt ist. Überall dort, wo nur Single- und keine Float/Fix-Solutions berechnet werden konnten, waren entweder (große) Häuser oder Wälder. Ähnliches war bei PPP zu beobachten.

RTKLIB_Track.png (8.97 KiB) 30574 mal betrachtet

Wer nähere Infos haben möchte (z.B. Rohdaten oder GPX-Files), kann gerne auf mich zu kommen.

Gruss
Bernd

[Hagen.Felix]

...
Das Samsung Galaxy S3 schneidet „gefühlt“ am besten ab.
...

Hallo Bernd,
zunächst mal vielen Dank für diesen hochinteressanten Test!

Dass insbesondere Samsung bei etlichen seiner Smartphones den GNSS-Empfang inzwischen schon so gut im Griff hat, nimmt man ja schon fast als selbstverständlich wahr, obwohl es natürlich trotzdem noch immer ziemlich sensationell ist.

Ich habe ähnlich hervorragende Ergebnisse auch schon mit einem Galaxy S2 (CSR SirfStarIV) erleben dürfen: in verschiedensten Empfangssituationen eigentlich immer besser als alle aktuellen Garmin-Geräte für den Outdoor-Gebrauch (GPSMAP60CSx, Oregon 550, Montana 650, eTrex 30). Und das trotz winzigstem Gehäuse (mit entsprechender Erschwernis für die Antenneneinrichtung) und sicher primärer Optimierung des GNSS-Systems auf minimalen Energiebedarf.

Aber was die Tracks vom NV08C-CSM mit der TW2410 betrifft, wäre es durchaus noch interessant, wie dessen eigene Positionierung ausgesehen hat.
Hast Du vielleicht auch noch die NMEA-Daten vom zweiten VCP aufgezeichnet?

Ohne es wirklich fundiert begründen zu können, würde ich kinematisches RTK für ein solch typisches Straßenfahrzeug-Tracking wohl nicht favorisieren (schon vom Ansatz her) und somit vermutlich auch selbst gar nicht erst testen, gerade daher ist ein solcher Trackvergleich mal sehr anschaulich!

Eine Frage noch: der zweite Track vom NV08C-CSM war im RTKNAVI von vorn herein auf SINGLE eingestellt? Oder doch kinematisches PPP (mit Broadcast-Daten)?

Was mich bei kinematischen Anwendungen mit dem NV08C-CSM am meisten interessieren würde, wäre ein Szenario, bei dem RTK ohnehin schon gern und gut dabei ist: das möglichst präzise Fahren auf dem Acker nämlich. Zumeist freier Himmel, relativ geringe Geschwindigkeiten und ein wiederholtes Abfahren der gleichen Fahrspuren (zumindest innerhalb einer Vegetationsperiode von der ersten Anlage der Fahrspuren bis zur Ernte).

Habe hierfür bisher leider noch keine Zeit gehabt (und in den vergangenen Wochen noch nicht mal mehr die nötige Hardware, da ich zwischenzeitlich mit dem "Denga10" regelrecht ausverkauft war), will das aber bei nächstbester Gelegenheit unbedingt mal realisieren! Natürlich jetzt im Spätherbst erst mal noch ohne Fahrspuren, und es muss ja auch nicht wirklich ein echter Acker sein, aber eben doch eine möglichst langsame (10 bis max. 20 km/h) Geradeausfahrt mit entsprechenden Vorgewende-Kehren (gleichmäßige enge 90°-Kurven) unter freien Himmel.

Da will ich dann schon mal sehen, wie sich RTK und Realtime-PPP (jeweils mit RTKNAVI, bei RTK möglichst mit einer hochgenauen VRS, bei PPP dann hoffentlich auch schon mit EGNOS-Daten) im Vergleich mit anderen Empfängern sehen lassen können. Als Vergleichsobjekt bei den Low-Cost-L1-Rohdatenempfängern würde ich dann wohl am liebsten einen LEA-6T von u-blox nehmen wollen, da dieser in solcherlei Anwendungen eben doch schon sehr oft erprobt wurde. Selbstverständlich sollten dann auch identische Antennen in identischer Montage am Fahrzeug verwendet werden. Mal sehen, vielleicht kann ich in einen solchen Test auch noch ein Zweifrequenz-RTK mit hinzunehmen.

Was jedoch die von Dir gezeigte Anwendung (Straßenfahrzeug in üblicher Geschwindigkeit durch Stadt, Wald und Flur) betrifft: Könnte vielleicht mal jemand einen Hinweis dazu geben, ob die Nutzung von Trägerphasen-Messungen hier überhaupt noch vorteilhaft sein kann bzw. sollte (sozusagen in grundsätzlicher Hinsicht)?

Viele Grüße aus Grimma,
Hagen

P.S.: Habe inzwischen wieder Hardware mit dem NV08C-CSM bei mir zur Verfügung und werde meine Beitragsreihe zur Verwendung mit RTKNAVI ("MB_mod") schnellstmöglich wieder fortsetzen. Großes Indianer-Ehrenwort!

[ssquare_de]

Hallo Bernd,

ja, vielen Dank, sehr interessant!

Zufälligerweise habe ich vor einiger Zeit ein vergleichbares kinematisches Log-File mit einem NEO-6P angefertigt.
Antenne war die N60XAM von REEL auf einem Alurohr mit 70mm Groundplane.
Jedoch war im NEO-6P als dynamische Plattform "nur" "Pedestrian" eingestellt.
In manchen Kurven sieht man das. ( Kalmanfilter fehlts an Dynamik!)

Zudem weist die Basislinie nach Wettzell eine schon sehr grenzwertige Länge mit >50km auf!

Ich hänge mal 2 .kml-Files an,
NEO-6P.kml repräsentiert die Ausgabe des autonomen NEO-6Ps,
RTKLIB.kml stellt die postprozessierte Lösung der gleichen Log-aufzeichnung dar.

Visualisieren könnt ihr beide Files natürlich in GoogleEarth,
oder, viel genauer, da das Karten/Luftbildmaterial viel besser georeferenziert ist, im BayernViewer:
http://geoportal.bayern.de/bayernatlas/?
Dort zuerst oben links den "EXPERT-Modus" auswählen, dann in einem zweiten und dritten Schritt die beiden .kml-Files hochladen...

NEO-6P.kml

(67.54 KiB) 889-mal heruntergeladen

RTKLIB.kml

(375.93 KiB) 873-mal heruntergeladen

Schaut euch die Waldstücke an, da liefert die autonome Lösung auch viel bessere, da ruhigere Ergebnisse als die postprozessierte Lösung mit RTKLIB.
Das ist bei den ublox-Empfängern immer so, da die Firmware speziell in suboptimalen Empfangssituationen auf viel ausgeklügeltere Algorithmen zurückgreift, als die RTKLIB-Lösung bieten kann.
Aber kaum herrscht einigermassen freie Sicht, kann man mit RTKLIB wunderbar überprüfen, wie gut (genau) der autonome NEO den Track in die Landschaft legt...

Bernd, der Hagen hat schon darum gebeten: bitte stelle auch die autonome Lösung hier ein, die der NVS ausspuckt.
Ich wette fast, die ist auch um einiges besser!

Hagen, wegen den kinematischen RTK-Anwendungen mit RTKLIB auf freiem Feld musst du dir kaum Sorgen machen, die liegen beim ublox sehr genau, und der NVS wird das Spielchen mit einiger Sicherheit mindestens gleichwertig beherrschen.
Und du hast Recht:
in professionellen Lösungen für dynamische Anwendungen werden die Multi-GNSS-Systeme(L1/L2) auch und gerade immer von zusätzlichen Sensoren (Trägheitsnavigation) unterstützt.
http://www.racelogic.co.uk/

Stefan

[Deichgraf]

@ Stefan,
... im 2. Track sind vor der 1. Autobahnunterführung 2 rote Trackpunkte?
Eigentlich hätte der Track gerade in die Unterführung führen und der Knick dann nach der Unterführung erfolgen müssen, wie beim 1. Track.

[ssquare_de]

Hallo Deichgraf,

ja, stimmt so, wie du es sagst.
Eigentlich hätten die beiden roten Trackpunkte ja irgendwo unter der Unterführung gesetzt werden müssen.
Rot steht dafür, dass RTKLIB keine differentielle Lösung in Verbindung mit den Daten der Referenzstation Wettzell berechnen kann.
Dann werden ausschliesslich die Rohdaten des NEO-6P für die Positionsberechnung herangezogen.
Intern im NEO-6P-Modul durchlaufen diese Rohdaten ja dann noch die Navigationsengine, die Multipathauswirkungen, Signalstärkeneinbrüche und komplette Signalausfälle einiger Sats berücksichtigen kann.
Zudem hat die Navigationsengine ja auch noch den Kalman-Filter zur Hand, der qualitätsverbessernd wirksam wird...

Ich habe mal die entsprechende Stelle aus dem Lösungsfile, das RTKLIB berechnet hat, herausgesucht, und als Textfile hier reingestellt:

RTKLIB.txt

(3.38 KiB) 918-mal heruntergeladen

Die beiden Einträge "5" in der "Qualitätsspalte Q" stellen die beiden roten Trackpunkte dar, die vor der Einfahrt in die Unterführung geplottet wurden.
Achtet man auf die Zeitstempel im Textfile, stellt man fest, dass sich RTKLIB nach dem zweiten roten Trackpunkt von 13:53:20.000 Uhr bis 13:53:24.000 Uhr eine Auszeit genommen hat, um sich wieder zu berappeln
und die nächste Positionsberechnung vorzunehmen.
Sieht man auch schön im Track-Plot, wo nach dem zweiten roten Trackpoint eine kleine Lücke bis zum nächsten Trackpunkt klafft...

Ich müsste jetzt im ublox-Log nachsehen, was der Empfänger in dieser Zeitspanne genau gemacht hat, aber Positionen hat er sicherlich berechnet und auch ausgegeben.
Nur werden die Signalstärken und die Signalqualität der empfangenen Sats in diesen Momenten mit einiger Wahrscheinlichkeit RTKLIBs Eingangshürden gerissen haben (Cycle slips, Signalstärke...) und sind somit von einer Auswertung ausgeschlossen worden.


Sorry für den OT hier, aber vielleicht hilft es den RTKLIB-Interessierten und -Anwendern, den Informationsgewinn aus RTKLIB zu steigern?


Stefan

[B14]

Aber was die Tracks vom NV08C-CSM mit der TW2410 betrifft, wäre es durchaus noch interessant, wie dessen eigene Positionierung ausgesehen hat.
Hast Du vielleicht auch noch die NMEA-Daten vom zweiten VCP aufgezeichnet?

Nein leider nicht, deswegen habe ich den Aufwand Gestern nochmal betrieben. Es hat sicher aber gelohnt.

Ohne es wirklich fundiert begründen zu können, würde ich kinematisches RTK für ein solch typisches Straßenfahrzeug-Tracking wohl nicht favorisieren (schon vom Ansatz her) und somit vermutlich auch selbst gar nicht erst testen, gerade daher ist ein solcher Trackvergleich mal sehr anschaulich!

Sehe ich auch so. Bei höheren Geschwindigkeiten (über ~15 km/h) oder bewaldeten (gibt es so ein Wort überhaupt?) Gebieten, sollte man überlegen, ob RTK ohne zusätzliche kinematische Sensoren überhaupt Sinn macht.

Eine Frage noch: der zweite Track vom NV08C-CSM war im RTKNAVI von vorn herein auf SINGLE eingestellt? Oder doch kinematisches PPP (mit Broadcast-Daten)?

Ich habe RTKLIB auch mit dynamischen PPP und genauen SP3-Daten rechnen lassen. Das Ergebnis war auch nicht besser.

Aber nun zu meiner neuen Auswertung (siehe nachfolgendes Bild). Ich habe vom NVS über den zweiten Port die NMEA-Daten ausgeben lassen. Mein erschüttertes Weltbild ist jetzt wieder in Ordnung gebracht worden. Die zusätzlichen Glonass-SATs, die sehr gute Antenne TW2410 und deren optimale Position in der Mitte des Fahrzeugdaches, haben einen Track erzeugt, den ich in so einer Qualität bisher noch nicht aufgezeichnet habe. Die NVS internen Algorithmen leisten also eine sehr anständige Arbeit.

Gruss
Bernd

NVS_Track.png (100.63 KiB) 30574 mal betrachtet

[Hagen.Felix]

...
Die NVS internen Algorithmen leisten also eine sehr anständige Arbeit.
...

Das ist ja wie gemalt!

Aber es wird schon seinen Grund haben, dass Panasonic für seine Toughbooks jetzt NVS als Lieferanten der GNSS-Module auserkoren hat ...

Und sicher wird die TW2410 auch ihren Anteil haben. Michele hat mir mal ein paar Diagramme gesendet mit den Daten einer Vergleichsmessung zwischen Patchantenne "Marke superbillig", der TW2400 (quasi gleich wie TW2410, braucht nur ein paar Volt mehr Versorgungsspannung) und einer High-End "Survey" Antenne (siehe https://www.optimalsystem.de/os/docs/Ta ... Report.pdf). Davon war ich schon ähnlich beeindruckt ...

P.S.: Hat jemand vielleicht eine Idee, was das Kürzel "etalon" (steht für eben die o.g. High-End-Antenne) in diesen Diagrammen bzw. in diesem Zusammenhang bedeuten könnte?

[B14]

P.S.: Hat jemand vielleicht eine Idee, was das Kürzel "etalon" (steht für eben die o.g. High-End-Antenne) in diesen Diagrammen bzw. in diesem Zusammenhang bedeuten könnte?

Hagen,

war Deine Frage echt ernst gemeint ? Das Institut liegt bei mir um die Ecke

http://www.iis.fraunhofer.de/content/da ... 101825.pdf

Gruss
Bernd

[ssquare_de]

Hallo Bernd,

na, das ist doch mal eine Spitzentrackaufzeichnung.
Prima, anscheinend ohne Fehl u. Tadel!

Antennenmontage am Auto:
Die Montage per Magnetbefestigung in der achsensymmetrischen Mitte des Daches ist superschnell und von der Empfangsleistung her sehr gut.
Ich habe keine belastbaren Vergleichsmessungen durchgeführt, aber rein vom Gefühl her ist die Montage auf der zur jeweiligen Patchantenne optimal grossen Groundplane (hier 100mm Durchm.) noch einen Hauch besser.
Dach, Distanz(stück ( ca. 5-10cm)), Groundplane, Antenne
In der Praxis würde also die Groundplanemontage samt Antenne auf einer Traverse erfolgen, die z.B. eine Dachreling überspannt.

---> Jedoch oft mühsame Montage!
Und deswegen vermutlich kaum den Mehraufwand wert...


Hagen, das "etalon" steht einfach für "Referenzantenne", Mass aller Dinge...
http://de.wikipedia.org/wiki/Ma%C3%9Fverk%C3%B6rperung



Stefan

[B14]

Wie bereits von Michele und Hagen kommuniziert, wird das NVS Protokoll jetzt offiziell von RTKLIB 2.4.2 b3 unterstützt.

Gruss
Bernd

[B14]

Hallo,

ich wollte wieder berichten, nachdem ich jetzt auch mal in freier Wildbahn einen mir genau bekannten topografischen Punkt aufgesucht habe, den ich mit dem NVS und der TW2410 untersuchen wollte (den musste ich erst wieder mit Spaten und Kelle freistellen). Erstellt habe ich die Koordinate mit RTKLIB 2.4.1, im Static-Mode mit High-Rates der GREF-Station ERLA und Ultra-Rapid SP3´s. Gemessen habe ich ca. 3 Stunden. Den Messaufbau mit der über Stativ fixierten und in ca. 3 Metern Höhe angebrachten Antenne kann man den folgenden Bildern entnehmen.

stativ.jpg (17.81 KiB) 30545 mal betrachtet

Details.jpg (29.19 KiB) 30545 mal betrachtet

Das reine Ergebnis ohne Bezug zum offiziellen Referenzpunkt ist schon beeindruckend. Nach ca. 15 Minuten wechselt die FLOAT- in eine FIX-Solution und das bleibt fast durchgängig so. Anbei der Groundtrack ohne die erste Stunde des Einschwingvorgangs. Es muss noch erwähnt werden, dass die Lage des topografischen Punktes ideal für GNSS-Messungen ist, weil es sehr gute Sicht zum freien Himmel gibt und auch sonst Multipath kaum eine Rolle spielen sollte.

GroundTrack.jpg (21.17 KiB) 30545 mal betrachtet

Der Vergleich mit den mir vorliegenden offiziellen Daten des Vermessungsamtes Nürnberg/Hersbruck hat mich dann noch weiter beeindruckt. Die Differenzen liegen in der East-Komponente bei 0,01X Metern und im North-Wert bei 0,00X Metern. Die Millimeterwerte machen bei solchen kurzen Messzeiten und den Messaufbauten (z.B. exakte Mastausrichtung mit Wasserwage und Bosch-Quigo-Laser, bei 3 Meter Masthöhe) auch keinen Sinn.

Endlich konnte ich mit einem L1-System ohne die Wirren der Koordinatentransformationsprobleme (WGS84, ETRS89, ITRF2008, IGS…, GK gibt’s ja immer noch) eine Solution im Zentimeterbereich mit Messzeiten von 2-3 Stunden bestätigt errechnen. GLONASS war dabei übrigens nicht hilfreich, sondern nur hinderlich (mag bei PPP anders sein).

Gruss
Bernd

[cr2_gps]

Hallo Bernd,
Du sagst nichts über die Höhenbestimmung, wie sieht sie denn aus ?
Ansonsten wird mich die Performance von Bullet III (3.3V Variante) mit 2.65V Versorgungsspannung interessieren,
um die Anschaffung von TW2410 möglichst zu vermeiden.

GLONASS war dabei übrigens nicht hilfreich, sondern nur hinderlich (mag bei PPP anders sein).

Das wird den lupenreinen Demokraten nicht gefallen

[Hagen.Felix]

...

GLONASS war dabei übrigens nicht hilfreich, sondern nur hinderlich (mag bei PPP anders sein).

Das wird den lupenreinen Demokraten nicht gefallen

Das entspricht allerdings auch meinen Erfahrungen bisher.

Wenn nicht gerade "Satelliten-Knappheit" herrscht, habe ich schon manchmal durch Abschalten von GLONASS im RTKNAVI einen etwas schnelleren und/oder stabileren Fix erreichen können.

Dieses Urteil kehrt sich jedoch ins völlige Gegenteil um, wenn nur wenige GPS-Satelliten nutzbar sind bzw. insbesondere dann, wenn bei sehr schlechten Empfangsbedingungen (z.B. Multipath bei viel Nässe) die Verwendung der relativ einfachen Antennen für RTK nur noch mit einer starken Erhöhung der Elevationsmaske möglich ist.

Dann ging es mit nur GPS schon mal auf 4-5 Sats zurück, während es mit GLONASS dazu eben doch noch die doppelte Anzahl war ...

Viele Grüße,
Hagen