(Danke an OpenDEM für den Tipp!)

Neben App und Mapeditor bietet das Projekt Links zu frei verfügbaren Daten und interessante Informationen aus dem Bereich.

Testsetup mit einer Basisstation und einem “Rover”

Die Distanz beider Stationen beträgt 3,63km und beide sind an einer dauerhaften DSL-Verbindung am Netz.

Setup Basis:

Die Basisstation besteht aus einem parallella mit einem Dual Core ARM A9 auf Basis eines Zynq7020 und einem 16 Core Epiphany SMP. Sowohl die Programming Logic als auch der Multicore-Prozessor kommen im ersten Schritt nicht zum Einsatz. Später soll möglicherweise der FPGA des Zynqs einige Operationen des RTL-SDR-Parts (z.B. via GPS Demystified) oder/und RTKLIB übernehmen.

Als Receiver für die GPS Daten kommt ein einfacher 10€ DAB+ Dongle mit RTL-Chip zum Einsatz. Auf dem SDR-GPS-Blog von Peter Hahn findet sich eine Anleitung, wie man mit Hilfe von GNURadio an die GNSS-Daten gelangt.

Die Korrekturdaten sollen mit Hilfe des NTRIP-Protokolls (über einen Proxy) veröffentlicht werden. Die interessante Frage ist erstens, wie zeitnah ein 1GHz Dual Core ARM die Daten mit Hilfe der RTKLIB berechnen kann und zweitens, wie zeitnah die Daten tatsächlich für welche Genauigkeit beim Rover sein müssen. Es ist klar, dass je aktueller die Differential-Daten tatsächlich sind, desto genauer wird die Korrektur sein. Möglicherweise genügt jedoch eine Update-Frequenz von Minuten um eine signifikante Steigerung der Genauigkeit zu erlangen. Zumal in dem Testsetup vorerst nur eine feste Station die Daten liefert.

Für den Test ist nicht vorgesehen, die Basisstation aufwendig zu eichen. Es soll lediglich eine mehrere Stunden dauernde Korrektur vorgenommen werden um eine annähernde Genauigkeit zu erreichen. Da die Station nicht bewegt wird dürfte sich die Ungenauigkeit an dieser Stelle nicht auf die Qualität der Korrekturdaten auswirken.

Setup “Rover”:

Der Rover ist in unserem Test keine bewegliche Einheit sondern ein stationäres System. Es soll zunächst nur dazu dienen, den Gewinn an Genauigkeit zu definieren. Es wird ein UDOO Quad Core verwendet. Das UDOO verfügt neben einem normalen ARM-System auch über eine Arduino-Einheit die uns die benötigten I/Os bietet. Als GPS-Receiver kommen zwei NaviLock NL 507E TTL zum Einsatz. Der darin verbaute u-blox kann mit NTRIP-Daten umgehen und sie zur Korrektur verwenden.

Dabei soll der nur einer der beiden Receiver die Korrekturdaten erhalten. Der andere Empfänger verwendet nur die onboard Positionierung. Dadurch können die beiden Daten verglichen werden und hoffentlich die Unterschiede in der Genauigkeit sichtbar werden.

Auf dem Rover-System läuft keine RTKLIB, die NMEA-Daten werden lediglich über TTL zur späteren Analyse gespeichert.

Die Besonderheit bei diesem Projekt ist die Programmierung des FPGA mit Forth. Sicher keine Allerweltssprache aber für den Zweck hervorragend geeignet. Der Sprachcore passt ohne Probleme in den inzwischen recht kleinen Spartan 3 mit unter 10k Logic Cells. Das Projekt ist ein hervorragender Ausgangspunkt für eigene Entwicklungen.

Basierend darauf hat John Seamons vor kurzem eine eigene Implementierung mit einem Spartan 6 und einem Beaglebone Black gemacht. Der FPGA wäre tatsächlich in der Lage, die Rohdaten aufzubereiten und der Prozessor auf dem Beaglebone hätte genug Power, die Differenzsignale zu berechnen. Die Kosten für eine solche Kombination sind allerdings derzeit noch mit knapp 150€ zu hoch. Spannender könnten dann Systeme sein, die über einen Zynq-Prozessor von Xilinx verfügen. Dieser hat zwei vollwertige ARM-Kerne und einen groß bemessenen FPGA gleich mit drin. Für $15 pro Zynq liessen sich wesentlich kostengünstigere und stromsparende GNSS-Reciever bauen.

