NV08C-RTK

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

Moderator: Roland

Benutzeravatar
spunky
Beiträge: 172
Registriert: 06.10.2013 - 11:30

Re: NV08C-RTK

Beitrag von spunky » 03.05.2016 - 13:16

Spielt es eine Rolle, wenn (wie jetzt) die Basis mit einem L2 Empfänger versorgt wird, wird dadurch das Ergebnis geschönt?
Wie sieht das Ergebnis aus, wenn Rover mit L2 und Basis mit L1 läuft?
Wie sieht das Ergebnis aus, wenn als Rover und Basis ein L1 Empfänger verwendet wird?
Wie lange läuft so eine Messung?
Interessant für die meisten Anwender ist die Spur-zu-Spur Abweichung innerhalb von 15 min und wie lange die Vorlaufzeit dafür ist, hast du Daten darüber?

MfG.

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

Re: NV08C-RTK

Beitrag von Hagen.Felix » 03.05.2016 - 18:30

spunky hat geschrieben:Spielt es eine Rolle, wenn (wie jetzt) die Basis mit einem L2 Empfänger versorgt wird, wird dadurch das Ergebnis geschönt?
L2-only? Theoretisch vielleicht denk- oder konstruierbar, in der Praxis aber wohl niemals zu erwarten. :mrgreen:

Ein System, das L2 empfangen und verarbeiten kann, hat für die jeweiligen Satellitensysteme daher auch immer schon L1 mit dabei. :wink:

Wenn mit einem reinen L1-Rover (wie z.B. der NV08C-RTK) eine Mehrfrequenz-Basis genutzt wird, bleibt der L2-Anteil in den Referenzdaten vom Rover eben ungenutzt.

Es ist also völlig egal, ob eine Basis nur L1 oder auch noch L2 (sowie ggfs. L2C und/oder L5) hat: Der L1-Rover verwendet immer nur den L1-Anteil.

Umgekehrt wäre aber dämlich. :roll:

Da nämlich der Rover (genauer gesagt die RTK-Engine, also "nur" Software, in der jedoch die wertvollsten und daher auch am besten gehüteten Arbeitsergebnisse des jeweiligen Herstellers stecken) das eigentlich preistreibende Element in RTK-Systemen ist, wäre es ziemlich blöd, einen sauteuren Mehrfrequenz-Rover an eine reine L1-Basis zu hängen ... :shock:

Zumal die Anbieter von Mehrfrequenz-Hardware (typischerweise als OEM-Platinen) deren Preise nach Leistungsmerkmalen gestalten, die dann mit kryptografischen Schlüsseln auf der einzelnen Platine freigeschaltet werden können, wobei eine Platine mit 1 Hz Rohdatenausgabe für L1+L2 (also wie für eine RTK-Basisstation benötigt) eben auch wesentlich kostengünstiger ist als die ansonsten völlig baugleiche Platine mit Freischaltung der RTK-Engine als Rover (sowie ggfs. mit höherer Update-Rate).

Was die sogenannte "Spur-zu-Spur-Genauigkeit" betrifft, so ist das für mich zumeist auch alles nur Hokuspokus und fauler Zauber. :evil:

Wer jemals auf einer Agritechnica war, wird diesbezüglich gewiss auch schon jegliche Phantasiezahlen von diversen Landtechnik-Verkäufern vernommen haben ... :roll:

Ein rabiater Software-Filter kann in dieser Hinsicht eigentlich immer etwas erreichen, was zunächst beeindruckend erscheint, auf den zweiten Blick aber dennoch relativ wertlos ist.

Gleichwohl gibt es durchaus seriöse Lösungen für den Spezialfall der Parallelführung im Ackerbau (z.B. "GLIDE" von NovAtel), denen ein gewisser Praxisnutzen kaum absprechbar sein dürfte ... :mrgreen:

Siehe z.B. unter http://www.novatel.com/assets/Documents ... /GL1DE.pdf bzw. http://www.novatel.com/assets/Documents ... D12139.pdf

