Hermes-Lite 2 und OpenHPSDR-Thetis im Remotebetrieb

Nachdem ich nun meinen Hermes-Lite 2 ins lokale Netzwerk integriert hatte, die SDR-Software Thetis eingerichtet habe und bereits viele QSO’s mit diesem Setup erfolgreich absolvieren konnte, stand nun die Aufgabe an, warum ich mich auch für den Kauf des Hermes-Lite 2 entschieden hatte – der Betrieb von unterwegs mit Notebook, aber ohne Funktechnik. Also Remote-Betrieb, wie man es inzwischen im Amateurfunk bezeichnet. Für mich, der oft aus beruflichen Gründen viel unterwegs ist und das nicht nur innerhalb von Deutschland, sondern häufig auch im Ausland, eine interessante Option, denn einen Notebook habe ich aus ebengenannten Gründen sowieso immer dabei, Funktechnik natürlich nur eher selten bis gar nicht.

Vorbereitung des lokalen Netzwerks für Zugriff von Außerhalb

Um außerhalb meines lokalen Netzwerks den Zugriff auf den HL2 zu ermöglichen, gibt es verschiedene Optionen. Ich habe mich dafür entschieden, diese Aufgabe mittels VPN umzusetzen und nicht per NAT/Portforwarding. NAT bzw. Portforwarding hat ein paar kritische Punkte, deswegen ziehe ich hier klar eine VPN-Lösung vor. Auch aus Sicht einer gewissen IT-Sicherheit sehe ich hier die VPN-Lösung im Vorteil. Ganz auf Portforwarding kann ich allerdings nicht verzichten, denn ich muss ja meinen VPN-Server hinter meinem Router erreichbar bzw. zugänglich machen.

Messungen im lokalen Netzwerk ergaben (bei einer Samplingrate von 48kbit, der geringsten, auf die sich der HL2 einstellen lässt), ich benötige etwa 1,5Mbit vom HL2 zum PC und zusätzlich etwa 0,5Mbit/s in die Gegenrichtung. Grob also 2MBit/s, die wir sicher, stabil und mit möglichst geringer Latenz und Jitter (!) transportieren müssen. Erhöhen wir die Samplingrate des HL2, steigt natürlich die erforderliche Bandbreite erheblich an. Für den Remotebetrieb sollten aber die 48kBit ausreichen.

Empfohlene Netzwerkoptimierungen unter WINDOWS 10/11

Die folgenden Anpassungen sind in der Registry vom eingesetzten WINDOWS vorzunehmen – der Umgang mit dem Registry-Editor unter WINDOWS wird also für die folgenden Anpassungen vorausgesetzt.

a) Abschalten des sog. Netzwerk-Throttling:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
new DWORD key "NetworkThrottlingIndex" with Value (hex) "0xffffffff"

b) Optimierungen für das UDP-Protokoll:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters
new DWORD key "FastSendDatagramThreshold" with value (hex) "0x10000"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
new DWORD key "MaximumReassemblyHeaders" with value (hex) "0xffff"

Besonders FastSendDatagramThreshold hatte einen positiven Effekt, denn der Datenverkehr zwischen dem HL2 und dem PC / Notebook ist UDP und da hat WINDOWS per default alles andere als optimale Einstellungen. Es würde jetzt hier zu weit führen, die Hintergründe genauer zu erläutern – ich empfehle, diese drei zusätzlichen Registry-Einträge zu machen – auch wenn man keinen Remotebetrieb plant und den HL2 nur im lokalen Netzwerk betreibt. Das Ergebnis ist danach eine stabilere und flüssigere Netzwerkverbindung ohne Hakeln zwischen Thetis und dem HL2 – das gilt auch und insbesondere im Falle des Einsatzes von WLAN / WiFi (mind. 5GHz WiFi 802.11ac empfohlen).

VPN – der sichere Zugang zu unserem Hermes-Lite 2 aus der Ferne

Bitte habt Verständnis, das ich hier nicht genauer auf die Installation und Einrichtung eines VPN-Servers eingehen werde. Es soll lediglich ein Wegweiser für eine mögliche praktische Umsetzung werden. Da jedes Netzwerk, auch das kleine, private zu Hause immer mit Eurer individuellen Technik ausgerüstet ist, gibt es also dafür kein Schema „F“ und hängt stark von den technischen Möglichkeiten ab, die Euch Eure verwendete IT bereitstellen kann.

VPN & Co. ist ausreichend im Internet beschrieben, auch viele Internet-Router haben sowas bereits „on-board“, z.B. die in Deutschland häufig anzutreffenden Fritzboxen von AVM. Welche Art von VPN-Zugriff Ihr also zu Eurem Netzwerk wählt, ist also Eure individuelle Entscheidung. Es gibt zwar verschiedene VPN-Architekturen (u.a. IPSec, OpenVPN, WireGuard), aber im Grunde machen sie alles das Gleiche – sie ermöglichen einen weitgehend abgesicherten und verschlüsselten Zugang zu Eurem privaten Netzwerk via Internet (auch oft als „Tunneling“ bezeichnet) und damit natürlich auch zu Eurem HL2, der sich ja meist in Eurem Heimnetzwerk integriert befindet.

