GNSS als Windows-Ortungssensor

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:

GNSS als Windows-Ortungssensor

Beitrag von Hagen.Felix » 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 ... :roll:

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. :D

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 ... :wink:

Allerdings, ein kleiner Pferdefuß steckt auch hier im Detail, und gerade der hat mir vor einiger Zeit auch mal richtig Kopfzerbrechen bereitet. :twisted:

Und zwar verursacht dieses Treiberpaket u.a. auch eine (temporäre) Änderung der Konfiguration des jeweiligen GNSS-Empfängers von u-blox ... :shock:

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:
Dateianhänge
UBX-USB-Sensor+VCP-1.png
UBX-USB-Sensor+VCP-1.png (23.52 KiB) 15268 mal betrachtet
UBX-USB-Sensor+VCP-2.png
UBX-USB-Sensor+VCP-2.png (17.77 KiB) 15268 mal betrachtet
UBX-USB-Sensor+VCP-removed.png
UBX-USB-Sensor+VCP-removed.png (23.76 KiB) 15268 mal betrachtet
Zuletzt geändert von Hagen.Felix am 17.07.2014 - 07:40, insgesamt 4-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)

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

u-blox USB (CDC-ACM) Driver

Beitrag von Hagen.Felix » 16.07.2014 - 23:51

Sofern (wieder) nur der klassische USB-Treiber wirksam ist, sollte es im Geräte-Manager so aussehen:
Dateianhänge
UBX-USB-CDC-ACM.png
UBX-USB-CDC-ACM.png (5.53 KiB) 15265 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:

Schöne neue Welt ...

Beitrag von Hagen.Felix » 16.07.2014 - 23:55

Allerdings, (nicht nur) aus der Froschperspektive eines Software-Entwicklers ist die Verfügbarkeit zeitgemäßer Technik wie eben z.B. der Windows-Ortungssensorik wirklich äußerst lukrativ ... :wink:
Dateianhänge
System-Device-Location-OSM.png
System-Device-Location-OSM.png (51.72 KiB) 15264 mal betrachtet
System-Device-Location-Bing.jpg
System-Device-Location-Bing.jpg (148.94 KiB) 15264 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:

Was der Bauer nicht kennt ...

Beitrag von Hagen.Felix » 17.07.2014 - 00:02

Wenn ich nun aber versuche, aus meinen Gesprächen mit Kunden, Interessenten, Entwicklungspartnern usw. "hochzurechnen" auf die Gesamtmenge aller GNSS-Anwender, habe ich eigentlich nur den Eindruck, dass quasi alle Welt noch immer ausschließlich mit den althergebrachten COM-Ports arbeitet ... :roll:

Täuscht dieser Eindruck? :?:

Oder kennt jemand unter uns vielleicht schon praktische Anwendungsfälle, in denen GNSS als Windows-Ortungssensor fungiert und dann auch darüber genutzt wird? :idea:

Viele Grüße 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)

B14
Beiträge: 65
Registriert: 01.05.2010 - 21:22

Re: GNSS als Windows-Ortungssensor

Beitrag von B14 » 18.07.2014 - 23:42

Hallo Hagen,

ich will dir jetzt nicht in die Parade fahren, aber Microsoft ist nich gerade dafür bekannt, offene Schnittstellen bereitzustellen. Die machen immer Sonderlocken und erst wenn es nicht mehr anders geht und der Markt anders entschieden hat, schwenken sie ein.

Nur einige Beispiele meiner leidvollen Erfahrungen:
- NetBUEI -> TCP/IP
- MDI -> PDF
- Silverlight -> HTML5
- WMF -> H.264/AVC

Ich will hier aber keinen Glaubenskrieg auslösen. Unser Tomoji macht es meiner Meinung nach vollkommen richtig und alles über Standard TCP/IP

- Input von beliebiger GNSS HW (wenn Treiber vorhanden) oder auch SW (z.B. NTRIP)
- Alles wird in einem Server gesammelt
- Output über Serial, TCP/IP, NTRIP oder File
- Auch mit Covertern von BINEX, Javad, Novatel, ... nach RTCM2/3
- Das ganz ist auch noch beliebig kombinier- und kaskadierbar
- Läuft unter Windows und Linux/Android

Ich mag dieses offene Schnittstellenkonzept :-)

Gruss
Bernd

Noch ein Bild aus der RTKLIB-Doku:
rtklib.png
rtklib.png (12.24 KiB) 15237 mal betrachtet

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

Location API vs. SerialPort vs. TCP

Beitrag von Hagen.Felix » 19.07.2014 - 23:03

B14 hat geschrieben:... Unser Tomoji macht es meiner Meinung nach vollkommen richtig und alles über Standard TCP/IP ...
D’accord ! :D

Nachdem man sich über so viele Jahre, mehr schlecht als recht und durchaus auch ziemlich mühsam, an die Selbstverständlichkeit des COM-Ports gewöhnt hat, scheinen jetzt doch die Karten wieder mal neu gemischt ... :mrgreen:

Die (zumeist jüngeren) iOS-, Android- oder JavaScript-Entwickler in meinem näheren und ferneren Umkreis können sich wohl kaum vorstellen, dass man "früher" (sozusagen in der Computer-Steinzeit) noch Hunderte oder gar Tausende Zeilen Quelltext schreiben musste, um einen seriellen Port sauber zu öffnen, den dann hereinströmenden Bytestream in sinnvollen Abschnitten einzulesen und beim Parsen der (NMEA-)Datenausgabe eines GPS-Gerätes die in den Einzelnachrichten enthaltenen Informationen adäquat zu verarbeiten und nicht nur das Schließen des COM-Ports bei Programmende nicht zu vergessen, sondern z.B. auch bei unvorhergesehenen Situationen nicht gleich zu kollabieren. :roll:

Ich denke da nur an solche Klassiker, dass z.B. Versionen von ArcPad auch schon mal zum Totalabsturz kamen, wenn sich mal eine unschuldige kleine (binäre) UBX-Nachricht in den NMEA-Bytestream verirrte ... :shock:

Demgegenüber eben, im wirklich krassen Gegensatz dazu, die proprietären Location APIs der neueren Plattformen von Google, Apple, Microsoft usw. :!:

Ein zumeist recht überschaubarer Funktionsumfang (gelinde gesagt), dafür jedoch eine geradezu verwirrende Mischung aus Komfort und Laufzeitstabilität!

Da ist es mit einem Objekt der entsprechenden Klasse und höchstens zwei oder drei Methodenaufrufen schon getan, und der Kram stürzt dann auch nicht einfach so ab ... :wink:

Dazu kommt speziell für mich (da ich seit einigen Jahren v.a. mit C# arbeite), dass die bisherige SerialPort-Klasse im .NET-Framework wirklich recht lausig ist. :evil:

Unter http://www.sparxeng.com/blog/software/m ... serialport ist es mit ziemlich harschen Worten beschrieben, aber m.E. leider noch gar nicht mal allzu übertrieben ... :cry:

Ich habe daher in den letzten Jahren viel lieber D2XX (siehe http://www.ftdichip.com/Drivers/D2XX.htm bzw. http://www.mikrocontroller.net/topic/220914) genommen, sofern natürlich FTDI-Hardware vorhanden bzw. verwendbar war.

Eine schöne Neuigkeit in diesem Zusammenhang: Mit dem erst vor wenigen Tagen von FTDI veröffentlichten Treiberpaket für Windows@ARM (Windows RT wie auf den Surface-Tablets von Microsoft oder dem letzten Lumia-Tablet von Nokia) ist nun endlich auch eine relativ flexible Lösung dafür verfügbar, auch auf dieser Plattform serielle Datenschnittstellen nutzen zu können, denn Microsoft selbst hat sich ja tatsächlich den Fauxpas geleistet, hierfür kein SPP zu implementieren ... :?

Die damit in vielen Fällen erreichte Stabilität (gerade auch im Langzeitbetrieb) und eine wirklich nur minimale Systembelastung auch bei vielen (z.T. > 10) gleichzeitig genutzten seriellen Schnittstellen wäre m.E. mit dem "guten alten" COM-Port nicht annähernd zu schaffen gewesen.

Eine echte Alternative dazu sind die Location APIs der Plattformhersteller natürlich nicht, schon allein durch deren extreme Beschränkung auf eine kleine Handvoll fest vorgegebener Größen, die darüber abrufbar sind.

Etwas überspitzt gesagt, bekommt man dort ja gerade mal Lat/Lon/Alt und vielleicht noch einen völlig nebulösen Qualitätsparameter geliefert ... :(

Auch wenn das für die Mehrheit der Nutzer von ortsbezogenen Anwendungen wohl schon zu genügen scheint. :mrgreen:

Die aktuell im Kontext der internen Datenweiterleitung vom RTKNAVI zu QGIS diskutierte (viewtopic.php?f=4&t=3509) Option über TCP hat mich jetzt aber auch noch mal etwas stärker für diese Problematik sensibilisiert, und soweit ich das jetzt schon überschauen kann, ist der von RTKNAVI, QGIS, gpsd und wohl noch tausenderlei weiteren Anwendungen gewählte Weg über TCP offenbar wirklich genau die richtige Alternative! :idea:

Universalität und Flexibilität sind nicht eingeschränkt, sondern sogar noch erweitert (man denke nur an die Möglichkeiten der Datenfernübertragung, wo seriellen Verbindungen ja schon nach kürzester Strecke die Puste ausgeht), und v.a. hat man auf quasi allen Hardware- und Software-Plattformen heutzutage nicht nur die Funktionalität an sich, sondern auch massenweise Unterstützung, z.B. durch Bibliotheken, mit denen es dann für einen Anwendungsentwickler ggfs. auch wieder ganz einfach sein kann ... :D

Es ist zwar unter Windows nicht ganz so trivial, dass man mit ein paar Mausklicks einfach mal eine gpsd.dll o.ä. verwenden könnte (und die Nutzung von gpsd auf Cygwin erscheint mir schon vom Ansatz her etwas abwegig, siehe z.B. unter http://hyperlogos.org/page/GPSD-Win32), aber bereits ein kurzer Blick "unter die Haube" zeigt ja, dass man letztlich auch nur ein paar ganz normale Socket-Verbindungen herstellen muss, um dann die jeweils benötigten gpsd-Teilfunktionalitäten für sich "emulieren" zu können:

https://github.com/qgis/QGIS/blob/maste ... ection.cpp

Im Moment fehlt mir noch etwas der Überblick, ob es vielleicht unter Windows sogar ähnlich gut wie unter Android gehen könnte, der Offenheit und Flexibilität von TCP mit dem Maximal-Komfort der Location API noch das Sahnehäubchen aufzusetzen (Stichwort "Mock Provider").

Hauptsache nur, der klassische COM-Port lässt sich möglichst bald aufs Altenteil schicken ... :mrgreen:

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:

SPP @ RFCOMM

Beitrag von Hagen.Felix » 17.12.2014 - 22:14

Hagen.Felix hat geschrieben:... denn Microsoft selbst hat sich ja tatsächlich den Fauxpas geleistet, hierfür kein SPP zu implementieren ... :? ...
Infolge anderer "Problemchen" in den letzten Monaten habe ich leider erst recht spät entdeckt, dass diese Lücke schon seit einiger Zeit geschlossen wurde ... :wink:

Tatsächlich ist es aber schon jetzt völlig problemlos möglich, einen GNSS-Empfänger mit Bluetooth-Schnittstelle in ganz althergebrachter Weise (NMEA-Datenausgabe über SPP) mit einer Windows-Store-App zu nutzen, und zwar ohne jeden Firlefanz, der z.B. unter iOS in vergleichbarer Situation erforderlich wäre. :?

Allerdings wird nun nicht mehr der "gute" alte COM-Port genutzt, sondern (etwas zeitgemäßer) mit RFCOMM gearbeitet:

http://msdn.microsoft.com/de-de/library ... 81201.aspx

http://msdn.microsoft.com/en-us/library ... 64587.aspx

Ich habe daraufhin mal kurz gestöbert und auch zumindest schon mal eine (m.E. jedoch sehr ordentlich entwickelte) bereits existierende Windows-Store-Anwendung gefunden, die schon einen (ganz normalen) externen GNSS-Empfänger mit Bluetooth-Schnittstelle verwenden kann, notwendigerweise natürlich auch unter Nutzung der o.g. Technik ... :D

http://apps.microsoft.com/windows/de-de ... c9a858a072

Und auch ganz im Sinne des neuen Konzepts der "Universal Apps" gilt dies adäquat ebenfalls für Windows Phone 8.1 ff., siehe z.B. unter

http://blogs.msdn.com/b/flecoqui/archiv ... tooth.aspx

Nun, das hat natürlich nur am Rande mit GPS/GNSS zu tun. :roll:

Aber für mich persönlich dürfte es wohl trotzdem recht bedeutsam werden ... :mrgreen:
Zuletzt geändert von Hagen.Felix am 11.01.2015 - 11:23, 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)

holgi63
Beiträge: 34
Registriert: 10.04.2012 - 18:27

Re: GNSS als Windows-Ortungssensor

Beitrag von holgi63 » 19.12.2014 - 10:28

Hallo Hagen, hallo an die Gemeinde,

an der COM- oder nichtCOM-Port Diskussion möchte ich gar nicht rütteln, als Anwender bin ich immer glücklich, wenn ich die gewünschte Verbindung hergestellt habe und sorge mich weniger darum, auf welchem Wege die Daten ankommen, außerdem bin ich als Alt-IT'ler der ersten Stunden (UNIX seit 1988, die Betriebssysteme von Microsoft hießen noch DOS und Editoren arbeiteten zeilenweise) mit serieller Kommunikation großgeworden.
Aber ich wollte einwerfen, dass Microsoft-betriebene Hardware auch im Tablet-Bereich unter Preisdruck gerät.
Von ODYS gibt es inzwischen ein Windows Tablet unter 200,-EUR.
Die Potenziale für unsere Bedarfe sollte man vielleicht mal ausloten.
Persönlich ziehe ich die MS-Geräte der Androidenwelt vor...

Odys Wintab 10
25,7 cm (10,1 Zoll) Tablet-PC
(Intel Atom Quad Core Z3735F, 2 GB RAM, 32 GB HDD, Intel Gen7,
HD IPS Display (1280 x 800), Windows 8.1,
Micro HDMI, USB, Micro SD, BT 4.0, Office 365 Personal)

Grüße
Holger

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

Re: GNSS als Windows-Ortungssensor

Beitrag von Hagen.Felix » 19.12.2014 - 11:13

holgi63 hat geschrieben:... Aber ich wollte einwerfen, dass Microsoft-betriebene Hardware auch im Tablet-Bereich unter Preisdruck gerät.
Moin Holger,

auf diese Preisentwicklung habe ich voller Ungeduld schon seit mehreren Jahren gewartet ... :wink:

Durch die verschiedenen Anwendungen in der Landwirtschaft, mit denen ich beruflich seit ca. 15 Jahren befasst bin (einerseits zu Fuß auf dem Acker und/oder im Stall mit der Notwendigkeit zur mobilen Datenerfassung, andererseits aber auch in der Traktorkabine mit dem Anwendungs-Klassiker der Parallelführung), verwende ich ja schon seit dem Erscheinen der Windows XP Tablet PC Edition eine Vielzahl entsprechender Geräte ... :roll:

Von den z.T. regelrecht absurd hohen Preisen in dieser Geräteklasse mal abgesehen, hat es bis vor kurzem aber auch auf Seiten der Technik selbst noch an (mindestens) zwei grundlegenden Faktoren gemangelt: zunächst dem notwendigen Verhältnis zwischen Rechenleistung und Kühlungsbedarf, um auch bei solch kleinen Geräten eine hinreichend flüssige Benutzeroberfläche zu gewährleisten, und dann aber auch an der Mensch-Maschine-Schnittstelle selbst.

Beim ersten Problem hat Intel m.E. erst mit der aktuellen Atom-Generation bzw. der gerade abgelösten Core-Generation die nötigen Grundlagen bereitgestellt.

Ich habe noch 2012 mit einem (seinerzeit durchaus aktuellen) Q550 von Fujitsu gearbeitet, dessen CPU-Leistung aber von Anfang an ungenügend war.

Die aktuellen Atom-Tablets sind jedoch schon völlig ausreichend motorisiert. :D

Das andere Problem betrifft die Software. Zwar hätte man als Entwickler durchaus sogar schon mit WinForms (Vorgänger von WPF) eine Benutzeroberfläche schreiben können, die auf einem Tablet auch nur mit dem "dicken Daumen" gut benutzbar ist, aber diese Mühe konnte und/oder wollte sich offenbar kaum jemand machen, zumal ja auch Microsoft selbst beim Betriebssystem viele Eingabemöglichkeiten so realisiert hatte, dass zur Bedienung die Maus oder zumindest der Eingabestift kaum vermeidbar war. :evil:

Als Resultat all dieser dumm gelaufenen Geschichten in diesen Jahren denken die meisten Leute heutzutage ja wirklich, das Tablet wäre von Apple erfunden worden. :lol:

So wie gemeinhin jetzt auch die Annahme dominiert, das Smartphone gäbe es erst seit dem iPhone, obwohl jenes zunächst ja noch nicht mal 3G-Mobilfunk konnte. :roll:

Man könnte also durchaus schlussfolgern, dass Microsoft es ziemlich vergeigt hat unter Ballmer. :cry:

Allerdings wäre es schlichtweg blöd, über die Vergangenheit zu greinen, wenn die Gegenwart bereits so gut ist! :D

Bei Microsoft selbst im Online-Laden gibt es aktuell für gerade mal 99 EUR (brutto ... :mrgreen:) ein von Hewlett-Packard hergestelltes Tablet. Ich würde das heutzutage zwar trotzdem nicht bevorzugen, weil mir beim RAM doch etwas zu sehr gegeizt wurde, aber man sieht zumindest schon überdeutlich, wie sehr sich die gesamte Marktklage geändert hat!

Umso mehr hätte es mich allerdings betrübt, wenn Microsoft bei der API-Bereitstellung noch immer SPP vernachlässigt hätte (wie es zu Beginn der neuen WinRT ja leider noch der Fall war).

Ungeachtet dessen, dass heutzutage sicherlich einige (durchaus z.T. sogar wesentlich bessere) Alternativen zur althergebrachten seriellen Datenübertragung existieren, wird im gewerblichen Bereich vermutlich noch in zehn Jahren ein größerer Teil des Datensalats über RS-232 & Co. transportiert.

Da wäre es m.E. schlichtweg eine Katastrophe geworden, wenn die neue(n) Plattform(en) von Microsoft dies nicht mehr ermöglicht hätte(n)!

Aber so: Ende gut, alles gut ... :mrgreen:

Frohe Weihnachten!
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)

Antworten