Posts Tagged ‘Flightradar24’

Sonntag, 19. Juni 2022

Testflugzeuge mit FlightRadar24 beobachten

Seit einiger Zeit habe ich mir auf FlightRadar24 einen Alarm eingerichtet für alle Flüge der Boeing B777-9 (Teil des B777X-Programms) mit Registrationsnummer N779XW: FlightRadar24-Steckbrief, JetPhotos-Steckbrief.

Seit letzter Woche kommt nun auch noch der Airbus A321XLR (Extra Long Range) mit Registrationsnummer F-WXLR hinzu: Pressemitteilung, FlightRadar24-Steckbrief, JetPhotos-Steckbrief

Tags: , , , , ,
Labels: Technik

Keine Kommentare | neuen Kommentar verfassen

Montag, 30. Mai 2022

Umstieg von dump1090 auf tar1090: Wo ist das Flugzeug-JSON?

Vor einigen Monaten habe ich meinen FlightRadar24 Raspberry Pi softwaretechnisch so umgebaut, dass er seine Daten auch mit ADS-B Exchange teilt. Hierzu wurde dump1090 mit tar1090 ersetzt.

Mit Cacti zeichne ich die Anzahl Messages pro Minute sowie die aktuell getrackten Flugzeuge auf. Leider funktionierte nach der Umstellung die Abfrage der JSON-Datei nicht mehr, welche bis anhin unter http://1.2.3.4/dump1090/data/aircraft.json abgerufen werden konnte.

Nach etwas Recherche dann die Erlösung: Die URL lautet neu nun http://1.2.3.4/tar1090/data/aircraft.json. Das Python-Script schwupp-di-wupp angepasst, und nun zeichnet Cacti wieder einen wunderschönen Graphen:

image-11490

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 22. März 2022

Energiewende: It’s simple Math: Mein persönlicher Lackmustest

Ich bin nicht nur nicht vor Rechenfehlern gefeit, sondern vielleicht mache ich auch Überlegungsfehler. Bitte benutzt die Kommentarfunktion, um mich auf Probleme hinzuweisen.

Ich habe grundsätzlich nichts gegen die Energiewende, doch muss allen Betroffenen klarer Wein über die Vor- und Nachteile eingeschenkt werden. Die Grenzen der Technologien müssen aufgezeigt werden, und Zukunftsprognosen sowie Wunschdenken (Prinzip Hoffnung) müssen klar getrennt werden von dem, was heute machbar ist.

Und ich behaupte hier, dass Energiewendler allzuoft die Realität schönreden, und ich unterstelle ihnen, dass sie das (mehrheitlich) bewusst tun — das heisst sie lügen.

Mein Anwendungszweck

Wieso ich den Apologeten der Energiewende bis heute nicht traue? Ich habe meinen eigenen, persönlichen Lackmustest, der mir die (heutigen) Grenze erneuerbarer Energie (fast) tagtäglich aufzeigt. Ja, es ist ein n=1 Erfahrungswert, aber für mich reicht dieser aus, um hier zu polemisieren.

Mein Setup: Ich betreibe einen Raspberry Pi (RPi) 3B, um ADS-B Signale einzufangen. Hierzu habe ich Pi24 heruntergeladen und auf die SD-Card installiert, sowie einen RTL-SDR USB-Receiver gekauft, an welchem eine empfangsstarke ADS-B Antenne hängt.

Die Antenne muss im Freien stehen, um die Signale aus möglichst allen Himmelsrichtungen empfangen zu können. Deshalb ist sie bei uns auf unserer Terrasse platziert. Den RPi möchte ich in der Nähe, sprich ein paar Meter von der Antenne entfernt, betreiben. Die Kommunikation mit dem Internet erfolgt per WLAN. Explizit möchte ich weder Strom- noch Antennenkabel in die Wohnung ziehen (Stichwort: Kältebrücke).

Der Stromverbrauch

Der RPi benötigt ungefähr 5 bis 5.5 Watt (USB, d.h. ca. 5V mit ca. 1A). Ein lächerlich geringer Stromverbrauch, könnte man meinen (ein Zwölftel der Leistung einer 60W Glühbirne aus meiner Jugend). Aber das alleine scheint es schon in sich zu haben.

Um den RPi einen Tag lang zu betreiben, benötige ich somit 5 × 24 = 120 Watt-Stunden (Wh).

Mein grünes Vorhaben

Seit Jahren träume ich davon, den RPi rund um die Uhr autonom, d.h. ohne Anschluss an das Stromnetz, zu betreiben. Die Lösung dazu liegt auf der Hand: Ein Solarpanel lädt eine Batterie, an deren USB-Anschluss hängt der RPi. Den Tag hindurch lädt die Batterie auf, in der Nacht gibt sie ihre erneuerbar generierte Stromladung ab.

Meine grüne (?) Ausrüstung

Mittlerweile bin ich dafür bei folgender Ausrüstung angekommen:

Nebenbemerkung: Man sieht es dem Titel an — wie „grün“ dieser Fuhrpark hergestellt wurde, lasse ich mal in den Raum gestellt. Sowohl das Panel als auch die Batterie wurden in China hergestellt, und danach vermutlich mit einem dieselbetriebenen Containerfrachter (Euro 0 Norm?) um die halbe Welt geschippt. Auch die lockeren Umweltvorschriften in China muss man sich hier in Erinnerung rufen. Panel und Batterieproduktion führen meines Wissens zu toxischen, umweltschädlichen Nebenprodukten. Die CO2-Bilanz dieser Produkte ist höchstwahrscheinlich fürchterlich, wie auch die lokale Umweltverschmutzungsbilanz.

Kosten-Nutzen

Insgesamt habe ich also fast 400 CHF ausgegeben, um ein Gerät rund um die Uhr mit ca. 5 Watt zu versorgen. Das sind im Jahr 5 × 8760 = 43800 Wh oder 43.8 kWh. Bei unserem Stromanbieter kostet die „dreckigste“ Kilowattstunde 22.40 Rappen (Quelle), das heisst der Stromkabelbetrieb der Installation würde mich 9.80 CHF/Jahr kosten. Damit ich mit der Solaranlage gemäss heutigen Zahlen den „break even“ erreichen würde, müsste ich diese 40.8 Jahre lang betreiben. Wetten, dass weder das Panel noch die Batterie so lange halten werden?

Unter uns: Irr. Aber die Spielerei macht es dennoch interessant.

Soviel zur reinen Kosten-Nutzen-Berechnung.

Technische Machbarkeit

Aber: Funktioniert die Lösung nun aber auch wirklich so, wie ich es mir vorstelle?

Vereinfachen wir die Situation zuerst ein wenig, damit sie einfacher fassbar wird: Wenn wir davon ausgehen würden, dass die Sonne 12 Stunden am Tag scheint, und ich mit dem Panel zu jeder Sekunde die angegebene Maximalleistung rausquetschen kann, dann reicht ein 5W Solarpanel nicht. Denn damit ist nur gerade der aktuelle Verbrauch gedeckt. Ich benötige also mindestens ein 10W Panel, welches während 12 Sonnenscheinstunden 5W an den RPi abgibt, und gleichzeitig die restlichen 5W in eine Batterie speichert. Wenn die Sonne während den restlichen 12 Stunden nicht mehr scheint, entleert sich die Batterie komplett.

Leider strotzt das Szenario vor einigen Denkfehlern: Wir müssen uns bewusst sein, dass Solarenergie (in unseren Breitengraden) vereinfacht gesagt zwei Gaussschen Glockenkurven folgt. Einerseits in der Mikro-Sicht, das heisst dem Tagesablauf. Mit einer Spitze beim höchsten Sonnenstand, vereinfacht gesagt um 12 Uhr mittags. Andererseits in der Makro-Sicht, das heisst im Jahresverlauf. Mit einer ähnlichen Spitze im Sommer.

Weatherspark hat für Orte eine Sektion „Solar Energy“, wo aufgezeigt wird, wie stark der Sonneneinfall pro Quadratmeter über das Jahr hindurch variiert (die Makro-Sicht).

Nebenbemerkung: Für Laupen (Neuenegg ist nicht auswählbar) beträgt der Unterschied zwischen dem tiefsten und höchsten Punkt fast Faktor 6. Ich deute das so, dass ich mein Panel mit der Zielleistung um diesen Faktor multiplizieren muss, um auch im Winter ausreichend Strom zu produzieren.

Weiter: Das Panel liefert am höchsten Sonnenstand und in perfekter Position vielleicht die gewünschten 10 Watt, aber eben nur gerade dann. Die Sonne scheint hier in Neuenegg nicht das ganze Jahr hindurch 12 Stunden pro Tag. Und ja, allzuoft haben wir keinen blauen, wolkenlosen Himmel, was die Leistung des Panels zusätzlich schmälert. Zudem hat mir ein Bekannter kürzlich mitgeteilt, dass es ein Irrglaube sei, dass die Panels im Sommer die höchste Leistung bringen — denn die Leistung von Solarpanels wird durch die Sommerhitze geschmälert. Wieder etwas gelernt.

