14.08.2026 – Wird je nach Entwicklungsstand laufend aktualisiert…
Wer Amateurfunk betreibt, kennt die Situation: Man ist auf einer Frequenz aktiv, hört mit, probiert etwas aus – oder sitzt gerade nicht am Gerät. Ruft in dieser Zeit jemand, bekommt man es schlicht nicht mit. Anders als beim Telefon gibt es keinen Kanal, der unabhängig von der aktuellen Betriebsart durchklingelt.
APRS bietet dafür eine naheliegende Grundlage. Der Standard wird von den meisten Geräten unterstützt, ist niederschwellig zugänglich und erlaubt neben Positionsmeldungen auch kurze Nachrichten an ein bestimmtes Rufzeichen.
Ziel
Beliebige Stationen in der näheren Umgebung sollen mich über das 2-m-Netz per APRS anpingen können — und ich bekomme Bescheid, auch wenn kein Funkgerät eingeschaltet ist.
Der Hintergrund ist zum einen Bastelei und Experimentierfreude. Zum anderen die Frage, wie man Funkamateure erreicht, wenn das Internet ausfällt. Für Notfunk existieren Konzepte über Orts- und Verbandsfrequenzen; was fehlt, ist die individuelle, persönliche Ansprache rund um die Uhr, ohne dafür dauerhaft auf einer Sprechfrequenz präsent zu sein.
Die Komponenten
1. Antenne und Empfänger
Eine Discone-Antenne mit RTL-SDR-Stick und Raspberry PI. Der Empfangsbereich deckt 10 m bis 70 cm ab, entscheidend sind hier 2m (ggf. 10m). Für diese und andere Anwendungen hängen insgesamt 4 SDRs an einem Pi V5.
2. Decodierung: OpenWebRX+
Auf dem Raspberry Pi läuft OpenWebRX+ mit aktiviertem Background Decoding. Damit werden APRS- und FT8-Nachrichten durchgehend decodiert, unabhängig davon, ob gerade jemand die Weboberfläche geöffnet hat.
Aktuelle Versionen können die decodierten Nachrichten an einen MQTT-Broker weiterreichen. Das ist der eigentliche Hebel: Aus einem geschlossenen Empfangssystem wird eine Datenquelle, die beliebige andere Anwendungen abonnieren können.
OpenWebRX+ ist für diesen Zweck nicht zwingend erforderlich. Dieselbe Aufgabe lässt sich mit Direwolf oder anderen Linux-SDR-Tools separat lösen – nur eben mit etwas Programmieraufwand. Ich nutze es, weil ich den SDR ohnehin für andere Dinge verwende und die Einrichtung niederschwellig ist.
3. Nachrichtenverteilung: MQTT-Broker
Als Broker dient Mosquitto, aktuell auf einer QNAP-NAS, kann aber auch freilich auf dem gleichen Raspberry laufen. Die Einrichtung ist in wenigen Minuten erledigt. Alle decodierten Nachrichten – APRS wie FT8 – laufen dort auf und stehen über Topics allen Rechnern im Netz zur Verfügung.
4. Regelwerk: n8n
n8n ist ein Werkzeug zur Prozessautomatisierung. In meinem Fall abonniert die Topics per MQTT und prüft jede Nachricht darauf, ob mein Rufzeichen als Empfänger eingetragen ist.
Mitgelesen wird alles: es ist durchaus interessant, was APRS-seitig in der Gegend unterwegs ist. Reagiert wird aber nur auf die Nachrichten, die mich betreffen. Diese werden angereichert und weitergeleitet:
- eine Nachricht per Chatbot an Telegram,
- ein Auftrag zur akustischen Signalisierung,
- eine Veröffentlichung in einem eigenen MQTT-Topic, das ausschließlich Nachrichten an mich enthält.
Das ließe sich ebenso gut selbst programmieren. Für den Einstieg und zum Experimentieren ist n8n aber praktisch, weil sich Workflows schnell umbauen lassen: Welche Daten interessieren, auf welche Nachrichten soll reagiert werden. Die Loggingmöglichkeiten und die einfach Anpassung sprechen für sich.
5. Anzeige: Display an der Wand
Ein Raspberry Pi Zero W hängt per HDMI an einem günstigen Display (etwa 60–70 €), das auch Ton ausgeben kann. Auf dem Pi läuft ein selbst geschriebener kleiner Server, der das dedizierte MQTT-Topic abonniert, die Nachricht auf der Linux-Konsole ausgibt und einen Ton abspielt.
Vorgesehen ist eine Farbcodierung – die ist freilich beliebig und je nach Geschmack:
| Farbe | Bedeutung | Status |
|---|---|---|
| Weiß | Alle Aktivitäten | umgesetzt |
| Rot | Direkter Ruf an mein Rufzeichen | umgesetzt |
| Grün | Ruf an einen befreundete Station | noch offen |
| Gelb | Warnungen | noch offen |
| Blau | Sonstige, mich selbst betreffende Aktivität | umgesetzt |
Betrieb
Alle Software-Komponenten ( OpenWebRX+, Mosquitto, n8n ) laufen in Docker-Containern. Bei dieser Anzahl unterschiedlicher Werkzeuge vereinfacht das Verwaltung und Orchestrierung erheblich und erlaubt den Betrieb auf einer Maschine – wenn man dies denn möchte. Zu allen genannten Komponenten gibt es reichlich Anleitungen im Netz.
Aktueller Stand
Überwacht werden derzeit 2 m APRS sowie FT8 auf 2 m und 10 m.
Bei FT8 genügt es, mein Rufzeichen voranzustellen, dann das eigene Rufzeichen und dahinter die QRG, über die man sprechen möchte. Oder einfach ein „Hallo!“:
DN9DML <eigenes Rufzeichen> <QRG>Der Ruf erscheint dann auf dem Wanddisplay, wird akustisch signalisiert und (solange Internet vorhanden ist) zusätzlich aufs Handy geschickt.
Ausblick
Der Pi Zero stellt sich aktuell etwas zu schwach heraus um neben der Textinformation auch eine Karte (OpenStreetmap) etc. anzuzeigen. Hier könnte es später mal ein Upgrade auf ein anderes Modell und etwas mehr Code geben um die Standortinformationen anzuzeigen (oder einfach das Map-Tool von OpenWebRx verwenden).
Weitere Ideen:
- Implementierung von MeshCore a) zum Empfang und Weiterleiten von Nachrichten b) Information über neue Kontaktversuche analog zu Telegram.
- Überwachung von FM Kanal (Audio) und Reaktion auf bestimmte Tonfolge (5-Tone) inkl. Audioaufnahme. „Whatsapp“-Sprachnachricht – nur eben via Radio
- Einbindung von Shelly für Lichteffekte in anderen Räumen
Fazit
Die Kette läuft durchgehend. Da der Stromverbrauch der beteiligten Geräte gering ist, bleibt sie auch bei Stromausfall über eine Pufferung realistisch betreibbar. Der Telegram-Zweig entfällt in diesem Fall, die lokale Signalisierung über Display und Ton funktioniert unabhängig vom Internet. Die Komplexität meiner Umsetzung …
Raspberry 5 -> Mosquitto (QNAP) -> n8n (QNAP) -> Raspberry Zero
… muss man ja nicht nachmachen: Wie schon erwähnt, das Ganze passt auch bequem auf einen Raspberry.
Damit ist das ursprüngliche Ziel erreicht: Ich bin per Funk persönlich ansprechbar, ohne dauerhaft auf einer Frequenz präsent sein zu müssen.