Ich habe bereits vor einiger Zeit darüber berichtet, wie man seinen eigenen ADS-B-Receiver bauen kann. Nachdem ich mein Projekt mit meinem Raspberry Pi abgeschlossen hatte, wollte ich ihn auch als Plattform für einen ADS-B-Receiver benutzen...

Grundlage war die bereits beim Projekt WLAN Access Point festgelegte Einschränkung, dass das System in einem Container laufen sollte - dazu musste das System auf dem Host davon überzeugt werden, das Gerät an den Container durchzureichen. Ich schaffte das mittels folgender Zeilen in der Konfigurationsdatei des Containers:

# RTL-SDR device
lxc.cgroup.devices.allow = c 189:* rwm
lxc.mount.entry = /dev/bus/usb/001 dev/bus/usb/001 none bind,optional,create=dir
lxc.mount.entry = /dev/rtl_sdr dev/rtl_sdr none bind,optional,create=file

Dabei ist speziell die Major/minor number gegebenenfalls anzupassen und auch der Name des USB-Buses - das folgende Kommando kann dabei helfen:

#auf dem Host!
ls -lisah /sys/dev/*|grep usb

Das vollständige Skript zur Einrichtung des Systems ist in folgendem Gist zu finden.

Wichtig hierbei war, dass ich auf dem Host-System die Benutzung des Sticks als DVB-Receiver verbieten musste (Linux und speziell Ubuntu machens dem Nutzer leicht - ich bin aber einer der wenigen, der den Haupteinsatzzweck des Sticks nicht benötigt - daher...)

#auf dem Host!
sudo printf 'blacklist dvb_usb_rtl28xxu\nblacklist \
rtl2832\nblacklist rtl2830' > /etc/modprobe.d/nortl.conf

Das Skript installiert einige Dinge, die für die reine Funktionalität als ADS-B-Receiver nicht unbedingt benötigt werden: wget und mono-complete werden für die Installation des Virtual Radar Servers benötigt. Der wird - wie gesagt - nicht unbedingt benötigt; Allerdings hatte ich nach Installation und Start von dump1090 den Eindruck, dass das Projekt kaputt wäre, da das Web-Frontend nicht funktionierte - irgendwas mit "Google Maps API nicht korrekt eingebunden". Als ich den Virtual Radar Server startete, kam dort im Web-Frontend allerdings dieselbe Fehlermeldung - Tatsächlich hat Google wohl irgendwann die Nutzungsbedingungen geändert - jetzt benötigt man eine Registrierung und einen Key. Das gilt jedoch nicht, wenn man das Web-Frontend auf localhost aufruft. Daher ist der Status im Moment bei mir so, dass ich dump1090 und den Virtual Radar Server installiert habe und beim Zugriff auf eines der beiden Web-Frontends halt eine Portweiterleitung über SSL einrichte...

Noch zwei Anmerkungen zum Virtual Radar Server: Unter Ubuntu/Mono4 lässt er sich nicht sofort starten - der Fehler kann behoben werden, wenn man den Inhalt dieses Gists ins Installationsverzeichnis unter dem Namen VirtualRadar.exe.config speichert.

Den Port, auf dem der Server sein Web-Frontend anbietet, kann man durch Speichern des Inhaltes dieses Gists im Homeverzeichnis unter ~/.local/share/VirtualRadar/InstallerConfiguration.xml (und entsprechende Anpassungen) ändern.

Wichtige Anmerkungen um jetzt richtig in die BigDataAnalyse der diversen Folterflüge der CIA einsteigen zu können: dump1090 leitet die empfangenen Transponder-Messages in einem Textformat auf Port 30003 (default) aus - man muss sich schon selber darum kümmern, diese Daten weiter aufzubereiten. Das kann man direkt auf dem Raspi zum Beispiel tun, indem man sie einfach als Rohdaten speichert. Dazu kann man sich beispielsweise einem der Beispielprogramme für py1090 bedienen (Achtung: setzt Python 3 voraus!).

Ich habe das Projekt geforkt, da ich einige Erweiterungen an FlightCollectionEntry vornehmen wollte und eines der Beispiele so nicht funktioniert hat...

Natürlich sind auch noch andere Wege denkbar: Der Virtual Radar Server beispielsweise bietet die Angaben zu allen aktuell sichtbaren Flugbewegungen als json über das Web-Frontend an.

Hier nun noch einige Links, die mir bei der Inbetriebnahme geholfen haben:

Links

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )