Wettersonden Empfänger unter Linux / RaspberryPi mit dxlAPRS

Stand 25.04.2020 by DL1NUX

Inhaltsverzeichnis

Einleitung

Die folgende Anleitung dient dazu in wenigen Schritten einen Wettersonden-Empfänger aufzubauen, der seine Daten an die Community-Seite radiosondy.info und auch in das APRS-Netzwerk weiterleitet. Die gleichzeitige Weiterleitung der Daten an die deutsche Seite wetterson.de ist ebenfalls unter bestimmten Voraussetzungen möglich, dazu aber unten mehr. Selbstverständlich kann man den Empfänger auch nur lokal nutzen ohne eine Weiterleitung der Daten.

dxlAPRS ist eine „Toolchain“ bzw. Programmsammlung für Linux Systeme rund um die Betriebsart APRS und wird von Christian OE5DXL entwickelt. Neben zahlreichen Funktionen für die Betriebart APRS bietet diese Toolchain auch einen Dekoder für Wettersonden. Der Begriff „Toolchain“ erklärt bereits, wie diese Programme funktionieren. Im Gegensatz zu vielen anderen APRS Programmen wie APRX oder Direwolf sind es viele kleine Programme die miteinander verkettet werden (chain = Kette). Jeder Programmteil ist für eine bestimmte Funktion zuständig und die Verkettung findet über UDP Ports statt. Das macht es einerseits etwas schwierig die Funktionsweise zu verstehen und das Ganze einzurichten, andererseits ermöglicht es eine sehr flexible und effektive Nutzung der Programme. Kein anderes APRS Tool hat diese Fülle an Funktionen und Möglichkeiten wie dxlAPRS. Die dxlAPRS Tools laufen komplett eigenständig und es sind bis auf eine Ausnahme keine weiteren Libraries notwendig oder Abhängigkeiten vorhanden. Lediglich für die Nutzung von SDR Sticks ist die Installation eines weiteren Pakets notwendig. Die dxlTools lassen sich daher auf quasi jedem beliebigen Linux System ohne Weiteres nutzen. Da die dxlAPRS Tools Open Source sind, sind auch die Quellcodes verfügbar.

Für den Wettersondenempfang und die Weiterleitung der Daten werden die folgenden Komponenten aus den dxlAPRS Tools benötigt:

  • sdrtst (Empfänger)
  • sondeudp (Sondendekodierung)
  • sondemod (Umwandlung der Daten in APRS Pakete)
  • udpbox (Weiterleitung der APRS Pakete an Gateway oder z.B. APRSMAP)
  • udpgate4 (APRS iGate)

In der folgenden Grafik ist die Verkettung der einzelnen Programme miteinander dargestellt. Einzig allein RTL_TCP gehört nicht zu den dxlAPRS Tools. Es ist Bestandteil des Pakets „rtl-sdr“ und wird nur bei der Verwendung von SDR-Sticks benötigt.

Man kann den Signalverlauf hier gut erkennen: rtl_tcp stellt einen SDR Server bereit. sdrtst zapt diesen SDR Server an und erzeugt Empfänger auf den vorgegebenen Frequenzen (sdrcfg0.txt). sdrtst sendet die empfangenen Signale in eine Audiopipe, an dessen Ende sondeudp arbeitet. sondeudp dekodiert empfangene Sondensignale und sendet die Rohdaten an sondemod. sondemod wiederrum erzeugt aus den Sondendaten konforme APRS-Pakete als APRS-Objekt und sendet diese an udpbox, wo sie weiterverteilt werden an ein eigenes APRS-Gateway (udpgate4) und ggf. ARPSMAP.

Hinweise für den Empfang von Wettersonden

Der Empfang von Wettersonden ist in manchen Ländern ein Verstoß gegen nationale Telekommunikationsgesetze. Bitte beachten sie ihre nationalen Gesetzgebungen! Ich übernehme keine Haftung für Verstöße jeglicher Art. Jeder ist für sein eigenes Tun und Handeln verantwortlich. Sagt hinterher nicht, ihr habt es nicht gewusst 🙂 Die Anleitung dient ausschließlich technisch wissenschaftlichen Experimenten für den privatgebrauch. Kommerzielle Nutzung ist nicht erlaubt. Die dxlAPRS Tools sind eine Entwicklung von Christian Rabler OE5DXL und seinen Freunden. Sie unterstehen der GPL Lizenz.

Für wen sind diese Skripte und Dateien geeignet?

Zielgruppe sind interessierte Wettersondenbeobachter, welche sich mit der Technik der dxlAPRS Tools auseinandersetzen möchten und auch entsprechende Linux-Vorkenntnisse besitzen. Anhand des Aufbaus des Skripts kann man die Funktionsweise der dxlAPRS Tools kennenlernen. Dies versetzt einem beim aufmerksamen studieren der Programme und Parameter in die Lage Optimierungen durchzuführen sowie Probleme zu erkennen und zu beseitigen. Mit diesen Dateien kann man auch den Wettersondenempfang in ein bereits bestehendes Linux-System integrieren, z.B. auf einem bereits laufenden Linux-Server oder RaspberryPi. Außerdem kann kann man damit auch ein mobiles Sondenempfangssystem auf Laptop oder RaspberryPi zu bauen, welches man auf der Suche dabei hat.

Wenn ihr keine Ahnung von Linux habt oder lieber ein fertiges System nutzen wollt, greift lieber zum Image von Michal SQ6KXY von radiosondy.info. Das könnt ihr euch nach einer Registrierung auf seiner Seite einfach selbst zusammenklicken und herunterladen. Man lernt zwar nichts dabei, aber in der Regel funktioniert es auf Anhieb.

Welche Wettersonden können empfangen werden?

Die dxlAPRS Tools können alle gängigen Wettersonden dekodieren, egal ob es Vaisala RS41 oder RS92 sind, DFM Sonden von Graw oder sonstige Sonden wie M10, C50, IMET etc. Voraussetzung ist jeweils, dass deren genaue Sendefrequenzen bekannt sind und diese in der Frequenzdatei (sdrcfgX.txt) eingetragen sind. Die dxlAPRS Tools können selbst nicht automatisch das Frequenzspektrum abscannen um neue Frequenzen zu finden. Insbesondere ist dies bei DFM Sonden ein Problem, da deren Frequenzen immer anders sind und auch nicht vorhergesagt werden können. Die dxlAPRS Tools sind in der Lage die Signale dieser Sonden zu dekodieren, jedoch nur wenn man die Frequenzen händisch einpflegt.

Für den Empfang von Sonden des Typs M10 sind Änderungen an der Konfiguration notwendig. Die Samplerate bei sdrtst und sondudp muss dann mindestens 20000 Hz auf dem Stick betragen, wo M10 Sonden gehört werden. Dies erhöht allerdings proportional die CPU Last. Deswegen sollte es auch wirklich nur dann geändert werden, wenn wirklich M10 Sonden in Reichweite sind.

Benötigte Hardware

Für den Sondenempfang ist ein gewöhnlicher RTL SDR USB-Stick zu empfehlen. Idealerweise benutzt man einen RTL SDR mit TCXO. Diese sind von der ersten Sekunde an frequenzstabil und benötigen auch keine Frequenzkorrektur. Als ideal hat sich der „nesdr Smart“ von NooElec erwiesen. Dieser hat einen TCXO, ein Metallgehäuse (gut für die Wärmeabfuhr!) und ein kompaktes Gehäuse. Die Gehäuseform ermöglicht es z.B. am RaspberryPi auch zwei Sticks nebeneinander zu betreiben ohne Verlängerungskabel. Zu beziehen sind die Sticks unter anderem bei Amazon. Es gibt eine Version ohne Bias-T und eine mit Bias-T. Je nachdem ob ihr noch einen Vorverstärker mit einer Versorgungsspannung versorgen wollt, nehmt ihr den richtigen. Man kann auch zwei oder mehr Sticks parallel an einem Rechner benutzen. Beschränkungen gibt es nur bei der CPU-Leistung und der Stromversorgung der Sticks über USB. Letzteres muss bei der Nutzung eines RaspberryPi berücksichtigt werden. Als Rechner kann jeder 32bit oder 64 bit PC oder auch so ziemlich jeder Einplatinenrechner (RaspberryPi, BananPi, OrangePi etc.) mit Linux Betriebssystem verwendet werden. Die dxlAPRS Tools stehen für folgende PC Architekturen zu Verfügung:

  • armv6 (z.B. RaspberryPi 1. Generation und Zero)
  • armv7hf (ab RaspberryPi 2 aufwärts)
  • x86_32 (z.B. Intel/AMD PC 32 bit)
  • x86_64 (z.B. Intel/AMD PC 64 bit)

Für nur einen SDR Stick würde ein RaspberryPi 2B reichen. An der CPU-Leistung sollte man jedoch nicht sparen. Empfehlenswert ist daher immer mindestens ein RaspberryPi 3B+ oder neuer. Diese haben dann auch genug Reserven. Bei normalen PCs spielt das keine Rolle mehr, die haben natürlich alle ausreichen CPU Power.

Um die Empfangsleistung zu verbessern kann man noch einen passenden Vorverstärker vor die Antenne schalten. Auch ein SAW Filter für 403 MHz ist empfehlenswert. Wenn ein Tetra BOS Sender in der Nähe ist, ist dies oft sogar notwendig, da deren Signale bei knapp unter 400 MHz gleich „um die Ecke“ lauern und dadurch den Wettersondenempfang stören können. Tipp: Bei Uputronics in Großbritannien bekommt man ein solches Fertiggerät mit Filter und Vorverstärker in einem schönen Alu-Gehäuse. Es kursieren aber auch Bauanleitungen für solche Filter und Vorverstärker im internet.

Installationshinweise

1. dxlAPRS installieren

Installieren Sie die dxlAPRS Tools gemäß folgender Anleitung:
http://www.dl1nux.de/dxlaprs-tools-grundinstallation/

2. Zusätzliche Pakete installieren

SDR-Softwarepaket:

sudo apt-get install rtl-sdr

Wenn man die Tools in einer grafischen Oberfläche laufen lassen will, empfiehlt sich die Nutzung des xfce4-terminal. Es ermöglicht die getrennte Betrachtung der Ausgaben der einzelnen Tools und hilft auch oft bei der Fehlersuche 😉

sudo apt-get install xfce4-terminal

So in etwa würde es auf der grafischen Oberfläche aussehen, je nach Fensteranordnung:

3. Bei Bedarf: Zugriffsberechtigungen anpassen

In den meisten Linux-Distributionen können Standard-User nicht ohne Weiteres den USB SDR-Stick ansprechen, sondern benötigen Root-Rechte. Weil dies zu vielfältigen Problemen führen kann, geben wir den normalen Benutzern mit folgenden Schritten die benötigten Rechte, um auf den USB SDR-Stick zugreifen zu können:

sudo nano /etc/udev/rules.d/20.rtlsdr.rules

Dort fügen wir folgende Zeile ein und speichern diese mit STRG+O:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"

4. Beispielskript und -dateien herunterladen und entpacken

Download und entpacken der Skripte und Dateien:

wget http://www.dl1nux.de/sondenskripte.zip
unzip -j sondenskripte.zip

Das Archiv enthält folgende Dateien:

sonde.sh Startskript für ein System MIT grafischer Oberfläche
sondestandalone.sh Startskript für ein Standalone-System OHNE grafischer Oberfläche
sondenstop.sh Beendet sofort alle dxlAPRS Prozesse
sdrcfg0.txt Musterdatei für die Sonden-Empfangsfrequenzen
sondecom.txt Enthält die Variablen für den APRS-Kommentartext
netbeacon.txt Defniert die APRS-Bake für den Empfänger ins APRS-IS Netzwerk
readme.txt Dokument mit Infos
sondenstart.desktop Verknüpfung zu Sondenstart-Skript für Desktop und Autostart
sondenstop.desktop Verknüpfung zu Sondenstop-Skript für Desktop
aprsmap.desktop Verknüpfung zu APRSMAP für Desktop
getalmd Bash Skript von OE5DXL zum Laden des GPS Almanach für RS92 Sonden

Alle *.sh Dateien und getalmd müssen vor der Nutzung noch ausführbar gemacht werden:

chmod 755 *.sh
chmod 755 getalmd

Für den Standalonebetrieb ohne grafische Oberfläche werden lediglich folgende Dateien benötigt: sondestandalone.sh, sondenstop.sh, sdrcfg0.txt, sondecom.txt, netbeacon.txt, getalmd.

Alle weiteren Dateien werden nur benötigt, wenn man die Tools in der grafischen Oberfläche betreiben will. Die *.desktop Dateien sind für dei PIXEL Oberfläche vom Raspbian gedacht. Wenn man diese in den Desktop-Ordner kopiert, sieht man die entsprechenden Symbole auf dem Desktop und kann diese direkt anklicken:

cp *.desktop /home/pi/Desktop (Kopieren)

Nun sollten entsprechende Symbole auf der Desktopoberfläche sichtbar und anklickbar sein:

5. Geoid Datendatei herunterladen

Zuletzt sollte noch die Datendatei für die Geoid-Berechnung geladen werden. Sie ermöglicht die korrekte Darstellung der Sondenhöhe über Grund:

wget https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/binary/WW15MGH.DAC

Alle Programmdateien, Skripte und Textdateien sollten sich der Einfachheit halber im selben Verzeichnis befinden. Auf dem RaspberryPi wäre das idealerweise das Verzeichnis /home/pi/dxlAPRS/aprs . Alle weiteren Anweisungen setzen voraus dass man sich in diesem Programmordner befindet. Bei Abweichungen bitte entsprechend anpassen.

Vor dem ersten Start beachten

Wenn alle Pakete und Programmdateien installiert sind und sich die Skript- sowie Textdateien im Programmverzeichnis befinden, müssen noch mindestens die folgenden Schritte bzw. Anpassungen vorgenommen werden:

1. Rufzeichen im Skript eintragen

Bei SONDEUDP, SONDEMOD und UDPGATE4 muss MYCALL durch euer Rufzeichen ersetzt werden.

2. Eigenen Locator oder GPS-Standort sowie Höhe über NN eintragen

SONDEMOD benötigt für die Berechnung von Distanz, Azimuth und Elevation zur Wettersonde den eigenen Locator bzw. GPS-Position sowie die eigene Höhe über NN. Die Position gibt man mit dem Parameter -P im 10-stelligen Maidenhead-Locator Format oder in Dezimalgrad an, z.B. -P JO01AB50CD oder -P 70.0506 10.0092. Den 10-stelligen Locator kann man auch hier bestimmen: http://k7fry.com/grid/. Die Höhe über NN trägt man im Parameter „-N“ ein, z.B. „-N 250“ bei 250m über NN.

3. Ziel APRS-Gateway eintragen

Es muss ein Ziel-APRS Gateway eingetragen werden, an welches die erzeugten APRS Pakete gesendet werden sollen. Für Wettersonden eignet sich der Server bei radiosondy.info von Michal SQ6KXY. Dieser bereitet die Daten zusätzlich auf einer eigenen Communityseite auf und leitet sie auch auf Wunsch an das APRS-Netzwerk weiter. Entscheidend ist hier der Port an den gesendet wird. Der Zielport 14580 liefert die Daten an radiosondy.info und leitet sie auch an das APRS-Netzwerk weiter. Möchte man die Daten NUR an radisondy.info senden ohne diese ans APRS-Netzwerk zu senden, sendet man die Daten an Port 14590. Selbstverständlich kann man diese Daten auch direkt ins APRS-Netzwerk oder jeden beliebigen APRS-Server senden ohne den Umweg über radiosondy.info.

4. APRS-Passcode

Den APRS-Passcode für das eigene Gateway-Rufzeichen trägt man bei UDPGATE4 im Parameter -p ein. Dies ist notwendig, da sonst die APRS-Server keine Daten entgegen nehmen. Generieren kann man diesen z.B. hier:
https://apps.magicbug.co.uk/passcode/

5. netbeacon.txt

Die netbeacon.txt enthält die Koordinaten und den Kommentartext für die APRS-Netzbake des eigenen iGates. Bitte die Informationen in der netbeacon.txt lesen und beachten.

6. sdrcfg0.txt

Diese Datei enthält Parameter und Sondenfrequenzen, die überwacht werden sollen. Für jeden SDR-Stick muss eine eigene sdrcfg Datei erzeugt werden. Idealerweise werden diese durchnummeriert: sdrcfg0.txt, sdrcfg1.txt, sdrcfg2.txt usw.

7. Optional: sondecom.txt

Optional deswegen, da die Vorgabe in der Regel reichen sollte. Anpassungen sind jedoch auf Wunsch und nach persönlichem Bedarf möglich. Diese Datei enthält die Variablen für die Informationen, die den APRS-Paketen als Kommentartext angehängt werden. Man kann mehrere Zeilen definieren, dann werden die Kommentare abwechselnd variiert. Zeilen beginnend mit # werden ignoriert. Der mitgelieferte Inhalt ist ein Vorschlag der nützliche Informationen mit anzeigt und sendet.

%d%D%A%E%f
%s%u%v%f

Die Beispielvariablen erzeugen zwei sich abwechselnde APRS-Kommentare bestehend aus:

  • RSSI-Wert (Empfangspegel), Entfernung zur Sonde, Azimuth und Elevation zur Sonde in Grad, Frequenzabweichung innerhalb der AFC
  • Anzahl der empfangenen GPS-Satelliten, bisherige Laufzeit der Sonde, sondemod Programmversion, Frequenzabweichung innerhalb der AFC

