Abbildung 1: Ab 2014 Realität: Ein GPS-Satellit der dritten Generation an seinem Arbeitsplatz. (©NASA)

Wie Satellitennavigation mit GPS funktioniert, welche Geräte mit Linux zusammenarbeiten und welche OpenSource-Software es gibt, um die Daten zu extrahieren .

Schuld trägt wie so oft das amerikanische Verteidigungsministerium. Bereits 1973 fassten Verantwortliche aus U.S. Navy und Air Force den Beschluss, ein militärisches, satellitengestütztes Navigationssystem aufzubauen. Heute, 36 Jahre später, umkreisen etwa 30 Satelliten (Abbildungen 1 und 2) des auch zivil nutzbaren Global Positioning Systems (GPS) mit fast 4 Kilometer pro Sekunde in einer Höhe von 20 000 Kilometern unseren Planeten. Über die ganze Erde verteilte Kontrollstationen messen, berechnen und korrigieren Uhrzeiten und Positionen, und auf den winzigen Displays in der Hand der Endkunden binden GPS-Empfänger den aktuellen Standort in meist proprietäres Kartenmaterial ein.

Abbildung 1: Ab 2014 Realität: Ein GPS-Satellit der dritten Generation an seinem Arbeitsplatz. (©NASA)

Abbildung 2: Zum Space Segment, den GPS-Satelliten, kommen die Kontrollstationen (Control Segment) und die GPS-Empfänger als User Segment.

Korea, Navstar, Golfkrieg

Für die zivile Nutzbarkeit bedurfte es einer Flugzeugkatastrophe: Als sich 1983 unter mysteriösen Umständen ein koreanisches Flugzeug über russischem Territorium verirrte, fackelte die Sowjetarmee nicht lange und schoss es ab. Um derartige Katastrophen zu vermeiden, beschlossen die USA, das 1978 gestartete, militärische Navstar (Navigation System for Timing and Ranging) auch für zivile Nutzung bereitzustellen, was der ohnehin schwächelnden Finanzierung der auf- wändigen Satellitentechnik einen wahren Boost verschaffte.

Aber die private Nutzung unterlag lange starken Einschränkungen. Genauere Positionsbestimmung als plus/minus 100 Meter ließen die US-Militärs nur für ihre Zwecke zu, bis Präsident Bush Senior in den ersten Golfkrieg zog. Weil da nicht genügend militärische Empfänger verfügbar waren, beschloss die Army, auch zivile Geräte zu verwenden und stattdessen die so genannte Selective Availa- bility (SA) auszuschalten. Ab sofort lag die zu erwartende Positionsgenauigkeit auch für Zivilisten in einem Bereich von 15 Metern. Aber 1991 reaktivierte das Militär die auf einem Zufallsgenerator basierende künstliche Verschleierung des Signals. Erst Präsident Clinton erhob die Verfügbarkeit hochauflösender Positionsdaten zum Allgemeingut und ließ die SA ab dem Jahr 2000 dauerhaft deaktivieren, was das System einem breiten Benutzerkreis bekannt machte. Mahnende Kritik gab es immer wieder für die Abhängigkeit vom amerikanischen Militär, nicht zuletzt deshalb entstand das ehrgeizige Galileo-GPS-Projekt der EU [1].

Heute erreichen moderne GPS-Empfänger theoretisch sogar Genauigkeiten im Bereich weniger Meter, weil zum Beispiel bei Technologien wie Differential GPS (DGPS) und Wide Area Augmentation System (WAAS) Bodenstationen als Referenzen dienen. Die hochwertigen Empfänger von Geodäten schaffen sogar Genauigkeiten im Millimeterbereich. Vorsicht ist trotzdem geboten, denn zum einen verspricht das Marketing der Hersteller oft optimistische Werte, zum anderen gestaltet sich eine korrekte Messung bei bewegten Empfängern sehr schwierig, auch die Höhe über (oder unter) null spielt dabei eine wichtige Rolle.

37 500 Bits bei 50 Bit/s

Jeder GPS-Satellit sendet (stark vereinfacht dargestellt) regelmäßig ein Zeitsignal, seine Kennung und seine aktuelle Position. Der GPS-Empfänger berechnet nun den Abstand zum Satelliten aus der Laufzeit des Signals, also den Unterschied zwischen der Uhrzeit des Sendens und des Empfangs auf dem Gerät.

