Im vorliegenden Artikel wird erklärt, wie ein Wettersondenempfänger mit der dxlAPRS Toolchain in einem Linux-System aufgebaut werden kann und funktioniert. Für ganz bequeme gibt es die notwendigen Skript- und Textdateien als Download oder Alternativ auch fertige Images zum Download.

Inhaltsverzeichnis

• Einleitung
• Hinweise für den Empfang von Wettersonden
• Für wen sind diese Skripte und Dateien geeignet?
• Welche Wettersonden können empfangen werden?
• Benötigte Hardware
• Funktionsweise der vorliegenden Skripte
• Fertiges Image für den Raspberry Pi
• Installationshinweise
• Vor dem ersten Start beachten
• Programmstart
• Autostart
• Ausführliche Erläuterung aller Parameter
• Tipps & Tricks

Stand 12.07.2022

Einleitung

Die folgende Anleitung dient dazu in wenigen Schritten einen Wettersonden-Empfänger aufzubauen, der seine Daten an die Community-Seiten radiosondy.info, wettersonde.net und auch in das APRS-Netzwerk weiterleitet. 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.

Weitere Informationen zu den dxlAPRS Tools findet man auch im Wiki unter http://dxlwiki.dl1nux.de.

Auch gibt es inzwischen eine Telegram-Gruppe in der sich Anwender der dxlAPRS Tools untereinander austauschen können, egal ob es um Wettersonden, APRS oder sonstiges geht. https://t.me/joinchat/CRNMIBpKRcfQEBTPKLS0zg

Was wird benötigt?

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 (Erzeugung von APRS Paketen aus den Sondendaten)
• udpgate4 (APRS iGate)
• udpbox (Verfielfältigung der AXUDP Streams)

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-Objekte und sendet diese an udpbox. Dort werden sie verfielfältigt um die erzeugten Pakete zeitgleich an zwei Server und ggf. noch an das Kartenprogramm APRSMAP schicken zu können.

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.

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.

Von Wolfgang Hallmann DF7PN gibt es eine Anwendung, mit der man an einem extra Stick die Frequenzen regelmäßig abscannen kann um damit Sonden auf unbekannten Frequenzen zu finden. Mit etwas Geschick und viel Wissen kann man den die vorliegenden Scripte auch mit dem Sondenscanner ergänzen. Weitere Infos: https://github.com/whallmann/SondenUtils

Für den Empfang von Sonden des Typs M10 sind Änderungen an der Konfiguration notwendig. Die Samplerate bei sdrtst und sondeudp 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) – nur 32 bit
• armv7hf (ab RaspberryPi 2 aufwärts) – nur 32 bit
• 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.

Funktionsweise der fertigen Skripte

Die Skripte empfangen und dekodieren die Daten der Wettersonden. Daraus werden APRS-Pakete (APRS-Objekte) erzeugt. Diese APRS Pakete werden dann an zwei Server gleichzeitig gesendet. Einmal an radiosondy.info von Michal SQ6KXY, und dann nochmal an wettersonde.net von Jean-Michael DO2JMG. Zusätzlich können die Daten noch mit APRSMAP auf einer Karte dargestellt werden.

Die meisten Parameter müssen in der Datei sondeconfig.txt eingetragen werden. Diese Datei wird von jedem Skript zu Beginn eingelesen und die enthaltenen Variablen an den richtigen Stellen eingefügt. Dadurch ist es möglich mit nur einer Konfigurationsdatei alle Skripte zu verwenden. Die verschiedenen Skripte müssen nicht mehr alle einzeln angepasst werden.

Darüberhinaus sind natürlich noch manuelle Anpassungen an den Skripten erlaubt.

Es sind insgesamt Sieben Skripte enthalten. Drei Startskripte für den Konsolenbetrieb ohne grafische Oberfläche, und drei für die Nutzung in der grafischen Oberfläche (*-gui.sh). Diese sind jeweils für die Nutzung von ein, zwei oder drei Sticks parallel gedacht. Ein weiteres Skript ist zum stoppen aller Prozesse gedacht (sondestop.sh).

Wenn der Empfänger läuft, kann man die zwei Webinterfaces der iGates einfach im Browser über die Ports 14501 und 14502 aufrufen, z.B.:

http://192.168.178.66:14501/mh (Verbindung zu radiosondy.info)
http://192.168.178.66:14502/mh (Verbindung zu wettersonde.net)

