SDR-System Hermes-Lite 2 – Remotebetrieb im Praxistest bei DF0BAU (Teil 1)

SDR-System vs. SDR-Transceiver

Wenn man von SDR-Technik redet, muss man unterscheiden, welches Gerätekategorie man eigentlich meint. Einerseits gibt es SDR-Transceiver, die sich in Aussehen und Funktion kaum von bisherigen, klassischen Transceivern unterscheiden, aber meist über eine Spektrumanzeige und/oder Wasserfall-Display verfügen, im Innern aber bereits SDR-Technologie verwenden. Beispiele gibt es genug, u.a. IC-7300, IC-705, FT-710, FTdx10, FTdx 101 und noch einige Andere mehr.

Die andere Kategorie sind SDR-Systeme. Das sind Transceiver, meist Direct-Sampler (HF wird direkt ohne Zwischenstufen einem Analog-Digital-Converter zugeführt), die den ersten Teil Hardware repräsentieren und deren zweiter Teil aus einer Softwareapplikation besteht, die auf einem Computer läuft. Beides ist also zum Funkbetrieb notwendig, der SDR-Transceiver UND die Softwareapplikation – sie bilden nur zusammen das ganze Funkgerät. Deswegen spricht man in diesem Fall von einem SDR-System. So ein SDR-System ist der preisgünstige Hermes-Lite 2, der hier bei mir zum Einsatz kommt – zusammen mit der SDR-Softwareapplikation OpenHPSDR-Thetis. Beide zusammen bilden ein hervorragendes Funkgerät für den Einsatz im Amateurfunk für Kurzwelle und sind – Hardware und Software – OpenSource. Es stehen also Programmcode von Thetis und die Hardware-Dokumentation des Hermes-Lite 2 allen frei zugänglich und offen zur Verfügung, einschließlich der Firmware für den Hermes-Lite 2.

Wir bewegen uns also grundsätzlich im Bereich der digitalen Signalverarbeitung, wenn wir von SDR-Technologie sprechen. Digitalisierung ist bereits fester Bestandteil auch des Amateurfunks geworden – das ist die Technik von heute und morgen. Höchste Zeit also, sich mit dieser neuen Technik intensiver zu beschäftigen und auseinander zu setzen und deren neue Möglichkeiten genauer zu erkunden. So viel kann ich schon aus eigener Erfahrung sagen – es lohnt sich auf jeden Fall.
Und genau eine dieser Möglichkeiten ist der Remote-Betrieb, wo sich mein Sender, Empfänger und auch die Antenne nicht mehr am selben Ort befindet wie ich als Operator.

Mit meinem ersten Hermes-Lite 2 hier im Home-QTH hatte ich erste Erfahrungen in Sachen Remote-Betrieb sammeln können, die ich bereits in diesem Artikel dargestellt hatte. Als nächsten Schritt werde ich einen zweiten Hermes-Lite 2, der inzwischen geliefert wurde, an unserer Klubstation DF0BAU in Wilthen zum Einsatz bringen. Über dieses Projekt werde ich hier in dieser Artikelserie, die aus mindestens zwei Teilen bestehen wird, ausführlich berichten. Neue Erkenntnisse aus den ersten Versuchen mit dem Hermes-Lite 2 und Remote-Betrieb werde ich auch in diese neue Artikelserie als Ergänzung einfliessen lassen.

Voraussetzungen Netzwerk (Internet und lokales Netzwerk/LAN)

Um ein SDR-System wie den Hermes-Lite 2 im Remotebetrieb, also „abgesetzt“ an einem anderen Standort, zu betreiben, müssen zuerst einige Voraussetzungen geprüft bzw. geschaffen werden.

Der Hermes-Lite 2 ist ein SDR-Transceiver, der über einen Ethernetanschluß verfügt. Von und zu diesem wird ein I/Q-Datenstrom transportiert unter Benutzung der Protokollschicht UDP bei heute üblicherweise verwendeten Netzwerk-Infrastrukturen auf TCP/IP-Basis. Um die Netzwerklast möglichst gering zu halten und ebenfalls die sich daraus ergebene erforderliche Bandbreite wählen wir die kleinste mögliche Samplingrate von 48000 aus. Maximal sind 384000 möglich, damit würde jedoch die notwendige Bandbreite und damit die Anforderungen an die vorhandene Internetverbindung erheblich ansteigen. Da wir jedoch einen stabilen Betrieb erreichen sollen, entscheiden wir uns also für die kleinste aller möglichen Optionen, also einer Samplingrate von 48000. Dazu benötigen wir netzwerkseitig etwa 2,5MBit/s, was mehrfache Messungen meinerseits als ausreichend bestätigt haben. Diese müssen allerdings mit einer sehr geringen Latenz (Laufzeit der Datenpakete) und geringem Jitter (Schwankungen in der Laufzeit der Datenpakete) übertragen werden, so dass wir schon Internetanbindungen im Bereich 50/10 VDSL oder besser 100/40 VDSL2 benötigen, noch besser geeignet sind natürlich die schnelleren Glasfaserverbindungen oder DSL-Anschlüsse mit SuperVectoring bis 300Mbit/s.

Das lokale Netzwerk („LAN“ bzw. „Intranet“) sollte ein modernes Netzwerk sein, heute üblicherweise mit dem Standard 1Gbit/s.

Den Einsatz von Netzwerktopologien wie PowerLine oder auch lokale WiFi-Repeater als Reichweitenextender empfehle ich nicht, diese verursachen aufgrund ihrer Technologien und Funktionsweisen eine deutliche Erhöhung der Latenzen und Jitter, was die stabile Übertragung von und zum SDR-Transceiver negativ beinflussen könnte – das Ergebnis sind meist „Drop-Outs“, also Unterbrechungen im Datenfluss. Viele kennen sowas bereits aus dem Bereich des Digitalfunks und es ist im QSO-Betrieb sehr störend.

Es ist ebenfalls ein DHCP-Server erforderlich, denn der Hermes-Lite 2 erwartet den Bezug einer IP mittels DHCP, so ist er „ab Werk“ konfiguriert. Er lässt sich durchaus auch auf statische IP umstellen, das ist allerdings etwas speziell in der Umsetzung und wird später nochmals ein Thema in einem extra Artikel innerhalb dieses Blogs werden, wo es um solche Feinheiten gehen wird.

Grundsätzlich sollte also das Netzwerk selbst so aufgebaut worden sein, dass eine stabile und schnelle Netzwerkkommunikation sichergestellt werden kann. Das gilt am Ende für alle eingesetzten Netzwerkkomponenten wie Ethernet-Switche, WiFi-Accesspoints und natürlich auch die Verkabelung inklusive Netzwerkdosen, die wenigstens der CAT6-Normung entsprechenden sollten (Kabellänge max. 100m bei Kupfer und 1Gbit/s), alternativ kann natürlich auch Glasfaser-Netzwerktechnik verwendet werden – im lokalen Netzwerk reicht bereits Multimode (Faserlänge max. 500m) aus, Singlemode ist natürlich die bessere Lösung (bis 10km Faserlänge).

Die hier beschriebenen Netzwerkanforderungen gelten unabhängig vom Betriebssystem, auf dem später die gewünschte SDR-Software eingesetzt werden soll – also sowohl WINDOWS als auch Linux oder macOS !

Voraussetzungen Computer, PC, Notebook & Co.

Ich verwende den Hermes-Lite 2 ausschließlich mit SDR-Software, welche unter WINDOWS läuft. Das sind hier in meinem Fall:

Andere Lösungen wie Quisk, SparkSDR oder auch PiHPSDR, die meist unter Linux bereits auf einem Raspberry Pi lauffähig sind, sind und werden hier nicht Gegenstand meiner Betrachtungen sein. Im Grunde werde ich mich auf OpenHPSDR-Thetis beschränken, da diese SDR-Softwarelösung die optimale SDR-Software für den Hermes-Lite 2 darstellt und die meisten technischen Möglichkeiten bietet – leider aber auch das komplexeste Setup hat.
SDR Console wäre noch eine Alternative, das Setup da mit dem Hermes-Lite 2 ist deutlich einfacher und man ist u.U. schneller QRV.

Benutzt bitte nicht wie meist im Afu üblich, ausgemusterte 15 Jahre alte PC oder Notebooks. SDR-Software stellt durchaus einige Anforderungen in Hinblick Rechnenleistung & Co., denn ein wesentlicher Teil der Signalaufbereitung wie Modulation und Demodulation erfolgt in der SDR-Software und nicht, wie vielleicht viele vermuten, in der Hardware des Hermes-Lite 2.

Hier also meine Empfehlung für den Computer, wo OpenHPSDR-Thetis oder SDR Console laufen soll:
mind. i3 / 8 GB RAM / SSD ab 256GB / WINDOWS 10 oder WINDOWS 11

Absicherung des Netzwerkzugangs auf der Remote-Seite

Das bedeutet, wir müssen den Zugang zum Remote-Standort auf andere Weise absichern, denn spätestens ab der neuen AfuV, welche am 23.6.2024 in Kraft tritt, ist das Bestandteil der künftigen Verordnung, die erstmalig auch den Remotebetrieb auf gesetzlicher Ebene einer grundlegenden Regelung unterwirft.

Am einfachsten ist es, den Zugang mittels VPN („Virtuelles privates Netzwerk“) abzusichern. Mittels VPN wird ein Tunnel von meinem PC zu dem entfernten Netzwerk aufgebaut, durch den ich Zugriff auf das Netzwerk der Remote-Seite bekomme. Dieser Tunnel oder besser der Datenverkehr durch diesen hindurch wird mittels moderner Kryptografie-Verfahren verschlüsselt übertragen, ebenfalls bietet VPN eine Zugriffskontrolle. Im einfachsten Fall per Nutzername samt Passwort, alternativ geht das oft auch über digitale Zertifikate. Für unsere Zwecke reicht aber schon ein einfaches Passwortverfahren aus. Nur wer über entsprechende Zugangsdaten verfügt, kann sich überhaupt in das Remote-Netzwerk verbinden und den Hermes-Lite 2 da ansprechen. Grundsätzlich kann immer nur EIN Benutzer den Hermes-Lite 2 ansprechen, eine „Multi-User-Nutzung“ gleichzeitig ist nicht vorgesehen und auch nicht möglich. Bei VPN selbst wäre das allerdings möglich – multiple Verbindungen – aber eben nicht zum Hermes-Lite 2. Falls lokale Firewalls zum Einsatz kommen sollten – ein Zugriff auf die Ports 1024/UDP und 1025/UDP in Verbindung mit der IP des Hermes-Lite 2 muss zugelassen werden.

Admin-Interface mittels eines mitgelieferten WINDOWS-Tools des OpenSource VPN-Servers SoftEther,
der hier derzeit auf einem
Raspberry Pi zum Einsatz kommt


Für welche VPN-Lösung man sich nun entscheidet – denn es gibt verschiedene – überlasse ich Euch. Einige Router wie die Fritzbox haben sowas bereits eingebaut und ist damit bereits Teil des Routers selbst (IPSec, Wireguard). Ich verwende OpenVPN auf einem im Remote-Netzwerk integriertem Raspberry Pi, der sonst seine Aufgabe als FM-SVXLINK- und DV-Hotspot zu erfüllen hat.
Im Grunde funktionieren aber alle VPN-Lösungen nach dem gleichen Prinzip – sie ermöglichen alle einen abgesicherterten und kontrollierten Zugriff auf das Remote-Netzwerk.

Es gibt genug Anleitungen im Internet zu VPN, die sich mit diesem Thema befassen, das würde hier einfach den Rahmen sprengen.

Besonderheiten bei 4G/LTE/5G oder TV-Kabel-Internet und VPN – Problemfall Carrier-grade NAT

Die gezeigte VPN-Server-Lösung hat Grenzen – da sie Eines zwingend voraussetzt: eine öffentliche IPv4-Adresse, welche ebenfalls „von außen“, also vom Internet aus erreichbar sein muss.

Leider gibt es Internet-Infrastrukturen, die das nicht gewährleisten. In diesen Fällen spricht man von Carrier-grade NAT, was insbesondere im mobilen Internet 4G/LTE/5G Anwendung findet, teilweise aber auch bei einigen TV-Kabelnetz-Internetanbietern zum Einsatz kommt. NAT („Network Address Translation“) setzt meist öffentliche IP-Adressen in sog. private IP-Adressen um, trennt aber diese beiden Bereiche voneinander wie eine Art Firewall – etwas vereinfacht erklärt.

IP-Adressen, besser Adressbereiche, die als privat bezeichnet werden und damit nicht im Internet verwendet werden, sind:

  • 10.0.0.0/8
  • 192.168.0.0/16
  • 172.16.0.0/12

