Obwohl gestern das Device “Null” (RaspberryPi + Navilock NL 507TTL) seinen ersten Test erfolgreich bestanden hat, soll nicht verheimlicht werden, dass es durchaus leistungsfähige Alternativen zu dem mit ~20€ sehr preiswerten Modul gibt. Zumal das Navilock nur noch in Restbeständen verfügbar ist.
Sébastien Carcanague hat uns aus Toulouse kontaktiert und auf die NV08C-Serie hingewiesen. Sébastien ist angehender PhD und schreibt grade seine Thesis an der dortigen Universität. Interessant für OpenDGPS ist er vor allem, weil er eine viel beachtete und von dem Institut of Navigation – ion (eine rührige Organisation, die leider nicht genug Abstand zum Militär hält) ausgezeichnete Arbeit mit dem Titel “Real-Time Geometry- Based Cycle Slip Resolution Technique for Single-Frequency PPP and RTK” veröffentlichte.
Ein NV08C-Modul mit seriellem Anschluss für etwas über 40€. (Quelle: Farnell Deutschland, mehr nach dem Klick …)
Ein Modul mit einem NV08C-Design ist beispielsweise bei Farnell Deutschland für 43€ in ausreichender Stückzahl verfügbar. Auf dem Modul kommt ein MAX2769 zum Einsatz, der die beiden Frequenzen für GPS/GALILEO (1575.42 MHz) und für GLONASS (1602.0 MHz) bearbeiten kann. Er unterstützt SBAS und kann 32 Kanäle erfassen.
Einen ausführlichen Einsatzbericht mit vielen Hintergrund-Links hat vor kurzem Hagen.Felix im kowoma GPS-Forum veröffentlicht. Leider wird dort wieder nur der Einsatz unter Microsoft Windows beschrieben und es ist wohl an uns, den Einsatz mit OSS zu dokumentieren.
Auf der Suche nach näheren Informationen zum u-blox LEA-4T stiess ich auf diese Seite. Soweit ich es bis jetzt verstanden habe, wollen sie ein Netzwerk von freien Referenzstationen aufbauen, dass die Differential-Daten mittels NTRIP ausliefert. Wie wollen sie jedoch die richtige Auswahl der benötigten Daten sicher stellen? Wenn in dem Netz 100 Server die Differenzinformationen für die gleichen Satelliten liefern unterscheiden sich die Abweichungen ja erheblich.
Bzgl. Windows und OSS: Es gibt auch unter Windows hunderttausende freie Software unter der GPL und anderen Lizenzen. Woher kommt die Abneigung gegen das weit verbreitetste Betriebssystem?
@RvB: Im Gegensatz zu @Zonist sehen wir den Einsatz von Windows recht entspannt. Allerdings kommt es zumindest für die Referenzstationen nicht in Frage. Diese müssen autonom/headless mit möglichst geringem Stromverbrauch permanent laufen. Ersteres würde man mit entsprechenden Tools noch hinbekommen, letzteres jedoch nicht. Es ist allerdings nicht zu übersehen, dass gerade in der Elektronikbastelgemeinde Windows überwiegt. Das liegt mit Sicherheit an den professionellen Programmen für das Platinendesign aber auch an der verbreiteten Legacy-Ausstattung der Rechner.
Die Auswahl der richtigen Referenzdaten lässt sich recht leicht berechnen. Da ja bei den festen Stationen die Position exakt bekannt ist und bei einer mobilen Station immerhin mit einigen Metern werden einfach die Daten der nächstgelegenen Station verwendet. Unter Umständen könnte man sogar noch eine Funktion einbauen, die die Laufzeit der Signale über IP ermittelt und bei besonders schlechter Netzverbindung einer Referenzstation dann lieber eine ausgewählt wird, die etwas weiter entfernt ist, dafür die Daten aber schneller liefert.
@RvB: Fast alle freie Software unter Windows ist ein mehr oder weniger verkrüppelter Versuch annähernd die gleiche Funktion hinzubekommen, wie sie unter Linux seit Jahren von Hause aus exsitiert. Für eine offenes Projekt verbietet sich der Einsatz eines solchen Betriebssystems sowieso.
Hallo,
Für 39,62€ gibt es bei Watterott ein GPS-Modul mit 10Hz Update Rate auf Basis eines MTK3339 :
http://www.watterott.com/de/Adafruit-Ultimate-GPS-Breakout-66-channel
Das Breakout-Board hat sowohl eine interne Antenne als auch einen Anschluß für eine externe aktive Antenne. Es läßt sich sehr einfach an einem Raspberry Pi betereiben.
Hier mal ein paar technische Daten:
Update rate: 1 to 10 Hz
Position Accuracy: 1.8 meters
Velocity Accuracy: 0.1 meters/s
Warm/cold start: 34 seconds
Acquisition sensitivity: -145 dBm
Tracking sensitivity: -165 dBm
Maximum Altitude for PA6H: tested at 27,000 Meters
Maximum Velocity: 515m/s
Vin range: 3.0-5.5VDC
MTK3339 Operating current: 25mA tracking, 20 mA current draw during navigation
Output: NMEA 0183, 9600 baud default
DGPS/WAAS/EGNOS supported
FCC E911 compliance and AGPS support (Offline mode : EPO valid up to 14 days )
Up to 210 PRN channels
Jammer detection and reduction
Multi-path detection and compensation
Ich verstehe leider zu wenig davon. Aber dort steht was von DGPS Support.
Heißt das, dass das Modul unter Umständen für Euer Projekt geeignet wäre?
LG Andreas
Hallo Andreas,
Danke für den Hinweis! Es ist nicht so ganz klar, ob man das Modul dazu bekommt, die Rohdaten rauszurücken. Das ist leider ein Unterschied zu der Fähigkeit, DGPS zu unterstützen. Wir untersuchen das aber auf jeden Fall, denn es gibt bestimmt eine Möglichkeit
rtklib unter WINE sieht gut aus.
Warte auf meinen NL 507TTL, um ihn an meine Himbeere zu stöpseln.
Spiele derweil ein bisschen mit rtklib rum (naja, fast etwas RTFM)
Good news: die zum Verständnis, Testen und Messen offensichtlich gern verwendeten GUI.exe-Teile von rtklib scheinen recht stressfrei unter wine zu laufen.
(natürlich nur auf einer x86… Maschine)
Zumindest kann man sie starten und bedienen.
Ich habe dann versucht, eine 0815 USB-GPS-Maus anzusprechen.
Der Trick: das USB-Device muß auf einen seriellen Port gemappt werden
http://ubuntuforums.org/showpost.php?p=8371229&postcount=2
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1
Ich sehe dann zumindest einen grünen Input in RTKNAVI blinken, und lsof zeigt Zugriff auf /dev/ttyUSB0. Allerdings habe ich nichts gefunden, RTKNAVI mit “normalen” NMEA-Daten zu irgendwas interessantem zu bewegen. So warte ich halt weiter auf ein rohdatenfähiges Device. Oder pflüge weiter durchs Manual, vielleicht finde ich ja noch ein Tool, das aus NMEA was hübsches generiert.
Ah, zumindest kann ich mit STRSVR den NMEA-Stream in ein File pipen, und wenn ich möchte, gleichzeitig über die Monitor-Funktion ansehen.
Vor allem aber weiß ich, daß der Zugriff auf das USB-Device funktioniert
Hallo zusammen, wir haben das o.g. Modul integriert und einen low cost Empfänger in Submeter Genauigkeit entwickelt. Alberding A07… Korrekturdaten werden automatisch über ein integriertes GPRS Modul empfangen und verarbeitet. Das System kann mit Apple oder Android (und alle Bluetooth fähige Geräte) mittels Bluetooth verbunden werden.
Beste Grüße
J.Peters
Hallo, vielen Dank für den Verweis auf das Projekt Guide4Blind. Gratulation zu der Entwicklung des A07. Wir haben das Projekt kurz beschrieben: http://opendgps.de/hohe-ortungsgenauigkeit-als-unterstutzung-fur-blinde/
Pingback: Hohe Ortungsgenauigkeit als Unterstützung für Blinde | OpenDGPS