Um seine Position akkurat zu bestimmen, braucht das Gerät in der Praxis Kontakt zu mindestens vier Satelliten, je mehr Signale es empfängt, desto genauer und schneller lässt sich der Standort berechnen. Aus regelmäßigen Messungen ergeben sich Bewegungsprofile und Geschwindigkeiten, wobei sich die Qualität der Empfangsgeräte auch in der Frequenz der Berechnung unterscheidet. Mehr Details zu Berechnung und Fehlerkorrekturen bei der Positionsbestimmung mit GPS findet sich unter [2].

Der Aufbau eines GPS-Signals ist komplex und das Ergebnis jahrzehntelanger Forschung. Zivile GPS-Signale der L1-Frequenz liegen auf 1,575,42 MHz, die für das überwiegend militärische Precision Position Coding (PPS) genutzte L2-Frequenz etwas darunter. Die Daten reisen dabei huckepack, auf das Trägersignal durch Phasenmodulation aufmoduliert, im Gegensatz zur bekannteren Frequenz(FM) oder Amplitudenmodulation (AM).

Ein Datensignal umfasst 25 Blöcke à 1500 Bits, insgesamt also 37 500 Bits, und gelangt mit einer Übertra gungsrate von 50 Bit/s zum Empfänger. Das Signal besteht aus drei großen Blöcken: einer Navigations-Message mit Uhrzeit und Zustand des Satelliten, der Ephemeris mit den exakten Daten des Orbits und drittens dem Almanach mit den kompletten Daten aller GPS-Satelliten und diversen Informationen über zum Beispiel die Beschaffenheit der Ionosphäre, der größten Fehlerquelle.

Lokaler Cache

Schnelle Kopfrechner haben bemerkt: Wegen der langsamen Übertragungsge- schwindigkeit dauert es fast eine Viertelstunde, bis ein Empfänger ein komplettes GPS-Signal empfangen hat. Das aber wäre für den Einsatz im Auto oder am Armband des Joggers untragbar. Deshalb cachen die meisten Geräte alle empfangenen Daten. Ist die letzte Position bekannt und hat sie sich beim Ausschalten des GPS-Empfängers nicht wesentlich verändert, so ist das Gerät fast unmittelbar einsatzbereit und die Positionsbestimmung vertrauenswürdig.

Die mit dem Signal übermittelte GPSUhrzeit lässt sich übrigens auch als NTP-Server verwenden, der Timing Service ist ein wichtiger Bestandteil des Systems und in der Manpage des Linux-GPS-Daemon Gpsd [3] beschrieben.

Die komplette, offizielle GPS-Signal-Spezifikation findet sich bei [4]. Mehr Informationen über die umfangreichen Maßnahmen zur Fehlerkorrektur gibts auf der offiziellen Seite unter [5] und im Kasten “Einstein und GPS”.

Einstein und GPS

Alles ist relativ und vom Standpunkt des Be- trachters abhängig, sogar die genaue Zeit, das wusste bereits Einstein. Auch heute noch liefern moderne Technologien wie GPS ganz unerwartet Beweise für seine beiden Theorien. Für die exakte Positionsbestimmung ist es nötig, die Zeit auf wenige Nanosekunden genau zu erfassen. Die spezielle Relativitätstheorie sagt aber voraus, dass für ein sich schnell bewegendes Objekt die Zeit langsamer vergeht. Die Atomuhren eines GPS-Satelliten erleiden allein durch die Bahngeschwindigkeit von fast 15 000 km/h einen Fehler von mehreren Mikrosekunden pro Tag im Vergleich zu den (weniger schnell bewegten) Uhren auf der Erde. Sechsmal stärker noch ist aber der von der Sechsmal stärker noch ist aber der von der allgemeinen Relativitätstheorie vorhergesagte Effekt, dass die Uhren an Bord wegen der deutlich geringeren Gravitation schneller laufen als ihre Verwandten auf der Erde. Insgesamt gehen die Uhren auf den Satelliten also etwas zu schnell. Das reicht aus, um die Genauigkeit der Positionsbestimmung schlimmstenfalls um mehrere Kilometer zu verfälschen. Zum Vergleich: Die meisten anderen Fehler (etwa atmosphärische Störungen, Unregelmäßigkeiten der Umlaufbahn, Uhrenfehler) addieren sich nur auf gute 10 Meter. Interessierte können sich in der Arbeit “Relativistische Korrekturen für GPS” [6] weitere Details holen. Vor allem der dort beschriebene Sagnac-Effekt gibt Anlass für eine nette Rechenaufgabe: Jeder Punkt des Äquators bewegt sich mit etwa 500 m/s. An den Polen ist diese Geschwindigkeit gleich null. Was bedeutet das für die Dauer eines Menschenlebens in Tansania und am Nord- oder Südpol? Abbildung 3: Albert Einstein – ohne seine Relativitätstheorien wäre GPS deutlich ungenauer.

Geräte und Hersteller

GPS-Empfänger bestehen im Wesentlichen aus einer Antenne und einer Präzisionsuhr und finden sich mittlerweile vom Auto bis zum Handy in immer mehr Produkten. Offene Standards der National Marine Electronics Association (NMEA 0183, NMEA 2000, [7]) stellen die Austauschbarkeit der Daten sicher, proprietäre wie SIRT und MTK komplettieren das Bild.

Aber wer die Signale ohne NMEA- Standard mit dem Laptop austauschen möchte – und das auch noch mit Linux -, der erlebt wahrscheinlich böse Überraschungen. Keines der Handys im Test war in der Lage, die Daten des GPS-Empfängers an den Laptop so zu übergeben (Kasten “Harte Ware für unterwegs”, Abbildung 4), wie das Bluetooth- oder USB-Geräte standardmäßig beherrschen. Dafür glänzen alle Mobiltelefone mit eigenen, meist kostenpflichtigen Navigationstools. Gut, dass es da auch für Handys freie Software gibt.

Abbildung 4: Das Bluemax-GPS ist mit dem Linux-Bluetooth-Daemon verbunden.

Harte Ware für unterwegs

Keines der Handys im Test war in der Lage, seine GPS-Daten live über offene Standards an einen angeschlossenen PC zu liefern. Die Hersteller möchten ihre Kunden ganz offensichtlich an die kostenpflichtigen Onlinedienste binden. Dank freier Software und mit Bluetooth-Empfängern wie denen von Bluemax und Nokia kann der Benutzer aber dennoch auf dem Handy und Laptop immer die aktuellen Positionsdaten erhalten und bearbeiten. Besonders auffällig ist das Abschneiden des Marktführers Garmin: Das Oregon 550t war mangels Satellitenempfang nicht in der Lage, am Arbeitsplatz in der Redaktion einen Standort zu bestimmen. Die Bluetooth-Geräte dagegen konnten am selben Standort mit bis zu acht Satelliten glänzen. Garmin-Kunden dürften da ein wenig enttäuscht dreinblicken, vor allem, weil die Konkurrenz doch nur ein Zehntel kostet. Und die Openstreetmap-Karten sind zumindest in Großstädten deutlich genauer als die im Garmin verbauten. Abbildung 5: Oben von links nach rechts: Das HTC Touch G2 von T-Online, Sony-Ericssons W995, Nokias 6720 Classic, Nokia 6500 und 6230i. Unten: Drei Bluetooth-GPS-Empfänger von Nokia (LD-4W), Bluemax (GPS-710 und 4013), ein USB-GPS-Stick von Navilock und das Garmin Oregeon 550t.

USB und Bluetooth

Die reinen GPS-Empfänger dagegen, die nur dem Empfang und der Weitergabe der Positionsdaten dienen, funktionieren problemlos mit allen getesten Geräten. Open Suse erkannte den Navilock-USB-Stick sogar vollautomatisch und verschaffte dem Gpsd sofort Zugriff.

Dennoch haben derartige USB-Geräte einen Nachteil: Sie arbeiten nur mit dem Notebook oder PC zusammen, während die Bluetooth-Empfänger auch mit Handys kommunizieren und sich ihre meist deutlich genaueren Positionsdaten so auch auf älteren Mobiltelefonen aufzeichnen lassen. Interessanterweise hatten alle Bluetooth-Geräte auch den mit Abstand besten Empfang, die Positionsbestimmung gelang deutlich schneller und zuverlässiger als mit dem zehnmal so teuren Garmin-Flaggschiff Oregon 550, gerade in geschlossenen Räumen.

