Rohdaten-Anwendungen mit dem NVS NV08C-CSM

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

Moderator: Roland

B14
Beiträge: 65
Registriert: 01.05.2010 - 21:22

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von B14 » 21.12.2012 - 19:26

Ich habe nochmal meine bereits beschriebene Messung http://www.kowoma.de/gpsforum/viewtopic ... =15#p15069 eines topografischen Punktes heraus gezogen und mit der neuen RTKLIB B6 durchgerechnet. Den Einschwingvorgang mit der 24 Kilometer entfernten Basisstation möchte ich hier zeigen. Nach ca. 18 Minuten wechselt die Float- in eine FIX-Solution (ich habe Backward gerechnet). Wie lange man mit reinen L1-Empfängern messen muss, um zufriedenstellende Ergebnisse zu erreichen, sollte daraus jeder selbst beurteilen. Ich habe festgestellt, dass man im FIX-Bereich auch noch mit einer gewissen Einschwingzeit rechnen muss, daher lieber etwas länger (min. 1 Stunde).

Gruss
Bernd
Dateianhänge
Einschwingvorgang.jpg
Einschwingvorgang.jpg (42.32 KiB) 24251 mal betrachtet

pawel
Beiträge: 1
Registriert: 19.12.2012 - 13:28

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von pawel » 14.01.2013 - 21:44

B14 hat geschrieben: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:
RTKLIB_Track.png
Wer nähere Infos haben möchte (z.B. Rohdaten oder GPX-Files), kann gerne auf mich zu kommen.

Gruss
Bernd
@B14
Ich würde mich gerne die Rohdaten und GPXFiles anschauen. Ich habe nämlich ein Problem, weil ich die Messdaten (NMEA) aus UBLOX Empfänger in GoogleEarth nicht einlesen kann. Ich überlege wie du das gemacht hast?

cr2_gps
Beiträge: 121
Registriert: 04.10.2011 - 19:18

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von cr2_gps » 08.02.2013 - 22:28

NV08C-CSM wird zum besten RAW-Empfänger, wer hätte das gedacht?
Zitat aus NEO-7_DataSheet_(GPS.G7-HW-11004).pdf :

Code: Alles auswählen

Note, that because of the different center frequencies, GLONASS and GPS signals cannot be received and
tracked simultaneously by u-blox 7 modules.
EVK-7
http://www.u-blox.com/evaluation-tools- ... -kits.html
wird in der Standardkonfiguration auch keine Rawdaten liefern:

Code: Alles auswählen

40.4 RXM-RAW (0x02 0x10)
40.4.1 Raw Measurement Data
Message         RXM-RAW
Description     Raw Measurement Data
Supported on:
· u-blox 7 firmware version 1.00 (only available with raw data product variant)

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

Neuigkeiten zum NVS NV08C-CSM

Beitrag von Hagen.Felix » 05.05.2013 - 08:42

Liebe Forenkollegen und anonyme Leser, :mrgreen:

nur kurz zwischendurch mal ein paar Hinweise auf aktuelle Neuigkeiten zum NVS NV08C-CSM:

Neue Firmware ! Insbesondere auch mit Bezug zur Rohdatenausgabe !!!

Auszug aus dem diesbezüglichen Newsletter von NVS:


Firmware Revision 0206

Release Date: April 22nd, 2013

We are pleased to release the performance improved Firmware v0206 for the NV08C Receiver Series.

Release Note

• Stabilised raw data output for output rates up to 10 Hz
• Extended $POUTC NMEA message, including:
- current LEAP SECONDS value
- flags for expected UTC correction
- PPS edge shift relative to UTC (Sawtooth correction SW)
• Stabilised Sleep mode operation ($POPWR,1111*66) for all NV08C series HW versions
• Increased position accuracy and stability in urban canyon conditions with poor SV visibility
• Cold Start initialised to LEAP SECOND 16 (LEAP SECOND 16 came into effect July 1st, 2012)


Firmware v0206 Update Summary

• Obtain initial receiver coordinates more quickly, in cold starts, low satellite signal (foliage/canopy) and loss of satellite signal conditions (indoor, garages, tunnels...).
• Greater satellite tracking reliability in poor visibility conditions (urban canyon/tall buildings, bridges/underpasses…).
• Stable raw data output up to 10Hz rate.
• Full Sleep mode support for effective power savings.
• Complies with ERA-GLONASS requirements.

