Remote Station: Lösungen im Überblick

In diesem Beitrag erhaltet ihr eine Übersicht über verschiedene Möglichkeiten, eure Station bequem von überall fernzusteuern.

Am kommenden Wochenende findet Europas größtes Amateurfunk-Event statt: die Ham Radio in Friedrichshafen am Bodensee. In diesem Jahr steht die Veranstaltung unter dem Motto „Remote Radio – Connecting the World“. Ein passender Anlass also, um einen genaueren Blick auf die verschiedenen Möglichkeiten zur hardwaretechnischen Realisierung einer Remote-Station zu werfen.

Motivation und rechtlicher Rahmen für den Remote-Betrieb

Es gibt viele Gründe, die Überlegung anzustellen, eine Remote-Station zu betreiben. Oft ist es der immer dichter werdende Störnebel am heimischen QTH, der den Funkbetrieb vor Ort zunehmend erschwert. In anderen Fällen erlaubt der eigene Wohnort, z.B. eine Mietwohnung, gar nicht erst die Errichtung geeigneter Antennenanlagen – sei es aus Platzgründen oder wegen baurechtlicher Einschränkungen. Umgekehrt kann das eigene QTH oder z.B. die Clubstation auch der ideale Standort für Funkbetrieb sein, den man gerne auch von unterwegs aus – etwa im Urlaub oder während einer Geschäftsreise – nutzen möchte.

Mit der Aktualisierung der Amateurfunkverordnung (AFuV) im Juni 2024 wurde der unbesetzte, fernbediente Betrieb ortsfester Amateurfunkstellen für Inhaber einer Zulassung der Klasse A nun eindeutig geregelt. Damit wurde nicht nur Rechtsklarheit geschaffen, sondern auch ein zukunftsweisender Schritt für moderne Betriebskonzepte im Amateurfunk getan.

Remote-Funk ohne eigene Station

Nur Empfang: WebSDR und Co.

Wer zunächst einfach nur herausfinden möchte, was empfangstechnisch an anderen Standorten möglich ist, findet in der folgenden Linkliste zahlreiche Möglichkeiten für den kostenlosen Online-Empfang. Die Stationen unterscheiden sich unter anderem in der genutzten Hardware, den verfügbaren Bändern, den unterstützten Betriebsarten sowie dem jeweils bereitgestellten Webinterface.

  • www.receiverbook.de: OpenWebRX, WebSDR und KiwiSDr mit Filtermöglichkeiten nach Frequenzbereich
  • websdr.org: Weltweite WebSDR mit Angaben zu möglichen Frequenzbereichen, verwendeter Hardware und Antennen
  • kiwisdr.com: Öffentlich verfügbare KiwiSDR
  • rx-tx.info: Mehr als 1900 gelistete SDR-Empfänger mit umfangreichen Filtermöglichkeiten
Screenshot von www.receiverbook.de

Receiverbook listet OpenWebRX, WebSDR und KiwiSDR auf

Sendebetrieb über fremde Remote-Stationen

Wer nicht nur empfangen, sondern auch senden möchte, jedoch (noch) nicht über eine eigene Remote-Station verfügt, kann auf die Infrastruktur anderer zurückgreifen. Einige Funkvereine und kommerzielle Anbieter stellen ihre Remote-Stationen zur Mitnutzung bereit – entweder exklusiv für Mitglieder oder gegen eine Gebühr auch für externe Nutzer.

Die Kostenmodelle variieren: Üblich sind monatliche oder jährliche Grundgebühren mit unterschiedlich großem Funktionsumfang, ergänzt durch Airtime-Gebühren je nach Nutzungsdauer. Wichtig: Um eine solche Station legal zu nutzen, benötigt man eine gültige Amateurfunkgenehmigung – entweder aus dem betreffenden Land oder eine anerkannte Gastlizenz, abhängig vom Standort der Remote-Station. Remote-Stationen finden sich u.a. hier:

Hinweis: Wer Links zu weiteren in Deutschland betriebenen oder öffentlich zugänglichen Remote-Stationen kennt, ist herzlich eingeladen, diese in den Kommentaren zu teilen – wir ergänzen den Beitrag dann gerne.

Der Weg zur eigenen Remote-Station

Wer eine eigene Remote-Station betreiben möchte, sollte das Vorhaben sorgfältig planen und sich zunächst über einige grundlegende Punkte im Klaren sein. Folgende Fragen helfen bei der Strukturierung und technischen Umsetzung:

  • Welche Betriebsarten sollen unterstützt werden? Nur klassische Sprach-QSOs oder auch digitale Betriebsarten wie CW oder FT8?
  • Wie soll die Bedienung erfolgen? Über die Bedieneinheit des Funkgerätes, die originale Gerätesoftware per Fernzugriff, eine Weboberfläche oder per App?
  • Welche Komponenten sollen fernbedient werden? Nur der Transceiver oder zusätzlich Antennenschalter, Rotorsteuerung, PA, Filtereinheiten, Relais usw.?
  • Wie wird die Sicherheit gewährleistet? Überwachung von Betriebszuständen wie Temperatur, VSWR, Stromaufnahme; automatische Abschaltungen bei Fehlerzuständen; ggf. Kameras zur visuellen Kontrolle.
  • Wer soll die Station nutzen dürfen? Nur man selbst oder auch ausgewählte befreundete Funkamateure – z. B. über Benutzerkonten mit Zugriffsbeschränkung?
  • Wie erfolgt der Zugang zur Station? VPN, dynamisches DNS, feste IP? Wie wird der Zugang abgesichert (z. B. mit 2-Faktor-Authentifizierung)?
  • Wie ist die Internetverbindung am Standort? Reicht die Bandbreite für Audio-/Datenströme? Gibt es ausreichend Upload-Speed und stabile Verbindung ohne große Latenz?
  • Welche Stromversorgung steht zur Verfügung? Absicherung gegen Spannungsausfall (USV), Überspannungsschutz, eventuell sogar Notstromversorgung? Abschaltung der Geräte wie Transceiver, PA oder Antennenumschalter bei Nichtnutzung per Fernzugriff – z. B. über WLAN-Steckdosen, Relaismodule oder intelligente Stromverteiler.
  • Welche gesetzlichen Vorgaben sind zu beachten? Einhaltung der AFuV, EMV-Grenzwerte, Standortmeldung, ggf. Genehmigung von Dritten (z. B. bei Mietobjekten)?

