RTKNAVI @ Windows via Bluetooth SPP

Fragen und Hinweise zu Software, die mit dem Thema GPS zu tun hat. Egal ob PC oder Handheld.

Moderator: Roland

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

RTKNAVI @ Windows via Bluetooth SPP

Beitrag von Hagen.Felix » 14.07.2014 - 22:48

Während die Gewittergüsse der vergangenen Tage nicht nur die Fußballzuschauer im Freien, sondern auch die GNSS-Datensammler ein wenig geärgert haben, bin ich mal etwas um ein Problem herumgeschlichen, das vielleicht auch schon mal jemand von euch zu spüren bekommen hatte ...

Und zwar den speziellen Fall, einen seriellen Input in RTKNAVI über das Bluetooth Serial Port Profile (SPP) öffnen zu wollen und dann leider nur folgende Fehlermeldung lesen zu können:

(1) getconfig error (87)

Zumindest dürfte das vielleicht schon mal irgendeinem Nutzer passiert sein, der einen Windows-Computer mit dem Bluetooth-Stack von Microsoft verwendet ... :roll:

Das heißt allerdings nicht, der jeweilige COM-Port würde gar nicht funktionieren, denn greift man darüber z.B. mit dem u-center (sofern das GNSS-Empfängermodul eines von u-blox ist) oder auch StoreGis (bei einem NVS-Modul) zu, klappt es üblicherweise relativ problemlos, auch wenn das u-center in den ersten Sekunden dann gelegentlich vielleicht mal "einzufrieren" scheint, da SerialPort.Open() vermutlich den GUI-Thread blockiert ... :evil:

Die eigentliche Ursache dieses Problems liegt offenbar in der Datei stream.c von RTKNAVI. :cry:

Michele Bavaro (OneTalent GNSS) hatte ja in den vergangenen Jahren schon ab und zu mal eigene RTKLIB-Patches geschrieben und dabei zumindest das o.g. SPP-Problem erfolgreich beseitigen können, indem er dort eine entsprechende Änderung vorgenommen hatte. :D

Ich werde versuchen, Tomoji dahingehend zu motivieren, eine solchermaßen wirksame Änderung auch schon in seinem ursprünglichen Entwicklungspfad zu realisieren.

Dann könnte man sich jedenfalls die nachträgliche Frickelei mit derlei Patches (oder gar Workarounds) zukünftig ersparen ... :mrgreen:

Gleichwohl, noch ist es nicht soweit. :roll:

Daher nun erst mal ein paar Optionen, das Problem aus dem Wege zu räumen, sofern es doch mal auftreten sollte:


1) SPP-Port auf COM1 ändern

Gute Neuigkeiten vom Greifswalder Bodden: ein neuer Nutzer des NV08C-CSM via SPP am RTKNAVI (aber dafür schon mit viel QGIS-Erfahrung und offenbar einem "grünen Daumen" für Computer :D ) hat mir gerade seine Lösung mitgeteilt. :idea:

Und zwar genügt es offenbar, die Portnummer des für Bluetooth-SPP verwendeten COM-Ports im Geräte-Manager auf COM1 zu ändern. :!:

Den Warnhinweis des Betriebssystems, dass dieser Port bereits belegt sei, kann (und muss) man dabei getrost ignorieren, allerdings natürlich nur dann, wenn COM1 nicht wirklich schon (zeitgleich) für andere Zwecke zwingend benötigt wird.


2) Ein alternativer Bluetooth-Stack

Ich selbst habe jetzt auf einem Rechner (Win 8.1 x64), der den o.g. "getconfig error" mit dem Bluetooth-Stack von Microsoft verursacht hatte, mittels einer Installation von BlueSoleil (aktuelle Version 10) erfolgreich Abhilfe schaffen können.

http://bluesoleil.com/bssoftware/BSoftware.aspx

Dinu Berca, der Geodät aus Bukarest, von dem seit einiger Zeit schon diverse RtkGps-Forks bei mir eingetrudelt sind, kam zum gleichen Egebnis:
"Hi Hagen, I tested today the receiver connected over BT SPP. I didn't get any error, I got a fix very fast (1-2mins). All my BT dongles (I told you I got 3) need IVT Bluesoleil to work and I used the latest RTKLIB build (http://www.rtklib.com/prog/rtklib_2.4.2_p8.zip). If your customer uses a BT dongle he (it's this guy? http://lists.osgeo.org/pipermail/foss-g ... 01068.html) must use the orieginal drivers from the manufacturer, not the ones installed by windows."