• alle Vermessungspunkte bundesweit,
• über eine einheitliche digitale Schnittstelle,
• in verschiedenen Koordinatensystemen,
• kostenfrei und
• zur kostenlosen Nutzung

verfügbar sein. Ganz offensichtlich leben wir ja nicht in einer idealen Welt und daher ist es nicht verwunderlich, dass einige dieser Wünsche als illusorisch darstellen.

Verantwortlich für die Messpunkte, respektive Vermessungspunkte sind die Länder. Und da Deutschland ein föderales System ist, gibt es keine zentrale Stelle die die Informationen sammelt.

Auch eine einheitliche digitale Schnittstelle oder auch nur ein und das gleiche System für die Abfrage der Daten gibt es nicht. Es gibt offensichtlich in keinem Land überhaupt eine Schnittstelle für die digitale Abfrage der Daten. Dass die Messpunkte noch nicht einmal einheitliche IDs haben versteht sich da schon fast von selbst.

Bei solcher föderaler Vielfalt versteht es sich schon fast von selbst, dass in verschiedenen Bundesländern auch verschiedene Koordinatensysteme geführt werden. Während irgendwo sonst das Gauß-Krüger-Koordinatensystem verwendet wird, setzt Berlin noch mindestens bis zum nächsten Jahr das Soldner-System ein. Wozu auch auf WGS84 umschalten? Das ist doch erst 30 Jahre alt und funktioniert ja nur hervorragend mit GPS/GNSS.

Wer bei solch einer Fülle von Ansprechpartnern und Umgebungsvariablen noch nicht die Lust verloren hat, an die Daten kommen zu wollen wird sich doch vielleicht endgültig von unkalkulierbaren Kosten abschrecken lassen, oder? Und tatsächlich sitzen die Behörden auf einem Schatz. Kein Mensch weiss, wie hoch der Wert dieses Schatzes ist und deswegen gibt es bei den Landesvermessungsämtern auch keine Preislist à la “… bis 5 Messpunkte im Monat sind umsonst, unter 100 kosten jeweils 0,15€ …”. Nein, man muss eine Mail schicken oder anrufen. Z.B. beim Landesbetrieb Geoinformation und Vermessung (LGV) in Hamburg, Öffnungszeiten gibt es nur nach telefonischer Rücksprache. Die Mindestbestellmenge ist aber auf jeden Fall schon mal 50€.

Möglicherweise lässt man sich ja selbst von Kosten in unbekannter Höhe nicht abschrecken. Was aber nicht heißt, dass man die Daten, egal in welcher Form, wirklich bekommt. Denn “Auskünfte und Auszüge aus den Nachweisen der Grundlagenvermessung erhalten ausschließlich Vermessungsfachleute”. Wie der Nachweis über eine solche Befähigung zu erfolgen hat steht leider nirgendwo.

OpenData in weiter Ferne

Es wäre vermessen anzunehmen, dass Behörden von selbst auf die Idee kämen, ihre Schätze allen in einer einfachen Form zur Verfügung zu stellen. Diese Forderung ist schon deswegen illusorisch, weil Behörden schon für die Entscheidungsfindung, ob und wenn ja, wie sie dies tun sollten langsamer sein müssen als Firmen oder Organisationen. Daher ist es nicht verwunderlich, dass die Bahn dem Datenbefreier Michael Kreil mit Klage gedroht hatte als dieser deren Fahrpläne von der CDROM in ein offenes Format transformierte und öffentlich zur Verfügung stellte.

Aber wir sind dennoch optimistisch. So hat Berlin seit kurzem ein Portal in dem die OpenData-Angebote des Senats gebündelt sind. Und prinzipiell ist die Politik dem Gedanken aufgeschlossen und wünscht sich eine höhere Beweglichkeit der Verwaltung. Das wird zum Beispiel deutlich an dem Projekt GeoApps durch das Projekte gefördert werden sollen, die Daten der Vermessungsämter nutzen sollen und sinnvolle Anwendungen entwickeln sollen. Leider ist das Setup solcher Förderungen – vorsichtig ausgedrückt – mitunter etwas exotisch.