Im Folgenden zeigen wir euch einige Möglichkeiten auf, wie ihr euren Transceiver remotefähig machen könnt.

Transceiver mit eingebauter Remote-Funktion (z. B. Icom, FlexRadio, Elecraft)

Moderne Transceiver der Marken Icom, FlexRadio und Elecraft bieten bereits integrierte Fernsteuermöglichkeiten, teilweise sogar ohne zusätzlich benötigten Server. Die Geräte lassen sich direkt über ihre LAN-Schnittstelle ins heimische Netzwerk einbinden und dort von jedem Gerät mit passender Software fernsteuern. Das ist besonders praktisch, wenn man z. B. im Sommer lieber aus dem Garten funkt, statt in der Funkbude zu sitzen.

Möchte man auch außerhalb des eigenen Netzwerks auf die Station zugreifen, gibt es zwei Möglichkeiten:

  • Für den privaten Zugriff (z. B. vom Urlaubsort aus) empfiehlt sich ein VPN-Tunnel, der sicheren Fernzugriff erlaubt.
  • Für den Zugriff durch andere Funkamateure muss der Router entsprechend konfiguriert werden – es sind Portfreigaben notwendig, und die Station sollte über Dienste wie DynDNS unter einer festen Adresse erreichbar sein.

Bei Icom kommt die kostenpflichtige Software RS-BA1 zum Einsatz. Die Fernsteuerung kann mit dem optionalen Remote Encoder RC-28 erweitert werden, der per USB mit dem Steuer-PC verbunden wird. Er bietet ein großes VFO-Rad, zwei Funktionstasten und eine integrierte PTT-Taste.

Remote-Betrieb mit Transceivern der Marke Icom, Quelle: www.icomjapan.com

Für Apple-Nutzer gibt es mit SDR-Control Mobile von Marcus DL8MRE, eine ebenfalls kostenpflichtige, aber leistungsstarke App für iPhone und iPad, mit der sich Icom-Transceiver steuern lassen.

Hardwarebasierte Remote-Lösungen (Remoterig, RigPi, Station Controller)

Einen etwas anderen Ansatz verfolgt RemoteRig: Hier wird die Steuereinheit des Transceivers physisch abgesetzt betrieben – das sorgt für echtes Funkfeeling, fast wie im heimischen Shack. Voraussetzung dafür ist, dass der jeweilige Transceiver über ein absetzbares Bedienteil verfügt und die Kommunikation zwischen HF-Teil und Bedienteil seriell erfolgt.

Remote-Betrieb eines Kenwood TS-480 mit Remote-Rig, Quelle: www.remoterig.com

Ein Nachteil dieser Lösung: Die Fernbedienung durch Drittpersonen ist nur möglich, wenn auch sie über ein kompatibles Bedienteil und RemoteRig-Hardware verfügen.

RemoteRig bietet neben dem Hauptsystem auch weitere fernsteuerbare Komponenten an – darunter Antennenumschalter, Rotorsteuerungen, PA-Steuerungen und vieles mehr. Eine Übersicht kompatibler Geräte sowie technische Details finden sich auf der offiziellen Website: www.remoterig.com

Remote-Rig RRC-1258MkII, Quelle: www.remoterig.com

Eine ausführliche Videoreihe zu RemoteRig bietet Michael DD0UL, auf seinem YouTube-Kanal DD0UL QTC.

Wie der Name schon vermuten lässt, basiert RigPi™ auf einem Raspberry Pi, auf dem eine speziell entwickelte Server-Software läuft. Durch verschiedene Hardware-Erweiterungen, die sich einfach auf den Pi aufstecken lassen, kann das System individuell an die Anforderungen des verwendeten Transceivers angepasst werden – beispielsweise durch ein Audio-Board, einen CW-Keyer und weitere Module.

RigPi Station Server, Quelle: rigpi.net

Das kostenpflichtige Software-Image liegt aktuell in Version 3 vor, ein umfangreiches Update auf Version 4 ist bereits angekündigt. Derzeit kann das Image noch über den MFJ-Webshop erworben werden. Auch nach Abschaltung des Shops soll es weiterhin verfügbar bleiben. Der passende CW-Keyer kann hier bezogen werden.

Weitere Informationen zu RigPi findet ihr unter rigpi.net.