Natürlich müsst ihr die passende IP-Adresse einsetzen, die euer RaspberryPi bzw. Rechner im Netzwerk hat.

Im Webinterface sieht man dann nach einiger Zeit die Empfangenen Sonden mit all ihren Daten aus den letzten 48 Stunden. Die Zeitspanne der Anzeige lässt sich auch bei Bedarf in den Startskripten händisch anpassen (-B beim udpgate4).

Fertiges Image für den Raspberry Pi

Informationen und Downloadlinks zu den fertigen Images von DL1NUX findet ihr ab sofort auf einer eigenen Seite.

Installationshinweise

1. dxlAPRS installieren

Installieren Sie die dxlAPRS Tools gemäß folgender Anleitung:
http://dxlwiki.dl1nux.de/index.php?title=Installationsanleitung

2. Zusätzliche Pakete installieren

SDR-Softwarepaket:

sudo apt 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 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 Zeilen ein und speichern diese mit STRG+O:

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

4. Beispielskript und -dateien herunterladen und ggf. in den APRS Ordner kopieren

4.1. Download der Dateien von github in den Ordner ~/dxlAPRS/aprs/:

cd ~/dxlAPRS/aprs/
git clone https://github.com/dl1nux/dxlAPRS-radiosonde-rx.git

Sollten die Dateien im falschen Ordner landen, einfach alles in den aprs Programmordner kopieren oder verschieben.

Das Archiv enthält folgende Dateien:

• getalmd – Bash Skript von OE5DXL zum Laden des GPS Almanach für RS92 Sonden (derzeit ohne Funktion da Datenquelle nicht mehr existiert)
• netbeacon_sonde.txt – Defniert die APRS-Bake für den Empfänger ins APRS-IS Netzwerk
• objectlink.txt – externer Link zu radiosondy.info für die Sondeneinträge im Webinterface
• README.md – Diese Infodatei
• sdrcfg0.txt – Musterdatei für die Sonden-Empfangsfrequenzen für den 1. Stick
• sdrcfg1.txt – Musterdatei für die Sonden-Empfangsfrequenzen für den 2. Stick
• sdrcfg2.txt – Musterdatei für die Sonden-Empfangsfrequenzen für den 3. Stick
• sonde1.sh – Startskript für ein System ohne grafischer Oberfläche und EINEM Stick
• sonde2.sh – Startskript für ein System ohne grafischer Oberfläche und ZWEI Sticks
• sonde3.sh – Startskript für ein System ohne grafischer Oberfläche und DREI Sticks
• sonde1-gui.sh – Startskript für ein System mit grafischer Oberfläche und EINEM Stick
• sonde2-gui.sh – Startskript für ein System mit grafischer Oberfläche und ZWEI Sticks
• sonde3-gui.sh – Startskript für ein System mit grafischer Oberfläche und DREI Sticks
• sondecom.txt – Enthält Parameter für den APRS-Kommentartext
• sondeconfig.txt – Enthält die wichigen Variablen für die Konfiguration
• sondestop.sh – Beendet sofort alle dxlAPRS Prozesse

Das Skript getalmd lädt den GPS-Almanach, welcher für RS92 Sonden notwendig ist. Das Skript funktioniert derzeit jedoch nicht mehr, da sich die Server für den Bezug der Daten geändert haben. Falls jemand die richtigen Serverdaten hat, kann er diese im Skript eintragen und die entsprechende Zeile im Startskript wieder aktivieren.

4.2. Dateien verschieben oder kopieren

Im Unterordner „Desktop“ befinden sich Desktopverknüpfungen für die grafische Oberfläche

• desktop-sonde1.desktop – Verknüpfung zum Startskript für EINEN Stick
• desktop-sonde2.desktop – Verknüpfung zum Startskript für ZWEI Sticks
• desktop-sonde3.desktop – Verknüpfung zum Startskript für DREI Sticks
• desktop-sondenstop.desktop – Verknüpfung zum Sondenstop-Skript
• aprsmap.desktop – Verknüpfung zu APRSMAP

Man kopiert diese entweder über den Dateimanager in den Ordner ~/Desktop oder oder kopiert sie an der Konsole wie folgt:

cp *.desktop ~/Desktop

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

Die Datei objectlink.txt muss in den Ordner ~/dxlAPRS/aprs/www/ kopiert werden. Sie enthält den externen Link zu radiosondy.info der aufgerufen wird, sobald man im Webinterface die Seriennummer einer empfangenen Sonde anklickt.

5. Geoid Datendatei herunterladen

Zuletzt sollte noch die Datendatei für die Geoid-Berechnung in den aprs Ordner geladen werden (dafür den Befehl idealerweise direkt aus dem Ordner ~/dxlAPRS/aprs/ heraus aufrufen)

 wget http://download.osgeo.org/proj/vdatum/egm96_15/outdated/WW15MGH.DAC

6. Optional: SRTM Höhendaten im System hinterlegen

Wenn man SRTM Datenfiles hat, kann das iGate udpgate4 diese nutzen um die Höhen der Sonden über Grund im Webinterface anzuzeigen. Dazu muss im Ordner ~/dxlAPRS/aprs/ der Ordner /srtm1 angelegt und die SRTM Datenfiles darin abgelegt werden. Bei udpdate4 muss im Aufruf der Parameter -A <Pfad zu /srtm1> hinzugefügt werden. In den Startskripten ist dies bereits berücksichtigt.

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. Parameter in der sondeconfig.txt eintragen:

• DXLPATH = Pfad zum aprs verzeichnis, z.B. /home/pi/dxlAPRS/aprs
• IGATECALL = Rufzeichen des iGates inkl. SSID, z.B. NOCALL-10
• SONDECALL = Rufzeichen des Absenders der Sondenobjekte inkl. SSID, z.B. NOCALL-11
• PASSCODE = APRS Passcode für das iGate-Rufzeichen, z.B. 12345
• LOCATOR = Eigener QTH-Locator (10 stellig!), z.B. JO01AA23BB (nur für Entfernungsberechnung relevant)
• HOEHE = Höhe des Empfängers in Meter über NN (nur für Elevationsberechnung relevant)
• ALT1 = Höhenschwelle in Meter für kleinstes Sendeintervall, z.B. 3000
• ALT2 = Höhenschwelle in Meter für zweites Sendeintervall, z.B. 2000
• ALT3 = Höhenschwelle in Meter für drittes Sendeintervall, z.B. 1000
• INTERVALLHIGH = Sendeintervall in Sekunden für Sonden oberhalb von HEIGHT1, z.B. 30
• INTERVALL1 = Sendeintervall in Sekunden für Sonden in der Höhe zwischen HEIGHT1 und HEIGHT2, z.B. 20
• INTERVALL2 = Sendeintervall in Sekunden für Sonden in der Höhe zwischen HEIGHT2 und HEIGHT3, z.B. 10
• INTERVALL3 = Häufiges Sendeintervall in Sekunden für Sonden unterhalb der Höhe von HEIGHT3, z.B. 5

Beim Vorhandensein von SRTM Daten in ~/dxlAPRS/aprs/srtm1/ werden bei den Parametern ALT* jeweils die Höhen über Grund zugrundegelegt.

Hinweis: iGate Rufzeichen und Absenderrufzeichen müssen identisch sein, jedoch muss sich die SSID der beiden Calls unterscheiden. Also z.B. NOCALL-10 und NOCALL-11. Wird dies nicht beachtet, werden die Pakete von der Seite
wettersonde.net verworfen.

2. netbeacon_sonde.txt

Die netbeacon_sonde.txt enthält die Koordinaten und den Kommentartext für die APRS-Netzbake des eigenen iGates. Diese müssen zwingen händisch eingetragen werden. Bitte die Informationen in der netbeacon_sonde.txt lesen und beachten.

3. sdrcfg0.txt / sdrcfg1.txt / sdrcfg2.txt

Diese Dateien enthalten SDR Parameter und die Sondenfrequenzen, die überwacht werden sollen. Für jeden SDR-Stick muss eine eigene sdrcfg Datei verwendet werden, weshalb diese durchnummeriert sind. Wird nur ein Stick verwendet, muss die Datei sdrcfg0.txt bearbeitet werden. Bei zwei Sticks die 0 und die 1 und bei drei Stick alle drei. Möchte man hier manuell eingreifen, sind Änderungen im Startskript beim Punkt sdrtst durchzuführen.

4. 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.

Programmstart

Das Programm kann an der Konsole mit z.B. ./sonde2.sh gestartet werden. Das startet das Skript für den Betrieb mit zwei SDR-Sticks an der Konsole. Wenn man sich sich nicht im Programmverzeichnis befinden, kann man auch den kompletten Pfad angeben: /home/pi/dxlAPRS/aprs/sonde2.sh