Ich benötige also ein deutlich grösseres Panel, und eine deutlich grössere Batterie als eine mit 5 × 12 = 60 Wh.

Zu prüfende Hypothese

Ich habe derzeit kein Vertrauen, dass selbst die 400 CHF-Anlage im Winter mit den kurzen, nicht immer sonnigen Tagen durchgehend Strom liefern wird: Im Winter 2021/22 (Dezember bis und mit Februar) registrierte Bern 300 Sonnenstunden auf insgesamt 90 × 24 = 2160 Stunden (Quelle). Das heisst ich kann nur während 14 Prozent der Zeit mit Sonne rechnen, und in dieser Zeit muss die Batterie so weit wie möglich gefüllt werden.

Und selbst im Sommer befürchte ich reichen auch ein, zwei sonnenarme Tage, um meinen RPi wieder zurück an die Steckdose zu bringen.

Der Erfahrungsbericht folgt über das restliche Jahr verteilt.

Was hat das mit der Energiewende zu tun?

Das Problem im Kleinen lässt sich auf das Problem im Grossen übertragen: Wir können noch so viel Photovoltaik auf unsere Dächer pappen — in der Nacht und im Winter brauchen wir eine Energiequelle, die unabhängig von der Sonne Strom liefert. Sprich entweder Kraftwerke (mein Favorit: Kernkraftwerke), die egal ob Sonne oder Dunkelheit, egal ob bei Sturm oder Windstille, zuverlässig Strom liefern. Oder aber wir haben nicht nur irgendwo gigantische Batterien rumstehen, sondern sie müssen auch gefüllt sein, damit wir sie anzapfen und unseren Stromengpass überbrücken können. Korrekt: Staumauern! Im Sommer nutzen wir Solarenergie, um das Wasser hochzupumpen, im Winter verbrauchen wir das Wasser dann, indem wir es ins Tal fliessen lassen, Generatoren antreiben und den damit produzierten Strom in das Stromnetz einspeisen. Für die Überbrückung der Nacht ist das aber nicht praktikabel, oder?

Wenn ich doch auch nur das Äquivalent einer Staumauer auf meiner Terrasse installieren könnte …

Tags: , , , , , , , , , ,
Labels: Energie, Politik

3 Kommentare | neuen Kommentar verfassen

Mittwoch, 16. September 2020

fr24feed 1.0.26-4 hat Probleme mit IPs, IPv6 und dem Web-Server

Kürzlich wurde auf meinem Pi24-Horchposten die neueste Version von fr24feed installiert: 1.0.26-4, Built on Sep 14 2020 08:32:40 (HEAD-bd20105.git/Linux/static_armel).

Umgehend reagierten meine monit Netzwerksensoren:

Connection failed Service pi24.domain.tld 

	Date:        Mon, 14 Sep 2020 19:03:03
	Action:      alert
	Host:        HOST
	Description: failed protocol test [HTTP] at [10.1.2.3]:8754 [TCP/IP] -- HTTP error: Regular expression doesn't match: No match

Your faithful employee,
Monit

Als ich auf das Web-Interface zugreifen wollte erschien auch tatsächlich folgende Fehlermeldung:

For security reasons the web interface is only availble from private class networks or after you have manually specified the bind-interface setting in /etc/fr24feed.ini

Please set it to bind-interface="0.0.0.0" to accept traffic from all interfaces or to the IP address of your preferred network interface!

For further assistance please contact support@fr24.com

Komisch! Nun gut, ich fügte also bind-interface="0.0.0.0" ans Ende der Datei /etc/fr24feed.ini und bootete den Pi24 neu. Das schaffte keine Abhilfe.

Selbst wenn ich auf dem Pi24 selber ein wget localhost:8754 respektive wget 127.0.0.1:8754 machte, erschien die Fehlermeldung.

Ich tüftelte noch eine Weile lang herum, und entdeckte dabei folgendes: Die neuste Version von fr24feed bindet sich aus irgendeinem Grund nur an IPv6:

$ netstat -tulpn
...
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp6       0      :::8754                   :::*                    LISTEN      -                   
...

Ein Eintrag für denselben Port beginnend mit tcp fehlte.

Das CHANGELOG zeigt auf, dass die Kollegen aktuell an den Netzwerkfunktionalitäten von fr24feed rumbasteln und dabei bereits mehrere Male nachbessern mussten. Offenbar ist auch die neuste Version noch nicht ganz koscher.