So sehen die erzeugten APRS-Pakete beispielsweise aus:

DL1NUX-11>APLWS2:;P3340619 *174008h4927.18N/01232.40EO112/027/A=056331!wbA!Clb=6.0m/s Type=RS41 rssi=68.5dB dist=270.218 azimuth=107 elevation=2.34 rx=402700(+0/5)

DL1NUX-11>APLWS2:;P3340619 *174028h4927.14N/01232.56EO107/021/A=056650!wbb!Clb=4.6m/s Type=RS41-SGP Sats=11 powerup h:m:s 01:08:51 sondemod 1.36 rx=402700(+0/5)

8. Programm und Dateipfade anpassen

Falls sich eure Programme und Dateien nicht in /home/pi/dxlAPRS/aprs befinden, müsst ihr alle genannten Dateipfade im Skript nachträglich anpassen

Programmstart

Das Programm kann an der Konsole mit ./sonde.sh bzw. ./sondestandalone.sh gestartet werden. Wenn man sich sich nicht im Programmverzeichnis befinden, kann man auch den kompletten Pfad angeben: /home/pi/dxlAPRS/aprs/sonde.sh

Wenn man eine grafische Oberfläche hat, kann man die Skriptdateien auch direkt aus einem Dateimanager heraus mit Doppelklick starten.

Autostart

Möchte man den Sondenempfänger automatisch direkt nach dem Hochfahren des Rechners starten, gibt es folgende Möglichkeiten.

1. Automatisches Starten auf einem Standalone-PC ohne grafische Oberfläche

Es hat sich bewährt das Skript direkt nach dem Hochfahren mit der crontab zu starten. Dazu muss die Datei /etc/crontab als root (sudo) editiert werden:

sudo nano /etc/crontab

Nun fügt man folgenden Eintrag der Tabelle hinzu:

ddddddd

„pi“ nach dem „@reboot“ ist der Benutzer, unter dem das Skript ausgeführt werden soll. Es sollte NICHT! als root laufen. Wenn der Dateiname des Skripts abweicht, bitte entsprechend eintragen.

Es gibt darüber hinaus auch andere Möglichkeiten das Skript automatisch starten zu lassen. Das ist euch dann selbst überlassen. Falls euer Rechner zu lange zum booten braucht und das Skript zu schnell startet, verpasst ihm einfach einen „sleep 20“ oder so am Anfang der Datei, dadurch startet es später.

2. Automatisches Starten auf einem RaspberryPi mit PIXEL GUI

Wenn man das Skript in einer grafischen Oberfläche startet, ist man in der Lage die Ausgabe der einzelnen Tools zu verfolgen. Auch kann man das Programm APRSMAP zur grafischen Darstellung der Sonden auf einer Karte nutzen.

Dazu erstellt man erst den autostart Ordner (sofern er noch nicht existiert) und kopiert anschließend die sondenstart.desktop Datei hinein.

mkdir ~/.config/autostart
cp sondenstart.desktop /home/pi/.config/autostart

Im grafischen Dateimanager muss ggf. erst die Option „Versteckte anzeigen“ im Menü „Ansicht“ aktiviert werden, damit man den Ordner ~/.config sieht.

Hinweis zum Senden von Sondendaten zu wetterson.de

wetterson.de funktioniert technisch anders als radiosondy.info. Während radiosondy.info Daten im APRS-Format annimmt, darstellt und ggf. weiterleitet, sammelt wetterson.de nur die puren Sondendaten vom sondeudp bei den Empfängern ein. Es findet keine Auswertung bei den Empfängern statt, sondern erst in Bremen am Server, denn dort befindet sich der sondemod. Möchte man seine Daten also dorthin senden, muss lediglich ein weiteres Ziel im sondeudp angegeben werden: -u IP-Adresse:Port