Für ältere Notebooks empfiehlt sich ein beliebiger USB-Bluetooth-Dongle wie die von Acer, die es bereits ab 5 Euro gibt. Moderne Distributionen wie Ubuntu und Suse konfigurieren ihn ebenfalls automatisch oder gestatten die Konfiguration per Mausklick. Das funktioniert zuverlässig, wenn die Pakete »bluez-libs«, »bluez-utils«, »gnome-bluetooth«, »kde-bluetooth« installiert sind.

Wer nicht mit Yast, den KDE- oder Gnome-Tools arbeiten will, sondern die Befehlszeile bevorzugt, erledigt das Gleiche in wenigen Schritten. Mit »lsmod« checkt er, ob USB- und Bluetooth-Module (»hci«, »bluez«, »l2cap« und »rfcomm«) geladen sind. Unter Suse findet er in der Datei »/etc/bluetooth/hci.conf« Grundeinstellungen, die sich weitgehend auch mit dem entsprechenden Yast-Modul setzen lassen.

In der Regel ist aber erst dann Handarbeit notwendig, wenn der Rechner ein angeschlossenes Bluetooth-Gerät ansprechen soll. Damit das klappt, müssen beide Devices über so genanntes Pairing gegenseitige Vertrauensstellungen erwerben, in der Regel durch die gleichzeitige Eingabe der gleichen Pin. In »/etc/bluetooth/hci. conf« trägt der Benutzer dann die Adressen und Parameter für bekannte Geräte ein, die der Scan mit dem Programm »hcitool« aus den »bluez-utils« liefert:

# hcitool scan
Scanning ...
         00:18:96:D1:62:57 GPS-710

Hier meldet sich das Bluetooth-Gerät als GPS-710 mit vollständiger Geräteadresse. Die landet jetzt in »rfcomm.conf« (Listing 1). Dank des Eintrags »bind yes« stellt das System automatisch die Verbindung her, wenn das Bluetooth-Device in Reichweite gelangt. In die Zeile »device« kommt die mit Hcitool eruierte Geräteadresse. Jetzt den Bluetooth-Daemon neu starten (»rcbluetooth restart«), und schon informiert ein kleines Popup über das gefundene und als »/dev/rfcomm0« verbundene Gerät (Abbildung 4).

#
# RFCOMM configuration file.
#
rfcomm0 {
# Automatically bind the device at startup
bind yes;
# Bluetooth address of the device
device 00:18:96:D1:62:57;
# RFCOMM channel for the connection
channel 1;
# Description of the connection
comment "My Bluetooth GPS-710";
}

Soweit unterscheidet sich die Konfiguration nicht von jedem x-beliebigen Handy oder Bluetooth-Gerät, das zum Beispiel als UMTS-Modem dienen soll. Allerdings kann der Admin jetzt das Universaltool für alle GPS-Dienste unter Linux anwerfen: »gpsd /dev/rfcomm0« startet auf dem Port 2947 einen Gpsd-Server und gibt dort die aktuell vom Gerät empfangenen GPS-Daten aus, was der Admin schnell mit Telnet überprüfen kann (Abbildung 6). Nach der Eingabe von »r« rieseln die GPS-Daten im Rohformat über den Bildschirm.

Abbildung 6: Position, Höhe und Bewegungsdaten im Raw-Format: Wenn der Telnet-Befehl ähnliche Ergebnisse bringt, hat Gpsd das Gerät erkannt und liefert auf Port 2947 NMEA-Positionsdaten aus.

Fehlersuche

Über Fehler gibt »/var/log/messages« Aufschluss, hier sollten Einträge wie die folgenden auftauchen, später liefert auch Gpsd seine Errors brav hier hab:

usb 1-1: new full speed USB device using uhci_hcd and address 3

Bei Verbindungsproblemen lässt sich mit »l2ping 00:18:96:D1:62:57« überprüfen, ob die GPS-Maus noch erreichbar ist:

Ping: 00:18:96:D1:62:57 from 
00:02:72:B2:74:85 (data size 44) ...
4 bytes from 00:18:96:D1:62:57 id 0 time 11.73ms

Zur Not beherrscht der Gpsd auch noch einen Debugmodus »-D«, den der Admin allerdings zusammen mit der Option »-N« aufrufen sollte. Damit bleibt Gpsd im Vordergrund und gibt Debug-Informationen auf Levels von 0 bis 9 aus. Aus Listing 2 lässt sich so erkennen, dass das GPS-Gerät nicht aktiv ist. Für Benutzer eines Bluetooth-GPS-Empfängers findet sich eine detaillierte Anleitung auf [8].