Compatibility
Firmware v0206 is compatible with current and preceding hardware revisions of the NV08C receiver series.

Firmware Download
The Firmware v0206 can be downloaded free of charge here.




Unter http://www.nvs-gnss.com/support/firmwar ... mware.html bzw. von dort ausgehend ist alles zu finden, was zum Update benötigt wird.
Zur Vorgehensweise stehen hier in dieser Beitragsreihe schon weiter vorn ein paar Erläuterungen.
Der Vorgang selbst ist relativ simpel und selbsterklärend.
Einziges ernsthaftes Risiko wäre ein physischer oder logischer Verbindungsabbruch direkt beim Flashen.
Also bitte nicht gerade in diesen Sekunden über das Kabel stolpern! :shock:
Und natürlich auch nicht unbedingt eine (USB-)Verbindung (Rechner bzw. Controller, der ggfs. noch zwischengeschaltete Hub, das Kabel selbst usw.) wählen, die vielleicht schon als unzuverlässig bekannt ist. :wink:


Und "last but not least" noch der Hinweis von NVS selbst auf die Verwendungsmöglichkeiten mit der RTKLIB:
http://www.nvs-gnss.com/news/79-rtklib- ... eries.html

Wir hier wissen ja, dass die Verwendung der RTKLIB mit NVS-Empfängern dank der initialen Arbeit von Michele schon etwas länger geht, auch wenn das seitens NVS jetzt so klingt, als wäre dies eine brandheiße Neuigkeit. :lol:

Ach so, ein wenig Eigenwerbung muss aber doch noch sein. :roll:

*LogWi-Ausführungen sind nämlich bereits seit einiger Zeit auch mit NVS-Innenleben verfügbar.

Konkret sind dies Bauformen auf Basis des "Denga10LogWi" (http://www.onetalent-gnss.com/ideas/wir ... nga10logwi), also im Kern das GNSS-Modul NV08C-CSM, eine STM32-MCU, ein MicroSDHC-Speicherkartenhalter, ein Steckplatz für XBee-Module zur seriellen Weiterleitung über Funkverbindungen und der ganze Kram zur autonomen Stromversorgung (Spannungsregler, Ladechip zur korrekten Aufladung eines LiPo-Akkus usw.).

Mit einer Firmware auf der MCU, die nach dem Einschalten primär dazu dient, die jeweiligen Ausgaben der beiden UART-Ausgänge des NV08C-CSM (NMEA und binäres BINR mit den für RTK und/oder PPP notwendigen Trägerphasen-Rohdaten) in einzelne Dateien zu schreiben, wobei das Verzeichnis für diese Dateien und die Dateien selbst aus dem aktuellen Datum benannt werden, welches als UTC aus dem GNSS-Empfang geholt wird. Ein UART wird zudem zum Funkmodul weitergeleitet, sofern sich eines im XBee-Steckplatz befindet (z.B. Bluetooth oder UHF mit 433 oder 868 MHz). Diese Funkverbindung zum NV08C-CSM ist dann auch bidirektional, d.h. es können darüber auch Kommandos an den NV08C-CSM gesendet werden (z.B. zur Konfiguration). Über die USB-Schnittstelle der STM32-MCU wird das FAT32-Dateisystem auf der Speicherkarte als Massenspeicher bereitgestellt, so dass sich die automen Aufzeichnungen des NV08C-CSM dann relativ unkompliziert auf den PC kopieren lassen können, auch wenn das ggfs. ein paar Minütchen dauert (Übertragungsrate pro Sekunde ca. 300-400 KB). Über USB wird auch der LiPo-Akku aufgeladen, der natürlich nicht nur den korrekten Ladechip dazwischen, sondern auch selbst noch die übliche Schutzschaltung gegen Überladung, Tiefentladung und Kurzschluss hat.

Im Detail sind sowohl die PCB-Designs als auch die Spezifikationen der einzelnen Bauteile derzeit noch immer sehr kurzen Versions- bzw. Revisionszyklen unterworfen, d.h. es gibt wirklich zumeist schon immer wieder nach wenigen Wochen weitere Verbesserungen und/oder Erweiterungen, so dass insbesondere die Bilder und Typangaben auf der Website von Michele eigentlich nicht den Festplattenplatz wert sind, auf dem sie geschrieben stehen. :lol:

Aber ganz im Ernst, Michele hat m.W. kaum die Zeit und wohl auch nicht so recht die Lust, jede kleine Änderung immer gleich auf seiner Website zu dokumentieren, und ich selbst habe es leider ja noch gar nicht geschafft, etwas dazu bei mir zu veröffentlichen. :cry:

Momentan ist aber Zeit für so etwas absolute Mangelware, den ich muss noch bis Ende nächster Woche dabei mithelfen, ein tonnenschweres Ungetüm aus Stahl und Starkstromaggregaten auch noch bis zur Halskrause mit Elektronik vollzustopfen, bevor es dann zu Väterchen Zar auf die Reise geht. :wink:

Aber eigentlich sollte es bis zum Sommer wieder etwas besser werden mit der Zeit, so dass ich dann sicher auch mal ein paar Erläuterungen und Abbildungen zu den Geräten auf Basis der Denga10LogWi-Platinen veröffentlichen kann.

Bis dahin erst mal weiter so wie bisher, also v.a. in bilateraler Absprache. Das ist eigentlich sogar grundsätzlich eher besser, da hierbei meistens noch Anpassungen oder Ausführungsvarianten (z.B. Gehäuse, elektrische Anschlüsse, Akkugröße, Funktechnik usw.) besprochen und ausgewählt werden können, die für den konkreten Anwendungsfall am besten passen.

So, und damit verabschiede ich mich erst mal wieder an dieser Stelle. Zurück in den Dienst für die deutsche Exportwirtschaft. :roll:

Ab Mitte/Ende Mai dann hoffentlich wieder mit weiteren Neuigkeiten. :idea:

Einen schönen Sonntag noch und beste Grüße aus dem Muldental,
Hagen
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)

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

PPP mit dem NVS NV08C-CSM

Beitrag von Hagen.Felix » 23.05.2013 - 17:01

Moin moin,
hier noch mal auf die Schnelle zwei Zitate aus den Rückmeldungen eines Kunden, der das NVS-Modul seit einigen Wochen (m.E. auch äußerst erfolgreich z.B. mit PPP-Postprocessing von Rohdatentracks mitten aus dem Pariser Stadtverkehr) einsetzt:

"Herr Takasu hat dieser Tage RTKLIB 2.4.2 mit einem experimentellen PPP-AR L1 Algorithmus veröffentlicht. Er meint zwar, dass dieser nur experimentell und wohl noch nicht ganz stabil ist. Jedenfalls kommen wir mit entsprechenden Einstellungen und Korrekturen (sp3, ionex) auf eine enorme Genauigkeit. Ich sehe sde/sdn Werte um die 0,1 - 0,2 Meter. Beste Grüße aus Paris, ..."

"In FW 2.06 (und das steht nicht in den release notes) funktioniert der Abgriff der .sbs Nachrichten über RTKLIB. Michele Bavaro hat diese Funktionalität in binary decoder implementiert. Der Effekt ist, dass die Ionosphären Korrekturen nun direkt über Satellit empfangen und in RTKLIB als .sbs Daten für post-processing zur Verfügung stehen. Bisher müssten die Daten entweder als Ionex Tec über IGS oder als .ems über den EGNOS Webserver bezogen werden."

In diesem Zusammenhang ist evtl. auch diese Veröffentlichung recht interessant:
http://www.fig.net/pub/fig2012/papers/t ... l_5909.pdf

Bis bald mal wieder mit besten Grüßen,
Hagen
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)

Josef Gerstenberg
Beiträge: 233
Registriert: 07.09.2009 - 20:00

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Josef Gerstenberg » 23.05.2013 - 20:23

Moin Hagen,

erfreulich, dass einer deiner Kunden bei einem Experiment sde/sdn Werte um die 0,1 - 0,2 Meter gesehen(!) hat.

Frage: Was ist mit sde / sdn gemeint?
Sind das die Standardabweichungen der Positionen Ost und Nord?
Wenn ja, dann sagt das nicht viel, weil bei PPP-Verfahren i.d.R. auf Teufel komm raus geglättet wird und dadurch die Standardabweichung mit der Zeit immer kleiner wird.
Mit dem tatsächlichen Positionsfehler hat das nichts mehr zu tun.