Allerdings: Wer RTK tatsächlich auch unter Praxisbedingungen zuverlässig nutzen kann (was mit RTKNAVI "vanilla" insbesondere im kinematischen Modus aber eigentlich kaum realistisch ist), braucht sowieso nicht an irgendeine "Spur-zu-Spur-Genauigkeit" denken, denn er ist ja ohnehin schon immer genau.

Nämlich ganz genau. :D

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)

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

ICBGLO für VRS

Beitrag von Hagen.Felix » 24.05.2016 - 23:46

Hagen.Felix hat geschrieben:... weder für Trimble (wäre ca. 0,16 bis 0,18) noch für NovAtel/Leica (0,0) typisch ...
Akuter Zeitmangel leider ziemlich chronifiziert, daher nur ein kurzer Zwischenstand an dieser Stelle. :roll:

Mittlerweile sind nun ja schon wieder etliche NV08C-RTK in freier Wildbahn unterwegs, und damit auch im Zusammenspiel mit den jeweiligen SAPOS-Netzen von weiteren Bundesländern. :wink:

Damit scheint sich auch der Trend zu bestätigen, den mir NVS schon vorhergesagt hatte. :D

Ganz grob gesagt, läuft es wohl doch zumeist auf Trimble vs. Leica hinaus, wobei zusätzlich NovAtel=Leica sowie NovAtel=NVS gilt. :mrgreen:

(Kleiner Hinweis dazu am Rande: NVS hat sich bei der Entwicklung bzgl. GLONASS-ICB nach eigener Aussage selbst an NovAtel orientiert.)

Selbst wenn man (noch) keine Prüfmessungen mit VRS eines bestimmten Bundeslands hat, kann es durchaus schon genügen, einfach mal in Erfahrung zu bringen, mit welcher Hardware die SAPOS-Referenzstationen dieses Bundeslands arbeiten.

Mit etwas Glück (wie ich es z.B. gerade erst vor ein paar Tagen selbst haben durfte) bekommt man diesbezüglich vielleicht sogar gleich auf Anhieb eine solch fundierte Antwort:

"Zunächst kann ich Ihnen zu Ihrer Anfrage mitteilen, dass das SAPOS-Netz in Rheinland-Pfalz mit 16 Stationen ausschließlich mit Empfängern des Typs Leica GR25 bestückt ist.
Insofern sollte die Bestimmung bzw. die Anbringung des ICB für Sie kein Problem sein, soweit es Rheinland-Pfalz betrifft.
...
Die Verwendung des ICB-Wertes ist, wenn ich mir diese Anmerkung erlauben darf, auch für statische Messungen wichtig.
Kombiniert mit GPS und GLONASS gemessene Verfahren scheitern bei der Auswertung häufig an einem falschen ICB, so dass letztlich in vielen Fällen nur mit GPS ausgewertet werden kann.
Zumindest ist dies unsere Erfahrung."


Davon dann der dementsprechende ICBGLO abgeleitet und flugs am NV08C-RTK eingestellt, und fertig ... :mrgreen:

Wenn man somit den zur jeweiligen Basis (bzw. dem der jeweiligen VRS zugrundeliegenden Referenznetz) passenden ICBGLO-Wert gesetzt hat, wobei dann natürlich auch ICBMODE,0 gelten muss, sind die RTK-Ergebnisse in der alltäglichen Praxis jedenfalls zumeist richtig gut!

Das ist inzwischen nicht nur meine eigene (vielfach wiederholte) Erfahrung, sondern auch die schon etlicher Anwender in diversen deutschen Bundesländern (sowie ebenso im europäischen Ausland).

Auf der anderen Seite der Medaille gibt es jedoch durchaus frustrierende Ergebnisse, wenn der festgesetzte ICBGLO-Wert nicht passt ... :shock:

In solchen Fällen (und natürlich auch bei noch gänzlich unbekanntem ICBGLO) sollte daher eher mit ICBMODE,1 gearbeitet werden. :!:

Mit ICBMODE,1 (und evtl. sogar auch mit ICBMODE,2) kann zudem erkundet und/oder verifiziert werden, in welcher Dimension sich der tatsächliche ICBGLO-Wert bei der jeweiligen Basis (bzw. dem der jeweiligen VRS zugrundeliegenden Referenznetz) befindet. :idea:

Hierzu bedarf es allerdings auch der entsprechenden Nachrichtenausgabe beim NV08C-RTK ... :wink:

Viele Grüße,
Hagen
Dateianhänge
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-1-part.png
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-1-part.png (14.63 KiB) 32183 mal betrachtet
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-2-part-1.png
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-2-part-1.png (9.45 KiB) 32183 mal betrachtet
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-2-part-2.png
2016-04-06-NV08C-RTK-G5Ant-72AT1-SAPOS-TH-2-part-2.png (38.4 KiB) 32183 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:

ICBGLO im VRS-Betrieb

Beitrag von Hagen.Felix » 09.06.2016 - 09:47

Hagen.Felix hat geschrieben:Die automatische ICBGLO-Anpassung mittels $PNVGRTK,ICBMODE,1 führte übrigens zu den Werten 0,114 (SAPOS BB) sowie 0,13 (SAPOS ST) ...
Nach und nach werden die passenden ICBGLO-Werte für immer mehr VRS-Anbieter bekannt, insbesondere natürlich die jeweiligen SAPOS-Dienste der einzelnen deutschen Bundesländer. :D

Um noch mal den bisherigen Schwierigkeiten mit SAPOS HEPS von Sachsen-Anhalt (Mountpoint-Suffix "ST") etwas gründlicher auf den Grund gehen zu können, habe ich vorgestern mal wieder eine dieser etwas aufwändigeren Testmessungen durchgeführt.

Wie üblich dabei mit einer ordentlichen Antenne (navXperience 3G+C) in relativ unbeeinträchtigter Umgebung, an der per Splitter (Tallysman TW150) sowohl ein NV08C-RTK als auch ein NovAtel OEM628 (mit Firmware-Option RT-2 für GPS und GLONASS) angeschlossen waren, die beide vom gleichen Ntrip-Client mit denselben RTCM-Daten versorgt wurden.

Wie ich es mit SAPOS ST ja leider schon öfter erlebt hatte, tat sich der NV08C-RTK auch diesmal ziemlich schwer damit, einen RTK-Fix zu erreichen.

Nach einiger Zeit gelang es mir gestern jedoch, und im direkten Vergleich mit dem OEM628 gibt es am Ergebnis ja auch nix zu meckern, nicht wahr?

Interessant ist jedoch v.a. der vom NV08C-RTK (mittels ICBMODE,1) gefundene ICBGLO,0.146 für diesen RTK-Fix!

Ich habe alle Daten (Rohdaten von SAPOS, NVS und NovAtel) mittlerweile auch schon an NVS gesendet.

Mal sehen, ob mir die Jungs in Moskau mit einer Analyse dieser Daten einen ICBGLO-Wert in dieser Dimension bestätigen können.

Dies ist jedenfalls eine Größenordnung, die schon relativ typisch für Trimble-Hardware im SAPOS-Stationsnetz von Sachsen-Anhalt wäre …

Ich melde mich aber auf jeden Fall noch mal, wenn ich eine Rückmeldung von NVS zu diesen Daten bekommen habe.

Bis dahin kann man allerdings ja durchaus auch schon versuchsweise (bzw. unter Vorbehalt) mit ICBGLO,0.146 arbeiten …

Code: Alles auswählen

$PNVGRTK,ICBGLO,0.146*63
Viele Grüße,
Hagen
Dateianhänge
2016-06-07-NV08C-RTK-SAPOS-ST-1-small.png
2016-06-07-NV08C-RTK-SAPOS-ST-1-small.png (37.84 KiB) 32117 mal betrachtet
2016-06-07-NV08C-RTK-SAPOS-ST-5-small.png
2016-06-07-NV08C-RTK-SAPOS-ST-5-small.png (51.18 KiB) 32117 mal betrachtet
2016-06-07-NV08C-RTK-vs-OEM628-SAPOS-ST-small.png
2016-06-07-NV08C-RTK-vs-OEM628-SAPOS-ST-small.png (9.05 KiB) 32117 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:

ICBGLO mit SAPOS ST

Beitrag von Hagen.Felix » 10.06.2016 - 18:16

Hagen.Felix hat geschrieben:Bis dahin kann man allerdings ja durchaus auch schon versuchsweise (bzw. unter Vorbehalt) mit ICBGLO,0.146 arbeiten …
Moskau hat seinen Segen gegeben. :mrgreen:

"Hi Hagen, ...
ICBGLO = 0.146 looks very good for this VRS. Below pictures show results of log-file processing.
Best regards, Nikolay"
:D

Viele Grüße,
Hagen
Dateianhänge
OEM628.png
OEM628.png (40.29 KiB) 32091 mal betrachtet
NV08C-RTK-GPS.png
NV08C-RTK-GPS.png (39.91 KiB) 32091 mal betrachtet
NV08C-RTK-GPS+GLO@ICBGLO,0.146.png
NV08C-RTK-GPS+GLO@ICBGLO,0.146.png (39.5 KiB) 32091 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:

ICBGLO für SAPOS Hessen

Beitrag von Hagen.Felix » 11.08.2016 - 07:43

NVS hat geschrieben:... yesterday we have tested NV08C-RTK with SAPOS Bayern mount-point VRS_3_2G_BY and detected ICBGLO = 0.16 with this mount point.
...
Both mount-point shows using of Trimble Pivot Platform as VRS-generator.
But GLONASS Inter-Channel Bias is varied for different areas.
It looks SAPOS uses GNSS receivers from different manufacturer in their network:
...
- VRS_3_2G_BY looks like Trimble
SAPOS Hessen verwendet selbst Trimble-Hardware, bindet in seine Vernetzungssoftware jedoch auch Daten von SAPOS-Stationen aus benachbarten Bundesländern ein, welche in der Nähe der Landesgrenze zu Hessen liegen (z.B. SEPTENTRIO von Niedersachsen sowie LEICA von Bayern und Rheinland-Pfalz).

In den meisten Fällen sollte für SAPOS HEPS Hessen (Mountpoint VRS_3_2G_HE) also ein Trimble-typischer Wert die besten Ergebnisse liefern können. :wink:

Wobei $PNVGRTK,ICBGLO,0.16 m.E. auch noch nicht zwingend der Idealwert sein muss!

Bereits aus eigenen Erfahrungen in anderen Bundesländern könnte z.B. auch ein Wertebereich zwischen 0,14 und 0,18 noch immer zu Trimble-Hardware passen (und in Hessen ja vielleicht sogar noch darüber hinaus in irgendeiner Richtung) …

Insbesondere in den entsprechenden Randbereichen von Hessen könnte sich der konkrete ICBGLO-Optimalwert ohnehin auch noch etwas verschieben.

Dann könnten eigene Tests, die auch sonst ja immer durchaus nützlich wären, das sinnvollste Mittel der Wahl sein (mehrfaches Herantasten mit $PNVGRTK,ICBMODE,1 oder auch $PNVGRTK,ICBMODE,2 unter möglichst idealen Empfangsbedingungen) … :idea:
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:

SFMODE ./. CoG+VC

Beitrag von Hagen.Felix » 23.08.2016 - 11:46

In den vergangenen Tagen hat sich ein böses kleines Fehlerchen der aktuellen Firmware (v.0027) gezeigt.

Und zwar bewirken manche Einstellungen des SFMODE, dass für CoG (Course over Ground) und Geschwindigkeit immer nur Nullwerte ausgegeben werden (z.B. in den NMEA-Nachrichten RMC und VTG). :shock:

Code: Alles auswählen

Secondary filter mode:

0 (by default) – DISABLE: Output coordinates correspond to the current position type (3D/Float/Fix) with possible discontinuity in the position when the receiver transitions from one position type to another one.

1 – RETAIN: Retain the relative offset of the position. There is no discontinuity in the position when the position type changes. Any offset in the position is maintained.

2 – TRANSITION: The position will slowly transition to the new position type with the transferring speed specified by the Transfer Speed parameter. There is no discontinuity in the position when the position type changes.

3 – HYBRID: TRANSITION mode when changing from less accurate positioning type to more accurate position type. RETAIN mode when changing from more accurate positioning type to a less accurate positioning type.
Einfachste und schnellste Lösung: SFMODE erst mal ausschalten. :wink:

Es gibt auch schon eine Vorab-Version der nächsten Firmware (PR0028), in der dieser Fehler behoben wurde.

Ich persönlich würde damit aber vielleicht noch warten, denn eine reguläre v.0028 müsste NVS ja eigentlich recht bald bereitstellen … :roll:

Mit besten Grüßen 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)

Merowech
Beiträge: 4
Registriert: 08.10.2016 - 10:31

Re: NV08C-RTK

Beitrag von Merowech » 26.10.2016 - 09:09

Spannender Beitrag! Ich überlege ob ich meinen Receiver-Bestand um einen NV08C-RTK erweitere...
Gibt es für das Glonass ICB-Problem eigentlich für u-blox-Receiver auch eine Möglichkeit zur Eingabe von Korrekturwerten? Oder gehört das eher in die Software (also z.B. rtklib)?

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

Re: NV08C-RTK

Beitrag von Hagen.Felix » 03.11.2016 - 08:50

Merowech hat geschrieben:Gibt es für das Glonass ICB-Problem eigentlich für u-blox-Receiver auch eine Möglichkeit zur Eingabe von Korrekturwerten? Oder gehört das eher in die Software (also z.B. rtklib)?
Das müsste ggfs. die RTKLIB übernehmen.

Siehe z.B. hier:

https://rtklibexplorer.wordpress.com/20 ... on-part-1/

https://rtklibexplorer.wordpress.com/20 ... receivers/

Bei gleicher Hardware für Base & Rover (also z.B. 2 * M8T) kann das Problem aber vernachlässigt werden.

Unterschiedliche Antennen fallen hingegen kaum ins Gewicht.

Erfahrungsgemäß entstehen die wirklich harten Brocken aber nur dort, wo die VRS mittels Trimble-Hardware in den zugrundeliegenden Referenzstationen erzeugt wird.

Die meisten anderen der verbreiteten Hersteller (v.a. Leica) sind eher "ICBGLO-neutral" ... :wink:
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:

FW 0028 (wichtig wg. GLONASS-Schaltsekunde!)

Beitrag von Hagen.Felix » 08.01.2017 - 14:36

Hagen.Felix hat geschrieben:... eine reguläre v.0028 müsste NVS ja eigentlich recht bald bereitstellen … :roll:
Es hat leider etwas länger gedauert damit. :cry:

Tatsächlich habe ich erst gestern folgenden Hinweis von NVS bekommen:

„Hi Hagen,
Please be informed RTK FW 0028 (NV08C-RTK and NV08C-RTK-A compatible) is now available:
http://nvs-gnss.com/support/firmware/it ... ad/88.html
We recommend to use this FW in order to guarantee stable operation of NV08C-RTK devices after recent UTC / LEAP SECONDS correction (which was happened at 00:00 UTC time, January 1, 2017).
Best regards, Nikolay“


Ich habe dann natürlich auch gleich versucht, diejenigen Anwender eines NV08C-RTK(-A), deren Gerät damit von mir angefertigt wurde, schon direkt zu informieren.

Denn wer um diese Schaltsekunden-Problematik nicht weiß und sich seit Silvester ggfs. rat- und hilflos fragt, warum die Kiste überhaupt gar keinen RTK-Fix mehr bekommt, ist vielleicht doch schon etwas frustriert ... :cry:

Ein paar Hintergründe dazu hat z.B. NovAtel in einer entsprechenden Benachrichtigung veröffentlicht:
http://www.novatel.com/assets/Documents ... n-2016.pdf

Nur ein kleiner Schritt auf der Uhr, aber umso gewaltiger in der Auswirkung auf RTK-Geräte, sofern diese denn mit GLONASS arbeiten. :wink:

Dass die Russen (im Gegensatz zu allen anderen GNSS auf der Welt) nicht nur unterschiedliche Frequenzen für alle einzelnen Satelliten nutzen, sondern auch die UTC-Schaltsekunden übernehmen, macht GLONASS eigentlich gleich doppelt problematisch.

