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 ...
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 ...
Die eigentliche Ursache dieses Problems liegt offenbar in der Datei stream.c von RTKNAVI.
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.
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 ...
Gleichwohl, noch ist es nicht soweit.
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
) hat mir gerade seine Lösung mitgeteilt. 
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 ...
Ü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.
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 ...
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 ...
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.
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 ...
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;
}
Code: Alles auswählen
if (!GetCommConfig(serial->dev,&cc,&siz))
...
Viele Grüße,
Hagen