Bei umfangreichen Remote-Stationen, z.B. mit mehreren Antennensystemen an exponierten Standorten, bietet der Sierra Radio Systems Station Controller von George KJ6VU eine modulare und robuste Lösung. Die Hardware-Module sind für die Montage auf Hutschienen konzipiert und kommunizieren über ein gemeinsames Bussystem. Je nach Bedarf lässt sich das System flexibel erweitern.

Zur Verfügung stehen unter anderem Relais- und GPIO-Module, koaxiale Antennenumschalter, Module zur Spannungs- und Leistungsüberwachung, sowie ein zentrales Kontrollboard auf Raspberry-Pi-Basis.

Die Überwachung und Fernsteuerung erfolgt bequem im Webbrowser über eine grafische Oberfläche auf Basis von Node-RED.

Mehr Informationen zum Station Controller erhaltet ihr unter www.packtenna.com/station-controller.html.

Softwarelösungen für den Remote-Betrieb

Im Folgenden listen wir euch vier softwarebasierte Lösungen auf, mit denen sich Funkstationen bequem über das Internet per Webbrowser fernsteuern lassen – teils kostenlos, teils kostenpflichtig. Je nach Lösung lassen sich Audio, CW und Digimodes sowie teilweise auch Rotoren und die Stromversorgung steuern.

SimpleHRR auf einem RaspberryPi mit Icom IC-7300, Quelle: simplehrr.com
  • RemoteTX®: Kostenpflichtige Komplettlösung für TRX (Icom, Yaesu, Elecraft), Rotor (Yaesu) und Stromversorgung – Sprache, CW und Digimodes per Browser über Smartphone, Tablet oder PC.
  • Web Radio Control (WRC): Kostenpflichtige Weblösung zur Steuerung kompatibler Icom-Transceiver – inklusive Audio, CW-Keying und CAT-Funktionen direkt im Browser, ohne zusätzliche Software.

Fazit

Es gibt bereits zahlreiche Lösungen, teils kostenlos, teils kostenpflichtig, mit denen sich die eigene Amateurfunkstation remote betreiben lässt. Moderne Transceiver von Herstellern wie Icom, FlexRadio oder Elecraft benötigen meist nur eine Verbindung zum Internet-Router und einige Konfigurationen für den Remote-Betrieb. Aber auch ältere Geräte lassen sich durch den Einsatz kleiner Computer wie dem Raspberry Pi, kombiniert mit Soundkarte und CAT-Steuerung, für den Remote-Betrieb nachrüsten. Wer das volle Funkerlebnis erhalten möchte, kann mit RemoteRig™ sogar über die originale Bedieneinheit seines Transceivers funken.

Dieser Beitrag gibt einen ersten Überblick und stellt nur eine kleine Auswahl verfügbarer Lösungen vor. In kommenden Beiträgen werden wir einzelne Systeme detaillierter vorstellen.

Remote oder nicht?

Macht mit bei unserer kurzen Umfrage.

📡 Seid ihr bereits Remote QRV? Wenn ja, wie?
11 votes · 12 answers
×

Kennt ihr weitere Möglichkeiten des Remote-Betriebes, die wir in diesem Beitrag noch nicht erwähnt haben? Dann schreibt sie gerne in die Kommentare unter diesem Beitrag oder diskutiert sie mit uns in unserer Telegram- oder WhatsApp-Gruppe.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘

M17: So werdet ihr QRV – Teil 2 (Hardware/Software)

Wie ihr in M17 mit einer Kombination aus Hardware und Software, oder sogar rein softwarebasiert, QRV werdet, zeigen wir in diesem Beitrag.

Im ersten Teil unserer Beitragsreihe über M17 haben wir euch bereits einige Möglichkeiten vorgestellt, wie ihr mit einem Funkgerät im M17-Modus QRV werden könnt. Falls ihr den Beitrag noch einmal nachlesen möchtet, findet ihr ihn hier.

Im zweiten Teil soll es nun um eine Kombination aus Hardware und Software gehen. Außerdem betrachten wir reine Softwarelösungen, mit denen ihr ebenfalls in M17 QRV werden könnt. Grundsätzlich unterscheiden wir dabei zwischen:

  • Ist nur M17-Empfang (RX) möglich, auch Sendebetrieb (TX) oder sogar beides (TRX)?
  • Wird nur Sprache im Stream Mode unterstützt, nur Daten wie Textnachrichten oder APRS im Packet Mode oder beides?
  • Für welches oder welche Betriebssysteme ist die Lösung geeignet?
  • Handelt es sich um eine Kombination aus Hardware und Software oder um eine reine Softwarelösung?

Mobilinkd TNC4 / NucleoTNC (TRX, Sprache: iOS, Android)

Das Mobilinkd TNC4 unterstützt das Senden und Empfangen von M17 über eine iOS- oder Android-App, die sich per Bluetooth Low Energy (BLE) mit dem TNC verbindet. Das TNC selbst wird an die Datenbuchse eines Funkgeräts angeschlossen. Wichtig ist dabei, dass diese Buchse ein direkt vom Demodulator des Empfängers stammendes Audiosignal – sogenanntes „Flat Audio“, auch als „Baseband Audio“ oder „Diskriminator-Ausgang“ bekannt – bereitstellt.

Auch für das NucleoTNC ist eine experimentelle Firmware verfügbar, die M17 unterstützt. Beide Lösungen richten sich an Funkamateure, die kompakte und portable Möglichkeiten zur digitalen Betriebsart suchen.

Mobilinkd TNC4, Quelle: Mobilinkd TNC4 User’s Guide