Ein Blick in das Log von fr24feed zeigte folgende Einträge:

2020-09-14 20:10:02 | ______  _  _         _      _                    _              _____    ___ 
2020-09-14 20:10:02 | |  ___|| |(_)       | |    | |                  | |            / __  \  /   |
2020-09-14 20:10:02 | | |_   | | _   __ _ | |__  | |_  _ __  __ _   __| |  __ _  _ __`' / /' / /| |
2020-09-14 20:10:02 | |  _|  | || | / _` || '_ \ | __|| '__|/ _` | / _` | / _` || '__| / /  / /_| |
2020-09-14 20:10:02 | | |    | || || (_| || | | || |_ | |  | (_| || (_| || (_| || |  ./ /___\___  |
2020-09-14 20:10:02 | \_|    |_||_| \__, ||_| |_| \__||_|   \__,_| \__,_| \__,_||_|  \_____/    |_/
2020-09-14 20:10:02 |                __/ |                                                         
2020-09-14 20:10:02 |               |___/                                                          
2020-09-14 20:10:02 | [main][i]FR24 Feeder/Decoder
2020-09-14 20:10:02 | [main][i]Version: 1.0.26-4/generic
2020-09-14 20:10:02 | [main][i]Built on Sep 14 2020 08:32:40 (HEAD-bd20105.git/Linux/static_armel)
2020-09-14 20:10:02 | [main][i]Running on: pi24-raspbian9
2020-09-14 20:10:02 | [main][i]Local IP(s): 
2020-09-14 20:10:02 | [main][i]Copyright 2012-2020 Flightradar24 AB
2020-09-14 20:10:02 | [main][i]https://www.flightradar24.com
2020-09-14 20:10:02 | [main][i]DNS mode: PING
2020-09-14 20:10:03 | [main][i]Automatic updates are ENABLED
2020-09-14 20:10:04 | ERROR: rmmod: ERROR: Module dvb_usb_rtl28xxu is not currently loaded
2020-09-14 20:10:04 | info | [httpd]Server started, listening on ::2020-09-14 20:10:04 | [e]PacketSenderConfiguration::fetch_config(): Unable to fetch configuration for yoda receiver
2020-09-14 20:10:06 | [d]TLSConnection::ctor(): Enable verify_peer in production code!
2020-09-14 20:10:06 | [main][i]Reader thread started
2020-09-14 20:10:06 | [main][i]Socket server started
2020-09-14 20:10:06 | [main][i]MLAT data feed started
2020-09-14 20:10:06 | [reader][i]Initializing reader
2020-09-14 20:10:06 | [reader][i]Connecting to DVBT receiver via (exe:///usr/bin/dump1090-mutability  --raw --mlat)
2020-09-14 20:10:06 | [bs][i]Initializing server
2020-09-14 20:10:06 | [bs][i]Starting server on 0.0.0.0:30003
2020-09-14 20:10:06 | [mlat][i]Waiting for MLAT configuration
2020-09-14 20:10:06 | [master][i]Starting processing thread
2020-09-14 20:10:06 | [reader][i]Connected to the receiver, configuring
2020-09-14 20:10:06 | [reader][i]Configured, processing messages
2020-09-14 20:10:07 | terminate called after throwing an instance of 'char const*'

Interessant sind folgende Zeilen:

...
2020-09-14 20:10:02 | [main][i]Local IP(s): 
...
2020-09-14 20:10:04 | info | [httpd]Server started, listening on ::
...
2020-09-14 20:10:07 | terminate called after throwing an instance of 'char const*'

Komisch! Dem Problem konnte ich nicht auf den Grund gehen, wieso fr24feed die IP des Raspberry Pis nicht herausfinden konnte. strace könnte hier wohl weiterhelfen, doch das ging mir dann doch etwas zu weit. Schlussendlich hatte ich genug und entschied ich mich für ein Downgrade auf eine „last known good“ Version:

$ wget "https://repo.feed.flightradar24.com/rpi_binaries/fr24feed_1.0.25-3_armhf.deb" --no-check-certificate
# dpkg -i fr24feed_1.0.25-3_armhf.deb

Damit die neueste Version am nächsten Tag nicht erneut installiert wird, habe ich auch noch /etc/cron.d/fr24feed_updater angepasst:

47 9 1 * * root /usr/lib/fr24/fr24feed_updater.sh >> /var/log/fr24feed_update.log 2>&1

Hoffen wir, dass es bis zum 1. Oktober eine neue Version gibt, die mein Problem behebt.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Februar 2018

Mit cacti die von fr24 entdeckten Flugzeuge und Nachrichten aufzeichnen

Der einfachste Weg, um dies zu bewerkstelligen ist die Verwendung der folgenden URL, die Statistiken im JSON-Format ausgibt:

http://%IP%/dump1090/data/aircraft.json

Mehr dazu: Mit einem Raspberry Pi, DVB-T-Stick und Flightradar 24 einen Hobby-ADS-B Empfänger aufbauen

Ich habe ein kleines Python-Script geschrieben, welches diese Informationen ausliest und so aufbereitet, dass es von cacti importiert werden kann:

fr24-cacti-stats

Nachdem man die Data Input, Data Source und Graph Templates erstellt hat, grüssen einen folgende Graphen:

image-7737

image-7738

Alternative

Da ich die dump1090-URL anfänglich nicht kannte, behalf ich mir als Alternative der Log-Datei unter /var/log/fr24feed/fr24feed.log.

Ich erstellte im Web-Root von lighthttpd einen Symlink auf die Log-Datei …

$ ln -s /var/log/fr24feed/fr24feed.log /var/www/fr24feed.log

… lud diese mittels wget auf den cacti-Server herunter, filterte dort mittels eines Scripts die jüngste Log-Meldung vom folgenden Format heraus und isolierte die Zahl vor „AC“:

2018-02-23 21:12:06 | [feed][i]removed 1 of 8 AC

Da die Log-Datei seit heute morgen nicht mehr geschrieben wird (Grund: unklar), bin ich nun auf die Echtzeitlösung mit dump1090 ausgewichen. Erste Erkenntnis: dump1090 meldet mehr Flugzeuge als die Log-Datei; Grund unklar.

image-7739

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Februar 2018

Einen Raspberry Pi mit autonomer Stromversorgung betreiben

(Kontext: Mit einem Raspberry Pi, DVB-T-Stick und Flightradar 24 einen Hobby-ADS-B Empfänger aufbauen)

Wie im oben verlinkten Blog-Post beschrieben muss sich die Antenne im Freien befinden, um den bestmöglichen Empfang der ADS-B-Signale zu realisieren.

Bevor ich entdeckte, dass das DVB-T-Antennenkabel problemlos durch einen Fensterrahmen geführt werden kann und das Schliessen des Fensters überlebt, machte ich mir Gedanken, wie man Antenne UND den Raspberry Pi zusammen auf dem Balkon der Mietwohnung installieren könnte.

Das grösste Problem war hierbei die Stromversorgung, da sich auf unserem Balkon kein Stromanschluss befindet.

Stromverbrauch

Gemäss der Web-Seite Solar Power for Raspberry Pi verbraucht mein Raspberry Pi 1, Model B, mindestens 480mA, was einem Tagesverbrauch von 57.6Wh entspricht.

Ein anderer Artikel Power Consumption berechnet mindestens 220mA, wenn man den HDMI-Port deaktiviert und die LEDs ausschaltet (wie man das macht, ist in diesem Artikel beschrieben: Raspberry Pi Zero – Conserve power and reduce draw to 80mA).

Der DVB-T-USB-Dongle verbraucht gemäss (geleaktem?) Data Sheet des Chip-Herstellers maximal 178mA.

Der bei einem Outdoor-Betrieb zwingend nötige WLAN-USB-Dongle sollte dann auch noch dazugerechnet werden. In meinem Fall hatte ich geplant, einen ZyXEL NWD2205-Stick zu verwenden. Gemäss Datenblatt saugt das Ding 315mA beim Senden und 250mA beim Empfangen.

Zusammengerechnet hätte dies also in einem Verbrauch von 480 + 178 + 315 = 973 mA oder 0.973A entsprochen — multipliziert mit 5V also genau 4.865 Watt.

Da ich den Raspberry Pi mittlerweile mittels Power-over-Ethernet PoE mit Strom versorge (hierzu verwende ich einen Uctronics U5159 Umwandler, der aus dem Ethernet-Kabel den Strom extrahiert, transformiert und dann mit 5V und bis zu 2.4A auf einen Micro-USB-Port ausgibt — bspw. erhältlich auf Amazon.com für $10), kann ich über den Unifi Controller sehen, wie viel Leistung das Ding zieht: 5.31 Watt. Es kann aber gut sein, dass diese Messung durch den UniFi-Switch sowie auch den Uctronics stark verfälscht wird.

USB-Powerbanks?

Von dieser Lösung nahm ich rasch Abstand, da gewisse Dinger mit 10000, 15000 oder gar 20000 mAh zwar ordentlichen Stromspeicher besitzen, aber trotzdem nicht geeignet sind:

  • Wie lädt man die Dinger auf — musste man mindestens zwei Powerbanks anschaffen sie täglich rotieren? Das kam für mich nicht in Frage.
  • Sind sie für den Aussenbetrieb geeignet, d.h. verkraften sie Temperaturen wie jetzt gerade bis zu minus 5 Grad in der Nacht?

Solar!

Nach einigen Überlegungen kam ich dann auf die naheliegende Lösung: Solarstrom!

Zwar gibt es bei Amazon haufenweise Powerbanks mit integriertem Solarpanel (sogar eine mit 20000mAh, derzeit aber vergriffen) (Digitec hat auch einige, bspw. Sandberg Outdoor Solar (16000mAh, Solarbetrieb) sowie DÖRR Solar Powerbank SC-10000 black (10000mAh, Solarbetrieb)), doch nach einiger Lektüre im Netz kam ich zum Schluss, dass die Dinger nicht für einen 24/7-Betrieb eines RPi taugen (sie laden die Batterie nicht schnell genug auf, damit der RPi die Nacht überlebt).

Ein Solarpanel muss her. Da dieses aber nur am Tag bei Sonnenschein Strom liefert, muss man auch hier mit Batterien arbeiten. Nicht aber mit Powerbanks (Li-Ion) sondern besser mit Blei-Batterien, wie man sie von USVs kennt.

Nicht zu vergessen ist auch, dass Solarpanels 12V ausgeben, was für USB-Geräte nicht brauchbar ist (der USB-Standard sieht eine Spannung von 5V vor). Somit muss man noch einen Transformator dazwischenschalten, der 12V auf 5V heruntertransformiert.

Auf der Suche nach Lösungen fand ich zwei Arten von Produkten: Einerseits Sets, die primär für RPis gedacht sind, sowie Allzweck-Anlagen, mit welchen man Gartenhäuschen, Wohnwagen etc. mit Solarstromversorgung ausrüsten kann.

Die von mir entdeckten RPi-spezifischen Lösungen sind nachfolgend aufgelistet:

Für andere IoT-Geräte konzipierte respektive generische Lösungen:

Hätte ich nicht realisiert, dass das Antennenkabel durch den Fensterrahmen geführt werden kann, hätte ich mir wohl schlussendlich folgendes Produkt geleistet:

Solar-Set Poly Esotec 120005 20 Wp inkl. Akku, inkl. Anschlusskabel, inkl. Laderegler 179.95 CHF bei Conrad.ch (dasselbe Produkt für 168 CHF ohne Versand bei Westfalia.ch)

Die Batterie besitzt einen Speicher von 8 Ah (d.h. 8000 mAh), das Solarpanel generiert 20 Watt Spitzenleistung. Die kleinere Version der Anlage mit „nur“ 4000 mAh kostet 99.95 CHF.

Anschliessend hätte ich wohl auch noch den Laderegler mit einem Produkt ersetzt, das zwei USB-Anschlüsse direkt eingebaut hat (damit verzichtet man auf zusätzlichen Kabelsalat):

ALLPOWERS 20A Solarladeregler 12V / 24V Intelligenz USB Teil Solar Panel Regler mit USB Port Display

Was ich bis jetzt nicht klären konnte: Liefert der USB-Anschluss wirklich nur 500mA (gemäss Handbuch), oder geben die Laderegler trotzdem auch gegen die 1A Strom aus (wie die kleinere Lösung, gemäss dessen Handbuch)?

Links

Bei der Recherche zur Lösung notierte ich mir unzählige Links notiert. Hier die wichtigsten:

Tags: , , , , ,
Labels: IT

2 Kommentare | neuen Kommentar verfassen

Sonntag, 25. Februar 2018

Mit einem Raspberry Pi, DVB-T-Stick und Flightradar 24 einen Hobby-ADS-B Empfänger aufbauen

Vor einigen Tagen wurde mein DVB-T-Empfänger und die ADS-B Antenne von jetvision.de geliefert.

Damit konnte ich einen alten, nicht mehr genutzten Raspberry Pi 1, Model B, zu einem Hobby-Empfänger für Flugzeugsignale (sog. ADS-B) umbauen.

Flightradar24 bietet dafür ein Raspberry Pi-Image an, mit welchem man den Radar in ein paar Minuten online hat — im Gegenzug erhält man als Dank kostenlos ein Business-Abonnement der Web-Site im Wert von mehreren hundert Dollar im Jahr.

Der Name meiner Antenne lautet T-LSZB123 (die Statistiken kann man sich nur ansehen, wenn man auf Flightradar24 registriert ist).

Aufstellen der Antenne

Flightradar24 hat eine Anleitung ins Internet gestellt, die den Hobby-Empfängern bildlich aufzeigt, wie man die Antenne installiert, um einen maximalen Empfang hinzukriegen.

Am Besten wäre die Installation auf dem Hausdach — als Mieter bleibt einem das selbstverständlich verwehrt. Auch muss man sich dann bezüglich Blitzeinschlag Gedanken machen und das Antennensignal mit einem Kabel irgendwo in die Wohnung verlegen.

In meinem Fall muss für die Platzierung der Antenne (leider) die äussere Fensterbank hinhalten — aber allemal besser, als den Empfänger mitsamt Antenne in der Wohnung zu platzieren. Die Alternative wäre gewesen, das gesamte Setup auf dem Balkon zu betreiben, was aber eine solar- und batteriebasierte Stromversorgung verlangt hätte. Das hätte aber grosse Kosten und noch einiges an Bastelaufwand verursacht.

Zum Glück realisierte ich bald einmal, dass man das Antennenkabel durch den Fensterrahmen legen und das Fenster schliessen kann, ohne das Kabel zu beschädigen (hoffe ich jedenfalls):

image-7702

image-7703

image-7704

Reichweite der Antenne

Beim Betrieb des o.g. Sets aus DVB-T-Dongle mitsamt mickriger Antenne in der Wohnung (am grossen Fenster zum Balkon) konnte die Software Signale von Flugzeugen in der Distanz von 20 Nautischen Meilen empfangen.

Nachdem ich den Empfänger probehalber auf dem Balkontisch platziert hatte, stieg die Reichweite auf 40 Nautische Meilen an.

Nach der Festinstallation auf dem äusseren Fensterbank und 48 Stunden Dauerbetrieb konnte ich die Reichweite in einigen wenigen Fällen auf 56 Nautische Meilen erhöhen (103.71 Kilometer).

image-7702

Bessere Antennen

Bei jetvision.de könnte man sich leistungsfähigere Antennen kaufen. Mein Favorit wäre die „A3 ADS-B“ Antenna (1090 MHz) für 77.95 EUR. Doch momentan zögere ich mich mit der Aufrüstung noch, da ich diese Antenne weiterhin auf dem äusseren Fensterbank montieren müsste.

Auf Amazon und AliExpress finden sich auch 1090 MHz-Antennen, teils deutlich günstiger, aber über deren Qualität kann ich nichts aussagen.

Web-Interfaces

Sobald der Raspberry Pi aufgesetzt und der Radar bei Flightradar24 registriert ist, kann man auf das lokale Web-Interface der Lösung zugreifen. Es ist unter folgender URL erreichbar:

http://%IP%:8754

image-7706

Folgende zwei Unterseiten sind nützlich:

  • http://%IP%:8754/settings.html Hier kann man Einstellungen vornehmen. Bei mir scheinen diese aber nicht übernommen worden zu sein (ist evtl. ein Neustart des Servers nötig? Ein Neustart der Software über das Web-Interface hat keinen Effekt gezeigt)
  • http://%IP%:8754/tracked.html Die Liste der aktuell empfangenen Signale von Flugzeugen

Weiter gibt es noch ein, zwei technische Interfaces, die Messdaten in strukturierter Form ausgeben:

  • http://%IP%/dump1090/data/aircraft.json
  • http://%IP%/dump1090/data/stats.json
  • http://%IP%/dump1090/data/receiver.json

Via: Raspberry Pi: Dump1090 erzeugt auch JSON-Dateien die extern verwendet werden können

Diese JSON-Daten eignen sich vorzüglich, um mit Cacti schöne Graphen zu erstellen.

Die Aufschlüsselung der JSON-Werte finden sich in folgendem Artikel: JSON output formats

Sonstige Interfaces

Mit netstat findet man schnell heraus, auf welchen Port fr24 Netzwerkdienste anbietet (ssh, snmpd, dhclient und avahi-daemon sind Systemdienste, die mit fr24 nichts zu tun haben):

# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      417/lighttpd        
tcp        0      0 0.0.0.0:30002           0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:8754            0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:30003           0.0.0.0:*               LISTEN      326/fr24feed        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      366/sshd            
udp        0      0 0.0.0.0:161             0.0.0.0:*                           352/snmpd           
udp        0      0 0.0.0.0:51123           0.0.0.0:*                           326/fr24feed        
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           262/avahi-daemon: r 
udp        0      0 0.0.0.0:36590           0.0.0.0:*                           262/avahi-daemon: r 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           561/dhclient        
udp        0      0 0.0.0.0:59213           0.0.0.0:*                           326/fr24feed

Prozesse

Auf den Raspberry Pi kann man nach der Installation des Flightradar24-Images mit den gewohnten Zugangsdaten per SSH zugreifen.

Auf dem Gerät laufen folgende zwei Prozessbäume, die zum Empfang und für die Verarbeitung der Signale zuständig sind:

  • /usr/bin/fr24feed
  • /usr/bin/dump1090-mutability --raw --mlat --write-json /run/dump1090-mutability/

Als Services werden installiert:

  • dump1090-mutability.service
  • fr24feed.service
  • fr24gui.service

fr24feed startet und stoppt man folgendermassen:

# systemctl start fr24feed
# systemctl stop fr24feed

Log-Dateien

Nach der Installation fand sich bei mir unter /var/log/fr24feed/fr24feed.log eine Log-Datei, die in Echtzeit aktualisiert wurde.

Nach ca. zwei Tagen Betrieb stoppten die Log-Meldungen plötzlich und ich konnte noch nicht herausfinden, wieso die Anwendung nichts mehr in die Datei schreibt.

Die Einstellungen habe ich zwar angepasst (Logfile mode: Keep up to 72h, rotate every 24h und Log file location: /var/log/fr24feed/custom.log), bisher wurden diese aber nicht geschluckt.

Offizielle Statistiken

Loggt man sich auf Flightradar24 ein, kann man sich ausführliche Statistiken zu seinem Empfänger anzeigen lassen (die Zahlen sind aus der Sicht von Flightradar24, d.h. die Informationen, die vom Raspberry Pi an den Dienst gesendet und effektiv dort ankommen):

image-7707

Die URL lautet www.flightradar24.com/account/data-sharing, wo man dann alle registrierten Empfänger angezeigt bekommt. Klickt man dort auf Show Statistics, erscheinen die ausführlichen Statistiken:

Tags: , , , ,
Labels: IT

4 Kommentare | neuen Kommentar verfassen

Mittwoch, 26. April 2017

Das vor Santa Barbara ankernde Kreuzfahrtschiff identifizieren

Dass man mit der iOS-Applikation von Flightradar24 überall mit Mobilfunkempfang direkt über einem kurvende Flieger ausmachen kann, sollte mittlerweile den meisten Leuten bekannt sein.

So vergewisserte ich mich zum Beispiel am 19. April 2017 — auf dem Gelände der Stanford University in Palo Alto stehend — dass es sich beim Flugzeug mit dem roten Heck im Landeanflug über dem Silicon Valley tatsächlich um LX38 handelte. Um ungefähr 17 Uhr zwar deutlich verspätet, aber ich ging damals davon aus, dass der Wintereinbruch in der Schweiz zu einer Startverzögerung geführt hatte (bestätigt durch ein Facebook-Post von Kollege Stürmer, welcher in einem anderen Flugzeug in ZRH sitzend eine Enteisung über sich ergehen lassen musste).

Gemäss FlightRadar24 erfolgte die Landung um 17:17 Uhr, gemäss Google um 17:22 Uhr (anstelle der eigentlich erwarteten Ankunftszeit von 16:25 Uhr):

image-7263

image-7264

Wohl deutlich weniger bekannt ist, dass es eine ähnliche Anwendung auch für Kreuzfahrtschiffe gibt. Als wir nämlich am 16. April am Ende der Pier von Santa Barbara standen, ankerte da ein Kreuzfahrtschiff. Mit einer kurzen Google-Suche stiess ich auf die Web-Site CruiseMapper, welche mir Beschied, dass der langsam beschleunigende Kahn ein, zwei Meilen ausserhalb des Hafens die Star Princess der Princess Cruises war, welche am 11. April in Vancouver abgelegt hatte, nach LA gefahren war und sich nun auf dem Rückweg entlang der Kalifornischen Küste befand:

image-7265

Tags: , , , , , , , , , ,
Labels: Reisen

Keine Kommentare | neuen Kommentar verfassen