Hilfreiche Links: Liste der Landesämter

Piksi Modul (Quelle: swift-nav.com)

Bei Kickstarter ist vor wenigen Tagen ein Crowdfunding Projekt gestartet, dass sich ideal für OpenDGPS eignen würde. Wenn es nicht viel zu teuer wäre. Mit $900 für zwei Piksi-Module verlangen die Macher fast das zehnfache der Materialkosten. Der Preis scheint aber gerechtfertigt, da schon jetzt die angestrebte Summe von $14.000 weit überschritten ist.

Ein Piksi-Modul besteht aus Antenne, einem Analog-Digital-Wandler, einem Startan-6 (jenem FPGA-Chip auf dem Mojo) und einem ARM Cortex-M4 (STM32F4, über diese günstige CPU hatten wir uns letzte Woche einen Vortrag auf der Makers Faire in Hannover angehört). D.h. Piksi verfügt selbst nicht über einen eigenständigen GNSS-Receiver und stellt damit eine neue Kategorie dar, die man in Zukunft häufiger antreffen dürfte. Zumal das Design mit einem Stromverbrauch von 500mA sehr sparsam ist.

Die Macher von Swift Navigation aus Kalifornien versprechen eine Genauigkeit von bis hinunter zu 1cm. Dabei muss man aber berücksichtigen, dass dazu das Differenzsignal von einer geeichten Feststation kommen muss. Andernfalls gilt diese Genauigkeit nur in Bezug zur Referenzstation. Insofern dürfte es bei einigen Käufern ein böses Erwachen geben. Denn immerhin sind DGPS-Signale noch nicht frei verfügbar.

Interessant ist das Projekt auch, weil sowohl Hardware als auch Software Open Source ist. Damit ist es auch anderen möglich, das Modul nachzubauen und dann bei wesentlich geringeren Kosten zu landen.

[Update] Mit Sicherheit wäre ein Zynq 7010 oder 7020 für das Projekt wesentlich besser geeignet als die Kombination aus Spartan-6 und Cortex-M4. Denn erstens ist darin ein wesentlich leistungsfähigerer ARM-Prozessor drin und zweitens hat der FPGA-Teil bis zu 10 mal mehr Logicelemente. Bei einer Abnahme von x000 Stück kostet eine solche CPU lediglich $15. [Update]

In der Größe zwischen Raspberry Pi und typischen Arduinos und mit ähnlich vielen In und Outs.

Unter dem Namen Mojo läuft grade bei kickstarter eine Sammelaktion für ein FPGA-Board mit einem Xilinx Startan-6 Prozessor. Für $65 bekommt man ein sehr gut mit Ein-/Ausgängen (analog und digital) ausgestattetes Board.

Wirklich interessant wäre es, wenn sich jemand finden würde, der eine RTKLIB-Implementierung für FPGAs anfasst. Zusammen mit einem Software-Defined-Radio könnte man damit dann einen DGPS-Receiver bauen, der in Echtzeit sehr hohe Genauigkeiten liefern würde. Insbesondere da die RTKLIB Daten von Bewegungssensoren einberechnen kann.

Laut Microsoft könnten so funktionierende GMP-Module mit extrem wenig Strom auskommen. Es bleibt allerdings fraglich, wie der einzusparende Strom nicht komplett durch die dadurch notwendige Online-Verbindung aufgefressen wird. Prinzipiell wäre so auch eine OpenDGPS-ähnliche Lösung zur Verbesserung der Positiondaten möglich. Davon schreiben die Autoren des originalen Papers merkwürdigerweise nichts.

Leider ist Mediawiki in der Standardinstallation ein riesiges Einfallstor für alle möglichen Angriffsformen. Da wir aber unsere Zeit derzeit nicht in die Pflege und das patchen von Serversoftware stecken können (und wollen) bleibt das Wiki vorerst offline.

Vielen Dank für die Hinweise!