Da letzteres ja aber gar nicht überraschend kommt, ist es schon etwas ärgerlich, dass NVS dies nicht schon länger vorher in ihrer Firmware berücksichtigt hat (wie es z.B. NovAtel offensichtlich bereits Jahre im Voraus tat) … :twisted:

Nun gut, wie üblich beim NV08C-RTK(-A), ist für Firmware-Updates deren Software nutzen:
http://nvs-gnss.com/support/soft/item/2 ... riter.html

Es ist zwar nicht per se zwingend notwendig, aber bei schon in fertigen Geräten eingebauten NV08C-RTK(-A) m.E. trotzdem äußerst sinnvoll, Firmware-Updates möglichst immer nur noch über deren integrierten USB-Port durchzuführen.

Hierzu sollte vorher allerdings schon der USB-Treiber von NVS installiert worden sein, siehe (ganz unten auf der Seite):
http://nvs-gnss.com/products/receivers/ ... c-rtk.html

Ob ein NV08C-RTK(-A) nach einem Firmware-Update noch immer seine vorherige Konfiguration hat, vermag ich nicht sicher abzuschätzen.

Daher habe ich mir auch angewöhnt, anschließend immer gleich wieder eine komplette (ggfs. geräte- und/oder anwendungsspezifische) Konfiguration auf das Modul zu übertragen und dort dauerhaft zu speichern:
https://www.optimalsystem.de/os/pics/Op ... h-Proc.png

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)

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

NV08C-RTK Firmware 0028

Beitrag von Hagen.Felix » 10.01.2017 - 17:24