Im Grunde die IP-Adressen, die Eure Internet-Router für Euer Heimnetzwerk vergeben. Zusätzlich gibt es noch einen IP-Adressbereich 100.64.0.0/10, der ausschließlich von den mobilen Internetanbietern in 4G/LTE/5G-Netzen verwendet wird, aber ebenfalls den privaten Adressbereichen zuzuordnen ist.

Das bedeutet, Remote-Standorte mit solchen Internetanbindungen wie 4G/LTE/5G sind schwieriger von außen erreichbar zu machen, jedoch unmöglich ist es nicht. Immerhin können noch VPN-Verbindungen nach außen aufgebaut werden, das geht auch in diesen Strukturen. Nur anders herum, wie im Falle unserer DSL-Anschlüsse, klappt das leider nicht. Das erfordert also eine andere Umsetzung entsprechender VPN-Strukturen, auf die ich hier jetzt nicht genauer eingehen werde.

Nicht von ungefähr haben wir den Standort unserer Klubstation in Wilthen mit einer WiFi-Linkstrecke für die Internetversorgung ausgestattet (an deren Endpunkt sich ein normaler VDSL2-Internetanschluß befindet) und auf 4G/LTE/5G als mögliche Alternative verzichtet.

Umsetzung in die Praxis – Remotebetrieb an der Klubstation DF0BAU in Wilthen

Alle Theorie ist grau – bis man in der Praxis nachweist, das es auch funktioniert. In Abstimmung mit dem Klubstationsleiter von DF0BAU, Fred/DL1VFR, habe ich einen ersten Testaufbau in den Räumlichkeiten unserer Wilthener Klubstation installiert:

Hier die prinzipielle, technische Umsetzung. Die Klubstation selbst verfügt leider nicht über einen eigenen Internet-Anschluß, so dass wir dieses Problem bereits seit einigen Jahren mit einer Punkt-zu-Punkt WiFi-Verbindung über eine Strecke von ca. 1,5km gelöst haben, die als Zubringer für Internetverfügbarkeit in den Räumen der Klubstation dient. Da Sichtverbindung zwischen den AccessPoints besteht, setzen wir hier 5GHz-WiFi-Technik aus dem professioniellen Business-IT-Bereich ein. Der WiFi-Link arbeitet dabei als Netzwerkbridge, die Verteilung des Netzwerks in den Räumen der Klubstation erfolgt über gemanagte Ethernet-Switches. Neben der Internetversorgung erfüllt das Netzwerk in der Klubstation gleichzeitig technische Aufgaben im Bereich Gebäudesicherung.

erster Testaufbau bei DF0BAU:

  • Hermes-Lite 2
  • ATU Antuner AT100M
  • Micro PA50 (max. 50W)
  • Netzteil SAMLEX SEC1235
  • Buddipole POWERmini
  • aktuell verwendete Antenne:
    84m Delta Loop Höhe 17m


Die „Zuweisung“ der Antenne zum SDR erfolgt derzeit „per Hand“, da der Funkbetrieb der Klubstation natürlich jederzeit Vorrang vor dem Remote-Betrieb haben muss. Das bedeutet, Remote-Betrieb nur im Fall einer personell unbesetzten Klubstation. Der Hermes-Lite 2 ist ein QRP-Gerät und liefert max. 5W. Diese gehen in eine Micro PA50, die einen derzeit eingestellten Output von ca. 40W erzeugt. Abgestimmt wird die Antenne automatisch mit einem ATU Antuner AT100M durch Trägeraktivierung mit ca. 5W. Beides – PA und ATU – entstammen meinem Outdoor/Portable-Rig. Die Micro PA50 wird in Kürze durch eine Neptune 100W von 60dbm.com ersetzt, die Lieferung ist allerdings noch nicht bei mir eingetroffen.

Antennenklemmbrett bei DF0BAU für folgende Antennen
(nichtbenutzte Antennen sind geerdet) :

  • Delta Loop 84m (80m-10m)
  • 160m Dipol (Monoband)
  • Opti Beam (20m-10m) / drehbar
  • Delta Loop vertikal für 30m (Monoband)
  • 6m 5-Element-Yagi / drehbar
  • 2m 9-Element-Langyagi / drehbar
  • 2m/70cm X300

Delta Loop 84m lang – 17m hoch und 160m Dipol (2x 40m) bei DF0BAU (Bahnhof Wilthen)


Weiter geht es in Kürze mit Teil 2 dieses Beitrags…

Schreibe einen Kommentar

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