IP-Adresse und Port des Zielservers erfragt man direkt bei den Betreibern von wetterson.de (https://wetterson.de/impressum/), denn diese sind nicht „öffentlich“. Möchte man Daten nur an wetterson.de senden, können die Zeilen im Skript für sondemod, udpbox und udpgate4 auskommentiert werden. Sie werden dann nicht benötigt.


Ausführliche Erläuterung aller Parameter

getalmd

Dieses Skript dient dazu stets den aktuellen GPS Almanach zu laden. Dieser ist für die korrekte Auswertung der Vaisala RS92 Sonden notwendig. Diese fliegen zwar nur noch selten, sind aber in der Regel mit den Ozonsonden im Huckepack unterwegs.


rtl_tcp -a 127.0.0.1 -d0 -p 18100 -n 1

rtl_tcp initialisiert den SDR Server

Die Parameter:
-a <IP-Adresse> = listen address
-d# = device index (default: 0)
-p <port> = listen port (default: 1234)
-n = max number of linked list buffers to keep

Erklärung:

  • Die „listen address“ gibt den eigenen Rechner (127.0.0.1 ist die interne IP-Adresse des eigenen Rechners) als Kommunikationsquelle an (sofern der Stick am selben Rechner hängt).
  • Der „device index“ gibt an, welcher SDR-Stick angesprochen wird. Wenn man mehrere SDR-Sticks angeschlossen hat, werden diese durchnummeriert beginnend mit d0, d1, d2 usw.
  • Der „listen port“ gibt den TCP Kommunikationsport an. Der SDR Server kann auf TCP Port 18100 „angezapft“ werden. Wenn man mehrere Sticks verwendet, muss jeder auf einem eigenen Port laufen.
  • Mit -n 1 hält man den Datenpuffer sehr klein und verhindert verzögerte Dekodierung

sondeudp -f 16000 -o /home/pi/dxlAPRS/aprs/sondepipe0 -I MYCALL-11 -L SDR0 -u 127.0.0.1:18000 -c 0 -n 0 -v 

sondeudp dekodiert die empfangenen Sondensignale und sendet die rohen Sonden-Bytes an den sondemod.

Hinweis: sondeudp sollte immer bereits vor sdrtst gestartet werden, damit sdrtst auch schon sicher ein Ziel hat wo er die Daten „abladen“ kann. In anderer Reihenfolge kann es zu Problemen kommen (muss aber nicht).

Die Parameter:
-f <num> adcrate (22050) (8000..96000)
-o <filename> oss devicename (/dev/dsp) or raw/wav audio file or pipe /dev/stdin
-I <call> mycall + ssid (use -C before to select 1 channel) else sondemod sets call
-L <name> Label of device sent to sondemod, max 4 char
-u <x.x.x.x:destport> send rx data in udp (to sondemod), -C <n> before sets
-c <num> maxchannels, 0 for automatic channel number recognition from sdrtst
-v verbous, (frames with Name looks ok)
-N <num> 1..255 generate DFM-ID from serial no. 0 automatic search for serial number
-n <num> same as -N but send substitute name if no serial number found in „-g“ min

Erklärung:

  • Die digitale Abtastrate am Empfänger beträgt 16 KHz (-f). Wenn man Sonden vom Typ M10 empfangen möchte, muss hier und beim sdrtst die Abtastrate auf mindestens 20 KHz erhöht werden! Aber Achtung, dadurch entsteht höhere CPU-Last!
  • Der Ursprung der Audioquelle (-o) ist in der Soundpipe „sondepipe0“ (auf korrekten Pfad achten!). Pipe muss vorher mit „mknod sondepipe0 p“ angelegt worden sein.
  • Der Absender der Daten (-I) lautet „MYCALL-11“. Hier muss das eigene Rufzeichen eingetragen werden. Dieses Rufzeichen erscheint auch auf den Wettersondenseiten als Absender. Wenn man mehrere Sticks hat, kann das Rufzeichen inkl. SSID überall gleich bleiben. Man kann aber die SSID auch variieren um die einzelnen Empfänger unterscheiden zu können.
  • Eine weitere Differenzierung der Empfänger ist mit dem Parameter -L möglich. Es sind maximal vier Zeichen erlaubt. Oft wird dieser Parameter auch genommen um Antennenrichtungen zu definieren, z.B. „OST“, „WEST“, „NORD“, „SUED“. In der weiteren Signalverarbeitung kann man die Herkunft damit unterscheiden.
  • Die rohen Sondendaten werden mit -u IP:PORT zu sondemod gesendet. Dieser kann sich auch auf einem entfernten Rechner befinden, wie beispielsweise bei der Seite wetterson.de. Es können auch mehrere Ziele hintereinander angegeben werden: -u IP1:PORT1 -u IP2:PORT2 -u IP3:PORT3 usw.
  • Eine automatische Erkennung der Kanalanzahl im sdrtst bewirkt der Parameter „-c 0“
  • Damit DFM-Sonden automatisch numeriert werden können, sucht sondeudp automatisch nach einer mitgesendeten Seriennummer (-n 0) und verpasst damit der Sonde einen eindeutigen Namen.
  • Eine optische Ausgabe der empfangenen Daten erfolgt mit „-v“. Dies kann man bei unbeaufsichtigtem Betrieb auch weglassen, stört aber nicht weiter.

sdrtst -t 127.0.0.1:18100 -r 16000 -s /home/pi/dxlAPRS/aprs/sondepipe0 -Z 100 -c /home/pi/dxlAPRS/aprs/sdrcfg0.txt -e -k -v

Empfänger starten

Diese Zeile startet den Empfänger am angegebenen SDR-Stick. Die empfangenen Signale werden in eine sogenannte „Audiopipe“ geschickt. Dabei handelt es sich um eine Art Transferdatei, die es ermöglicht die Audioinformationen von einem Programm zum anderen zu tranferieren. Diese wird im Skript vorher bereits angelegt mit mknod sondepipe0 p.

In der Datei sdrcfg0.txt (die Datei kann natürlich auch beliebig anders heißen) erfährt der Empfänger, auf welchen Frequenzen er hören soll. Für jede Frequenz wird dort eine eigene Zeile angelegt.

Inhalt:

# Parameter für SDR Stick:# p 5 = Frequenz Offset in PPM - Sticks mit TCXO benötigen die syntax p 5 0
p 5 0
# p 8 = Automatic Gain Control (AGC)
# p 8 1 = AGC an / p 8 0 = AGC aus
p 8 1
#-----------------------------------------------------------------------------------------------------
# Einstellen der Sondenfrequenz(en) (Wichtig: Als MHz-Trennung einen Punkt verwenden, und KEIN Komma (403.0 anstatt 403,0)
# f <mhz> <AFC-range><squelch%> <lowpass%> <IF-width>
# f 405.31 5 65 0 6000 # Einstellung für DFM Sonden
# f 402.70 5 70 0 12000 # Einstellung für Sonstige Sonden (RS41, RS92 etc.)
# f 403.00 8 80 0 20000 # Einstellung für M10 Sonden
# Bei M10 Empfang unbedingt auch die Samplerate bei sdrtst und sondeudp auf mindestens 20000Hz erhöhen!
#-----------------------------------------------------------------------------------------------------
# Wichtig: Die SDR Sticks haben nur etwa 2 MHz Bandbreite!
# Wenn Sie mehrere Frequenzen überwachen, sollten diese nicht mehr wie 2 MHz auseinander liegen

Erklärung:

  • Wir benutzen einen Stick mit TCXO und benötigen keine Frequenzkorrektur (p 5 0), die AGC ist an (p 8). Es können auch weitere SDR Parameter für rtl_tcp hier angegeben werden.
  • Sondenempfangsfrequenzen werden nach Bedarf ans Ende der Datei eingetragen, je eine pro Zeile. Es sind drei Frequenzbeispiele aufgeführt. Die Parameter AFC-Range, Squelsh, Lowpass und IF-Width sind eine Empfehlung von Chris OE5DXL je nach Sondentyp. Die Eingabe erfolgt ohne die Raute # am Anfang.

Kommen wir nun zurück zum ursprünglichen Befehl mit seinen Parametern:

Die Parameter:
-t <url:port> = connect rtl_tcp server
-r <Hz> = Output sampelrate Hz for all channels 8000..192000. For FM min. 25% more than rx IF-width
-s <soundfilename> = 16bit signed n-channel sound stream/pipe
-Z = sleep time (no cpu) for inactive rx if squelch closed (-z 100), fast open with no audio quieting for sending
-c <configfilename> = Read channels config from file
-e = enable sending SDR Data hidden in audio channels (tune/afc/rssi..)
-k = keep connection
-v = Show rssi (dB) and afc (khz)

Erklärung:

  • Wir connecten uns an den rtl_tcp Server (-t), den wir mit „rtl_tcp“ initialisiert haben mit einer Abtastrate von 16 KHz (-r). Wenn man Sonden vom Typ M10 empfangen möchte, muss hier und beim sondeudp die Abtastrate auf mindestens 20 KHz erhöht werden! Aber Achtung, dadurch entsteht höhere CPU-Last!
  • Als Bindeglied zu sondeudp dient die zuvor erstellte Pipe „sondepipe0“ (-s)
  • Der Parameter -Z spart CPU-Auslastung, wenn die Rauschsperre geschlossen ist auf einzelnen Kanälen
  • Die Frequenzen bzw. Frequenzparameter sind in der Datei „sdrcfg0.txt“ zu finden (-c).
  • Nützliche Daten über das Empfangssignal (RSSI, AFC usw.) können mit -e an sondeudp weitergegeben werden.
  • „Keep connection“ soll dafür sorgen, dass sdrtst die TCP-verbindung zu rtl_tcp neu startet wenn sie versehentlich beendet wird. Dies kann z.B. dann passieren, wenn der SDR Stick in der USB Buchse bewegt wird.
  • Mit -v wird die Signalstärke in dB und die AFC Abweichung in KHz des Signals mit ausgegeben.

sondemod -o 18000 -I MYCALL -r 127.0.0.1:9001 -b 20 -B 6 -A 1500 -x /tmp/e.txt -T 360 -R 240 -d -p 2 -M -L 6=DFM06,7=PS15,A=DFM09,B=DFM17,C=DFM09P,D=DFM17,FF=DFMx -t /home/pi/dxlAPRS/aprs/sondecom.txt -v -P JO12AA01BB -N 123 -S /home/pi/dxlAPRS/aprs/

sondemod erzeugt aus den Sondenrohdaten APRS-Pakete als APRS-Objekte.

Die Parameter:

-o <UDPport> = receive demodulated data via UDP port from ’sondeudp -u …‘
-I <mycall> = Sender of Object Callsign -I OE0AAA if not sent by ’sondeudp‘
-r <ip>:<port> = send AXUDP -r 127.0.0.1:9001 use udpgate4 or aprsmap as receiver
-b <seconds> = high altitude minimum send intervall or 0 for never send -b 20
-B <seconds> = low altitude send intervall -B 10
-A <meter> = at lower altitude use -B beacon time (meter) -A 1000
-x <filename> = gps almanach rinexnavigation format (prefered)
-T <minutes> = stop sending data after almanach age (-T 360)
-R <minutes> = request new rinex almanach after minutes if receiving gps (-R 240)
-d = dao extension for 20cm APRS resolution instead of 18m
-p <num> = 0 send if weather data ready, 1 if MHz known, 2 send immediatly (1)
-M = Send „MHz“ in APRS (if not received in Data) from SDR-parameter +afc
-L = IF there is a dependency, assign DFM-Types to highest found first 4 bit in frame (in hex)
-t <filename> = append comment lines from this file at start of line eg „%f%d%v text…“
-v = verbous
-P = <lat> <long> or <locator> my Position for Distance/Azimuth/Elevation
-N <meter> = my altitude over NN for Distance/Elevation to sonde output
-S <pathname> = directory with SRTM(1/3/30) Data and WW15MGH.DAC file (egm96-Geoid)

Erklärung:

  • sondemod erhält die Daten vom sondeudp (-o). Es können auch merere sondudp ihre Daten hierhin senden, auch von der gleichen Frequenz, z.B. auf unterschiedlichen Antennen.
  • Falls bei sondeudp kein Rufzeichen als Absender mitgesendet wird, wird dieses (-I) angehängt.
  • Sende die APRS-Pakete per UDP an „-r“ (z.B. udpbox/udpgate/aprsmap).
  • Die APRS Pakete werden in zwei Taktraten erzeugt und -A definiert die Schwelle zwischen den Taktraten in Metern. -b definiert die Taktrate in Sekunden für hoch fliegende Ballons über der Schwelle und -B die Taktrate für tiefer fliegende Ballons unterhalb der Schwelle. Dies ermöglicht eine genauere Landevorhersage, da dann mehr Daten für die Auswertung vorhanden sind.
  • -x, -T und -R werden nur für RS92 Sonden benötigt und beziehen sich auf den GPS Almanach (getalmd).
  • Auf 20cm genaue APRS-Positionen werden mit dem Parameter -d aktiviert.
  • Damit APRS Pakete sofort gesendet werden, setzt man -p auf 2.
  • -M gibt die Empfangsfrequenz weiter im APRS Paket, wenn sie nicht in den Sondendaten enthalten ist.
  • Um DFM Sondentypen genauer zu bestimmen, wird der Parameter -L mit den Sondentypen definiert.
  • Der Parameter -t verweist auf eine Datei (sondecom.txt) welche Variablen für den APRS Kommentartext erhält (siehe auch unten).
  • Eine informative Bildschirmausgabe der Daten wird durch -v erzeugt.
  • Die eigene Position und Höhe über NN wird mit den Parametern -P und -N definiert. Dies ermöglicht eine genaue Berechnung von Distanz, Elevation und Azimuth zur empfangenen Sonde. Die Informationen können z.B. im APRS Kommentartext (-t) weitergegeben werden
  • Für die Umwandlung von WGS84 in EGM96 Höhendaten wir die Datei WW15MHG.DAC benötigt. Der Parameter -S gibt an, wo sich diese im Dateisystem befindet.

Erklärung der Variablen in der sondecom.txt:

# Kommentar-Zeile, wird ignoriert
%A Azimuth vom RX zur Sonde
%d RSSi Signalpegel wenn es von sdrtst -e mitgesendet wird
%D Distanz vom RX zur Sonde
%E Elevation vom RX zur Sonde
%f SDR Frequenz + AFC von sdrtst mit -e sofern nicht von der Sonde ausgesendet
%F Gleich wie %f, sendet die Info aber immer aus
%l Bezeichnung des Empfängers, der von sondeudp -L mitgegeben wird
%n Frame Nummer sofern verfügbar
%r hdil wenn verfügbar, GPS horizontal Rauschen in Meter
%s Anzahl der empfangenen GPS Satelliten sofern verfügbar
%u Einschaltdauer der Sonde sofern verfügbar
%v sondemod Version


udpbox -R 127.0.0.1:9001 -l 127.0.0.1:9101 -l 127.0.0.1:9105 -v

udpbox sammelt alle Datenpakete, auch von mehreren Empfängern ein, und leitet diese weiter an das Gateway bzw. andere Ziele wie APRSMAP

Die Parameter:
-R <ip>:<port> = read raw axudp frame, 0 ip read from all
-l <ip>:<port> = send raw axudp frame (AXUDP v2)
-v = show frames and analytics on stdout

Erklärung:

  • UDPBOX empfängt AXUDP Daten an Port 9001 von sondemod.
  • Zur Weiterleitung an das iGate sendet UDPBOX die Daten an Port 9101 weiter. Für die Darstellung unter APRSMAP werden die Daten ebenfalls an Port 9105 gesendet. Dies kann bei standalone Nutzung aber auch entfallen.
  • Hinweis: Man kann APRSMAP auch auf einem anderen PC laufen lassen, auch einem Windows-PC. Dazu sendet man die Daten an den passenden Rechner IP-Adresse:Port, z.B. -l 192.168.178.20:9105. Natürlich sollte man dann sicherstellen das der Rechner immer unter der IP-Adresse erreichbar ist und auch keine Firewall die Datenübergabe an APRSMAP blockiert.
  • Außerdem werden mit -v im Ausgabefenster Informationen zu den einzelnen Paketen angezeigt (kann bei standalone Nutzung entfallen).

Hinweis: udpbox kann man weglassen, wenn man die Daten nur an das iGate senden möchte. Dann sollte sondemod seine Daten per UDP direkt an udpgate4 senden, ohne Zwischenstation (Portangaben anpassen!).


udpgate4 -s MYCALL-10 -R 127.0.0.1:0:9101 -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt -g radiosondy.info:14580#m/0,-t/t -p 12345 -t 14580 -w 14501 -v -D /home/pi/dxlAPRS/aprs/www/

UDPGATE4 ist das iGate welches die APRS Pakete an einen beliebigen APRS-Server weiterleitet

Die Parameter:
-s <call> = server call of this server -s MYCALL-2 (-S no callcheck)
-R <ip>:<dport>/<lport>[+<byte/s>[:<radius>]][#<portname>] (axudp format)
-n <min>:<file> = netbeacon minutes:filename
-g :<filename> = read gateway urls from file url:port#filter,filter,…
-p <password> = login passwort for aprs-is servers -p 12345. To hide password in commandline use file mode -p pass.txt
-t <localport> = local igate tcp port for in connects -t 14580
-w <port> = port of www server -w 14501
-v = show frames and analytics on stdout
-D <path> = www server root directory (-D /usr/www/)

Erklärung:

  • Das iGate empfängt die APRS Pakete im AXUDP Format auf Port 9101 (-r) auf dem gleichen Rechner (127.0.0.1) von udpbox.
  • Zwischen 127.0.0.1 und dem Port 9101 ist noch eine Null. Dies ist der „destination port“ der bei einem reinen Empfangs iGate irrelevant ist und daher auf „0“ steht.
  • Es wird außerdem alle 30 Minuten eine APRS Bake mit dem Inhalt der Datei „netbeacon.txt“ eingerichtet („- n“). Die „Bake“ erzeugt für das iGate ein entsprechendes Symbol auf der APRS Karte (z.B. bei aprs.fi) unter dem Rufzeichen „MYCALL-10“. Es sollte keinesfalls öfter eine Bake gesendet werden! Es reichen sogar 60 Minuten. Die Symbole bleiben trotzdem auf der APRS Karte (z.B. aprs.fi) sichtbar. Die Aussendung der Bake kann unterbunden werden. Siehe Tipps & Tricks weiter unten.
  • Die APRS Daten werden an den Server radiosondy.info auf Port 14580 gesendet. Sendet man die Daten an Port 14580 von radiosondy.info, werden die Daten an das APRS-Netzwerk weitergeleitet. Möchte man dies nicht und seine Daten ausschließlich an radiosondy.info weiterleiten, sendet man die Daten an den „nonforwarding“ Port 14590. Es sind noch Filter hinterlegt (#m/0,-t/t), welche Übermittlung und Anzeige von unnötigen Informationen aus dem APRS-Netzwerk unterdrückt.
  • Den Passcode für die Übermittlung (Kann z.B. hier generiert werden: https://apps.magicbug.co.uk/passcode/) übergibt der Paramter „-p“.
  • -t gibt den Port an, auf dem das iGate für eingehende Verbindungen lauscht. Dieser Port darf auf diesem Rechner noch nicht in Benutzung sein und lautet standardmäßg 14580. Das iGate kann daher auch von anderen Stationen connected werden zur Übermittlung von APRS-Daten an das entfernte APRS Gateway.
  • -w gibt den Port an, auf dem die Weboberfläche des iGate abrufbar ist (auf dem iGate Rechner selbst z.B. mit der Adresse 127.0.0.1:14501 im Browser abrufbar). Von anderen Rechnern aus mit http://IP-Adresse:14501. Für Sondenempfang ist das allerdings weniger interessant.
  • -D gibt den Pfad an, an dem die Dateien für die iGate Weboberfläche abgelegt sind.
  • Außerdem werden mit -v die einzelnen gesendeten APRS Frames im Terminalfenster ausgegeben (kann bei standalone Nutzung entfallen).

Inhalt der Datei netbeacon.txt:

!5010.00N/01100.00E`Radiosonden iGate von MYCALL
#
# Geokoordinaten in Grad und Dezimalminuten ohne °-Symbol
# Beispiel 50°10.00 N = 5010.00N und 011°00.00 E = 01100.00E
# Die Ost-Gradzahl muss immer! dreistellig angegeben werden, also 011 bei 11 Grad Ost
#
# APRS-Symbol ist änderbar durch ersetzen der Symbolzeichen nach dem N
# und nach dem E, siehe auch APRS Symboltabelle unter:
#
https://www.yachttrack.org/info_camper/downloads/APRS_Symbol_Chart.pdf


Tipps & Tricks

Tipp 1: Tipps für Standalone Betrieb

Betreibt man das Sonden-Empfangssystem im Standalonebetrieb, also ohne grafische Oberfläche nur im Hintergund arbeitend, lohnen sich folgende Anpassungen:

  • udpbox weglassen. Da udpbox den axudp Output von sondemod nur vervielfältigt, damit man ihn in APRSMAP anzeigen kann, kann man udpbox dann auch ganz weglassen. Der destination port bei sondemod sollte dann direkt zum listen port bei udpgate4 führen.
  • Da keine visuelle Ausgabe von Daten am System gewünscht ist, kann man überall, falls vorhanden, den Parameter -v weglassen. Dieser erzeugt nur Datenausgaben auf dem Bildschirm, die im Standalonebetrieb nicht benötigt werden.

Tipp 2: iGate ohne Symbol auf der APRS Karte

Das iGate udpgate4 erzeugt in der Grundeinstellung ein eigenes Symbol auf der APRS Karte (Parameter -n). Diese Positionsbake ist in der netbeacon.txt gespeichert und wird direkt per TCP/IP an das APRS-IS Netzwerk übermittelt. Wenn man nicht auf der APRS Karte erscheinen möchte, kann man auch den kompletten String -n 30:/home/pi/dxlAPRS/aprs/netbeacon.txt aus dem Aufruf entfernen.

Tipp 3: APRSMAP nutzen, um die empfangenen Daten anzuzeigen

APRSMAP ist eine vollwertige APRS Anwendung mit iGate Funktionalität und einer guten Kartendarstellung. APRSMAP kann SEHR viel, aber darauf möchte ich hier nicht im Detail eingehen. Vieles nachlesen kann man in der (nicht ganz vollständigen) Anleitung zu APRSMAP. APRSMAP ist automatisch bei den dxlAPRS Tools dabei, und zwar im Ordner dxlAPRS/aprsmap. Im Startskript senden wir bereits alle Daten an für APRSMAP an den Port UDP 9105. Um nun die empfangenen Daten im APRSMAP anzeigen zu können, muss man dort noch einstellen, das APRSMAP auf UDP Port 9105 „hören“ soll.
Dazu wechselt man im Menü „Config“ zu „RF-Ports“ und dann „RF-Port 1“. Im öffnenden Fenster gibt man dann folgendes ein: :0:9105 . Dies sagt APRSMAP, das es auf dem gleichen Rechner auf Port 9105 lauschen soll. Der davor angegebene Port 0 wäre der destination Port, der aber für unsere Zwecke nicht relvant ist. Wichtig ist die genaue Schreibweise wie angegeben. Alternativ kann man auch 127.0.0.1:0:9105 angeben, es entspricht dem gleichen Ergebnis. Man kann auch beliebig weitere RF-Ports aktivieren, wenn z.B. von einem anderen Rechner ebenfalls AXUDP Daten übermittelt werden (z.B. von 2m APRS). Dann würden diese Daten ebenfalls angezeigt werden. Wichtig ist hier, dass der grüne Punkt leuchtet, denn erst dann ist der Port auch wirklich aktiv und nimmt Daten entgegen.

Tipp 4: Kartenladeprobleme in APRSMAP lösen

Seit Ende März 2020 gibt es Probleme mit dem automatischen Kartendownload von OpenStreetMap im APRSMAP. Diese kann man schnell lösen, wenn man einen anderen Kartenserver angibt. Dazu bearbeitet man die Datei maplist im ARPSMAP Ordner. Die erste nicht-auskommentierte Zeile sieht wie folgt aus:

tiles zxy png http://tile.openstreetmap.org

Hier ersetzt man nun die Karten-URL wie folgt:

tiles zxy png http://tile.openstreetmap.de/tiles/osmde

Man kann aber auch eine beliegibe andere OSM Kartenquelle eintragen, wenn man eine kennt.


Diese Anleitung wurde mit bestem Wissen und Gewissen und mit Hilfe des Entwicklers Christian OE5DXL erstellt. Aber auch hier kann sich natürlich der Fehlerteufel verstecken. Deshalb sind alle Angaben ohne Gewähr! Auch geht die Entwicklung der dxlAPRS Tools immer weiter, was auch Veränderungen mit sich bringen kann. Wenn ihr einen Fehler findet oder Fragen habt, zögert nicht mich zu kontaktieren. Gerne auch als Kommentar auf der Webseite.
Kontaktmöglichkeiten:

  • per E-Mail attila [at] dl1nux . de
  • per IRC Chat im Hamnet (HamIRCNet) im Kanal #hamnet-oberfranken
  • per Packet-Radio im DL/EU Converse Kanal 501

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.