Leider habe ich (trotz Nachfrage hierzu) noch kein Changelog von NVS zu dieser Firmware bekommen. :(

Natürlich darf vermutet werden, dass in einem solchen Kompilat alle möglichen Verbesserungen und/oder Fehlerbehebungen enthalten sind, die seit der letzten Version realisiert werden konnten.

Wobei es diesmal vielleicht auch nicht allzu viele Änderungen waren, denn offenkundig war (und ist) NVS mit dem neuen NV08C-RTK-M wohl ziemlich beschäftigt ... :wink:

Umso interessanter daher folgende Rückmeldung eines Anwenders aus Holland:

"Hello Hagen,
Good news, firmware 28 of the NV08C chip is drastically improving fix times for me.
The NV08C is immediately going into float modus after applying RTCM corrections, with FW 27 this wasn’t the case.
Sometimes even after 1000 RTCM messages no float with that firmware.
ICBGLO values are 0-0,004 range with my VRS provider.
(https://www.lnrglobalcom.nl/lnr-net)
Perhaps some information for your other clients.
Greetings,"


:D
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-RTK @ wide-lane VRS

Beitrag von Hagen.Felix » 01.02.2017 - 02:18

Die "Thüringer Revolution" (viewtopic.php?f=2&t=3686) weckt mittlerweile auch den Sportsgeist der Randfichten. :mrgreen:

So z.B. ein Nutzer des NV08C-RTK aus dem Vogtland, der ca. 37 km entfernt von der Thüringer Landesgrenze sitzt.

Eigentlich ja bereits viel zu weit für ein L1-RTK, aber dank guter Empfangsbedingungen (anständige Antenne oben auf dem Hausdach) offensichtlich doch nicht unüberwindbar ... :D

Zwei voneinander unabhängige Messungen im Abstand von etlichen Stunden, und beide erreichten den RTK-Fix jeweils schon nach relativ kurzer Zeit:
Dateianhänge
2017-01-31-NV08C-RTK-SAPOS-TH-wide-lane-1-mini.png
2017-01-31-NV08C-RTK-SAPOS-TH-wide-lane-1-mini.png (17.71 KiB) 31337 mal betrachtet
2017-01-31-NV08C-RTK-SAPOS-TH-wide-lane-2-mini.png
2017-01-31-NV08C-RTK-SAPOS-TH-wide-lane-2-mini.png (54.02 KiB) 31337 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)

Wade
Beiträge: 25
Registriert: 08.05.2016 - 10:57

Re: NV08C-RTK

Beitrag von Wade » 02.02.2017 - 00:52

Jetzt muss ich doch mal doof fragen wie das mit dem kostenlosem SAPOS außerhalb von Thüringen funktioniert? Hab irgendwo mal gelesen dass die das ziemlich streng mit der Landesgrenze halten, die Nutzung geht nur bis 10m außerhalb von Thüringen.
Geh das kostenlose SAPOS nun doch auch weiter außerhalb Thüringens? Was muss man beim Empfänger einstellen dass es funktioniert?
Bin hier nur 3km von der Grenze entfernt, würde mir gern nen L1 RTK System zusammenbauen. Da wär so nen kostenloses RTK Korrektursignal schon was feines zum rumspielen...

edit:
http://www.sapos.thueringen.de/01122016.php#Opendata
In den Thüringen benachbarten Bundesländern sind diese Daten und Dienste weiter kostenpflichtig. Aus diesem Grund ist die Nutzung der thüringischen "offenen Daten" deutlicher als bisher auf das Gebiet von Thüringen einzuschränken.

RTK-Messungen mit thüringischen Korrekturdaten waren bisher auch noch in großem Abstand außerhalb der Thüringer Grenzen möglich (z.B. bis Leipzig). Die Korrekturdaten der Nachbarstationen in den angrenzenden Bundesländern werden auch weiterhin zur Berechnung der Vernetzung genutzt. Ab dem Zeitpunkt der Freigabe der Daten werden nur noch Daten abgegeben, die in die Zuständigkeit Thüringens fallen. Bei RTK-Messungen ist dafür die vom Rover gesendete NMEA-Nachricht entscheidend. Diese enthält, wenn der Rover sich im Satellitenpositionierungssystem orientiert hat, eine ca. 10 m genaue Näherungsposition. Liegt die Position in Thüringen, wird der Nutzer mit dem SAPOS-TH-Caster verbunden und mit Korrekturdaten versorgt. Wird keine Position übertragen oder liegt diese außerhalb von Thüringen, dann wird der Nutzer abgewiesen.

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

VRS von SAPOS TH mit virtueller Position

Beitrag von Hagen.Felix » 02.02.2017 - 03:36

Wade hat geschrieben:... Bin hier nur 3km von der Grenze entfernt ...
Eine solch kurze Basislinie ist ja schon fast wie ein mittlerer Lottogewinn. :mrgreen:

Die Android-Software von Lefebure (https://play.google.com/store/apps/deta ... ient&hl=de) kann das beispielsweise.

Dort müsste man in den „NTRIP Settings“ bei „Reported Location“ statt „Get from External Receiver“ die Option „Manual Lat-Lon“ wählen und die Koordinaten der nächstgelegenen Position innerhalb der Thüringer Landesgrenzen eingeben (z.B. mit Google Earth suchen).

Die unter viewtopic.php?f=3&t=3626&start=30#p17597 ff. beschriebenen Messungen haben eine entsprechende Funktionalität der FeldLog-Software genutzt (welche allerdings auch nicht für beliebige Hardware zur Verfügung steht).

RTKNAVI kann es aber auch schon (Screenshot nur symbolisch, hier z.B. noch mit falschem Dezimaltrennzeichen):
Dateianhänge
RTKNAVI-Input-VRS-FakePos.png
RTKNAVI-Input-VRS-FakePos.png (14.67 KiB) 31306 mal betrachtet
Zuletzt geändert von Hagen.Felix am 03.02.2017 - 01:25, insgesamt 1-mal geändert.
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)

Wade
Beiträge: 25
Registriert: 08.05.2016 - 10:57

Re: NV08C-RTK

Beitrag von Wade » 02.02.2017 - 13:48

TOP Dankeschön :D
3km Baseline sind schon fein, noch lieber wäre es mir wenn die Bayern auch den Schritt gehen würden, aber das wird wohl nen nen paar Jahre auf sich warten lassen...

Da brauch ich nun nur noch passende Hardware. Hab dir die Tage ne Mail geschrieben, verkaufst du die Ublox M8T auch im "Rohzustand"? Würd den gern selber in ne Box verstauen, zum anschließen mittels USB an nen Tablet. Brauch da des Blootooth etc eigentlich nicht...

Antworten