Wenn man eine grafische Oberfläche hat, kann man die Skriptdateien auch direkt aus einem Dateimanager heraus mit Doppelklick starten – dann am besten die GUI-Varianten. Diese öffnen einzelne Programmfenster und bieten daher eine bessere Übersicht.

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:

@reboot pi /home/pi/dxlAPRS/aprs/sonde2.sh

„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überhinaus 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 eine Wartezeit am Anfang der Datei. In den Skripten ist dies unter dem Punkt „Wartezeit“ bereits eingebaut, jedoch standardmäßig auskommentiert. Zum aktivieren entfernt man einfach die # vor der Zeile.

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 desktop-sonde2.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.

---

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. Das Skript ist derzeit nicht funktionsfähig (siehe oben) und in den Skripten auskommentiert.

---

rtl_tcp -a 127.0.0.1 -d0 -p 18200 -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 -W 5 -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
-W (s) cyclic sleep (seconds) inactive demodulators to save CPU, wakes 1..2s (dep. on type) and stay long awake if found fitting pattern. do not use in frequency-hopping environment.

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 25 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. 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.
• Der Parameter -W sorgt dafür, dass die Empfänger in einen Standbymodus gehen und erst dann richtig wach werden, wenn wirklich ein Signal empfangen wird. Dies spart bei vielen gleichzeitig empfangenen Frequenzen CPU-Rechenleistung ein. Im genannten Beispiel wird alle 5 Sekunden nach einem Signal Ausschau gehalten.
• 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:18200 -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 transferieren. 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 0p 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 25 KHz 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 30:20:10:5 -A 3000:2000:1000 -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>[:<seconds>]… minimum send intervall or 0 for never send -b 30:20:6:2. first for high altitude, next below (descending) altitudes as given in -A
-A <meter>[:<meter>] at lower altitude use -b beacon time (meter) -A 3000:1000:200. if SRTM/EGM-data available, Overground will be used
-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).
• Bakenintervall = 30 Sekunden oberhalb 3000m, 20 Sekunden zwischen 3000m und 2000m, 10 Sekunden zwischen 2000m und 1000m und 5 Sekunden unterhalb von 1000m Sondenhöhe. Bei der Nutzung von SRTM Daten wird die Höhe über Grund zugrunde gelegt (siehe -A und -b).
• -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:9999 -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 9999 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:9999. 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 -B 1440 -u 50 -A /home/pi/dxlAPRS/aprs/ -n 30:/home/pi/dxlAPRS/aprs/netbeacon_sonde.txt -g radiosondy.info:14580#m/1,-t/t -p 12345 -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)
-B [+]<time> Minutes show heard Items/Objects, with „+“ from AprsIs too (-B +60)
-u <maxlines> raw frame listing by click to frame counter in Heard list (20) (0 off)
-A <path> srtm directory path to enable overground calculation (-A /usr/srtm/)
-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
-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.
• Mit -B wird eine Objekt-Liste der letzten 24 Stunden (144 Minuten) mit zahlreichen Informationen im Webinterface angezeigt.
• -u 50 erhöht die Liste der gespeicherten APRS-Pakete pro Objekt auf 50. Man kann sich so von jedem Objekt die letzten 50 generierten APRS-Pakete anzeigen lassen.
• Mit -A gibt man den Pfad zum Ordner an, indem sich der Ordner /strm1 befindet, der die SRTM Datenfiles enthält. Dies ermöglicht eine relativ genaue Berechnung der Sondenhöhe über Grund. Die SRTM Datenfiles sind nicht Teil der dxlAPRS Tools und müssen aus anderen Quellen beschafft werden. Besitzt man die Datenfiles nicht, lässt man diesen Parameter einfach weg.
• Es wird außerdem alle 30 Minuten eine APRS Bake mit dem Inhalt der Datei netbeacon_sonde.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/1,-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“.
• -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_sonde.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

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 9999. Um nun die empfangenen Daten im APRSMAP anzeigen zu können, muss man dort noch einstellen, das APRSMAP auf UDP Port 999 „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:9999 . Dies sagt APRSMAP, das es auf dem gleichen Rechner auf Port 9999 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:9999 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.

 

---

Disclaimer:
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.

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

Support:
dxl-Wiki: http://dxlwiki.dl1nux.de
Telegram-Gruppe: https://t.me/joinchat/CRNMIBpKRcfQEBTPKLS0zg