Rohdaten-Anwendungen mit dem NVS NV08C-CSM

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

Moderator: Roland

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

Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Hagen.Felix » 05.09.2012 - 23:30

Moin moin!

Nachdem kürzlich bereits der NV08C-CSM (http://www.nvs-gnss.com/products/receiv ... c-csm.html bzw. http://www.onetalent-gnss.com/gnss-chips/nvs-nv08c-csm) in die hiesige Diskussion um alternative Low-Cost-Hardware für Präzisionsmessungen wie RTK oder PPP gelangt ist (siehe http://www.kowoma.de/gpsforum/viewtopic ... 943#p14941), möchte ich hier mal eine Beitragsreihe eigens zu diesem Thema beginnen.

Der NV08C-CSM, intern auf zwei Stück des MAX2769 (http://www.maximintegrated.com/datashee ... vp/id/5241) basierend, ist gewiss auch schon im "Normal-Modus" (d.h. auf die Verwendung der NMEA-Ausgaben beschränkt) ein sehr ordentlicher Multi-GNSS-Empfänger. Nicht ohne guten Grund wird beispielsweise die Wahl von Panasonic auf den NV08C-CSM gefallen sein, um künftig einige der allseits bekannten Toughbooks damit auszustatten (siehe http://www.nvs-gnss.com/news/72-nvs-tec ... sonic.html). Der entscheidende Clou allerdings, infolge dessen der NV08C-CSM sicher auch hier im Forum bald eine besondere Aufmerksamkeit genießen wird, war schlicht und einfach eine neue Firmware, seit deren Veröffentlichung (http://www.nvs-gnss.com/news/65-nvs-tec ... eries.html) nun auch die Trägerphasen-Rohdaten mit in der binären Nachrichtenausgabe (proprietäres BINR-Format, siehe http://www.nvs-gnss.com/support/documen ... ation.html) enthalten sein können.

Damit wurde der NV08C-CSM schlagartig auch hochinteressant für alle, die sich im Bereich Low-Cost-RTK/PPP eben so herumtummeln ... :D

Quasi an vorderster Front ist dabei der - vielen hier schon bekannte - Michele Bavaro (http://www.onetalent-gnss.com/resume) tätig geworden. Bereits etliche Zeit vor der o.g. Firmware-Veröffentlichung hat er (in enger Zusammenarbeit mit NVS und dabei auch unter deren NDA) daran gearbeitet, die Rohdatenausgabe des NV08C-CSM mit den verschiedenen Einzelanwendungen der RTKLIB (RTKNAVI, RTKCONV u. STRSVR) nutzen zu können. Diese Arbeit ist aufgrund einiger Unterschiede in der Herangehensweise von NVS bzw. eben von Meister Takasu (http://www.rtklib.com/rtklib_reference.htm) offenbar kein Kinderspiel und daher leider bis jetzt auch noch immer nicht ganz fix und fertig. So gibt es beispielsweise bis dato einige Schwierigkeiten mit den SBAS-Daten (äußerst wünschenswert für PPP), aber abgesehen davon ist schon jetzt ein erfolgreicher Einsatz des NV08C-CSM in den o.g. RTKLIB-Anwendungen durchaus möglich.

Ich selbst, der ich ja im GNSS-Bereich seit Ende 2011 in einer Kooperation mit Michele tätig bin, habe in den letzten Wochen ziemlich viele Testmessungen und auch schon einige Praxiseinsätze mit dem NV08C-CSM und den von Michele um einen BINR-Import erweiterten RTKLIB-Anwendungen durchgeführt. Mittlerweile häufen sich auch die Anfragen zu diesem Thema bei mir, so dass es aus meiner Sicht schon sinnvoll wäre, möglichst viele Informationen dazu bereits hier im Forum zu vermerken. Einerseits soll dies denjenigen, die gerade erst ganz neu mit dem NV08C-CSM anfangen, die ersten Schritte etwas erleichtern. Denn, wie natürlich auch bei vergleichbaren Komponenten von anderen Herstellern, gibt es hier einige Besonderheiten, ohne deren Beachtung die gewünschten Funktionalitäten entweder gar nicht oder nur eingeschränkt erreicht werden können. Ich werde versuchen, möglichst bald auch eine eigene Anleitung in deutscher Sprache dazu anzufertigen und zur Verfügung zu stellen, aber das kann durchaus noch etliche Wochen dauern. Außerdem bietet ein solches Forum wie hier eben auch die Gelegenheit, dass weitere Nutzer des NV08C-CSM ihre Erfahrungen mit einbringen können, so dass letztlich alle Beteiligten etwas davon haben: die blutigen Anfänger ebenso wie die alten Hasen, welche ja auch nicht wirklich alle möglichen Erfahrungen höchstselbst gewinnen können ...

So, nun aber genug der Vorrede!

Im nächsten Beitrag stelle ich erst mal ganz grob die Grundlagen zum bzw. ersten Schritte mit dem NV08C-CSM und den o.g. RTKLIB-Anwendungen vor.

Bis dahin mit besten Grüßen aus Grimma,
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:

Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Hagen.Felix » 06.09.2012 - 00:51

Erst mal aber dennoch ein wenig weitere Vorrede, um wirklich ganz beim Anfang zu beginnen ...

Warum der NV08C-CSM hier eigentlich überhaupt so besonders interessant ist?

Leichte Antwort: weil er gleichzeitig GPS und GLONASS empfangen kann!

In der (hier im Forum ja sicher ganz besonders geschätzten) Marktnische von Low-Cost-Hardware mit Trägerphasen-Rohdatenausgabe gab es mit den T-Modulen (+Derivaten) von u-blox und später auch einem adäquaten Modul von SkyTraq ja bislang nur Empfänger für GPS L1 (sowie SBAS).

Während die bekannten GNSS-Hersteller der oberen Preisklassen bereits seit einiger Zeit mit der zusätzlichen GLONASS-Option werben, ist nun mit dem NV08C-CSM dies endlich auch für die Freunde der kostengünstigen Hardware in greifbare Nähe gerückt.

Warum die gleichzeitige Verwendbarkeit von GPS und GLONASS eine feine Sache ist, zeigt die untenstehende Abbildung (von einer ganz normalen Messung auf einem ganz normalen Feldweg) schon auf den ersten Blick: Satelliten satt!

Und genau hierin liegt auch der maßgebliche Vorteil des kombinierten Systems. Dass nämlich quasi automatisch die Genauigkeit drastisch verbessert wird (wie es in so mancher Werbebroschüre erscheint), ist eigentlich gar nicht unbedingt der Fall. Die Auflösung der Trägerphasen-Mehrdeutigkeiten, was ja erforderlich ist für die hier bevorzugt diskutierten GNSS-Präzisionsanwendungen, stellt bei den GLONASS-Signalen sogar ein viel größeres Problem als bei denen der GPS-Satelliten dar.

Aber: Wo eine so große Gesamtmenge zur Verfügung steht, wird das Empfangssystem des Nutzers eben v.a. deutlich robuster gegenüber dem Problem, dass bei schwierigen Umgebungsverhältnissen (insbesondere bei sehr starken Abschattungen) sonst schon gelegentlich die Anzahl der noch nutzbaren Satelliten einfach nicht mehr ausreicht, um die benötigte Fixierung weiter aufrechterhalten zu können. Aufgrund der jeweiligen Satellitenbahnen wirkt sich die zusätzliche Nutzbarkeit von GLONASS umso gewinnbringender aus, je weiter nördlich gemessen wird. Die Vorzüglichkeit des NV08C-CSM ist also z.B. in Skandinavien (oder meinetwegen auch in meiner Ossi-Heimat) schon noch eine andere als vielleicht in Griechenland oder gar Nordafrika ...

Sicher werden über kurz oder lang quasi alle relevanten Hersteller auch GLONASS mit unterstützen, aber im Moment ist z.B. bei u-blox, auch wenn von dort schon einige recht großartig klingende Ankündigungen zu diesem Thema gekommen sind, eine gleichzeitige Verwendbarkeit von GPS und GLONASS in deren Empfänger-Serien mit Trägerphasen-Rohdatenausgabe leider noch immer in recht weiter Ferne ...

Soweit, so gut - das mag als einleitende Erläuterung, warum der NV08C-CSM hier so besonders interessant erscheint, erst mal genügen meinerseits. Jetzt möchte ich doch langsam zur praktischen Anwendung kommen!

Bis gleich,
Hagen
Dateianhänge
NV08CCSM-TW3430-PPP-static-Broadcast-RTKNAVI.png
Reichlich Satelliten mit dem NV08C-CSM
NV08CCSM-TW3430-PPP-static-Broadcast-RTKNAVI.png (23.45 KiB) 35238 mal betrachtet
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:

Erste Schritte mit dem NVS NV08C-CSM

Beitrag von Hagen.Felix » 06.09.2012 - 10:21

So, jetzt aber wirklich zum praktischen Beginn mit der Technik ...

Vorausgesetzt wird in meinen folgenden Ausführungen stets die Verwendung der von OneTalent GNSS entwickelten Platinen, die ich selbst ja auch nur (sowohl zum Eigenbedarf als auch innerhalb meiner Angebote) verwende. Konkret betrifft das zunächst den relativ einfachen Empfänger mit USB-Anschluss (in der Kodierung von Michele seit jeher "Denga10" genannt, siehe http://www.onetalent-gnss.com/ideas/usb ... rs/denga10 bzw. https://www.optimalsystem.de/os.aspx?x=4114). Zudem hat Michele aber unter dem Kürzel "Denga10LogBt" (http://www.onetalent-gnss.com/ideas/wir ... nga10logbt) auch eine erweiterte Platine mit Mikrocontroller, Speicherkartenfassung und Bluetooth-Modul entwickelt. Deren aktueller Nachfolger (auf den Seiten von Michele bisher nur in der Bildergalerie zu sehen, eine Beschreibung kommt aber sicher in Bälde) firmiert jetzt unter der Kodebezeichnung "Denga10LogWi" und stellt eine Trägerplatine für den NV08C-CSM dar, auf die je nach Bedarf dann z.B. ein Bluetooth- oder ein XBee-Modul gesteckt werden kann. Insbesondere mit dem XBee-PRO 868 (http://www.digieurope.de/de/products/wi ... 8#overview) ermöglichen diese neuen Platinen nun z.B. die Realisierung eigener (v.a. auch mobiler) RTK-Basisstationen ohne die Notwendigkeit eines extra Rechners dafür. Im einfachsten Falle ist solch eine Basisstation dann gerade einmal ein ungefähr zigarettenschachtelgroßes "Kästchen" (Akku für ein paar Stunden Laufzeit bereits enthalten), an das dann nur noch die Antennen für GNSS und XBee angeschlossen werden müssen. Indem damit die Nutzung eigener mobiler Basisstationen relativ unkompliziert möglich ist, lässt sich eine typische Einschränkung von Einfrequenz-RTK (die Länge der Basislinien im Vergleich zu den mit L1/L2-Empfängern noch problemlos nutzbaren Entfernungen) so doch sich in vielen Situationen deutlich besser bewältigen ...

Wenn man den NV08C-CSM allerdings in eigenen Platinen oder solchen von anderen Anbietern verwendet, müsste man u.a. darauf achten, wie man die Nachrichtenverteilung bzw. -nutzung mit den beiden Standardein-/-ausgängen (UART A + B jeweils mit 1,8 bis 3,3V CMOS-Pegel) realisiert und wie man seiner Antenne die jeweils erforderliche Versorgungsspannung liefert (der NV08C-CSM stellt von sich aus hierfür nur 2,65 V bereit, was insbesondere bei vielen höherwertigen Antennenfabrikaten noch nicht ausreicht).

Der Denga10 jedenfalls stellt beide UART-Schnittstellen des NV08C-CSM über einen sogenannten DUART-Chip mit einem einzigen USB-Anschluss nach außen bereit. Hierfür ist der FT2232D von FTDI verbaut. Die (D-/Q-)UART-Wandler dieser Chipschmiede sind ja sozusagen der Goldstandard und zeichnen sich nicht zuletzt durch eine exzellente Treiberunterstützung für quasi alle relevanten Betriebssysteme aus. Unter Windows ist es beispielsweise so, dass die notwendigen Treiber automatisch gesucht, heruntergeladen und installiert werden, wenn man erstmalig einen FTDI-Chip via USB am Rechner anschließt. Wer das nicht realisieren kann (Uralt-Windows oder momentan fehlende Internetverbindung) oder ggfs. einen neueren als den letzten WHQL-zertifizierten Treiber nutzen möchte, kann natürlich auch selbst mit dem Gerätemanager aktiv werden. Die Treiber sind unter http://www.ftdichip.com/Drivers/VCP.htm verfügbar und sorgen dann in einem Microsoft-Betriebssystem dafür, dass den via USB am Rechner angeschlossenen UART-Schnittstellen sogenannte "Virtuelle COM-Ports" (VCP) eingerichtet werden, die sich mit den gängigen Techniken (wie z.B. der SerialPort-Klasse, siehe http://msdn.microsoft.com/de-de/library ... lport.aspx) öffnen und zum Lesen und/oder Schreiben nutzen lassen können.

Der Denga10 ist normalerweise so konfiguriert, dass die eine UART-Schnittstelle für das NVS-proprietäre (binäre) BINR-Nachrichtenformat genutzt wird, während die andere dann für die üblichen NMEA-Nachrichten zuständig ist. Diese Trennung sorgt zunächst mal dafür, dass sich ein Programm nicht an einer solch wilden Mischung von binären und Textnachrichten verschlucken kann, wie sie z.B. ein Empfänger von u-blox via USB ausgibt, sofern beide Nachrichtentypen (NMEA und proprietäres binäres UBX-Format) aktiviert sind. Zudem erleichtert der Denga10 damit auch die Vorgehensweise, bei Vermessungsarbeiten bereits unmittelbar die gewünschten Geometrien kartieren zu können, auch wenn die eigentlich zu erzielende Genauigkeit erst später im sogenannten Postprocessing entsteht. Dazu kann man die BINR-Nachrichten des NV08C-CSM (vorher allerdings unbedingt darauf achten, dass die Rohdatenausgabe aktiviert wurde, dazu später aber noch mehr) sogar erst mal gänzlich unbesehen in binärer Form fortlaufend in eine Datei wegspeichern, während man mit der NMEA-Ausgabe beispielsweise verschiedene Einzelflächen aufnimmt. Dabei sollte jedoch auch gewährleistet sein, dass man über die GNSS-Zeitinformationen später wieder rekonstruieren kann, wo bzw. wann z.B. die Aufnahme eines Polygons begonnen und beendet wurde. Denn nach der Postprozessierung hat man ja die korrigierten Daten dann z.B. auch wieder als (künstlich erzeugte) NMEA-Nachrichten vorliegen, die fortlaufend über die komplette Aufzeichnungszeit in einer einzigen Datei stehen. Wenn man also schon bei der ursprünglichen Kartierung im Feld für jedes einzeln aufgenommene Polygon jeweils auch den entsprechenden NMEA-Abschnitt zusätzlich mit abspeichert, kann man später völlig problemlos diese einzelnen Abschnitte aus dem Gesamt-NMEA der Postprozessierung extrahieren. Beim NV08C-CSM geht das dann sogar bis auf die Zehntelsekunde genau. Die dazu benötigten Zeitinformationen stehen als UTC übrigens an erster Stelle der GGA-Nachrichten. Um diese Vorgehensweise in der eigenen Praxis (landwirtschaftlicher Mess- und Datendienst) mit einem Touchscreen-Gerät einigermaßen komfortabel realisieren zu können, habe ich ein kleines WPF-Programm geschrieben, das mittlerweile sowohl für private als auch gewerbliche Endanwender kostenfrei zur Verfügung steht (http://www.feldlog.optimalsystem.de). Zunächst sollte man jedoch erst mal kurz nachschauen, auf welchem der beiden VCP auf dem eigenen Rechner NMEA ankommt. Das geht natürlich immer mit einem ganz einfachen Terminal-Programm (z.B. https://sites.google.com/site/terminalbpp/), aber im Falle des NV08C-CSM ist das Windows-Programm "Storegis" (http://www.nvs-gnss.com/support/soft/it ... regis.html) dazu eigentlich das beste Werkzeug. Wie das damit geht, werde ich im nächsten Beitrag zeigen.

Fortsetzung folgt ...
Dateianhänge
FTDI-DUART-VCP.png
Virtuelle COM-Ports für den FT2232D DUART-Adapter
FTDI-DUART-VCP.png (51.32 KiB) 35228 mal betrachtet
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 » 07.09.2012 - 18:10

Hallo Hagen,

ich wollte nun auch mal in diesen Thread einsteigen, da ich seit ca. 2 Wochen mit dem NV08C und einer TW2410 experimentiere und im Vergleich zu meiner bisherigen Skytraq/Bullet-III-Ausrüstung doch deutliche Vorteile feststellen konnte.

Den größten Vorteil überhaupt, sehe ich in der gesteigerten Anzahl der nutzbaren Satelliten. Damit kann man in multipath-schwierigen Situationen die Evalution Mask höher setzen, ohne die FIX-Solutions zu verlieren. Bisher habe ich mit Skytraq/Bullet III nur 5-10% FIX gegenüber einer 24 km entfernten GREF-Station (ERLA) im Post Processing erreicht, bei NVS/TW2410 konnte ich bei einem Winkel von 31 Grad 96-97 Prozent FIX-Solutions erreichen (siehe Screen). Zu den Absolutwerten, möchte ich jetzt aber nichts sagen (ETRF89, WGS84, DHND90 – 30-40 cm in Nord-Ost Richtung sind immer verdächtig).
Track.png
Track.png (9.93 KiB) 34966 mal betrachtet
Ich habe mich bei den aktuellen Tests auf RTK und weniger auf PPP konzentriert, da RTKLIB hier wohl noch Nachholbedarf (z.B. gegenüber BNC) hat. Aber warten wir hier mal auf 2.4.2.
Wenn SBAS ins Spiel kommt, sollte man immer auch die Koordinatensysteme beachten. Hier geht es um die Unterschiede WGS84(ITRF2005) und ETRF89. Die letzteren bekommt man von den lokalen Vermessungsbehörden (wenn überhaupt in ETRF89, statt in GK). Die Koordinaten vom BKG sind in der Regel in ETRF89 und nicht in IRTF2005. Diese sollte man bei der Base Station Definition in RTKLIB immer beachten.
ECEF.png
ECEF.png (2.97 KiB) 34966 mal betrachtet
Die Antennenfrage möchte ich in einem weiteren Posting gerne klären. Konkret geht es darum, ob man mit einer Standard-Antenne (z.B. TW2410) durch unterschiedliche Groundplanes (Metallscheiben zwischen 7-10 cm oder auch Choke Rings) Verbesserungen erreichen kann. Mit der Analyse der Multipatheffekte bin ich bisher aber noch nicht zufrieden. Sowohl der Multipath-Analyser von Javad als auch Tomijo´s GPSTools for Matlab habe mich da nicht richtig weiter gebracht.

Eventuell kennt jemand von euch eine bessere Möglichkeit OBS-Dateien darauf hin zu analysieren.

Gruss
Bernd
Zuletzt geändert von B14 am 23.09.2012 - 14:53, insgesamt 1-mal geändert.

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

NVS NV08C-CSM : Antennenoptimierung

Beitrag von Hagen.Felix » 07.09.2012 - 21:11

B14 hat geschrieben: ...
Die Antennenfrage möchte ich in einem weiteren Posting gerne klären. Konkret geht es darum, ob man mit einer Standard-Antenne (z.B. TW2410) durch unterschiedliche Groundplanes (Metallscheiben zwischen 7-10 cm oder auch Choke Rings) Verbesserungen erreichen kann.
...
Hallo Bernd,

ich freue mich sehr, dass Du gleich in diese Beitragsreihe mit einsteigst!

Angesichts dessen, dass Michele meistens etwas einsilbig ist mit seinen Erläuterungen zu den Spezifika des NV08C-CSM und dann ja auch immer noch ein wenig das Sprachproblem (Italienisch-Englisch-Deutsch) im Wege steht, ist es umso gewinnbringender, wenn jemand wie Du, der sich hierzulande bereits ziemlich intensiv und eben auch relativ kundig mit diesem neuen Rohdatenempfänger beschäftigt, auf die Besonderheiten damit hinweisen kann ...

Ich habe erst am heutigen Vormittag ein längeres Telefonat mit Michele geführt und dabei mit ihm u.a. auch eine ganze Weile über die Eigenarten der Datenausgabe des NV08C-CSM im Kontext des bislang üblichen Datenimports der RTKLIB gesprochen. Mit meinen beschränkten Fachkenntnissen im Bereich "GNSS-Technik unter der Haube" konnte ich jedoch leider (wieder mal) nicht allzu viel davon auch wirklich verstehen ... :(

Daher erst mal nur kurz das Resümee, dass Michele aktuell sowohl mit NVS als auch mit Meister Takasu jeweils direkt daran arbeitet, dass möglichst schon bald eine hinreichend saubere Lösung dafür gefunden wird und dann auch Eingang findet in eine kommende offizielle Version der RTKLIB.

Bis dahin will ich mich bemühen, die Zwischenschritte und "workarounds" für erfolgreiche Rohdaten-Anwendungen mit dem NV08C-CSM z.B. in dieser Beitragsreihe hier im Forum darzulegen ...

Als nächstes kommen dann aber meinerseits erst mal noch ein paar weitere "erste Schritte" für einen möglichst nicht allzu holprigen Start mit dem NV08C-CSM und der RTKLIB!

Ein kleiner Hinweis jedoch gleich noch zum Antennenproblem.
Ich habe gerade erst gestern von Gyles Panther („President & CTO“ bei Tallysman, siehe auch unter http://www.tallysman.com/management.php) höchstpersönlich die nachfolgend zitierte Antwort auf meine entsprechende Anfrage beim "Director - Operations" von Tallysman bekommen:
With respect to the ground plane, 100mm diameter is a near optimum size for the patch gain at L1, and because the through hole (and magnetic mount) antennas are normally mounted on a metal surface, we optimize the patch tuning for a 100mm ground. The ground plane size vs gain is a soft function, so a little smaller or bigger would also be ok, but in any event, I would suggest you not go below 70mm diameter.“

Diese 100 mm hatte ich als optimale Größe von zusätzlichen Grundplatten für diese "Precision / near-survey grade / dual-feed" Antennen von Tallysman ja auch schon vorher mal genannt bekommen, aber jetzt haben wir eben noch die definitive Bestätigung dazu hinsichtlich der Abstimmung mit dem Patch-Element!

Was allerdings das Multipath-Problem betrifft, so können wir wohl allein von solch einer Grundplatte noch keine wirklichen Wunder erwarten (v.a. natürlich unter wirklich schwierigen Empfangsbedingungen wie z.B. einem nassen Untergrund). Aber genau deswegen haben wir ja auch schon den Bau eines Choke-Rings im Visier, oder? :idea:

Viele Grüße & bis demnächst!
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)

ssquare_de
Beiträge: 671
Registriert: 07.10.2006 - 16:23

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von ssquare_de » 08.09.2012 - 09:18

Hallo Bernd,


ist zwar hier nun ein wenig OT, ich werde mich also kurz fassen mit den unterschiedlichen Koordinatensystemen.
Aber wenn ich hier schon einen Anwender aus Bayern (ERLA) "heimsuchen" kann...dann mach ich das auch! :wink:

Also:
SAPOS positioniert den Rover im ETRS89-System, wie du schon richtig angemerkt hast.
Auch fürs Postprozessing liegen die Stationskoordinaten der Basisstationen im ETRS89-System vor, die man in RTKLIB nutzen kann.

Ein Problem tritt hier im Freistaat aktuell immer dann auf, wenn man per SAPOS zwar den Rover schon im ETRS89 positioniert, aber noch auf Geodaten aus dem "alten" GK-Bestand zurückgreifen will/muss.
Die bayerische Vermessungsverwaltung bietet dafür mehrere Lösungen an:
https://sapos.bayern.de/transformation.php

Dazu ein paar Anmerkungen:
Leider unterstützt RTKLIB derzeit die per RTCM 3.1 übermittelte Transformation ETRS89--->GK (noch?) nicht!

Zudem wäre noch abzuklären, ob die im obigen Link beschriebene gitterbasierte Transformation im NTv2-Standard derjenigen entspricht, die hier
http://www.geodatenzentrum.de/geodaten/ ... _user_id=0
dem Anwender kostenlos zugänglich gemacht wird.

Vermutlich wird aber wohl ein genaueres, verdichtetes Shift-Gitternetz speziell für das Gebiet Bayerns vorliegen, das die Genauigkeit auf die im Link erwähnten < 5-7cm Lage und < 3cm Höhe sicherstellt!
Denn das landesweite Verfahren (obiger Link) kenne ich nur mit dem Label: Submetergenauigkeit (dies allerdings eben im gesamten Bundesgebiet!)

Hierzu ein Link von ESRI. allerdings schon aus dem Jahr 2006. ( Bayern ab Seite 6 )
http://support.esri.de/files/support/NT ... chland.pdf

Vielleicht schon ein bischen angestaubt und nicht mehr ganz aktuell?!?
Denn das hinterlegte und in dem Link beurteilte Shift-Grid könnte mittlerweile in einer verbesserten Version vorliegen?!?
Müsste man mal mit den jeweilgen Verantwortlichen u. Fachleuten abklären!


Das soll es zu diesem Thema an dieser Stelle auch schon gewesen sein, vielleicht lohnt sich ein eigenes Thema mit (Linksammlung) zu den Koordinatentransformationen?
Dazu gibts ja einiges zu wissen, auch das Thema ist derzeit im Bewegung und zudem auch noch in D abhängig vom jeweiligen Bundesland...zumindest bis flächendeckend dann mal das ETRS89 eingeführt ist.
Es nervt halt ungemein, wenn man schon mit hochgenauen GNSS-Methoden herumhantiert und dann "passts wieder nicht ganz genau" ! :)


Aber spätestens jetzt zurück zu euerem interessanten Thema hier:
NVS NV8C-CSM


Stefan

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

NV08C-CSM : DUART mit Storegis öffnen / BINR-VCP suchen

Beitrag von Hagen.Felix » 16.09.2012 - 11:20

So, nun aber erst mal wieder etwas zum NV08C-CSM bzw. der Verwendung seiner Trägerphasen-Rohdatenausgabe ...

Ich war ja dabei stehengeblieben, die beiden vom DUART-USB-Adapter FT2232D realisierten VCP mit dem NVS-Programm Storegis (http://www.nvs-gnss.com/support/soft/it ... regis.html) anzusprechen. Beispielsweise dazu, um zunächst nur mal zu sehen, auf welchem VCP eigentlich welche Daten ausgegeben werden.

In einem der vorigen Beiträge hatte ich ja schon ein Bild hochgeladen, in dem erkennbar ist, wie diese beiden vom FT2232D (bzw. letztlich nur vom FTDI-Treiber in der Windows-Registry) bereitstellten VCP im "Geräte-Manager" der Windows-Systemsteuerung aussehen. Das sollte übrigens in allen Windows-Version von XP bis 8 so ziemlich gleich sein, ich bin jedenfalls gerade mit dem alltäglich verwendeten Rechner auf Version 8 umgestiegen und kann diesbezüglich keine Unterschiede entdecken ...

Je nachdem, wie die beiden UART-Schnittstellen des NV08C-CSM konfiguriert sind (auf jeden Fall aber im üblichen Auslieferungszustand der Denga10-Platinen), sollte auf einer NMEA ausgegeben werden und auf der anderen BINR. Nach dem Start von Storegis (das ist tatsächlich nur eine "lose" ausführbare EXE-Datei, muss also nicht erst in klassischer Weise installiert werden) wählt man zunächst einen der beiden VCP im "Drop-down"-Auswahlfeld (z.B. "COM18") ganz links oben im Programmfenster (siehe Bild) aus. Und da man ja primär auf der Suche nach der BINR-Ausgabe ist, um diese eben mit einer Anwendung der RTKLIB nutzen zu können, kann man als "PROTOCOL" natürlich auch gleich BINR auswählen und dabei auch schon "raw data" mit einem Häkchen versehen. Die Baudrate muss man selbst auch gar nicht zwingend optimal einstellen, da Storegis hier immer einige Möglichkeiten durchprobiert, aber für die Denga10-Platinen ist eine Baudrate von 115200 eigentlich meistens die beste Wahl. Manchmal habe ich aber auch schon problemlos mit 230400 gearbeitet. Nach dieser Vorauswahl bezüglich des VCP klickt man schließlich auf die Schaltfläche "Synchronization" (die angedeutete Rechteckfunktion ganz links unter dem schwarz hinterlegten Anzeigefeld), und wenn Storegis auf diesem VCP dann ein Weilchen später das gewünschte Nachrichtenformat empfangen konnte, erscheint in diesem Anzeigefeld die Meldung "Connection Ok". Hier sieht man übrigens auch (ganz oben bei "device:") die Modul- und Firmware-Version des NV08C-CSM. Aber zum Thema Firmware schreibe ich dann noch einen extra Beitrag ...

Dann hat Storegis seinen Dienst eigentlich auch schon getan. Man könnte jetzt natürlich noch mal die Schaltfläche "Record" betätigen, dann wird der VCP erneut geöffnet und damit eine Aufzeichnung als *.dat-Datei im aktuellen Verzeichnis der Storegis-EXE-Datei geschrieben (Aber Achtung: Diese Dateien sind jedoch nicht als Rohdatenaufzeichnung z.B. für die Postprozessierung verwendbar!). Wenn man möchte, kann man hierbei auch die entsprechenden Häkchen für "SATELLITES", "VISUAL" und "S/N RATIO" setzen und sich mal anschauen, was man aktuell so an Satellitensignalen hereinbekommt. Aber ansonsten genügt es, sich den für BINR verwendeten VCP zu merken, um ihn dann später z.B. mit RTKNAVI zu öffnen, denn schließlich will man ja eben dies, nicht wahr?

Ein kleiner Hinweis noch zu den VCP bzw. dem Wirken der FTDI-Treiber in der Windows-Registry:
Wenn man mal ein Paar von VCP (z.B. COM18 und COM19) für diesen FT2232D hat, muss das nicht zwingend bedeuten, dass dies auch für immer so bleibt! So gut die FTDI-Treiber sonst auch sind, hier kann es schon mal passieren, dass man irgendwann auch wieder neue VCP eingerichtet bekommt. Typischerweise z.B. dann, wenn man einfach nur mal eine andere USB-Buchse am Rechner bzw. am USB-Hub verwendet. In dieser Hinsicht ist man ja vom USB-Treiber für die GNSS-Empfänger von u-blox so verwöhnt, da bleibt der einmal eingerichtete VCP eigentlich für alle Ewigkeiten erhalten und erspart einem damit im Alltag auch viel Konfigurationsaufwand. Bei den FTDI-Treibern muss man da immer etwas aufpassen. Am besten ist eigentlich, man schließt gar nicht erst das Fenster mit dem Geräte-Manager der Windows-Systemsteuerung, dann genügt meistens schon ein kurzer Blick dort hinein ...

Bis später & mit besten Grüßen,
Hagen
Dateianhänge
nvs-gnss-konfiguration-011.png
VCP mit Storegis öffnen: Ergebnisanzeige
nvs-gnss-konfiguration-011.png (4.49 KiB) 35069 mal betrachtet
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:

NV08C-CSM : Firmware-Versionen u. Initialisierungs-Sequenzen

Beitrag von Hagen.Felix » 16.09.2012 - 20:16

So, diesen eigenen Beitrag zum Thema der Firmware hatte ich ja schon angekündigt ....

Zunächst mal ist es natürlich eine völlig plausible Strategie, sich als Anwender des NV08C-CSM ganz einfach die aktuell vom Hersteller selbst unter http://www.nvs-gnss.com/support/firmwar ... mware.html veröffentlichte Version zu holen. Dort lässt sich ohne jede Hürde die entsprechende *.bin-Datei herunterladen, ggfs. in Form eines *.zip-Archivs, aus dem sie dann erst mal, z.B. mit der Freeware "7-zip" oder mit Bordmitteln wie dem Windows-Kontextmenü, entpackt bzw. extrahiert werden muss.

Welche Firmware-Version man momentan auf seinem NV08C-CSM hat, erkennt man ja nach einer erfolgreichen BINR-VCP-Ansprache mit Storegis; siehe Bild im vorigen Beitrag, dort steht die derzeit offizielle Version 2.05 ja in der obersten Zeile "device:" (zunächst der Modultyp "CSM23", dann eben die Firmware-Versionsnummer und schließlich das Veröffentlichungsdatum dieser Firmware).

Mit der jeweils von NVS selbst veröffentlichten Version liegt man gewiss nicht wirklich falsch, aber bis zur Veröffentlichung einer neueren Version könnte es ggfs. auch Zwischenschritte geben, die zwar nicht offiziell sind, aber trotzdem schon etliche Verbesserungen beinhalten. Eine solche Vorgehensweise ist bei Software jeglicher Art ja schon länger nicht ganz unüblich, diese sogenannten Beta-Versionen eben: mehr oder weniger frei verfügbar, aber immer auch unter dem Vorbehalt möglicher Fehler, für die der Hersteller hier ganz sicher auch noch keinerlei Verantwortung übernehmen möchte ...

So ist es derzeit jedenfalls auch mit der Firmware des NV08C-CSM. Hier haben die Jungs von NVS, mit denen zusammen Michele ja momentan an der passenden Rohdatenausgabe für RTK & Co. arbeitet, zwischendurch schon mal einen Entwicklungsstand kompiliert, dessen angezeigte Versionsnummer zwar verwirrend niedrig ist, in dem jedoch trotzdem schon solche Dinge wie z.B. die SBAS-Rohdaten realisiert sind. Beispielsweise hierin hat nämlich die aktuelle v.02.05 ja noch ein paar Lücken, das wird denjenigen auch aufgefallen sein, die schon mal eine SBAS-Nutzung z.B. für PPP mit RTKNAVI (Aber Achtung: bislang sowieso nur mit "rtknavi_mb.exe" möglich, weitere Erläuterungen dazu folgen in Kürze) versucht haben ...

Solche Beta-Versionen sind auf Anfrage ggfs. auch bei mir vorhanden, so dass ich z.B. dann einen Empfänger mit dem NV08C-CSM auch gleich mit der jeweils am weitesten entwickelten Firmware ausliefern kann, sinnvollerweise direkt zusammen mit den passenden RTKLIB-Kompilaten und den zugehörigen Initialisierungs-Sequenzen.

Aber ein Firmware-Update ist beim NV08C-CSM ein solches Kinderspiel, dass davor wirklich niemand Angst haben muss! Lediglich ein Ausschalten des NV08C-CSM direkt während des Aktualisierungsvorgangs sollte man natürlich tunlichst vermeiden ...

Das Aktualisierungsprogramm "PatchWriter" von NVS (http://www.nvs-gnss.com/support/soft/it ... riter.html) funktioniert einfach und sicher, am besten auch über den BINR-VCP. Die Bedienung ist tatsächlich selbsterklärend und der aktuelle Vorgangsstatus wird unmissverständlich angezeigt, ich hatte mit dem PatchWriter jedenfalls noch nie irgendwelche Probleme. Und wenn fertig angezeigt wird, ist es auch fertig und die soeben aufgespielte Firmware sitzt fest und sauber im NV08C-CSM!

Und nun zu den schon mehrmals erwähnten Initialisierungs-Sequenzen. Diese sind ja schließlich auch kein Hexenwerk, sondern nur ein paar schnöde Zeilen, die im RTKNAVI bestenfalls einmalig hinterlegt werden müssten, und so sieht das dann dort beispielsweise aus:
Dateianhänge
nvs-gnss-konfiguration-017.png
NV08C-CSM Initialisierungs-Sequenzen
nvs-gnss-konfiguration-017.png (13.97 KiB) 35061 mal betrachtet
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 » 23.09.2012 - 13:17

Hallo zusammen,

ich habe den NVS zusammen mit der TW2410 in einer längeren Messreihe im RTK-Betrieb (http://gibs.bkg.bund.de/gref/gstainfo.php?st=7) beobachtet und wollte hierzu nun im Forum berichten. Hierbei ging es mir besonders um die Wiederhohlgenauigkeit. Dazu habe ich eine 13 tägige Gesamtmessung in 12 Tagesscheiben geschnitten und grafisch dargestellt. Die Antennenposition blieb dabei absolut unverändert. In der Regel hatte ich FIX-Solutions zwischen 96-98%. Nur an einem Tag mit ganztätigem staken Regen waren es nur 15% und der Rest nur FLOAT. Die Abweichung betrug an diesem Tag über 48 cm, gegenüber den sonstigen max. 2 cm. Ich habe ihn deshalb nicht im Diagramm dargestellt. Hier bestätigt sich wieder, GNSS-Messungen bei stärkerer Nässe sind vorsichtig zu bewerten.
RTK_Auswertung.png
RTK_Auswertung.png (29.17 KiB) 34968 mal betrachtet
Eine weitere Erfahrung war, dass Glonass (zumindest mit RTKLIB 2.4.1 und nur L1) bei langfristigen Messungen mit RTK die Genauigkeit vermindert. Das mag wohl an den fehlenden präzisen Bahndaten und weniger genau gehenden Satellitenuhren liegen. Sobald die finalen Ephemeriden vom IGS verfügbar sind (dauert ja immer zwischen 12-18 Tagen), werde ich hier aber nochmal nachrechnen. Im PPP-Betrieb (NTRIP Broadcaster) bringen die zusätzlichen Satelliten aber eine deutliche kürzere Einschwingzeit.

Parallele Messungen mit den NVS an einer Bullet III Antenne haben gezeigt, dass diese ähnlich gute Ergebnisse bei RTK liefert. Die Glonass-Satelliten kann man dabei aber kaum verwenden, da sie (wenn überhaupt) mit sehr schwacher Feldstärke ankommen. Das spricht für die Trimbleantenne und ihren optimalen Bandpass für GPS-L1. Eine billige Patchantenne lieferte die Signale, hatte aber mit Multipath mehr Probleme.

Die TW2410 habe ich dann mit dem guten alten Skytraq getestet. Im Vergleich zum NVS konnten hier aber erheblich weniger FIX-Solutions bereitgestellt werden (weniger als 10%). Ich will das jetzt aber nicht überbewerten, da es an den beiden Messtagen auch stark geregnet hat.

Gruss
Bernd
Zuletzt geändert von B14 am 03.11.2012 - 14:21, insgesamt 1-mal geändert.

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

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von cr2_gps » 29.09.2012 - 09:59

B14 hat geschrieben: Eine weitere Erfahrung war, dass Glonass (zumindest mit RTKLIB 2.4.1 und nur L1) bei langfristigen Messungen mit RTK die Genauigkeit vermindert.
Um welche Hardware-Version handelt es sich bei deinem Empfänger: V2.1 oder V3.1 ?
Die Glonass-Satelliten kann man dabei aber kaum verwenden, da sie (wenn überhaupt) mit sehr schwacher Feldstärke ankommen. Das spricht für die Trimbleantenne und ihren optimalen Bandpass für GPS-L1. Eine billige Patchantenne lieferte die Signale, hatte aber mit Multipath mehr Probleme.
Bullet III ist auch nur eine teure Patchantenne, die ganze Bandfilterintelligenz steckt wohl in den LNA.
Die TW2410 habe ich dann mit dem guten alten Skytraq getestet. Im Vergleich zum NVS konnten hier aber erheblich weniger FIX-Solutions bereitgestellt werden (weniger als 10%).
Ein Vergleich mit ublox (4/6) konnte auch sehr interessant sein. Wie bei Gazprom wäre es unklug nur auf die lupenreinen Demokraten zu setzen :roll:

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 » 30.09.2012 - 08:29

cr2_gps hat geschrieben: Um welche Hardware-Version handelt es sich bei deinem Empfänger: V2.1 oder V3.1 ?
...
Diesbezüglich habe ich gestern extra noch mal bei Michele nachgefragt (wie auch vor einigen Monaten schon einmal), denn ich war ja auch etwas besorgt, ob diese Frage für unsere Zwecke relevant ist.

Michele, der ja (allerdings unter NDA) mit den Entwicklern von NVS direkt zusammenarbeitet, hat mir aber auch dieses weitere Mal ganz klar erklärt, dass der Unterschied zwischen V2.1 und V3.1 (deutlich am Aufdruck auf der Blechhaube des NV08C-CSM erkennbar, siehe Abbildung unten) nach seiner Informationslage nicht von Bedeutung ist für die von uns ausgeübte Nutzung als Trägerphasen-Rohdatenempfänger (z.B. in Verbindung mit der RTKLIB).

Es sind allerdings hardwareseitige Änderungen bei NVS in Arbeit, die dann auch diese Verwendungsart berühren werden. Konkret geht es dabei dann um das Problem des sogenannten "group delay" bei GLONASS bzw. einer entsprechenden Kalibration, aber bitte fragt mich nicht nach den theoretischen Grundlagen dazu ... :roll:

Ein wenig Literatur dazu ist hier zu finden:
http://webone.novatel.ca/assets/Documen ... ignals.pdf

Und noch mehr hier:
http://lea.hamradio.si/~s53mv/navsats/theory.html

Soweit erst mal dazu.
Mit besten Grüßen aus Grimma,
Hagen
Dateianhänge
Denga10LogWi-XBee868.jpg
Denga10LogWi-XBee868.jpg (106.84 KiB) 34731 mal betrachtet
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)

ssquare_de
Beiträge: 671
Registriert: 07.10.2006 - 16:23

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von ssquare_de » 30.09.2012 - 09:49

Hallo,

zum Thema "Inter frequency carrier phase biases" und ergänzend zu Hagens Links:

http://www.insidegnss.com/auto/mayjune12-Sleewaegen.pdf
http://www.biasws2012.unibe.ch/pdf/bws12_1.4.5.pdf
http://www.zvm.tu-dresden.de/die_tu_dre ... ss_jog.pdf
http://tu-dresden.de/die_tu_dresden/fak ... ureNow.pdf

Und hier ist auf Seite 6 die Problemstellung zusammengefasst und leicht verständlich formuliert :!: (Danke Tomoji :wink: )
http://www.denshi.e.kaiyodai.ac.jp/jp/a ... yamada.pdf

Stefan

savsic

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von savsic » 02.10.2012 - 20:35

Hallo,
Ich habe zwei NV08C beträgt 2,1 bis 3,1.
Durch integrierte Softwarelösungen RTKLIB von Michele Bavaro Ich habe sehr gute Ergebnisse sowohl im statischen oder kinematischen.
Mit Master-und Rover in 3 oder 4 Minuten, ich muss zentimetergenau.
Wirklich gut.
Er braucht ein wenig mehr Stabilität, um ein wenig mehr reifen. Besitzen auch Skytraq S1315F und uBlox 5 und 6.
Aber diese NVS GPS und Glonass ist eine andere Geschichte
Hallo
Saverio Siciliano

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

Antennenoptimierung

Beitrag von Josef Gerstenberg » 02.10.2012 - 22:19

Hallo Bernd,
In der Regel hatte ich FIX-Solutions zwischen 96-98%. Nur an einem Tag mit ganztätigem starken Regen waren es nur 15% und der Rest nur FLOAT. Die Abweichung betrug an diesem Tag über 48 cm, gegenüber den sonstigen max. 2 cm. Hier bestätigt sich wieder, GNSS-Messungen bei stärkerer Nässe sind vorsichtig zu bewerten.
Bernd, man muss GNSS-Messungen bei Nässe nicht vorsichtig bewerten, sondern man muss eine gute Antenne haben!

Patch-Antennen ohne etwas Drumrum sind Schönwetter-Antennen, so meine leidvolle langjährige Erfahrung!

Warum das so ist, erläutere ich mal ein wenig:
- Ist es unter der Antenne "schön" trocken, werden von dort 0-10% der Satelliten-Signale gespiegelt und gelangen von unten an die Antenne.
Das Signal-Durcheinander kann ein GNSS-Empfänger und ein Postprozessig-Programm auseinander halten, da das Verhältnis > 10:1 beträgt.
- Ist es unter der Antenne richtig nass (ein Wasserfilm, Wasser, Eis, nasser Schnee), werden von dort 90-100% der Satelliten-Signale gespiegelt und gelangen von unten an die Antenne.
So ein Signal-Durcheinander kann ein GNSS-Empfänger und ein Postprozessig-Programm nicht mehr auseinander halten, da das Verhältnis > 10:9 beträgt.

Was kann man tun?
1. Eine simple Groundplane aus Metall hilft nicht, egal wie groß sie ist!!!
2. Im professionellen stationären Bereich werden in großer Höhe montierte große, schwere und teure Choke-Ring-Antennen eingesetzt.
3. Im professionellen beweglichen Bereich werden z.B. Antennen mit "sanftem" Groundplane-Rand (Trimble-Zephyr) oder "verschluckenden" sekundären Antennenelementen (NovAtel) verwendet.

Fazit:
- Entweder einen kleinen Chokering um eine simple Patch-Antenne machen (habe ich gemacht und funktioniert gut). Ist frei von Patenten.
- oder z.B. eine sanfte Groundplane aus unterschiedlich leitenden Graphitfolien (gibts es für Fußbodenheizungen) basteln. Da gibt es diverse Patente.
- oder eine professionelle Antenne kaufen.

Soweit dazu,
Josef

Deichgraf
Beiträge: 506
Registriert: 09.02.2006 - 13:22

Re: Rohdaten-Anwendungen mit dem NVS NV08C-CSM

Beitrag von Deichgraf » 03.10.2012 - 12:06

B14 hat geschrieben:....
Eine weitere Erfahrung war, dass Glonass (zumindest mit RTKLIB 2.4.1 und nur L1) bei langfristigen Messungen mit RTK die Genauigkeit vermindert. Das mag wohl an den fehlenden präzisen Bahndaten und weniger genau gehenden Satellitenuhren liegen....

Gruss
Bernd
... was ist der Unterschied zwischen einer Atomuhr und einer genauer gehenden Atomuhr?

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

Antworten