gpsd: launching (Version 2.37)
gpsd: listening on port gpsd
gpsd: shmat(0,0,0) succeeded
gpsd: shmat(0,0,0) succeeded
gpsd: shmat(0,0,0) succeeded
gpsd: shmat(0,0,0) succeeded
gpsd: successfully connected to the DBUS system bus
gpsd: running with effective group ID 0
gpsd: running with effective user ID 0
gpsd: opening GPS data source at '/dev/rfcomm0'
gpsd: device open failed: Connection timed out - retrying read-only
gpsd: speed 115200, 8N1
gpsd: => GPS: $PASHQ,RID*28x0dx0a FAILED
gpsd: Navcom: command dump: 0299661c0800040200001203
gpsd: => GPS: 0299661c0800040200001203 FAILED
gpsd: Navcom: sent command 0x1c (Test Support Block)
gpsd: Navcom: command 0x1c mode = 02, length = 0
gpsd: Navcom: command dump: 029966200e000001ae02000071000000f203
gpsd: => GPS: 029966200e000001ae02000071000000f203 FAILED
gpsd: Navcom: sent command 0x20 (Data Request) - data block id = ae at rate 00
gpsd: Navcom: command dump: 029966200e00000186020a0071000000d003
gpsd: => GPS: 029966200e00000186020a0071000000d003 FAILED
gpsd: Navcom: sent command 0x20 (Data Request) - data block id = 86 at rate 0a
gpsd: garmin_gps not active.
gpsd: no probe matched...

Sirfmon und Gpsprof

Das Paket »gpsd« enthält außerdem exzellente, von Eric S. Raymond verwaltete Manpages und zwei weitere Tools, die sich in vielen Fällen als hilfreich erweisen: Gpsprof gestattet es, für GPS-Geräte Profile zu erzeugen und so durch Berechnen der für das Gerät typischen Latenzzeit eine höhere Genauigkeit bei Bewegungen zu erzielen.

Sirfmon dagegen bietet ein Clientprogramm, das sich über Port 2947 mit Gpsd verbindet und die Daten der meist verbauten Sirf-Chipsätze ausliest und in Ascii-Grafik darstellt. Wenn bis hierhin alles problemlos funktioniert, ist es Zeit für die Gpsd-Clients aus dem gleichnamigen Paket und andere Desktop-Programme wie Qlandkarte, die ein anderer Schwerpunkt-Artikel beschreibt.

Gypsy und Geoclue

Wer mit mehreren Clients gleichzeitig auf ein oder mehrere GPS-Geräte zugreifen möchte, sollte sich Gypsy [9] und das Geoclue-Framework [10] anschauen. Die Software mit dem Sinti-Namen ist ein GPS-Multiplexer und gewinnt auf Laptops und Desktops immer mehr an Relevanz. Wie auch Geoclue versteckt sie den kompletten NMEA-Stack vor der Anwendung und arbeitet wie ein GPS-Proxy, der auf Wunsch Clients nur über für sie relevante Änderungen informiert. Diese erhalten bei einer Bewegung zum Beispiel nur die neuen Positionsdaten, nicht aber zum Beispiel die Lageveränderung eines Satelliten.

Mit der zugehörigen Libgypsy lassen sich passende Anwendungen einfach erstellen, ideal für Smartphones. Die über das D-Bus-API bereitgestellte GPS-Daten bieten erstaunliche Möglichkeiten. Maemo Stars [11] beispielsweise soll dank Geoclue immer den aktuellen Sternenhimmel über dem Benutzer anzeigen, und auch die automatische LAN-Konfiguration (inklusive zum Beispiel Netzwerkdrucker) kann Software aus der GPS-Position vollautomatisch bestimmen.

Mit zunehmender Verbreitung von Location Based Services (LBS) auf mobilen Geräten – Sony spendierte seinen Geräten gar eine eigene Rubrik dafür – setzen die freien Oberflächen von Mobile Gnome, Maemo und Moblin auf derartige GPS-Frameworks, während die Platzhirsche Google (Android) und Apple (I-Phone) die proprietären Wege beschreiten. Das Gleiche gilt für die Allianz von Garmin und Asus, aus der das Nüvifone [12] stammt, eine Kombination aus Navi und Telefon, das es laut Hersteller aber wahrscheinlich nur für den amerikanischen Markt geben wird.

Open Source auf dem Handy

Wer sich unter mobilen Geräten ein wenig umschaut, stellt schnell fest: Die meisten Hersteller sind offenbar nur darauf aus, dem Kunden Verträge und Dienstleistungen der Onlinedienste (Google) über diverse Stores und Mapservices (Nokia) aufzudrücken. Gut, dass es da freie Software und die Kartengrundlage von Open- streetmap gibt. Jedes Java-fähige Handy mit Bluetooth lässt sich so zu einem kleinen Navigationssystem aufrüsten. Egal ob der betagte Klassiker Nokia 6230i, oder das W995: Einfach Gmaps Mobile (Creative Commons Licence, [13]) oder den Mobile Trail Explorer (GPL, [14]) per Download eines Jar- oder Jad-Archivs installieren, GPS aktivieren oder Bluetooth-GPS verbinden – und los gehts, auch wenn auf älteren Telefonen keine eindrucksvollen Performancewunder zu erwarten sind.

Auch Google bietet mit Google Maps for Mobile eine Java-basierte kostenlose Kartensoftware an, die aber beim Funktionsumfang nicht an die freie Konkurrenz heranreicht und natürlich nur die eigenen Geodaten verwendet. Interessanterweise scheint der Suchmaschinenriese offenbar bereits ein Auge auf die freie Konkurrenz zu haben: Mgmaps Mobile hat er schon vor Jahren die Nutzung der Google-Kartengrundlage verboten.

Macht aber nichts, beide OSS-Tools können im Gegensatz zur proprietären Konkurrenz Daten aus unterschiedlichsten Kartengrundlagen nutzen, Open- streetmap ist hier sicherlich die beste Wahl. Details über GPS-Empfang, Satellitenposition, Höhenprofile und Durch- schnittsgeschwindigkeit zeigen beide auf Knopfdruck an, die Onlinesuche hilft das nächste Restaurant, den Briefkasten oder Geldautomaten zu finden.

Der Mobile Trail Explorer ist zwar etwas anspruchsvoller und läuft vielleicht nicht auf jedem älteren Handy, aber dafür kann er Tracks aufzeichnen und sowohl als KML- [15] oder als GPX-Dateien [16] exportieren. Diese lassen sich mit Googles GIS-Anwendungen und zahlreichen Linux-Desktop-Programmen editieren (siehe Artikel zu GPS-Desktop-Programmen). Das GPS Exchange Format (GPX) dürfte allen Benutzern bekannt sein, die über ein USB-GPS-Gerät, zum Beispiel von Garmin, verfügen, es schon mal über USB angeschlossen haben und Tracks, Waypoints oder Karten hinauf- und heruntergeladen haben, etwa mit dem Universaltool Gpsbabel [17].

Globales Süppchen

Linux und GPS arbeiten prächtig zusammen, wenn der User darauf achtet, die richtigen Geräte zu kaufen. Wichtig ist die Unterstützung des NMEA-Standards, der meist schon auf der Verpackung genannt ist. Bluetooth-Geräte funktionieren nicht nur mit dem Laptop, sondern auch mit dem Handy, USB-Sticks in der Regel out of the Box.

Ganz anders die Handys: Deren primärer Zweck scheint schlicht die Bindung an einen Onlinedienst zu sein. Eine Mail des Linux-Magazins an die Entwickler von Gpsd beantwortete Eric S. Raymond höchstpersönlich: “Wir wissen nicht, wie sich die GPS-Daten aus Mobiltelefonen extrahieren lassen. Wenn Sie das herausfinden, bitte geben Sie uns Bescheid!” Eine Möglichkeit gibt es dennoch: Programmierer könnten auf die GPS-Daten von Java- oder Android-Handys zugreifen, wie es Mgmaps Mobile, der Trail Explorer und der Workshop von Linux Magazin Online [18] für das Google-Phone zeigen. Über Files, USB und das Web lassen sich die Positionsdaten heute bereits exportieren und für Anwendungen verwenden. Wer NMEA-Daten in seine Anwendungen integrieren möchte, findet in Jon Persons Anleitung [19] eine gute Einstiegshilfe. Was noch fehlt, ist eine Art Java-Gpsd für mobile Geräte, der die Daten des Sensors im NMEA-Standard über Bluetooth oder USB für den Rechner zur Verfügung stellt.