Hagen: Mehr Butter bei die Fische. Wie das geht, habe ich hier und dir bereits erläutert.

Lieben Gruß nach Grimma,
Josef

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

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Hagen.Felix » 24.05.2013 - 00:29

Josef Gerstenberg hat geschrieben: ...
Wenn ja, dann sagt das nicht viel, weil bei PPP-Verfahren i.d.R. auf Teufel komm raus geglättet wird und dadurch die Standardabweichung mit der Zeit immer kleiner wird.
Mit dem tatsächlichen Positionsfehler hat das nichts mehr zu tun.

Hagen: Mehr Butter bei die Fische. Wie das geht, habe ich hier und dir bereits erläutert.
...
Moin Josef,
wie immer bohrst Du ohne große Umschweife den Finger direkt in die offene Wunde ... :)

In diesem Falle ist es aber sogar noch etwas problematischer meinerseits, weil dieser konkrete Anwender nicht nur mal eben die neue RTKNAVI-Version verwendet hat, sondern "dahinter" auch noch diverse eigene (ebenfalls neue) Software, die vermutlich jedoch noch komplett unter "Geschäftsgeheimnis" fällt (also einen vollständig kommerziellen Hintergrund hat).

Daher wäre ein detailliertes Nachbohren von mir, wie das dort in Paris jetzt tatsächlich funktioniert hat, wohl auch ziemlich aussichtslos gewesen. :roll:

Aber ich muss zu meiner Schande gestehen, dass ich es noch nicht mal versucht hatte. :cry:

Nur soviel vielleicht an dieser Stelle: Es geht bei dieser konkreten Anwendung m.W. nicht vorrangig um höchstmögliche Genauigkeit (wie etwa im Sinne einer geodätischen Punktvermessung), sondern um möglichst "saubere" bzw. plausible Tracks von Fahrzeugen im Straßenverkehr. Also etwas, das zunächst weniger vorrangig auf die sachgerechte Verwurstung von Trägerphasen-Rohdaten angewiesen sein dürfte als wohl vielmehr auf solche Techniken wie besonders angepasste Kalman-Filter o.ä., wobei ich nicht mal weiß, ob dabei jetzt auch schon derlei Zeug wie ADR (http://www.u-blox.com/de/dead-reckoning.html) mit im Spiel war ...

Ich vermute allerdings, dass dieser Anwender vielleicht noch nicht mal die tatsächlichen Positionsfehler (mittels notwendigem Abgleich mit Koordinaten aus hochgenauen alternativen Messverfahren für identische Antennenpositionen) selbst bestimmen konnte. Möglicherweise war hier also lediglich eine Sichtprüfung in Google Earth oder Bing Maps möglich, ob der Track auch einigermaßen spurtreu auf der richtigen Fahrbahnseite verläuft. :roll:

Und natürlich könnte man sich jetzt durchaus fragen: Warum eigentlich hier überhaupt Trägerphasen-Rohdatenempfänger mit RTKNAVI? Zumal im Kontext dessen, was die meisten Teilnehmer in diesem Forum doch viel mehr interessieren dürfte (also die typische geodätische Vermessung mit kostengünstiger L1-Technik)? Leider weiß ich das wirklich (noch) nicht, und in den letzten Wochen war ich dermaßen zeitraubend mit solchem "Quatsch" wie der Anbindung von Echoloten über längere Entfernungen mit RS-422 beschäftigt, so dass ich noch nicht mal selbst die neue RTKLIB testen konnte, obwohl ich doch mittlerweile sogar schon an der Quelle für diese hübschen kleinen 3G+C sitze ... :cry:

Ein interessantes "Schmankerl" ist allerdings noch die (hier gleichwohl eher nebensächliche) Information, dass dort im Süden inzwischen auch schon die RTKLIB nach iOS portiert wurde. :shock:

Mit guten Vorsätzen für eine baldmöglichst wieder etwas stressärmere Zukunft,
Dein hoffentlich nun immer folgsamer :mrgreen:
Hagen
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)

Josef Gerstenberg
Beiträge: 233
Registriert: 07.09.2009 - 20:00

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Josef Gerstenberg » 24.05.2013 - 20:16