Mehr Informationen findet ihr unter store.mobilinkd.com.

DroidStar (TRX, Sprache und Daten: Android, iOS, Windows, Linux und Mac)

DroidStar von Rohith VU3LVO ist eine reine Softwarelösung, die auf einer Vielzahl von Plattformen läuft. Unterstützt werden Android, iOS, Windows, Linux und macOS. Die Anwendung ermöglicht die Verbindung zu M17-Netzwerken über MREF- oder URF-Räume und unterstützt Sprachübertragung (Senden und Empfangen) und neuerdings sogar auch den Versand und Empfang von Textnachrichten über M17.

Wenn ihr Interesse an einer Installationsanleitung speziell für iOS-Geräte habt, lasst es uns gerne in den Kommentaren wissen!

Mehr Informationen und den Download findet ihr auf der offiziellen Projektseite bei GitHub: github.com/nostar/DroidStar

mvoice (TRX, Sprache: Linux)

mvoice von Thomas N7TAE ist eine grafische, rein softwarebasierte M17-Anwendung für Linux. Die Software kann sich mit M17-Reflektoren verbinden und unterstützt auch Routing. Am besten funktioniert mvoice mit einem USB-Headset mit Mikrofon, das direkt an einem Linux-Rechner wie zum Beispiel einem Raspberry Pi angeschlossen wird. Die Audio-Ein- und Ausgabe erfolgt über die Standardgeräte von Pulseaudio oder ALSA.

Mehr Informationen und die Software findet ihr unter github.com/n7tae/mvoice.

m17-tools (TRX, Sprache: Windows, Linux und Mac)

m17-tools umfasst mehrere C++-basierte Werkzeuge zur Erzeugung, Verarbeitung und Weiterleitung von M17-Signalen. Dazu gehören unter anderem:

  • m17-mod: Wandelt ein Audiosignal in ein M17-Basisbandsignal um
  • m17-mod-gui: Grafische Bedienoberfläche für m17-mod
  • m17-demod: Dekodiert ein M17-Basisbandsignal zurück in ein Audiosignal
  • m17-gateway-link_mod: Verbindet sich mit dem G4KLX M17Gateway und setzt die von dort empfangenen Pakete in ein M17-Basisbandsignal um
  • m17-gateway-link_demod: Sendet ein M17-Basisbandsignal an ein verbundenes G4KLX M17Gateway
m17-mod-gui unter Windows, Quelle: github.com/M17-Project/m17-tools

Eine detaillierte Anleitung zur Installation und Nutzung findet ihr unter github.com/M17-Project/m17-tools.

m17-texting (TX, Daten: Linux)

m17-texting ist eine grafische Anwendung zum Senden von Textnachrichten über M17 im Packet Mode. Die Software ist in C geschrieben und erzeugt M17-Basisbandsignale, die anschließend über ein geeignetes Interface wie dem Digirig Mobile in Verbindung mit einem analogen Funkgerät mit entsprechendem Datenport wie dem Yaesu FTM-6000 übertragen werden können.

Grafische Bedienoberfläche von m17-texting

Weitere Informationen findet ihr unter github.com/M17-Project/m17-texting.

m17-fme (TRX, Sprache, Daten: Linux)

m17-fme ist eine eigenständige Softwarelösung zum Kodieren und Dekodieren von M17-Sprach- und Datenpaketen. Sie eignet sich sowohl zum Erzeugen als auch zum Analysieren von M17-Signalen und kann in bestehende Anwendungen integriert oder als eigenständiges Werkzeug genutzt werden.

Beispielhafter Empfang eines M17-Sprachsignal unter m17-fme, Quelle: github.com/lwvmobile/m17-fme

Weitere Informationen findet ihr unter github.com/lwvmobile/m17-fme.

SDR-Software

Auch im Bereich der SDR-Software gibt es spannende Möglichkeiten, M17 zu empfangen, zu dekodieren oder sogar zu senden. Nachfolgend nennen wir drei Beispiele, die entweder von Haus aus oder durch Erweiterungen für M17-Sprache und -Daten geeignet sind. In künftigen Beiträgen werden wir diese Softwarelösungen noch genauer vorstellen.

  • SDRangel (TRX, Sprache und Daten: Windows, Linux und Mac)
  • SDR++ mit M17 Decoder (RX, Sprache: Windows, Linux, Mac, BSD)
  • OpenWebRX Plus mit m17-cxx-demod (RX, Sprache: Linux)

GNU Radio mit gr-m17 (TRX: Linux)

gr-m17 ist eine Sammlung von GNU Radio-Modulen zur Modulation und Demodulation von M17-Basisbandsignalen. Die Bausteine können direkt in GNU Radio eingebunden werden und ermöglichen so die Verarbeitung von M17-Signalen innerhalb eigener Signalflussdiagramme.

Im Repository sind auch mehrere Beispielprojekte enthalten, darunter ein einfacher „Papagei“, der empfangene Signale wiederholt. Außerdem wird gezeigt, wie sich ein RTL-SDR-Stick zum Empfang und ein PLUTO-SDR für den Sendebetrieb nutzen lassen.

Hinweis: gr-m17 wurde für GNU Radio Version 3.10 entwickelt. In neueren Versionen kann es zu Einschränkungen oder Inkompatibilitäten kommen. Zudem verwendet gr-m17 noch nicht die neue libm17-Bibliothek.

Beispiel eines M17-Papagei, Quelle: github.com/M17-Project/gr-m17

Mehr Informationen findet ihr unter github.com/M17-Project/gr-m17.

rpitx (TX, Daten: Linux)

rpitx ist ein Softwareprojekt, das es ermöglicht, HF-Signale direkt über den GPIO-Pin eines Raspberry Pi zu erzeugen. Es nutzt dabei keine klassische Funkhardware, sondern wandelt digitale Daten direkt in ein HF-Signal um, das über eine einfache Drahtantenne abgestrahlt werden kann.

Tomasz SP5LOT demonstriert in einem Video, wie sich mit rpitx Texte im M17-Format aussenden lassen. Die ausgesendeten Daten werden anschließend mit einem SDR-Stick empfangen, in GNU Radio dekodiert und in der Konsole angezeigt.

Mehr Informationen zu rpitx findet ihr unter github.com/F5OEO/rpitx.

M17_3310 (TRX, Daten)

Wer noch eines der legendären Nokia 3310 oder 3330 in der Schublade hat und gerne bastelt, kann es durch Austausch des Mainboards in einen M17-Daten-Sender und -Empfänger verwandeln. Die Nachrichten werden direkt über die originale Tastatur des Nokia-Handys eingegeben und mithilfe eines SA868S-Funkmoduls im 70 cm-Amateurfunkband ausgesendet. Empfangene und dekodierte Datenpakete erscheinen auf dem Display des Geräts.

Versenden einer Nachricht mit einem modifizierten Nokia 3310, Quelle: m17project.org

Mehr Informationen findet ihr unter github.com/M17-Project/M17_3310.

libm17 Software-Bibliothek

Wer selbst eine Anwendung für M17 programmieren möchte, findet mit libm17 eine Software-Bibliothek. Sie ist in C geschrieben und enthält alle Komponenten wie Faltungs- und Golay-Kodierer, Bit-Interleaver, Fehlerkorrektur und Rufzeichenkodierung, die im Protokoll für Stream- und Packet Modi beschrieben sind.

Screenshot von github.com

libm17 Github-Seite

Alle weiteren Informationen zu libm17 findet ihr unter github.com/M17-Project/libm17

Ein ungewöhnliches, aber spannendes Beispiel für die Verwendung der libm17-Softwarebibliothek ist gba_m17. Dabei handelt es sich um einen M17-Datenkodierer und -dekodierer, der auf einem Game Boy Advance oder in einem entsprechenden Emulator läuft. Auch wenn der GBA längst nicht mehr hergestellt wird und der praktische Nutzen begrenzt ist, demonstriert dieses Projekt eindrucksvoll, wie vielseitig libm17 einsetzbar ist. Es soll dazu inspirieren, ältere Elektronikgeräte, die vielleicht noch in der ein oder anderen Schublade liegen, kreativ neu zu nutzen.

libm17 auf einem GameBoy Advance, Quelle: github.com/sp5wwp/gba_m17

m17-cxx-demod Software-Bibliothek (TRX, Sprache: Windows, Linux)

m17-cxx-demod ist ein in C++ geschriebener Software-Modulator und Demodulator für M17-Signale. Er ermöglicht das Dekodieren von M17-Audio-Streams, beispielsweise aus einem Diskriminator-Ausgang oder einer SDR-Quelle. Die Software kann als eigenständiges Kommandozeilenwerkzeug verwendet oder in andere Anwendungen eingebunden werden und ist besonders für Embedded- und Low-Power-Systeme wie dem Mobilinkd TNC4 oder NucleoTNC interessant.

Mehr Informationen und den Quellcode findet ihr unter github.com/mobilinkd/m17-cxx-demod.

Im ersten und zweiten Beitrag haben wir euch bereits einige Möglichkeiten aufgezeigt, wie ihr in M17 QRV werden könnt – von (fast) schlüsselfertigen Lösungen bis hin zu spannenden, experimentellen Ansätzen für Bastler und Entwickler.

Uns interessiert nun, wo ihr steht: Habt ihr M17 schon ausprobiert? Nutzt ihr bereits Hardware, Software oder SDR-Lösungen? Oder beobachtet ihr die Entwicklung noch mit Interesse von außen?

🔍 Hast du schon Erfahrungen mit M17 gemacht?
18 votes · 33 answers
×

Seid ihr an einer der Lösungen genauer interessiert und wüsstet gerne mehr darüber? Schreibt es uns gerne in die Kommentare unter diesem Beitrag oder diskutiert mit uns in unserer Telegram- oder WhatsApp-Gruppe darüber.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘

APRS-IS Wetterstation mit der LaCrosse WS2300

In diesem Beitrag beschreibe ich, wie die Wetterdaten einer LaCrosse WS2300 Wetterstation zusätzlich an das APRS-IS Netzwerk gesendet werden können.

Das Wetter in Ostfriesland ist oft wechselhaft und meist windig, geprägt von milden Sommern, kühlen Wintern und häufigen Regenschauern. Die Nähe zur Nordseeküste sorgt generell für ein maritimes Klima. Als Technik-affiner Funkamateur finde ich es sehr spannend, die Wetterdaten selbst zu erfassen. Damals kaufte ich mir dazu eine gebrauchte LaCrosse WS2300 Wetterstation, da diese in der APRS-Gemeinschaft oft verwendet wurde. Dieses lag nicht zuletzt daran, dass zahlreiche APRS-Hardware den direkten Anschluss und somit die Übertragung der Wetterdaten ins APRS-Netzwerk ermöglichten.

