GNSS als Windows-Ortungssensor
Verfasst: 16.07.2014 - 23:40
Um die Beitragsreihe zur Datenübertragung zwischen RTKNAVI und QGIS (viewtopic.php?f=4&t=3509) damit nicht allzu sehr auf Abwege zu bringen, eröffne ich hier mal eine neue Reihe v.a. zur Thematik der Windows-Ortungssensoren und dabei speziell auch zur Wirkungsweise der beiden alternativen USB-Treiber von u-blox.
Zunächst ein wenig zu den Hintergründen:
Nicht erst seit dem Erscheinen von Windows 8, sondern schon seit etlichen Jahren, ist direkt im Windows-Betriebssystem eine Verwaltung von Sensoren enthalten. Darunter nicht nur, aber eben auch Sensoren zur Positionsbestimmung:
http://windows.microsoft.com/de-de/wind ... er-sensors
Diese grundlegende Funktionalität ist seitdem allerdings noch weiter ausgebaut worden, wodurch jetzt u.a. auch eine (grobe) Positionsbestimmung z.B. mittels WLAN-Triangulation erfolgen kann, auch wenn im Rechner selbst gar keine GNSS-Hardware verfügbar ist:
http://msdn.microsoft.com/de-de/library ... 64919.aspx
Je nachdem, ob eine Anwendung, die auf einem aktuellen Windows-Rechner läuft, noch gegen das alte Win32-API oder schon gegen das aktuelle WinRT-API kompiliert wurde oder z.B. auf .NET läuft, wird diese Positionsbestimmung ggfs. etwas unterschiedlich angesprochen, z.B. so:
http://msdn.microsoft.com/de-de/library ... .110).aspx
Das soll aber jetzt auch nicht zu weit führen, schließlich ist dieses Forum ja nicht primär für Software-Schreiberlinge vorgesehen ...
Was jedoch wohl auch für viele GNSS-Anwender interessant sein könnte, ist gewiss schon die grundlegende Frage, welche Alternativen zum "guten alten" COM-Port heutzutage eigentlich schon bestehen und inwieweit diese unter welchen Umständen relevant sind.
Tatsächlich ist der klassische serielle Port ja schon dermaßen antiquiert, dass er nicht nur historisch, sondern auch technisch in die Computer-Steinzeit gehört ...
Demgegenüber das zeitgemäße Location API, dessen Pendants in Android und iOS heutzutage schon so selbstverständlich erscheinen, dass dort quasi alle Anwendungen, in denen eine Ortungsfunktion verwendet werden soll, entweder primär oder sogar ausschließlich mittels Zugriff auf diese jeweiligen Standard-Schnittstellen arbeiten.
Manche GIS-Anwendungen (wie z.B. das legendäre "Locus") bieten alternativ auch die Option an, externe GNSS-Hardware, die typischerweise über Bluetooth (SPP) genutzt werden kann, statt des internen Location API als Grundlage der Positionsbestimmung zu verwenden.
Dabei wird "unter der Haube" natürlich auch wieder nur in althergebrachter Weise ein serieller Port geöffnet und dann versucht, aus dem eingehenden Datensalat bestimmte NMEA-Nachrichten (z.B. RMC, GGA, GSA, GSV, VTG) entnehmen zu können ...
Ganz besonders interessant wird es z.B. dann, wenn (wie im Falle des kürzlich erschienen "RTKGPS+") eine Anwendung auch als ein sogenannter "Mock Provider" fungieren kann, das Location API des darunter liegenden Betriebssystems also ihrerseits mit einer (sinnvollerweise relativ präzisen) Position versorgt.
Aber zurück zu den Windows-Ortungssensoren und dies mal am konkreten Beispiel einer via USB angeschlossenen GNSS-Hardware von u-blox illustriert.
Schon seit einiger Zeit liefert u-blox einen alternativen USB-Treiber hierfür aus:
http://u-blox.com/de/drivers-a-middlewa ... river.html
Dieser Treiber sorgt, sofern ein GNSS-Empfänger von u-blox via USB angeschlossen ist, einerseits für einen virtuellen COM-Port (VCP), der in gewohnter Weise dazu genutzt werden kann, seriell die jeweiligen Daten vom und/oder zum GNSS-Empfänger zu transportieren.
In der Systemsteuerung ist dieser Treiber daran zu erkennen, dass der jeweilige COM-Port auch explizit mit "VCP" benannt ist (auch wenn strenggenommen der COM-Port des klassischen USB-Treibers ja ebenso ein VCP ist).
Zusätzlich sorgen diese "Windows 8/7 USB drivers for sensor and VCP features" natürlich auch (bzw. sogar hauptsächlich) dafür, dass die Windows-Positionssuche mittels dieser externen GNSS-Hardware ggfs. recht präzise Ergebnisse liefern kann ...
Allerdings, ein kleiner Pferdefuß steckt auch hier im Detail, und gerade der hat mir vor einiger Zeit auch mal richtig Kopfzerbrechen bereitet.
Und zwar verursacht dieses Treiberpaket u.a. auch eine (temporäre) Änderung der Konfiguration des jeweiligen GNSS-Empfängers von u-blox ...
Das heißt konkret: bei jeder Verbindungsaufnahme werden ein paar UBX-Kommandos zum Empfänger gesendet, damit dieser dann z.B. auch die vom Sensor-Treiber für seine Berechnungen benötigten NMEA-Nachrichten ausgibt (nicht nur Positionskoordinaten, sondern auch Qualitätsparameter).
Bei einem Anwender, der seine Empfänger (aus durchaus zwingendem Grund) ausschließlich nur GGA und VTG ausgeben lassen wollte, war das natürlich eine tagelange Frustrationsquelle, bis sich dann endlich herausgestellt hatte, dass man in solchen Fällen unbedingt wieder den klassischen USB-Treiber verwenden muss:
http://u-blox.com/de/drivers-a-middlewa ... river.html
Falls jemand auch mal in diese Situation kommen sollte: Da wäre zunächst der "Sensor/VCP-Treiber" vollständig zu entfernen, und zwar bei noch angeschlossenem GNSS-Empfänger und dann erst bei den COM-Ports und danach bei den Sensoren. Anschließend sollte der GNSS-Empfänger erst mal wieder vom Rechner getrennt werden, um den klassischen USB-Treiber neu zu installieren (ggfs. gleich zusammen mit dem aktuellen u-center). Wenn dann der GNSS-Empfänger wieder angeschlossen wird, sollte nur bei den COM-Ports etwas erscheinen und in diesem Fall auch ohne "VCP" benannt sein, also z.B. nur als "u-blox GNSS Receiver COM5)".
Hier ein paar Screenshots dazu:
Zunächst ein wenig zu den Hintergründen:
Nicht erst seit dem Erscheinen von Windows 8, sondern schon seit etlichen Jahren, ist direkt im Windows-Betriebssystem eine Verwaltung von Sensoren enthalten. Darunter nicht nur, aber eben auch Sensoren zur Positionsbestimmung:
http://windows.microsoft.com/de-de/wind ... er-sensors
Diese grundlegende Funktionalität ist seitdem allerdings noch weiter ausgebaut worden, wodurch jetzt u.a. auch eine (grobe) Positionsbestimmung z.B. mittels WLAN-Triangulation erfolgen kann, auch wenn im Rechner selbst gar keine GNSS-Hardware verfügbar ist:
http://msdn.microsoft.com/de-de/library ... 64919.aspx
Je nachdem, ob eine Anwendung, die auf einem aktuellen Windows-Rechner läuft, noch gegen das alte Win32-API oder schon gegen das aktuelle WinRT-API kompiliert wurde oder z.B. auf .NET läuft, wird diese Positionsbestimmung ggfs. etwas unterschiedlich angesprochen, z.B. so:
http://msdn.microsoft.com/de-de/library ... .110).aspx
Das soll aber jetzt auch nicht zu weit führen, schließlich ist dieses Forum ja nicht primär für Software-Schreiberlinge vorgesehen ...
Was jedoch wohl auch für viele GNSS-Anwender interessant sein könnte, ist gewiss schon die grundlegende Frage, welche Alternativen zum "guten alten" COM-Port heutzutage eigentlich schon bestehen und inwieweit diese unter welchen Umständen relevant sind.
Tatsächlich ist der klassische serielle Port ja schon dermaßen antiquiert, dass er nicht nur historisch, sondern auch technisch in die Computer-Steinzeit gehört ...
Demgegenüber das zeitgemäße Location API, dessen Pendants in Android und iOS heutzutage schon so selbstverständlich erscheinen, dass dort quasi alle Anwendungen, in denen eine Ortungsfunktion verwendet werden soll, entweder primär oder sogar ausschließlich mittels Zugriff auf diese jeweiligen Standard-Schnittstellen arbeiten.
Manche GIS-Anwendungen (wie z.B. das legendäre "Locus") bieten alternativ auch die Option an, externe GNSS-Hardware, die typischerweise über Bluetooth (SPP) genutzt werden kann, statt des internen Location API als Grundlage der Positionsbestimmung zu verwenden.
Dabei wird "unter der Haube" natürlich auch wieder nur in althergebrachter Weise ein serieller Port geöffnet und dann versucht, aus dem eingehenden Datensalat bestimmte NMEA-Nachrichten (z.B. RMC, GGA, GSA, GSV, VTG) entnehmen zu können ...
Ganz besonders interessant wird es z.B. dann, wenn (wie im Falle des kürzlich erschienen "RTKGPS+") eine Anwendung auch als ein sogenannter "Mock Provider" fungieren kann, das Location API des darunter liegenden Betriebssystems also ihrerseits mit einer (sinnvollerweise relativ präzisen) Position versorgt.
Aber zurück zu den Windows-Ortungssensoren und dies mal am konkreten Beispiel einer via USB angeschlossenen GNSS-Hardware von u-blox illustriert.
Schon seit einiger Zeit liefert u-blox einen alternativen USB-Treiber hierfür aus:
http://u-blox.com/de/drivers-a-middlewa ... river.html
Dieser Treiber sorgt, sofern ein GNSS-Empfänger von u-blox via USB angeschlossen ist, einerseits für einen virtuellen COM-Port (VCP), der in gewohnter Weise dazu genutzt werden kann, seriell die jeweiligen Daten vom und/oder zum GNSS-Empfänger zu transportieren.
In der Systemsteuerung ist dieser Treiber daran zu erkennen, dass der jeweilige COM-Port auch explizit mit "VCP" benannt ist (auch wenn strenggenommen der COM-Port des klassischen USB-Treibers ja ebenso ein VCP ist).
Zusätzlich sorgen diese "Windows 8/7 USB drivers for sensor and VCP features" natürlich auch (bzw. sogar hauptsächlich) dafür, dass die Windows-Positionssuche mittels dieser externen GNSS-Hardware ggfs. recht präzise Ergebnisse liefern kann ...
Allerdings, ein kleiner Pferdefuß steckt auch hier im Detail, und gerade der hat mir vor einiger Zeit auch mal richtig Kopfzerbrechen bereitet.
Und zwar verursacht dieses Treiberpaket u.a. auch eine (temporäre) Änderung der Konfiguration des jeweiligen GNSS-Empfängers von u-blox ...
Das heißt konkret: bei jeder Verbindungsaufnahme werden ein paar UBX-Kommandos zum Empfänger gesendet, damit dieser dann z.B. auch die vom Sensor-Treiber für seine Berechnungen benötigten NMEA-Nachrichten ausgibt (nicht nur Positionskoordinaten, sondern auch Qualitätsparameter).
Bei einem Anwender, der seine Empfänger (aus durchaus zwingendem Grund) ausschließlich nur GGA und VTG ausgeben lassen wollte, war das natürlich eine tagelange Frustrationsquelle, bis sich dann endlich herausgestellt hatte, dass man in solchen Fällen unbedingt wieder den klassischen USB-Treiber verwenden muss:
http://u-blox.com/de/drivers-a-middlewa ... river.html
Falls jemand auch mal in diese Situation kommen sollte: Da wäre zunächst der "Sensor/VCP-Treiber" vollständig zu entfernen, und zwar bei noch angeschlossenem GNSS-Empfänger und dann erst bei den COM-Ports und danach bei den Sensoren. Anschließend sollte der GNSS-Empfänger erst mal wieder vom Rechner getrennt werden, um den klassischen USB-Treiber neu zu installieren (ggfs. gleich zusammen mit dem aktuellen u-center). Wenn dann der GNSS-Empfänger wieder angeschlossen wird, sollte nur bei den COM-Ports etwas erscheinen und in diesem Fall auch ohne "VCP" benannt sein, also z.B. nur als "u-blox GNSS Receiver COM5)".
Hier ein paar Screenshots dazu: