Der Automatic Dependent Surveillance-Broadcast, kurz ADS-B, ist ein unverschlüsseltes Überwachungssystem, mit dem Flugzeuge aktuelle Parameter ihres Fluges fortlaufend senden. Mithilfe einer erschwinglichen Antenne, die per USB an einen Computer oder Minicomputer angeschlossen werden kann, können auch Laien diese Fluginformationen empfangen und auf bestimmte Plattformen hochladen, die mit vielen tausenden dieser Empfänder genaue Flugrouten und weitere Statisiken bauen können. Dafür werden die Personen, die solch eine Datenspende betreiben, mit gratis Premium-Accounts dieser Plattformen entlohnt. Diese Premium beziehungsweise Enterprise-Accounts werden sonst in der Regel für einen mittleren dreistelligen Betrag pro Jahr verkauft, der Weg zu einem solchen Account über so eine Datenspende rentiert sich also weniger als einem halben Monat.
Diese Anleitung dient als Leitfaden des Aufsetzen und betreiben eines ADS-B-Empfängers auf der x86-Platform mit Debian-basiertem Betriebssystem. Dieser Weg lohnt sich in der Regel nur, wenn bereits ein Server im 24/7-Betrieb vorhanden ist – deutlich effizienter (und kostengünstiger) ist sonst das Betreiben eines Raspberry Pi-Microcomputers (Version 3B oder höher), der mit einem extra Image bespielt werden kann, welches nahezu mühelos den Einstieg in die ADS-B-Datenspende erlaubt.
Wir werden in dieser Anleitung mit Docker Piaware und Fr24feed aufsetzen und untereinander verbinden, damit wir Daten an Flightradar24 und FlightAware senden können.
Vorbereitungen
Bevor es los gehen kann, müssen noch ein paar Vorbereitungen getroffen werden:
1. Die Hardware
Ich nutze für meine Installation und die folgenden Schritte einen Odroid h2+ als Hardwareplattform, jedoch sollten auch alle anderen x86-basierten Systeme kompatibel sein.
Als ADS-B-Empfängerset nutze ich einen TV28T-v2-USB-Dongle, der mit dem RTL2832U-Chip ausgestattet ist. Dieser Dongle kann bei Amazon für rund 25 Euro erworben werden.
2. Die Software
Ich selber nutze Ubuntu 20.04 LTS in der Server-Version, ich empfehle stark die Nutzung eines Linux-basierten Betriebssystems – auch wenn mit Docker und Docker Compose, der einzigen weiteren benötigten Software für diese Anleitung, die Anwendung auch unter Windows und weiteren Systemen funktionieren sollte (und übrigens auch auf ARM, aber da gibt es ja auch direkt das Image von Flightradar24).
Die API-Keys erhalten
Ein erster Schritt in dieser Anleitung ist das Vorbereiten des Erhalten der API-Keys, mit der wir unsere Daten richtig zugeordnet spenden können. Hier brauchen wir zwei verschiedene API-Keys, da wir an zwei Portale unsere empfangenen Daten weitergeben wollen. An erster Stelle sollten Nutzeraccounts auf Flightradar24 und FlightAware erstellt werden.
Danach wird mit
sudo -s
docker pull mikenye/piaware:latest
timeout 60 docker run --rm -e LAT=YOURLATITUDE -e LONG=YOURLONGITUDE mikenye/piaware:latest | grep "my feeder ID"
der API-Schlüssel für PiAware generiert. Achtung: Im letzten Befehl muss der zukünfigte Standort des Empfängers als Koordinaten ersetzt werden. Dieser sollte nach dem starten des letzten Befehls in folgendem Syntax angezeigt werden:
2020-03-06 06:16:11.860212500 [piaware] my feeder ID is acbf1f88-09a4-3a47-a4a0-10ae138d0c1g
Der hintere Teil ist dabei der Schlüssel für PiAware (diesen Aufschreiben!). Damit der Schlüssel auch dem richtigen Benutzer-Account zugeordnet werden kann, sollte auf PiAware Claim der Empfänger „geclaimed“ werden.
Für Flightradar24 benötigen wir ebenfalls noch den API-Schlüssel:
docker run \
--rm \
-it \
-e FEEDER_LAT="YOUR_FEEDER_LAT" \
-e FEEDER_LONG="YOUR_FEEDER_LONG" \
-e FEEDER_ALT_FT="YOUR_FEEDER_ALT_FT" \
-e FR24_EMAIL="[email protected]" \
--entrypoint /scripts/signup.sh \
mikenye/fr24feed
Auch hier werden wieder die Koodinaten und dieses mal die E-Mail-Adresse des Nutzeraccounts bei Flightradar24 sowie die Höhe des Sensors über dem Meeresspiegel in Fuß (!) ersetzt.
Nach kurzer Zeit sollte der API-Schlüssel folgendermaßen angezeigt werden:
FR24_SHARING_KEY=XXXXXX-YYYYYYY
FR24_RADAR_ID=T-XXXX123
Mit dem API-Schlüssel der beiden Plattformen notiert kann es nun endlich zur Einrichtung und Installation gehen.
Grundlegende Einstellungen: Setup
Mit den API-Keys ausgestattet sollte zuerst überprüft werden, dass Docker läuft und aktuell ist, dies (und alle weiteren Schritte) führen wir mit Superuser-Rechten aus:
sudo -s
apt update && apt upgrade
Als nächstes wird ein neuer Ordner für das Composer-Skript und den Zwischenspeicher von piaware angelegt (eventuell den Speicherort abändern, im Home-Verzeichnis docker compose-ordner zu haben, ist nicht wirklich optimal):
mkdir adsbreciver
Dann wird im nächsten Schritt der USB-Dongle eingesteckt, die Antenne sollte bereits mit dem USB-Dongle verbunden sein. Danach werden die Kernel-Module des RTL-Empfängers deaktiviert, damit Docker ungestört auf den Empfänger zugreifen kann. Mit
nano /etc/modprobe.d/blacklist-rtl2832.conf wird eine neue Datei angelegt, in diese wird
# Blacklist RTL2832 so docker container piaware can use the device blacklist rtl2832
blacklist dvb_usb_rtl28xxu blacklist rtl2832_sdr
geschrieben – nach einem Neustart des Computers kann nun die eigentliche Software-Konfiguration beginnen. Zuerst gehen wir in den schon erstellten adsbreciver-Ordner:
sudo -s
cd adsbreciver
Dann erstellen wir eine Docker Compose-Datei:
nano docker-compose.yml
In diese wird der folgende Inhalt eingefügt:
In der Datei selber muss wie schon bei der API-Schlüssel-Erzeugung der korrekte Ort eingetragen werden, die Koordinaten des Aufstellorts ersetzen die Platzhalter-Koordinaten unter LAT= und LONG= in Zeile 18 und 19 der Datei. Dazu werden nun in Zeile 20 und 35 die API-Schlüssel eigetragen, dannach kann die Datei abgespeichert und geschlossem werden (strg + x, dann mit „y“ bestätigen).
Wenn all diese Punkte geschafft sind, wird es spannend – mit
docker-compose up -d
kann der Docker-Container gebaut und gestartet werden, wenn alles klappt sollten keine großen Fehlermeldungen nun aufkommen.
Ob die Container tatsächlich laufen, lässt sich dann mit
docker ps
überprüfen – dort sollten nun als Container „piaware“ und „fr24feed“ gelistet sein.
Funktionsüberprüfung und Einchecken der Sendestation
Herzlichen Glückwunsch, wenn alles gestimmt hat und die Container richtig laufen, auf den Dongle zugreifen können und die API-Keys stimmen, können nun im Browser die Statusseiten der Empfängersoftwaren geöffnet werden. Um diese zu sehen wird hinter die IP des Servers, auf dem der Software-Stack läuft, einen von zwei Ports hinzugefügt. Mit dem Port :8080 kommt man auf die Statusseite von PiAware, mit dem Port :8754 sieht man die Statusseite von Flightradar.
Wenn tatsächlich alles geklappt hat, sollten zügig auch Mails von Flightradar24 und FlightAware eintreffen, dass die Sendestation erfolgreich eingecheckt hat und Daten sendet – damit wird in der Regel auch direkt der Bussiness-/Enterprise-Account bei den Platformen als Dank freigeschaltet. Jetzt geht es nur noch darum, den Sender dauerhaft zu betreiben.
Nach ein paar Tagen lohnt sich umbedingt auch ein Blick auf die Statistik-Seiten von Flightradar und FlightAware, die Punkte wie Ausrichtung, übermittelte Flugzeuge und Verfügbarkeit aufschlüsseln. Hierzu einfach auf den Seiten jeweils über den Nutzeraccount den Punkt „My Statistics“ aufrufen.
Die Seite meines Empfängers lässt sich übrigens hier anschauen :-).
Hinweise für längerfristiges Betreiben
Noch ein paar Anmerkungen, wenn man die Software dauerhaft betreiben möchte:
- Firewall-Configurationen anschauen: Die statusseiten sollten keinesfalls von außen erreichbar sein, dementsprechend sollten die Ports der Empfänger-Software nicht geöffnet sein. Bei handelsüblichen Routern ist dieses Verhalten Standart, im Zweifelsfall aber lieber nochmal die Konfiguration anschauen. Sollte man für längere Zeiträume keinen Zugriff auf das lokale Netzwerk haben (z.B. bei einer ausgedehnten Radtour durch Skandianvien), kann man mithilfe eines VPN-Zugangs (Fritzboxen haben diese Funktion eingebaut) auch ohne nach außen offene Ports auf die Statusseiten zugreifen.
- Sollten die Container mal händisch neugestartet werden oder ein Update in der Empfängersoftware benötigt werden, kann mit docker-compose down der Container offline genommen werden. Hierbei gehen keine Daten verloren.
Trubleshooting-Tipps
Nicht alles funktioniert immer beim ersten Versuch. Ich empfehle immer erstmal einen Neustart bevor es ans lesen von Log-Dateien geht.
Sollte dieser nicht das Problem behoben haben, ist der zweite Schritt für mich immer, mit
docker ps
den aktuellen Status der Container abzufragen. Im nächsten Schritt rufe ist Standartmäßig die Logs der Container auf. Dies ist unkompliziert mit
docker logs [container]
möglich, container wird hierbei mit „piaware“ und „fr24feed“ ersetzt. In aller Regel geben diese Logs schon sehr konkrete Hinweise auf den Fehler, z.B. dass die API-Schlüssel falsch sind oder der Container nicht auf den ADS-B-Dongle zugreifen kann.
Letzterer Fehlerfall hat als eine Besonderheit, dass das Betriebssystem auch Treiber für den Dongle geladen haben könnte, weshalb dann Docker nicht auf den Dongle zugreifen kann. Dieser Fehler wird mit
2019-04-29 21:14:31.642500500 [dump1090-fa] Kernel driver is active, or device is claimed by second instance of librtlsdr.
2019-04-29 21:14:31.642635500 [dump1090-fa] In the first case, please either detach or blacklist the kernel module
2019-04-29 21:14:31.642663500 [dump1090-fa] (dvb_usb_rtl28xxu), or enable automatic detaching at compile time.
2019-04-29 21:14:31.642677500 [dump1090-fa]
2019-04-29 21:14:31.642690500 [dump1090-fa] usb_claim_interface error -6im Log angezeigt – in diesem Fall kann mithilfe der Befehle
sudo rmmod rtl2832_sdr sudo rmmod dvb_usb_rtl28xxu sudo rmmod rtl2832
der Treiber für den Moment deaktiviert werden. Nach einem Neustart ist es jedoch sehr wahrscheinlich, dass die Treiber wieder geladen werden; deshalb nochmal die Datei unter /etc/modprobe.d/blacklist-rtl2832.conf überprüfen, ob hier die Treiber richtig geblacklistet sind.
Weitere häufige Probleme sind das greifen von UFW (Uncomplicated Firewall), sollte eine Distribution mit vorinstallierter Firewall gewählt sein – hier kann der Status (und mögliches Port-Blockieren) der Firewall mit
ufw status
überprüft werden.
Sollte alles in den Logs gut aussehen, die Seite von extern aber doch nicht aufrufbar sein, kann ein kleiner Test in der Konsole (oder bei einem Betriebssystem mit GUI direkt im Browser) die Anzahl der möglichen Fehlerquellen deutlich reduzieren: Einfach localhost:8080 und localhost:8754 aufrufen – wenn keine Seite geladen wird, liegt das Problem im Bereich der Container, wenn die Seite geladen wird, stimmt was mit dem externen Aufruf nicht.