So betrieb ich die Wetterstation einige Jahre an meinem ehemaligen QTH am Bodensee, bevor sie nach dem Umzug in einem Karton verschwand.

Otmar DJ1OF bei der Installation der Wetterstation am alten QTH JN47MR in 2016

Da die Wetteranlage meines Vaters DL9BGG dem rauen Ostfriesischen Wetter auf Dauer nicht gewachsen war entschlossen wir uns im Mai diesen Jahres kurzerhand, meine alte Wetterstation zu testen und an seinem QTH zu installieren.

Ein erster Test im Innenraum wurde erfolgreich bestanden und so Stand einer Installation auf dem Hausdach nichts mehr im Wege.

Da mein Vater keinen APRS-Sender betreibt, ich die Daten aber gerne ins APRS-Netzwerk spielen wollte, um mir auch in Singapur ein Bild über das aktuelle Wetter in Singapur machen zu können, suchte ich nun nach einem Weg, die Daten direkt ins APRS-IS Netzwerk zu senden.

Da ich das Rad, auch aus Zeitgründen, nicht komplett neu erfinden wollte und ich mir sicher war, dass dieses in etlichen Projekten bereits realisiert wurde, recherchierte ich im Internet nach geeigneten Lösungen. Nach nur kurzer Zeit wurde ich im Internet fündig und musste mir die einzelnen Bausteine nur gemäß meiner Konfiguration zusammensetzen.

Der slowenische OM Andrej S55MA beschreibt in seinem HAM Blog in dem Beitrag „La Crosse WS2300, WS2307 series APRS with Xastir“ ein vom ihm geschriebenes Script, welches das Programm Fetch2300 nutzt und die Daten der Wetterstation zunächst in eine temporäre Textdatei schreibt. Fetch2300 kommt als Teil des open2300 Projektes von dem Dänen Kenneth Lavrsen, welches nicht mehr weiterentwickelt wird. Das Script von Andrej S55MA öffnet dann diese Textdatei um sie zu lesen, wertet die Daten dann aus und schreibt sie in einen Textstring, der von der Linux APRS-Software Xastir gelesen werden kann. Sein Script stellt außerdem einen Webserver bereit, mit dem sich Xastir dann verbinden kann, um sich die Textzeile mit den Wetterdaten zu holen. In seinem Blog beschreibt er außerdem detailliert die dazu erforderlichen Installationsschritte.

Xastir erfordert jedoch die Verwendung einer grafischen Oberfläche (Gui). Da ich das Ganze auf einem Raspberry Pi nebenher laufen lassen wollte, auf dem bereits ein OpenWebRX+ ohne grafische Oberfläche läuft und ich die anderen Funktionalitäten einer vollen APRS-Software in meinem Fall nicht benötige, suchte ich nach einer anderen Möglichkeit. OpenWebRX+ verwendet DireWolf von WB2OSZ, um die mit dem SDR empfangenen APRS-Pakete zu decodieren und ins APRS-IS Netzwerk weiterzuleiten. Was lag also näher, eine entsprechende Bake für die Wetterdaten zu konfigurieren?

Leider führte mich auch das in eine Sackgasse. Zwar konnte ich die Wetterdaten als Bake aussenden, jedoch nicht in dem Bakenformat, um sie als Wetterstation zu erkennen. Eine neue Lösung musste also her. Ich entschied mich kurzerhand, das Script von Andrej S55MA so umzuschreiben, dass es statt der Bereitstellung eines Webservers, über den die Daten abgerufen werden, die Daten gleich selbst ans APRS-IS Netzwerk sendet. Glücklicherweise fand sich unter dem Titel Send APRS objects or telemetry via Bash auch für diese Aufgabe eine passende Anleitung in Andrej’s Blog. Ich musste also nur seine beiden Blog Einträge kombinieren und schon hatte ich Erfolg.

Wetterdaten von DL9BGG-13 auf aprs.fi

Screenshot von aprs.fi

DL9BGG-13 auf aprs.fi

Die Anpassung meines Scriptes basiert auf Version 1.6 seines Scriptes. Im Eingangsbereich des Scriptes konfigurieren wir zunächst unser Rufzeichen, die zu verwendende SSID, den dazugehörigen Passcode, den Längen- und Breitengrad der Wetterstation im DDM-Format (Dezimal-Minuten), sowie optional einen statischen Kommentar (z.B., welche Wetterstation verwendet wird). Außerdem definieren wir noch, an welchen APRS-IS Server gesendet werden soll, dessen Port und das Intervall in Sekunden, indem gesendet werden soll. Schließlich benötigt das Script noch den vollständigen Pfad zur open2300 Konfigurationsdatei. Abweichend zu Andrej’s Anleitung habe ich diese in dem Verzeichnis „/usr/local/etc/“ liegen.

#DEFINE VARIABLES
callsign="xxxxxx"
aprsssid="13"
passcode="xxxxx"
lat="0000.00N"
long="00000.00E"
comment="LaCrosse WS2300"
server="euro.aprs2.net"
port="14580"
interval="60"
ws2300config="/usr/local/etc/open2300.conf"

Das Auswerten und schreiben der einzelnen Werte ist identisch zu Andrej’s Script mit dem Unterschied, dass ich zusätzlich noch die Tendenz und die Vorhersage auswerte und später mit in den Kommentar schreibe.