Moin Hagen,

entschuldige - ich wollte nicht in Wunden bohren, sondern sachliche Kritik üben.
Folgsam musst und solltest du in keiner Weise sein.
Sachlich, freundlich, offen und kritisch miteinander diskutieren, das ist für mich ein feines Ding!

Nur kurz etwas zum eigentlichen Thema, denn auch ich bin gerade im Streß:
Wenn es bei einer Anwendung, wie hier, nicht sehr um die Genauigkeit geht, sondern um "schöne" Tracks mit halber Straßenbreiten-Genauigkeit, dann ist eine Glättung selbstverständlich von Vorteil.
Die Standardabweichungen sagen dann aber fast nichts mehr über den tatsächlichen Positionsfehler aus.

Vielen Dank für die ausführlichen Informationen
und einen lieben Gruß nach Grimma,
Josef

cr2_gps
Beiträge: 121
Registriert: 04.10.2011 - 19:18

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von cr2_gps » 24.09.2013 - 21:28

Bei der Suche nach einem kostengünstigen NV08C-CSM Empfänger bin ich auf diese Seite gestoßen
http://forre.st/nv08c-csm
Hoffentlich wird es irgendwann endlich einen NV08C-CSM als XBee-Modul geben...

B14
Beiträge: 65
Registriert: 01.05.2010 - 21:22

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von B14 » 23.02.2014 - 19:51

Hallo zusammen,

nachdem ich kürzlich eine neue Firmware für den NVS bekommen habe, wollte ich hier kurz über die damit gemachten Erfahrungen berichten. damit konnte ich das erste mal Galileo-SAT sehen. Auswerten konnte ich sie noch nicht, ich werden jetzt längere Zeit Logs mitlaufen lassen und schauen was da dann auftaucht. Als Hardware wurde ein NV08C-CSM/HW 3.1 und eine TW3430 genutzt.

Gruss
Bernd
GalileoSATs1.jpg
GalileoSATs1.jpg (86.54 KiB) 22537 mal betrachtet
GalileoSATs2.jpg
GalileoSATs2.jpg (42.53 KiB) 22537 mal betrachtet

hannes
Beiträge: 31
Registriert: 01.02.2011 - 13:17

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von hannes » 05.03.2014 - 10:14

Welche Version der Firmware?
Und konntest du die Sats auch in Rtklib sehen? oder ist das noch nicht freigeschalten?

lg

Robert.Roessler
Beiträge: 3
Registriert: 05.06.2014 - 15:24

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Robert.Roessler » 05.06.2014 - 18:18

Hallo,

ich bin neu in der GPS-RTK Schule und habe in eurem Forum schon sehr viel gelernt. Ich bin sehr froh, dass es weiter besteht da es ein Topf voller Wissen ist.

Viele Fragen kommen oft vor und ich habe versucht alle meine Fragen so gut es geht mit Hilfe des Forums zu beantworten. Ich versuche so wenig wie möglich redundante Fragen zu stellen aber es kann sein, dass doch das eine oder andere hier im Forum schon besprochen wurde. Auswahl der Hardware und die ersten Schritte habe ich bereits anhand des Wissens im Forum getan.

Ausgangsituation:
2x Denga10 Receiver Boards --> NVS NV08C-CSM Hardware 4.1 vorkalibriert mit GLONASS Group Delay --> Daher habe ich mir diesen Thread ausgesucht
2x TW3430 mit 100mm Grundplatte (Besten Dank nocheinmal an Herrn Piotraschke Hagen F. für die hervorragende Betreuung und Beratung)
2x i7 Multicore Verarbeitungsrechner (Keine Einschrängung bei Energiebedarf)
Registriert bei EUREF-IP um den Ntrip Caster der TU-Wien TUWI0 über eine Internetverbindung zu benutzen.

Ziel:
Für die Evaluierung von Simultaneous Mapping and Localization Algorithem benötigen wir eine Ground Truth Messung gegen die, die Abweichung der Lokalisierung des Algorithmus berechnet werden kann. Ohne einer aussagekräftigen Ground Truth Messung können wir unsere Algorithmen und dessen Modifikationen nicht benchmarken und sinnvoll vergleichen.

--> Für uns ist in diesem Zusammenhang eigentlich nur eine sehr genaue Lokalisierung zu einem Punkt ausreichend. Sprich es würde uns reichen eine sehr genaue relative Lokalisierung von Basisstation --> Rover zu erhalten. Falls sich eine globale Lokalisierung im ECEF Frame auch erreichen lässt ist das natürlich auch sehr angenehm.

Ich befinde mich leider ziemlich in der Stadt und bin im Büro von Hochhäusern umgeben. Die ersten Testmessungen habe ich daher in meinem VW-Bus auf einem Hofer(Aldi)-Parkplatz relativ "hoch" auf dem Wiener Berg bei mir in der Nähe gemacht. Die Antennen waren dabei mit Saugnäpfen auf dem Dach angebracht, jeweils am Ende des Busdaches eine.

Vorgehen:
1) Zunächst habe ich eine PPP Static Messung mit einer der Antennen durchgeführt und eine Weile lang laufen lassen. Als Base Station habe ich den Ntrip Broadcaster hinzugefügt. Ich denke das war wohl unnötig, da PPP eigentlich mit Korrekturdaten arbeitet die unabhängig von einer Basisstation über ein File bereitgestellt werden habe ich vorhin gelesen.

2) Im nächsten Schritt habe ich RTK Navi umkonfiguriert und die zweite Antenne als Rover und die Antenne für die ich vorhin die Messungen durchgeführt habe als Basestation eingetragen. Unter dem Positions Reiter habe ich dann noch die zuvor eruierte Position für die Basistation eingetragen.

3) Nach kurzer Zeit gibt es einen Fix. Jedoch springt das Ergebnis im Submeterbereich. Die Messungen an den Sprungpositoinen streuen so wie ich es mir erwarten würde im Zentimeterbereich. Das Ergebnis springt teilweise zwischen den Sprungpunkten hin und her. Leiderhabe ich keine Screenshots von den Koordinatenveränderungen über die Zeit erstellt, sondern nur vom xy-Positions Plot. Die Position stimmt ganz gut, ich stand nämlich am sechsten Parkplatz von rechts.


Fragen:
- Welche Ursachen können diese Sprünge haben? Meine Vermutung sind ja die oft genannten und dominierenden Multipath Einflüsse (da ja kein Choke Ring). Je nachdem ob eine Reflexion stark genug ist oder nicht wird das Ergebnis verfälscht um einen gewissen Betrag --> Sprung. Liege ich da richtig? Sollte ich daher die Elevation Mask erhöhen (derzeit großzügig bei 5°)?
VorSprung.PNG
VorSprung.PNG (15.32 KiB) 21946 mal betrachtet
Spruenge.PNG
Spruenge.PNG (21.57 KiB) 21946 mal betrachtet
SatBild.PNG
SatBild.PNG (240.05 KiB) 21946 mal betrachtet
- Ich habe versucht eine Messung als Kinematik (Rover + Ntrip Korrektur) durchzuführen. Der Abstand zur TU-Wien ist dabei <10km also sollte die Baseline eigentlich kurz genug sein. Jedoch erhalte ich bei dieser Variante nur Single Solutions mit der üblichen Standardaweichung von GPS. Vielleicht bin ich zu ungeduldig, aber es scheint auch nach einigen Minuten keine Besserung zu erfolgen. Da ich ja mit der eigenen Base Station eine Fix Solution erreiche, scheinen die Receiver korrekt eingestellt und die Antennen auch genug Strom zu bekommen. Verbindung zum Ntrip Caster besteut und ich bekomme auch alle 0.2sec eine Nachricht.
Welche Fehlerquellen gibt es erfahrungsgemäß noch die ich prüfen könnte?

- RTK und PPP sind wie ich gelesen habe zwei verschiedene Paar Schuhe. Da bisher bei mir nur PPP gefruchtet hat, habe ich meine Basisstation damit vermessen. Um die PPP Berechnung zu verbessern, muss man Korekturdaten der ultrarapide Ephemeriden berreitstellen. Diese würde ich mir für den aktuellen Tag hier: http://igscb.jpl.nasa.gov/components/prods_cb.html runterladen.
Muss ich das .SP3 File dann bei Corrections als File berreitstellen als Format SP3 einstellen und unter Settings1 Ephemersis/Clock auf Precise stellen? Habe gelesen, dass man sich diese Daten auch automatisch laden kann, jedoch sind die Dateien ja nur im komprimierten Format auf der Seite vorhanden.
Für ältere GPS Wochen gibt es noch .erp Dateien auch. Haben diese eine Bedeutung? Sind diese in RTK unter Files EOP Data File dem RTK bereit zu stellen?
Ich habe in diesem Zusammenhang gelesen, dass man auf das International Reference Frame umstellen soll ITRF, jedoch finde ich in den Einstellungen von RTKLib irgendwie nichts davon.