Ich würde zudem davon ausgehen, dass auch die 9er Version von BlueSoleil für diesen Zweck genügen sollte, denn der in BlueSoleil 10 verwendete SPP-Treiber ist bereits so alt, dass er gewiss auch schon in der Vorgängerversion gewerkelt hatte ... :mrgreen:

Übrigens: in meinem Falle hatte die Installation von BlueSoleil den MS-Stack ohne weitere Rückfragen von der Zuständigkeit für die interne (via USB verbundene) Bluetooth-Hardware verdrängt. :shock:

Das kann aber durchaus auch unangenehme Nebenwirkungen haben, wenn plötzlich eine Standard-Funktionalität des Rechners komplett von einer Software übernommen wird, die leider ziemlich viele Negativ-Klischees einer in Fernost entwickelten Benutzeroberfläche erfüllt ... :roll:

Es ist aber vielleicht auch denkbar, BlueSoleil nur mit einer externen Bluetooth-Hardware zu verwenden, die lediglich bei Bedarf angeschlossen wird.

Möglicherweise ist alternativ aber z.B. auch die Bluetooth-Software von Toshiba ein probates Mittel für diesen Zweck.
Das müsste ich ggfs. noch mal überprüfen.


3) com0com (ggfs. in Kombination mit hub4com)

http://sourceforge.net/projects/com0com/files/
http://sourceforge.net/projects/com0com/files/hub4com/

Erfordert möglicherweise auch eine etwas mühselige Installation und Konfiguration, sollte dann aber schon dazu geeignet sein, das Auftreten des SPP-Problems im RTKNAVI zu vermeiden.

Bietet zudem auch gleich noch die Möglichkeit, den Bytestream des betreffenden COM-Ports parallel an (quasi beliebig viele) weitere Anwendungen weiterzuleiten, indem zusätzliche virtuelle COM-Ports (VCP) angelegt und entsprechend konfiguriert werden.

Ein kleiner Hinweis schon mal an dieser Stelle, dass die Installation unter 64-Bit-Versionen von Windows aufgrund der dort gegenüber den 32-Bit-Varianten verschärften Sicherheits-Mechanismen (Treiber-Signierung) möglicherweise noch etwas komplizierter ist ... :wink:


4) Franson GpsGate Client

http://gpsgate.com/products/gpsgate_client

Bis vor einigen Jahren habe ich selbst noch relativ viel damit gearbeitet, wenn auch damals nur mit NMEA-Daten. :roll:

Momentan habe ich das bis jetzt noch nicht für RTKNAVI-kompatible Binärdaten ausprobiert.

Ich habe jedoch von dritter Seite gehört, dass dies möglicherweise eine Alternative sein könnte ... :?:

Ergänzung
Von Asko Määttä (askomaatta.fi), einem professionellen "Wald-Kartierer" aus Finnland, habe ich gerade folgende Rückmeldung bekommen:
"Hi Hagen, I use Franson GPSGate with RTKNAVI and NEO-7P. It works fine also with binary code. But with NV08C-CSM Franson was useless :("



5) DIY : Write your own RTKNAVI patch ... :wink:

Die o.g. Lösung von Michele ersetzt folgenden Aufruf von GetDefaultCommConfig() in der Datei stream.c von RTKNAVI:

Code: Alles auswählen

if (!GetDefaultCommConfig(port,&cc,&siz))
{
        sprintf(msg,"getconfig error (%d)",(int)GetLastError());
        tracet(1,"openserial: %s\n",msg);
        CloseHandle(serial->dev);
        free(serial);
        return NULL;
}
durch einen Aufruf von GetCommConfig() an selbiger Stelle:

Code: Alles auswählen

if (!GetCommConfig(serial->dev,&cc,&siz))
...
Ich würde mich freuen, wenn vielleicht noch jemand hier im Forum seine Erfahrungen mit dieser speziellen Problematik schildern könnte ... :idea:

Viele Grüße,
Hagen
Dateianhänge
RTKNAVI-Input-SPP-VCP-1.png
RTKNAVI-Input-SPP-VCP-1.png (9.26 KiB) 34969 mal betrachtet
RTKNAVI-Input-SPP-VCP-2.png
RTKNAVI-Input-SPP-VCP-2.png (6.58 KiB) 34969 mal betrachtet
RTKNAVI-Input-SPP-VCP-3.png
RTKNAVI-Input-SPP-VCP-3.png (11.79 KiB) 34969 mal betrachtet
Zuletzt geändert von Hagen.Felix am 16.07.2014 - 10:42, insgesamt 3-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)

XPosition
Beiträge: 214
Registriert: 25.08.2008 - 00:09

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von XPosition » 15.07.2014 - 10:08

Kann es sein, dass dieser Stack ganz einfach keine Default Werte in die Registry schreibt ?
Falls das so ist, kann man sie ja einfach mal reinschreiben.

Der API Aufruf von Michele ist eh besser. Man will ja die aktuellen Werte wissen und nicht die Default-Werte. Oder ?

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

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von Hagen.Felix » 15.07.2014 - 10:36

XPosition hat geschrieben:Kann es sein, dass dieser Stack ganz einfach keine Default Werte in die Registry schreibt ?
Falls das so ist, kann man sie ja einfach mal reinschreiben. ...
Wie müsste denn ein solcher Registry-Eintrag aussehen?
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)

XPosition
Beiträge: 214
Registriert: 25.08.2008 - 00:09

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von XPosition » 15.07.2014 - 11:00

Sorry, keine Ahnung. :)
Aber vergleich doch was dort "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM" bei beiden Stacks drinsteht.

oekoplaner
Beiträge: 21
Registriert: 10.07.2014 - 10:58
Kontaktdaten:

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von oekoplaner » 15.07.2014 - 16:58

Ich stand vor ein paar Tagen vor genau diesem Problem - ich denke mal, mein längeres Telefonat mit Hagen war für ihn der Anlass, sich mal wieder mit dem Problem zu befassen.
Ich habe es für mich im Moment mit der Variante com0com + hub4com gelöst.
  • Eine signierte Variante von com0com habe ich unter https://code.google.com/p/powersdr-iq/d ... e&can=2&q= gefunden.
  • In com0com habe ich zwei Paare von virtuellen ComPorts eingerichtet
    com0com.jpg
    com0com.jpg (49.23 KiB) 34989 mal betrachtet
    Das zweite Paar dient der Weiterleitung des Outputs von RTKNavi an QGIS - hat also mit dem Problem hier nichts zu tun.
  • Eine Batch-Datei mit dem Befehl

    Code: Alles auswählen

    hub4com --baud=115200 --parity=odd --octs=off \\.\COM4 \\.\COM6
    leitet den physikalischen Port 4 auf den virtuellen Port 6 um
    hub4com.jpg
    hub4com.jpg (49.01 KiB) 34989 mal betrachtet
Danach empfängt RTKNavi problemlos die Rohdaten vom NVS NV08C am Port 7.

Vielleicht hilft's ja jemandem beim Tüfteln. :wink:

Holger

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

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von Hagen.Felix » 16.07.2014 - 10:44

Kleine (aber nicht ganz belanglose :mrgreen: ) Änderung, siehe Ursprungsbeitrag ...
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)

oekoplaner
Beiträge: 21
Registriert: 10.07.2014 - 10:58
Kontaktdaten:

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von oekoplaner » 16.07.2014 - 14:19

Hagen.Felix hat geschrieben:1) SPP-Port auf COM1 ändern

Gute Neuigkeiten vom Greifswalder Bodden: ein neuer Nutzer des NV08C-CSM via SPP am RTKNAVI (aber dafür schon mit viel QGIS-Erfahrung und offenbar einem "grünen Daumen" für Computer :D ) hat mir gerade seine Lösung mitgeteilt. :idea:

Und zwar genügt es offenbar, die Portnummer des für Bluetooth-SPP verwendeten COM-Ports im Geräte-Manager auf COM1 zu ändern. :!:

Den Warnhinweis des Betriebssystems, dass dieser Port bereits belegt sei, kann (und muss) man dabei getrost ignorieren, allerdings natürlich nur dann, wenn COM1 nicht wirklich schon (zeitgleich) für andere Zwecke zwingend benötigt wird.
Stimmt! Das ist ja einfach! :mrgreen:

Grüße

Holger

oekoplaner
Beiträge: 21
Registriert: 10.07.2014 - 10:58
Kontaktdaten:

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von oekoplaner » 18.09.2014 - 15:48

Ich habe mittlerweile das Tablet in Betrieb genommen, das hier im Büro für den Einsatz mit GPS + RTKLib angschafft worden ist (Dell Venue 11 Pro mit Z3770 Prozessor). Beim Koppeln des NVS NV08C-CSM an das Gerät stand ich wieder vor dem oben beschriebenen Problem und da das Gerät nicht nur von mir sondern auch von anderen Mitarbeitern genutzt werden soll, hielt ich alle Lösungen mit zusätzlicher Software für zu fehleranfällig / frickelig in der Handhabung und habe deshalb RTKNavi mit dem von Hagen geposteten Patch für die Datei stream.c neu kompiliert. Von sowas hatte ich vorher keine Ahnung, und deshalb hat es ziemlich lange gedauert, bis ich herausgefunden hatte, was ich installieren muss ( https://downloads.embarcadero.com/free/c_builder ). Danach ging es dann ruckzuck und das Ergebnis scheint einwandfrei zu funktionieren (auch wenn die exe-Datei erstaunlicherrweise 6,14 MB groß ist gegenüber 5,10 MB beim Original)! 8)
Ich gehe davon aus, dass ich das Ergebnis weitergeben darf, weil es eben OpenSource ist. Wer also eine gepatchte Version von RTKNavi haben will, einfach hier melden und am besten eine Mailadresse per PM schicken.

Holger

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

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von ssquare_de » 09.11.2014 - 09:39

Servus Hagen, hallo RTKLIB-Nutzer,


der Bluetooth-Bug in RTKLIB wurde mit Patch 10 von Tomoji niedergemacht.
Da auch ansonsten mit Patch 10 einige Fehler gefixed werden, ist die Einspielung von P-10 empfehlenswert.

Siehe dazu auch:
http://www.rtklib.com/rtklib_support.htm

Zusätzlich hat u-blox in dem neuen Produkt-Katalog 16
http://www.u-blox.de/images/downloads/P ... log_16.pdf
für nächste Zeit den NEO-M8T/LEA-M8T angekündigt, die die Ausgabe von Rohdaten auch offiziell unterstützen, also über die "altbekannten" Messages " RXM-RAWX" und "RXM-SFRBX" .
Werden von erwähntem Patch 10 auch schon unterstützt.
:-)


Stefan

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

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von Hagen.Felix » 09.11.2014 - 14:27

ssquare_de hat geschrieben:... NEO-M8T/LEA-M8T angekündigt, die die Ausgabe von Rohdaten auch offiziell unterstützen, also über die "altbekannten" Messages " RXM-RAWX" und "RXM-SFRBX".
Moin Stefan,

als u-blox vor einigen Tagen diesen neuen Produktkatalog mit den M8T-Modulen bereitstellte, habe ich mich schon darüber gefreut, dass die Schweizer Jungs das Thema Rohdatenausgabe nicht ganz zum alten Eisen gelegt haben, nachdem in der 7er Generation nur noch der NEO-7P und der LEA-M8F dann schon gar nicht mehr mit "offiziellen" Rohdaten auf den Markt gebracht wurden ... :roll:

Dass Onkel Takasu dem M8N sozusagen durch die Hintertür Rohdaten (in einwandfreier Qualität, wie wir inzwischen wissen :D ) zu entlocken vermochte, war da natürlich schon von gewisser Bedeutung ... :mrgreen:

Allerdings ist das Datenvolumen der dabei genutzten Debug-Nachrichten ja schon recht üppig (für GPS+GLONASS mit 10 Hz muss man schon 230400 Baud haben und trotzdem noch alle sonstigen Ausgaben abschalten), so dass sicher insbesondere die Nutzer von Funkstrecken wie z.B. über 433 oder 868 MHz mit dem M8T wieder eine taugliche Alternative bekommen. :wink:

Ob der M8T im Vergleich zum M8N noch mehr Vorteile bietet, wird sich hoffentlich recht bald zeigen.

Im schlimmsten Falle ist die Hardware identisch, und die Firmware des M8T hat sonst auch nur die "offiziellen" Rohdaten-Nachrichten RAWX und SFRBX als "Mehrwert" zu bieten, während der M8T voraussichtlich ja trotzdem ein Vielfaches kosten wird ... :shock:

Aber vielleicht gibt es ja doch auch beim M8T wieder ein paar nette Überraschungen, mal sehen.

Der M8N hat sich schließlich auch schon ganz unabhängig von RTKLIB & Co. als ein im autonomen Betrieb (z.B. mit SBAS oder RTCM-Input, auf jeden Fall aber der eigenen Positionsbestimmung) geradezu verblüffend guter Empfänger erwiesen, womit ich zugegebenermaßen nicht wirklich gerechnet hatte ... :o

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)

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

Re: RTKNAVI @ Windows via Bluetooth SPP

Beitrag von ssquare_de » 13.11.2014 - 02:39

Hallo Hagen,


..."Der M8N hat sich schließlich auch schon ... geradezu verblüffend guter Empfänger erwiesen..."...
Ja, stimmt, und ich kann morgen (=heute) endlich in der von mir gestarteten Beitragsreihe " NEO-M8N " die ersten autonomen Versuche vorstellen, nachdem ich wieder an meine SD-Card rankomme, die ich blöderweise liegengelassen hatte.
:-)

Spekulativ bezüglich neuen ublox-Features:
Im aktuellen u-center Ver. 8.12 gibts ja Spuren zu Quellen der möglichen Überraschungen. ;-)
neben den aktuellen NEO-M8N Firmware 2.01 mit Protokollversion 15.01 kann man ja schon bis Protokollversion 17 vorauswählen:
da erscheinen dann in der Rohdatenausgabe zusätzlich zu den bisher bekannten Messwerten die dazugehörigen Deviationswerte. (Könnte man gut zur Qualitätsbeurteilung der Messwerte in einer RTK- oder Postprozessing-Software heranziehen.)
RAWX (Multi-GNSS RAW Measurement Data.JPG
RAWX (Multi-GNSS RAW Measurement Data.JPG (35.05 KiB) 34652 mal betrachtet
Zudemfindet man im "Chart-Window" im Auswahlregister für die Y-Achse ganz am Ende seltsame EInträge wie "SV G1(L2C) Qi" oder auch "SV R1(L2C) Qi....
Da werden doch wohl nicht die L2C-Frequenzen von GPS und GLONASS damit gemeint sein?!?
Oder werfen da L1/L2-Empfänger für den Massenmarkt ihre Schatten vorraus?!?
Auch wenn die zweiten Frequenzen "nur" zur genauen Bestimmung der Ionosphären-Bedingungen genutzt werden sollte (PPP)?... :?:

:wink:

Edit/Ergänzung:
Hagen, du wirst sicher auch schon in der Protokoll-Doku zur ublox M8-Generation geblättert haben ?!?
Da
http://www.u-blox.de/images/downloads/P ... Public.pdf
unter Punkt 21.17.2 UBX-RXM-RAWX (0x02 0x15)

..."GLONASS interfrequency channel delays are compensated with
an internal calibration table....
...The carrier phase initial ambiguity is initialised using an approximate value to make the magnitude of the phase close to the pseudorange measurement....
und eine verbesserte Empfängeruhrensteuerung

sollten uns zu Recht auf eine nochmals deutlich gesteigerte RTK/Postprozessing-Leistung bei den Raw-Data-Modellen aud der M8-Generation hoffen lassen!
(fast) gleichwertige GLONASS-Satnutzung für die ambiguity solution (stabilere, robustere FIX-Lösungen) und verringerte Initialierungszeiten (bis zur FIX-Lösung).

Die M8erRohdaten-Modelle und die Sensorfusionsunterstützung durch das nächste RTKLIB-Release im Frühjahr....Tomoji erwartet sich 10cm-Genauigkeiten in üblen Empfangslagen ... und weit liegt der gute Mann ja in aller Regel nie daneben... :wink:



Stefan

Antworten