tendency=$(cat "$fetch_path" | grep -oP 'Tendency\s+\K\S+')
forecast=$(cat "$fetch_path" | grep -oP 'Forecast\s+\K\S+')

Interessanter wird es jetzt beim Zusammenbau des Bakenstrings. Der zusammengebaute Bakentext mit den Werten sieht dann beispielhaft so aus:

DL9BGG-13>APN000,TCPIP*,qAC,T2PRT:@025940z5336.60N/00709.97E_157/009g...t068r000p000P...h71b10544LaCrosse WS2300, Tendency: Falling, Forecast: Rainy

Schließlich starte ich das Script einfach durch einen cronjob, wenn der Raspberry Pi hochfährt. Führt dazu den Befehl sudo crontab -e aus und ergänzt in einer neuen Zeile:

@reboot bash /usr/local/sbin/wxdata.sh &

Interessierte können mein modifiziertes Script hier herunterladen.

Linux-Script: WS2300 Wetterdaten an APRS-IS Senden

#This script reads weather data via fetch program which is part of Open2300 suite written by Kenneth Lavrsen (http://www.
#lavrsen.dk/foswiki/bin/view/Open2300/WebHome).
#It outputs the right data needed to feed Xastir for APRS weather reports. The scripts utilizes Ncat utility as server to
#serve the fetched output to Xastir.
#Fetched Data is pushed to Ncat server and then to Xastir. (Fetched data -> Ncat server -> Xastir)
#Ncat is part of Nmap, get it by installing Nmap.
#This script should work for LaCrosse weather stations, WS23xx series. Testing was done with WS2307.
#Written by S55MA and S56IUL, May 2016
#Origin Source: https://s55ma.radioamater.si/2016/05/03/la-crosse-ws2300-ws2307-series-aprs-with-xastir/

# Modified by DG1BGS/9V1LH, 23rd June 2024
# Removed the web server. APRS data is now sent directly to the APRS-IS network using ncat.
# Please update the variables in the section below.
# For more information, visit dl-nordwest.com

Größe: 12 kB
Version: 2024-07-23

Tipp: Vergabe von eindeutigen Com-Port Namen unter Linux

Um sicherzustellen, dass einem externen Gerät unter Linux immer der gleiche Com-Port zugewiesen wird, kann man externen Geräten eindeutige Namen zuweisen. In meinem Fall habe ich in dem Verzeichnis /etc/udev/rules.d eine Datei mit dem Namen 99-usb-serial.rules angelegt und die folgenden Zeilen eingefügt:

#Weather station open2300
#ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable
SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", SYMLINK+="ttyWX"

Die Vendor- und Product-ID eures externen Gerätes erhaltet ihr nach Eingabe des Befehls lsusb. In meinem Fall erhalte ich nach Eingabe des Befehls u.a. die folgende Ausgabe:

Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable

Ab dem nächsten Neustart des Rechners wird der Wetterstation in diesem Beispiel jetzt immer der Com-Port /dev/ttyWX zugeordnet, den ich auch in der open2300.conf gesetzt habe.

Fazit

Das Projekt war kurzweilig und hat viel Spaß gemacht, da sich nach nur kurzer Zeit ein Erfolg eingestellt hat. Durch die gute Programmierarbeit und Dokumentation von Andrej S55MA war es sehr einfach, das Gewünschte entsprechend der eigenen Umgebung zu implementieren. An dieser Stelle meinen herzlichen Dank an alle, die ihre Projekte für andere zur Verfügung stellen und dokumentieren.

Durch das übermitteln der Wetterdaten an das APRS-IS Netzwerk sind diese jetzt nicht nur lokal verfügbar, sondern auch von jedermann weltweit abrufbar. Und obendrein erhält man auf aprs.fi noch eine statistische Darstellung der Wetterdaten.

Ich habe auch schon Ideen für künftige Erweiterungen: Die Wetterdaten könnten zusätzlich an einen MQTT-Broker gesendet werden, um sie auch an andere Stelle auszuwerten und darzustellen. Ggf. wäre das auch ein tolles Projekt für ein Wetterdisplay mit ePaper-Display. Außerdem könnte man die APRS-Baken zusätzlich durch den Einsatz eines kleinen Funkmoduls auch über VHF lokal abstrahlen und oder oder sie für eine LoRa-Telemetriebake nutzen.

Betriebt ihr auch eine eigene Wetterstation und nutzt die Daten nicht nur für euch selber? Wenn ja, berichtet gerne in den Kommentare unter diesem Beitrag über euer Projekt oder diskutiert es mit uns in unserer Telegram- und oder WhatsApp-Gruppe. Eventuell habt ihr ja auch Lust, euer eigenes Projekt hier mal vorzustellen.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘

Unser Besuch auf der Ham Radio 2024

Lest in diesem Beitrag über unseren Impressionen vom Besuch der diesjährigen Ham Radio.

Am 29. Juni machten wir, Otmar DJ1OF, und ich, Stephan DG1BGS/9V1LH, uns bei strahlendem Sonnenschein mit dem Katamaran von Konstanz auf den Weg zur Ham Radio 2024 in Friedrichshafen. Im Shuttle-Bus trafen wir bereits viele Funkamateure, darunter den bekannten DXpeditionär Mac JA3USA.

Mit dem Katamaran ging es von Konstanz nach Friedrichshafen