Beachtet bitte, der HL2 hat selbst keine eingebauten Sicherheitsmechanismen wie Passwortschutz oder Ähnliches und kann einfach so per Netzwerk angesprochen werden – weswegen aus meiner Sicht auch das anfangs angesprochene NAT/Portforwarding überhaupt keine Option sein sollte, schon allein aus Sicherheitsgründen, wenn man aus der Ferne arbeiten möchte.
Es liegt in Eurer Verantwortung oder besser Pflicht, unberechtigte Zugriffe auszuschließen, was im Übrigen auch in der ab 23.6.2024 geltenden neuen AfuV §2 Abs. 6a und §13a Abs. 5 „Remote-Betrieb“ gesetzlich vorgeschrieben sein wird.
Außerdem regelt die neue AfuV im §13a Abs. 1, das künftig Remote-Betrieb einer Amateurfunkstelle nur Inhabern der Lizenzklasse A gestattet ist und künftig der Rufzeichennennung im Falle von Remote-Betrieb der Suffix /R für „remote“ hinzuzufügen ist. Damit wird der bisher gesetzlich ungeregelte Remote-Betrieb fester Bestandteil der künftig geltenden AfuV und unterliegt damit klaren gesetzlichen Vorschriften, die einzuhalten sind.

NAT/Portforwarding erfordert nämlich keine zusätzlichen Authentifikationsmaßnahmen, es wird einfach der entsprechende Port durch den Router an die entsprechende interne IP weitergegeben.
Den autorisierten Zugriff sichert in diesem Falle ersatzweise unsere VPN-Verbindung ab, denn diese besitzt sehr wohl die notwendige Zugriffskontrollen, die dem HL2 selbst leider vollständig fehlen.

Für VPN verwende ich in diesem Fall einen eigenen OpenVPN-Server, basierend auf dem SoftEther VPN Project einer Universität aus Japan, der bei mir auf einem Raspberry Pi 3B+ unter Raspian/Debian Linux läuft:

Jetzt gehts los – wir arbeiten Remote mit unserem Hermes-Lite 2

Wir starten Thetis auf dem Notebook, NACHDEM wir die VPN-Verbindung erfolgreich aufgebaut haben, denn sonst erreichen wir ja unseren HL2 nicht.

Denkt immer daran, wir übertragen den gesamten I/Q-Datenstrom und nicht, wie in anderen Remotelösungen, nur Audio und ggf. CAT.
Ein I/Q-Datastream ist – technisch bedingt – einfach das wesentlich Anspruchsvollere (wenn man beides vergleicht), bietet aber letztlich mehr Möglichkeiten.

Fazit zum Remotebetrieb Hermes-Lite 2 und Thetis

Hat man unterwegs ein brauchbares, schnelles Internet zur Verfügung, funktioniert der Remotebetrieb via VPN weitgehend reibungslos. Nach den beschriebenen Netzwerk-Optimierungen vom WINDOWS läuft auch der UDP-Datastream stabil ohne nennenswerte Aussetzer bzw. Unterbrechungen, selbst im Falle von WLAN/WiFi-Betrieb. Dadurch, das man hier I/Q-Daten überträgt und ein wesentlicher Teil dieses Systems mit der SDR-Software Thetis auf dem lokalen Notebook läuft, bleibt die Bedienung und Benutzung weitgehend flexibel – im Gegensatz zu anderen Remote-Lösungen, die sich dann meist nur auf Audio-Daten und/oder Transceiversteuerung beschränken.
Durch den Einsatz des Hermes-Lite 2 zusammen mit Thetis kann ich nur sagen, so stellte ich mir den Remotebetrieb vor.

Unbedingt beachten:
Macht Ihr diesen Remotebetrieb über mobiles Internet wie LTE oder 5G, fallen in sehr kurzer Zeit sehr hohe Datenmengen an. Ein permantenter Datenstrom von ca. 2Mbit/s sind 256kByte/s und bereits nach einer Stunde Betrieb sind fast 1 GByte an Daten verbraucht. Eine Daten-Flatrate, natürlich ohne irgendwelche Drosselungen, ist dafür unumgänglich.

Ergänzende Fernüberwachung meiner PA XPA125B mittels eines ESP32-Webservers

Da ich hinter dem Hermes-Lite 2 noch eine 100W-Endstufe betreibe, die aus den max. 5W des HL2 dann eben 100W bereitstellt, musste ich noch eine Lösung für eine Art Fernüberwachung meiner PA im Remote-Betrieb finden. Das ist mir auch gelungen. Ich habe die SWR-Messbrücke der PA „angezapft“ und dieses Signal nach außen geführt – genauer gesagt, ich speise dieses Signal zur Verarbeitung einem ADC eines kleinen ESP32-Moduls ein, welches per WiFi mit meinem Netzwerk verbunden ist. Auf diesem ESP32 läuft ein kleiner Webserver, der mittels Websockets-Technologie mir die Ausgangsleistung der PA in Echtzeit in einem Browserfenster anzeigen kann. So habe ich auch remote die Funktion der PA immer im Blick.