Um von Wetter-Satelliten empfangen zu können (bei uns NOAA-Satelliten), baue man sich einen Kreuzdipol optimiert auf 137 MHz-Empfang.
Bei uns steht die fertige Antenne nicht ebenerdig, sondern auf dem Balkon, um auch die Rückseite vom Gebäude erreichen zu können. Bei einer Mastlänge von etwa 2 Metern klappt das dann. Der Dipol ist rechtsdrehend zirkular.
Wir arbeiten mit einer 50 Ohm-Zuleitung, L/4-Umwegleitung (zur Verbindung der Rohrstücke) und Transformationsleitung (zwei Teilstücke mit 75 Ohm) und bringen die Dipol-Enden zur Befestigung in einem Plastikgehäuse innerhalb einer käuflichen Abzweig-Dose unter. Etwa 80cm unterhalb haben wir einen Reflektor angebracht.
Der Antennenausgang geht zu einem Software-Defined-Radio.
Heutzutage nur noch ein kleiner Stick. Zwar nicht so empfindlich, aber recht preiswert.
Bei uns ein kleiner Stick mit RTL-Chipsatz, wie von Gixa oder bei uns ein Nooelec. Jener hat dann eine USB-Verbindung zu einem Empfaenger-Raspi, der den Stick steuert und die Dekodierung uebernimmt. Dazu soll auf dem Pi „rtl_fm“ zum Einsatz kommen…
Was muss man also tun, um den Raspi am RTL-Stick vorzubereiten? Zuerst wie immer die Installationsbasis auf neuesten Stand bringen:
$ sudo apt-get update
$ sudo apt-get upgrade
In /etc/modprobe.d/ blacklisten. z.B. in einer „no-rtl.conf“, welche in das Verzeichnis eingestellt wird, mit folgenden Eintraegen:
blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830
Alternativ kann auch die „/etc/modprobe.d/raspi-blacklist.conf“ mit diesen Eintraegen bestueckt werden (am Ende anfuegen).
Als Editor ist dazu bspw. „nano“ schon vorhanden, ansonsten kann auch noch der Midnight-Commander installiert werden, welcher sich zur Navigation und zum anfaenglichen Dateitransfer im Netzwerk nicht schlecht macht:
$ sudo apt-get install mc
Nun git, cmake, libusb und die Build-Essentials installieren:
$ sudo apt-get install git-core
$ sudo apt-get install git
$ sudo apt-get install cmake
$ sudo apt-get install libusb-1.0-0-dev
$ sudo apt-get install build-essential
Letztere sind meist schon auf dem neuesten Stand.
Dann die rtl-sdr-Tools von osmocom holen und bauen (man ist hier am Anfang im Home-Verzeichnis):
$ git clone git://git.osmocom.org/rtl-sdr.git
$ cd rtl-sdr/
$ mkdir build
$ cd build
$ cmake ../ -DINSTALL_UDEV_RULES=ON
$ make
$ sudo make install
$ sudo ldconfig
$ cd ~
$ sudo cp ./rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
Neu starten:
$ sudo reboot
Nach neuem Login am Pi die Installation testen:
$ rtl_test
Eine solche oder aehnliche Ausgabe sollte zu sehen sein:
# Found 1 device(s):Found 1 device(s):
# 0: Generic, RTL2832U, SN: 77771111153705700
#
# Using device 0: Generic RTL2832U
# Found Rafael Micro R820T tuner
# Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 # 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
# Sampling at 2048000 S/s.
#
# Reading samples in async mode…
Damit sollte dann auch ein Testempfang um 137MHz mittels
$ rtl_fm -f 137100000 -s 44100 -g 44 -p 55 -E wav -E deemp -F 9 -r 11025 test.wav
funktionieren und eine Audio-Datei entstehen, welche (da adhoc ausgeloest) jetzt noch keine auswertbaren Daten enthaelt.
Ist ein Wetter-Satellit in der Naehe erkannt, werden wir aber so einen Aufruf mit entsprechender Empfangsfrequenz („-f“, je nachdem, um welchen NOAA-Satelliten es sich handelt) verwenden, um eine WAV-Datei zur weiteren Verarbeitung zu erzeugen.
Mittels diverser zusätzlicher Software kann man übrigens gut kontrollieren, ob ein geeignetes Signal von einem NOAA-Satelliten hereinkommt. Denn leider überfliegen die das eigene Gebiet zu ganz unterschiedlichen Tageszeiten, da sie nicht im 24h-Rhythmus wiederkommen.
Dazu braucht es also noch eine Prediction-Software (predict).
Genauso wie bei der anschließenden Dekodierung (wxtoimg) sind das bei mir Linux-Tools, die am Tag auf einem Raspberry Pi automatisiert ablaufen.
Und am Ende kriegt man dann ein nettes Bild in Normaldarstellung und Infrarot geliefert und auf die Website hochgeladen. Wie die Wetterfrösche…
Zunaechst braucht es also noch weitere Software auf unserem Empfangs-Pi hier, damit dieser auch noch die Sounddateien dekodieren kann.
Dazu soll das beliebte „wxtoimg“ (wir benoetigen die Kommandozeilen-Version) genutzt werden.
Dies ist nicht aus einem Repository erhaeltlich, aber als Debian-Package fuer ARM von der Website downloadbar. Mit dpkg zu installieren:
$ sudo dpkg -i wxtoimg-armhf-2.11.2-beta.deb
Juhu, danach geht
$ wxtoimg test.wav test.png
und wir haben unser erstes Zwischenziel erreicht!
Das Empfangen und die Konvertierung der Signale ist das eine, die Vorhersage der Satelliten-Ueberfluege das andere. Unser Empfangs-Raspi soll dazu rechtzeitig ein- und ausgeschaltet werden und nicht staendig in Betrieb bleiben.
Es braucht also noch eine funktionierende Prediktion von geeigneten Wettersatelliten.
Diese könnte unser Hausserver uebernehmen, da dieser ohnehin staendig online ist. Aber an der Stelle wollten wir vereinfachen, um nicht mehrmals am Tag einen zweiten Raspi fernzusteuern.
Also wird die Empfangsinstallation nur zwischen 18 und 20 Uhr scharf geschalten (über den FHEM-Hausautomationsserver und einer entsprechenden Schaltsteckdose).
Unser Skript läuft dann mittels crontab ein paar Minuten verzögert an und greift auf eine Predict-Installation zu.
Das alte Tool „predict“ erscheint da als die beste Wahl, da man es auch gut in eigene Skripte einbinden kann.
Alles verbleibt also auf unserem Empfangsraspi. Und dieser kriegt zuerst einmal „predict“ verpasst:
$ sudo apt-get install predict
Damit sind alle Tools installiert, wenn noch nicht vorhanden, sollte python-paramiko noch geholt werden. Bei uns die Grundlage für sftp und damit dem Upload auf die eigene Website.
Damit man auch von NOAA-15, 18 und 19 (17 derzeit in der Abschaltung, Sinkflug) empfangen kann, sind noch die Auffrischung des Setup von „Predict“ (welche Satelliten berücksichtigt werden) bzw. der zugehörigen Kepplerfiles notwendig.
Das macht man, in dem man sich eine aktuelle tle-Datei vom Server holt… Wie sieht die Ablaufsteuerung nun aus? Im Empfangsraspi haben wir dazu folgende lokale Crontab-Einträge gemacht:
13 18 * * * /home/pi/weather/pre_update.sh
15 18 * * * python /home/pi/weather/noaacapture.py
45 19 * * * rm /home/pi/weather/*.wav
46 19 * * * rm /home/pi/weather/*.png
Wir nutzen das Capture-Skript „noaacapture.py“ von Dr. Paul Brewer und haben im Python-Skript noch divers angepasst. Also die bevorzugten Satelliten und einen sftp-Upload (mittels python-paramiko) auf die eigene Website hinzugefuegt, nebst einer FIFO-Warteschlange, in der in drei Dateien (sat[1..3].png) immer die drei aktuellsten Aufnahmen bereitstehen. Außerdem beschränken wir uns auf ein gewisses Zeitfenster (18 -20 Uhr, siehe letzter Abschnitt), ansonsten werden jeden Tag die Überflugdaten erneuert (pre_update.sh) und das Capture-Skript setzt ein. Divers erzeugte wav- und png-Dateien werden nach dem täglichen Bearbeitungslauf gelöscht, damit die SD-Karte des Pi nicht zuläuft.
Bekannte Probleme? Ja, mittels rtl_fm ist es nicht möglich, während einer Aufnahme die Empfangsfrequenz zu ändern. Die optimale Frequenz schwankt aber, da sie vom Dopplereffekt beeinflusst ist, nur genau eben, wenn sich der betreffende Satellit über Kopf befindet.
Der Kompromiss ist, Überflüge nur dann aufzunehmen, wenn sie denn auch genügend den eigenen Standort decken und nur das Zeitfenster auszuwerten, was man mindestens für eine vollständige Aufnahme (ordentliches Bild mit Telemetriedaten) braucht.