An der Pinnwand war ich überrascht, dass Singapur bereits mit zwei Pins vertreten war. Eine Rückfrage in der Singapur Ham-Telegram-Gruppe ergab, dass tatsächlich zwei meiner Funkkollegen aus meiner neuen Heimat vor Ort waren.

Die erste Flohmarkthalle (Halle A2) war im Vergleich zu meinem letzten Ham Radio-Besuch deutlich luftiger. Wir machten am Flohmarktstand vom OV A48 Pfullendorf halt. Dessen OVV Thomas DL2GTS feierte einen runden Geburtstag und gab Gratulanten ein Bier aus. An dieser Stelle noch einmal alles Gute vom Team DL-Nordwest. Der Flohmarkt war wie gewohnt: alte Funktechnik, Röhren und Bücher, Bausätze, kommerzielle Funktechnik, PCs und PC-Komponenten, Mess- und Löttechnik usw.

Der Flohmarkt in Halle A2 war eher luftig

Leider schafften wir es zeitlich nur bis zur Hälfte der ersten der beiden Flohmarkthallen, denn nun war es Zeit für ein paar Vorträge. Zunächst nahmen wir an der Session „KI Applikationen für DV – Übersicht, Diskussion und Zukunftsaussichten“ teil, geleitet von Jochen DL1YBL. Das TetraPack-Team sprach über die neuen Möglichkeiten der Vernetzung von Tetra TMO. Die Präsentation erfolgte auf Englisch durch Elliott 2E0YCA und wurde von Ralph DK5RAS ins Deutsche übersetzt. Die Präsentation kann hier heruntergeladen werden. Mehr Informationen über das Projekt gibt es zudem hier.

Vortrag über das TetraPack TMO-System

Der Hauptprogrammierer Artöm (Artem) R3ABM/DL5ABM verkündete Freibier am BrandMeister-Stand zum Anlass ihres zehnjährigen Jubiläums, was mit großem Applaus gewürdigt wurde. Schließlich referierte Jochen DL1YBL über seine Experimente mit Künstlicher Intelligenz im Amateurfunk und rief zur Bildung einer Arbeitsgruppe auf. Interessenten können sich per Email bei ihm melden.

Vortrag über Künstliche Intelligenz im Amateurfunk

Michael DF4WX referierte über „Remotebetrieb nach der neuen Amateurfunkverordnung – rechtliche und technische Grundlagen„. Der voll besetzte Vortragsraum und die zahlreichen Wortmeldungen der Zuhörer zeugten vom großen Interesse. Es wurden die neue Gesetzgebung und technische Tipps zur Umsetzung einer eigenen Station besprochen.

Danach besuchten wir die Halle A1 mit den kommerziellen Ausstellern. ICOM zeigte die bereits auf der Dayton präsentierten Komponenten des kommenden Konzeptmodells zum 60. Jahrestag sowie eine Ausstellung der Funktechnik der vergangenen 60 Jahre. Der Kenwood-Stand fiel eher mickrig aus und es gab keine neuen Informationen zum kommenden Mobilfunktransceiver (Tribander). Yaesu präsentierte ihr komplettes Spektrum an aktuellen Hand- und Mobilfunkgeräten, Zubehör, Wires-X sowie Digitalrelais DR-2X.

WIRES-X Setup am Stand von YAESU

Am Stand von Funk24 aus Aachen herrschte reger Betrieb. Hier konnte man aktuelle Funktechnik sowie Raspberry Pis, Anderson PowerPoles und Zubehör erwerben. Der Mitbegründer von SDRplay Jon (Jo) G4ABQ beantwortete Fragen der interessierten Käufer. Kai DK1TEO erklärte Interessenten seinen Bausatz, der Funkgeräte mit einer Freisprecheinrichtung ausstattet. Mehr Informationen darüber sind hier zu finden.

Reger Betrieb am Stand von Funk24

Sehr interessant waren auch die technischen Aufbauten der Interessengemeinschaften. Hier wurde u.a. das M17-Projekt sowie die Prototypen der Hardware vor- und ausgestellt. Am Stand des ÖVSV wurden aktuelle Projekte wie LoRaWAN und MeshCom 4.0 präsentiert. Aber auch digitales Amateurfunk-Fernsehen, SDR-Transceiver Charly25, Amateurfunk-Satelliten und der Notfunk kamen nicht zu kurz.

M17-Hardware

Weitere Impressionen bietet unsere Bildergalerie:

Fazit: Auch wenn wir an einem Tag nicht alles in Ruhe anschauen konnten, hatten wir einen fantastischen Tag mit vielen guten Gesprächen mit OMs, die man sonst nur vom Funkgerät kennt. Solche Veranstaltungen sind sehr wichtig und sollten nicht an Bedeutung verlieren. Die Karte zeigte außerdem, wie international die Veranstaltung besucht wurde.

Seid ihr auch auf der Ham Radio gewesen? Und was waren eure persönlichen Highlights? Schreibt sie uns gerne in die Kommentare unter diesem Beitrag oder diskutiert sie mit uns in unserer Telegram- und oder WhatsApp-Gruppe.

Team DL-Nordwest, Stephan 9V1LH/(9M2/)DG1BGS


Möchtest du das DL-Nordwest Projekt unterstützen? Dann freuen wir uns über deinen Gastbeitrag, das Teilen unserer Inhalte oder eine (kleine) Spende 🤑 Vielen Dank für deine Unterstützung! 😘