In den nächsten Wochen soll es einen ersten Test für die grundlegenden Funktionen von OpenDGPS geben. Eine mobile Station soll mit Hilfe eines RTL-Dongles die Korrekturdaten für die eigene Position ermitteln und diese via Ntrip (Server, Caster & Client sind hier verfügbar) an eine entfernte Station senden, die die Differential-Daten verwendet um die eigene Positionsgenauigkeit zu verbessern. Ein Vergleichs-Receiver an dieser Station dient dazu, die Verbesserung bei verschiedenen Situationen (delay, Wetter) zu vergleichen.
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.
hallo,
wäre es für einen ersten test nicht sinnvoller, basis und rover an der gleichen location zu haben? dann würde man doch die differenzen sehen. und es würde weniger auffwendig.
grüße und danke für das projekt! wäre toll, wenn es mal ein wenig schneller vorwärts gehen würde (just my 2¢).
Hi, gibt es hierzu mittlerweile publizierbare Ergebnisse ?
Stimme @ronalds zu: es sollte mal ein wenig vorwärts gehen. Vielleicht wäre es ja sinnvoll, wenn Ih mal schildern würdet, woran es hakt. Das Projekt ist interessant und es sollten sich doch wenigstens für einige Dinge Leute finden, die was übernehmen würden.
Ich stehe zum Beispiel für alles rund um PCBs zur Verfühung.
@ronald, @Oliver, G@H: Verschiedene äussere Umstände haben bisher erfolgreich einen Start verhindert. Aber wir sind zuversichtlich und gehen davon aus, dass im Frühjahr sowohl eine genauere Beschreibung der Testumgebung als auch der Hard- und Software veröffentlicht werden kann. Die ursprünglichen Planungen haben sich sowohl in Hinsicht auf die verwendete Hardware als auch auf den Software-Stack als zu schwer handelbar rausgestellt.