- Beste Antennenposition: Auf einem Stativ möglichst hoch? In wie fern muss man die Antennenhöhe beachten? Empfängt die Antenne nicht mehr Multipath Einflüsse, wenn sie hoch ist da mehr vom Boden reflektierte Signale empfangen werden können? Andererseits umgeht man damit wohl Reflexionen die von vertikalen Flächen verursacht werden bei breiten Elevation Masks.

Das waren mal einiges an Fragen!

Vielen Dank schon mal im Vorraus!

Lg Robert

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

Nutzbare Elevationsmasken mit NV08C-CSM

Beitrag von Hagen.Felix » 06.06.2014 - 06:33

Robert.Roessler hat geschrieben:... Welche Ursachen können diese Sprünge haben? Meine Vermutung sind ja die oft genannten und dominierenden Multipath Einflüsse (da ja kein Choke Ring). Je nachdem ob eine Reflexion stark genug ist oder nicht wird das Ergebnis verfälscht um einen gewissen Betrag --> Sprung. Liege ich da richtig? Sollte ich daher die Elevation Mask erhöhen (derzeit großzügig bei 5°)? ...
Hallo Robert,

das im Bild (Spruenge.PNG) so deutlich erkennbare Muster einer großflächigen Verteilung von "Pseudo-Fix"-Positionen ist m.E. ziemlich typisch für L1-RTK mit RTKNAVI, insbesondere in Messumgebungen mit relativ viel Multipath.

Das hat mich auch schon etliche Male schier zur Weißglut gebracht ...

Allerdings, der große bzw. entscheidende Vorteil des NV08C-CSM gegenüber den bisher für L1-RTK in der "Szene" so gern verwendeten Rohdaten-Empfängern von u-blox ist ja v.a. die Möglichkeit, sich gleichzeitig die (Trägerphasen-)Rohdaten von GPS und GLONASS (und ggfs. auch GALILEO) ausgeben lassen und dann auch parallel im RTKNAVI nutzen zu können.

Und dieser Vorteil bedeutet eben: Man kann die Elevationsmaske noch viel weiter erhöhen, bis die Anzahl der dann noch nutzbaren Satelliten zu gering für einen RTK-Fix wird!

Schon mit "GPS only" sind ja eher 15° als die von Dir genannten 5° üblich, und mit dem NV08C-CSM bin ich dann gelegentlich sogar noch deutlich über 20° gegangen, manchmal sogar schon Richtung 30°.

Das wäre m.E. auch für Dich jetzt der nächste zwangsläufige Schritt.

Aber auch dann kann es trotzdem sein, dass Deine Messumgebung noch etwas mehr Aufwand erfordert.

Andere Antennen, die deutlich besseren Schutz gegen Multipath bieten, würden sicher eine erhebliche Verbesserung bringen, sind jedoch leider gleich um ein Vielfaches teurer.

Ich habe in ähnlichen Messumgebungen wie der von Dir beschriebenen doch recht häufig zur NovAtel 701-GG gegriffen, und das war dann eben auch meistens der Unterschied zwischen "geht eigentlich nicht" und "geht hinreichend" ... :roll:

In städtischem Umfeld gibt es einfach zu viele Reflektoren! :evil:

Möglicherweise müsstest Du somit auch noch in diesen "sauren Apfel beißen", wenn die Erhöhung der Elevationsmaske noch nicht genügen sollte ...

Allerdings, der von Josef hier im Forum beschriebene Choke-Ring sollte die Situation gewiss auch deutlich entspannen! :D

Ich habe ja schon seit so vielen Monaten vor, für diese Bauform von Tallysman-Antennen eine Kleinserie in Angriff zu nehmen, aber bisher haben mich leider einige andere "Problemchen" noch davon abgehalten ... :cry:

Manchmal wird man aber auch in der Bucht fündig, wenn gebrauchte geodätische Antennen vertickt werden, z.B. aus den USA. Dann lohnt sich dank mächtig gewaltiger Preisunterschiede auch noch die Zahlung von relativ üppigen Versandkosten und Einfuhrabgaben in Deutschland. :mrgreen:

Viele Grüße,
Hagen
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)

B14
Beiträge: 65
Registriert: 01.05.2010 - 21:22

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von B14 » 06.06.2014 - 20:56

Hallo Robert,

auch von meiner Seite, willkommen im Forum.

Ich setze auch zwei NV08-CSM im RTK-Static-Betrieb von Hagen ein. Folgende Vorgehensweisen, bzw. Erfahrungen habe ich dabei gemacht:

Je höher die Antennenposition, umso hoeher ist auch die Anzahl und Stabilität der FIX-Solution´s. Dafür habe ich die TW3430 auf einen 20mm dicken und 2,6 Meter langen Alustab befestigt. Gibt es im Baumarkt als Gardinenstangen.
TW3420.png
TW3430 auf 2,6 Meter hohem Alustab
TW3420.png (108.89 KiB) 21932 mal betrachtet
Mit der Elevationmask gehe ich meistens so auf 27-31 Grad. Gehe ich zu weit runter, wird das Verhältnis immer mehr zu FLOAT´s verschoben. Zu weit nach oben, führt dazu, dass keine Lösung mehr gefunden wird (zu wenig SAT´s in view). Aber Hagen sagte es schon, mit GPS und Glonass hat man mehr Reserven.

Ein weiterer Punkt ist Nässe oder Schnee. Nach meinen Erfahrungen ist es so ziemlich das schlimmste, was man einer einfachen GNSS-L1-Antenne antun kann. Ich betreibe eine NVS/TW-Kombination seit zwei Jahren im Dauerbetrieb und die Streuung steigt stark an, wenn der Boden sehr nass (z.B. bei Dauerregen) oder durchgängig schneebedeckt ist. Die oft so gelobten Chokerings, sind übrigens auch nicht immer eine Wunderwaffe gehen Multipath, vor allem wenn er mehr von oben als von unten kommt. Daraus folgt, gutes trockenes Wetter ist zum Messen immer gut, bei schlechtem Wetter sollte es aber mindestens eine Multipath unempfindlichere Antenne sein.

Dein 10 Kilometer entfernter NTRIP-Caster sollte eigentlich super Ergebnisse liefern. Ich selbst kann online leider nur die 130 km entfernte EUREF-Station in Wettzell (WTZ0) nutzen und bekomme bei gutem SAT-View ab und zu auch FIX-Solution´s zustande. Im Offlinebetrieb (Postprocessing) nutze ich in der Regel die 24 km entfernte SAPOS/GREF-Station in Erlangen. Damit kriege ich bei gutem Skyview und wenig Multipath so nach max. 20 Min einen FIX hin (viewtopic.php?f=3&t=3307&start=45#p15269). Mein Wunsch nicht kommerziell über den GREF-Caster auf ERLA zuzugreifen, wurde vom BGK leider abgelehnt, da dies ja auch eine SAPOS-Station sein. Kann ich auch ein wenig verstehen - SAPOS hat ja ein Bezahlgeschäftsmodell.

Meinen zweiten NVS setze ich übrigens nur selten als Basisstation ein. Der kommt in der Regel nur zu Kontrollzwecken, oder bei Messpunkten zum Einsatz, wo eine Wiederholmessung sehr aufwendig wäre.

Gruss
Bernd

Benutzeravatar
Roland
Beiträge: 2055
Registriert: 18.02.2004 - 22:33
Wohnort: Wusterhausen(Dosse)

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Roland » 07.06.2014 - 12:17

Hallo,


Robert bekommt von den Anwendern schon Tipps.
Und ich staune, was man mit L1-Empfängern alles erreichen kann.
Daneben hab' ich mir nur den Messpunkt 'Innovationsstraße' in Googlemaps angeschaut und gesehen, dass da zwei große Neubauten südlich und südöstlich stehen, vrmtl. mit glatten Fassaden. Da kann man gut über Multipath orakeln.

Grüße Roland

Antworten