HB3YAQLuzern
PRIVATE EMPFANGSSTATION / LUZERN
HB3YAQOpenWebRX+Mein Signal. Mein System.
Self-hosted Software Defined Radio · Raspberry Pi 4 · SDRplay RSP1B · Nooelec NESDR SMArt v5
Funk wird zu Daten. Daten werden hörbar. Dazwischen liegt eine Infrastruktur, die ich selbst betreibe – vom USB-Empfänger bis zum geschützten Browserzugang.
01 / COMPUTE
02SDR-Empfänger
8 GBRAM / Raspberry Pi 4
500 GBSamsung SSD
464Einträge · dokumentierter Stand
Projektstand: beide Aufbauphasen am 15.10.2026 als abgeschlossen dokumentiert. Privater Zugang für ausgewählte Benutzer; keine Live-Verfügbarkeitsanzeige.
01 / HARDWARE
Vier Bausteine. Ein System.
Rechenleistung, Speicher und zwei getrennte Wege zum Funksignal. Eigene schematische Zeichnungen statt erfundener Stationsfotos.
01 / 8 GB RAM
8 GB RAM
Raspberry Pi 4
Das Rechenzentrum im Kleinen.
Aufgabe im System
Ein gemeinsamer Rechner für Betriebssystem, Empfangssoftware und Signalverarbeitung. Die SSD ergänzt ihn als Massenspeicher.
Technischer Hintergrund ↗02 / 500 GB SSD
500 GB SSD
Samsung 860 EVO
Die persistente Grundlage.
Aufgabe im System
Dokumentierter Speicher für den SSD-Betrieb. Adapter und Boot-Aufteilung sind nicht belegt; Backups bleiben eine separate Aufgabe.
Technischer Hintergrund ↗03 / RTL-SDR
RTL-SDR
Nooelec NESDR SMArt v5
Kompakt. Ein eigener Empfangszweig.
Aufgabe im System
Über RTL-SDR-Treiber eingebunden. Der Empfänger ist Teil eines Gesamtsystems; seine Abstimmspanne ist kein Versprechen flächendeckenden Empfangs.
Technischer Hintergrund ↗04 / Hardware API 3.15
Hardware API 3.15
SDRplay RSP1B
Der zweite Weg zum Signal.
Aufgabe im System
Eigenständiger SDR-Zweig mit dokumentierter API-Anbindung. SoapySDR gehört zum Softwareaufbau. Kein behaupteter Diversity-Verbund.
Technischer Hintergrund ↗02 / SIGNAL PATH
Vom Empfänger bis zum Browser.
Öffne einen Baustein. Die Zeichnung trennt Funktionen, nicht zwingend physische Geräte. Zugangsschutz und Betrieb begleiten die gesamte Kette.
01SDR-EmpfängerNESDR v5 / RSP1B→
Zwei getrennte Hardwarequellen wandeln empfangene Signale in digitale Daten. Ihre Antennenzuleitungen sind hier nicht spezifiziert.
02Raspberry PiLinux / SSD / USB→
Raspberry Pi OS Lite 64-bit auf Debian 13 stellt das Systemfundament. Hardware API, SoapySDR und RTL-SDR-Treiber gehören zur Anbindung der Geräte.
03OpenWebRX+PROFILES / SESSIONS→
Die nativ installierte Anwendung organisiert Profile, Empfangsquellen und Benutzersitzungen. Gemeinsame Hardware bleibt eine geteilte Ressource.
04SignalverarbeitungFILTER / DEMOD / CODEC→
Innerhalb der Softwarekette werden Signale gefiltert und demoduliert. Für digitale Sprache ergänzen Decoder und CodecServer die Verarbeitung. Dieser Schritt ist funktional getrennt gezeichnet, kein zusätzlicher physischer Server.
05WebbrowserAUTHORISED USERS+
Ausgewählte Benutzer bedienen den privaten Empfänger im Browser. Diese öffentliche Projektseite ist nicht mit ihrer Sitzung verbunden.
+Geschützter ZugangWIREGUARD / NFTABLES+
VPN und Firewall begleiten den Zugriff auf das System. Dynamic DNS aktualisiert eine Namenszuordnung, erteilt aber keine Zugangsrechte. Konkrete Endpunkte bleiben privat.
+Betrieb & RecoveryBACKUP / BOOTSTRAP+
Automatisierte Sicherungen und das Bootstrap-Konzept unterstützen die Wiederherstellung. Wartung umfasst System und Empfangssoftware; ein aktueller Restore-Test ist hier nicht belegt.
NESDR SMArt v5RSP1B
→Gemeinsamer RechnerGetrennte Quellen · gemeinsame Ressourcen
03 / RECEPTION WORKBENCH
Sehen, was Abstimmen bedeutet.
Frequenzsprung, Filter und Scan als bedienbare Illustration. Jede Änderung bleibt in deinem Browser.
Illustration · kein Live-EmpfangRX / HF
7.100 MHzLSB · Illustrativer Scan-Schritt 1/3
ANALOG
AM / FM / SSB / CW
Filtern → Demodulieren → Audio
DIGITAL VOICE
DMR / D-STAR / YSF / NXDN
Signal → digitale Daten → Sprachcodec → Audio
04 / FIELD NOTES
Der Aufbau, im Detail.
25 Kapitel. Bestätigte Ausstattung, technische Zusammenhänge und die Grenzen dessen, was dokumentiert ist.
Einführung und Projektidee
Funk empfangen, die Verarbeitung verstehen und die Infrastruktur selbst betreiben: Darum geht es bei meiner privaten Station in Luzern. Der Raspberry Pi verbindet zwei USB-Empfänger mit einer browserbasierten Bedienoberfläche. Die eigentliche Empfangstechnik bleibt vor Ort, ausgewählte Benutzer bedienen sie aus der Ferne.
Diese Präsentation dokumentiert den Aufbau. Sie stellt keinen Hörzugang bereit und zeigt keine aktuellen Empfangsdaten. Anders als das öffentliche Empfängerverzeichnis Swiss-SDR ist dies eine einzelne, privat betriebene Anlage.
Was ist OpenWebRX+?
OpenWebRX+ ist eine erweiterte Variante der quelloffenen OpenWebRX-Empfangssoftware. Die Software verbindet SDR-Hardware mit Signalverarbeitung und einer Weboberfläche. Der Browser ist das Bediengerät; er ersetzt weder Antenne noch Empfänger.
In diesem Projekt ist OpenWebRX+ nativ auf dem Raspberry Pi installiert. Damit gehören die Empfangssoftware, ihre Abhängigkeiten und die Hardwaretreiber zum betreuten Linux-System. Die Installation ist kein eingebetteter Dienst dieser Website.
Hardware und physischer Aufbau
Vier Komponenten bilden den dokumentierten Kern: Raspberry Pi 4 mit 8 GB RAM, Samsung SSD 860 EVO mit 500 GB, Nooelec NESDR SMArt v5 und SDRplay RSP1B. Der Pi übernimmt die Verarbeitung, die SSD den Massenspeicher und die beiden SDRs die Digitalisierung der empfangenen Signale.
Die Zeichnungen zeigen Rollen und Verbindungen, keine massstabsgetreue Installation. Antennenmodell, Verteiler, Kabelwege, Kühlung und Stromversorgung sind hier nicht abschliessend dokumentiert. Aus zwei Empfängern folgt insbesondere keine bestätigte gemeinsame Antennenverteilung.
Raspberry Pi 4 und SSD-Betrieb
Der Pi ist der gemeinsame Rechner für OpenWebRX+, Treiber und Decoder. Seine 8 GB Arbeitsspeicher sind eine bestätigte Ausstattung, aber keine Aussage über die Anzahl gleichzeitig möglicher Hörsitzungen. Welche Last tragbar ist, hängt auch von Abtastraten, Decodern und parallelen Aufgaben ab.
Für den SSD-Betrieb ist eine Samsung 860 EVO mit 500 GB dokumentiert. Der genaue Adapter, das Partitionsschema und die Boot-Konfiguration werden hier nicht veröffentlicht oder vorausgesetzt. Eine SSD ersetzt keine separate Sicherung: Datenverlust und fehlerhafte Änderungen bleiben mögliche Ausfallursachen.
Nooelec NESDR SMArt v5
Der kompakte RTL-SDR-Empfänger ergänzt die Station als eigener Empfangszweig. Die Herstellerangabe für den Abstimmumfang beträgt 100 kHz bis 1,75 GHz. Der untere Bereich verwendet Direct Sampling; dieser Betriebsweg ist vom normalen Tunerbetrieb zu unterscheiden.
Im Projekt sind RTL-SDR-Treiber dokumentiert. Der Herstellerumfang bedeutet nicht, dass die Station jeden Bereich mit derselben Antenne, Qualität oder einem aktiven Profil abdeckt. Entscheidend ist die gesamte Empfangskette, nicht nur die aufgedruckte Frequenzspanne.
SDRplay RSP1B
Der RSP1B bildet den zweiten, eigenständigen SDR-Zweig. SDRplay nennt einen durchgehenden Abstimmumfang von 1 kHz bis 2 GHz. Die Station dokumentiert die SDRplay Hardware API 3.15 und SoapySDR als Bestandteile der Softwareanbindung.
Hardware API, Treiberanbindung und OpenWebRX+ erfüllen unterschiedliche Aufgaben: Zugriff auf das Gerät, einheitliche Ansprache und schliesslich die Bedienung des Empfangs. Hier sind weder eine gemessene Empfindlichkeit noch ein tatsächlich genutzter maximaler Frequenzausschnitt belegt.
Zusammenwirken beider Empfänger
Zwei SDRs eröffnen getrennte Empfangszweige auf demselben Rechner. Sie können unterschiedlichen Aufgaben und Profilen zugeordnet werden. Welche Frequenzbereiche hier dauerhaft welchem Gerät zugeteilt sind, ist nicht abschliessend belegt und wird deshalb nicht festgeschrieben.
Die Signale werden nicht automatisch zu einem leistungsfähigeren Empfänger zusammengerechnet. Es handelt sich weder um belegten Diversity-Empfang noch um ein phasensynchrones System. Beide Zweige teilen sich Rechenleistung, USB-Ressourcen und die verfügbare Netzwerkverbindung.
Empfangsbereiche und Frequenzverwaltung
Drei Ebenen sind zu unterscheiden: der technische Abstimmumfang eines Geräts, der durch Antenne und Umgebung sinnvoll nutzbare Bereich und der tatsächlich konfigurierte Empfangsausschnitt. Ein gespeicherter Frequenzeintrag sagt noch nichts über ein empfangbares Signal aus.
Die Verwaltung verbindet Profile mit verständlichen Namen, Frequenzen und passenden Betriebsarten. Die Demonstration weiter oben verwendet lediglich Beispielwerte. Sie ist kein Export meiner Konfiguration und schaltet keinen der echten Empfänger um.
Schweizer Frequenzsammlung und Bookmarks
Der zuletzt dokumentierte Stand umfasst 464 Einträge. Diese Zahl beschreibt die gepflegte Sammlung zum Projektstand, keine laufend abgefragte Datenbank und keine 464 bestätigten Empfangsmöglichkeiten. Ein Eintrag dient als Orientierung und Einstieg in eine passende Einstellung.
Bei der Pflege gehören Bezeichnung, Frequenz, Modus und Aktualität zusammen. Doppelte oder veraltete Einträge erschweren die Bedienung. Die private Sammlung wird hier nicht zum Download angeboten; auf der öffentlichen Projektseite erscheinen keine vertraulichen Kommunikationsziele.
SDR-Empfangsprofile
Ein Profil beschreibt einen vorbereiteten Empfangsausschnitt eines SDR-Geräts. Es hilft, zwischen Aufgaben zu wechseln, ohne sämtliche Einstellungen erneut zusammenzustellen. Profile für verschiedene Frequenzbereiche sind Bestandteil des dokumentierten Projekts.
Der gerade sichtbare Ausschnitt ist nicht der gesamte Abstimmumfang des Empfängers. Ein Profilwechsel kann andere Benutzer desselben Geräts betreffen. Deshalb ist die Auswahl eines Profils auch eine Entscheidung über gemeinsam genutzte Ressourcen.
Spektrum und Wasserfall
Das Spektrum ordnet Signalanteile nach Frequenz. Der Wasserfall ergänzt den zeitlichen Verlauf: Anhaltende Signale hinterlassen Spuren, kurze Aussendungen nur kurze Abschnitte. Eine helle Stelle ist nicht automatisch verständliche Sprache.
In dieser Präsentation stammen Kurve und Farbstreifen aus einer gestalteten Illustration. Sie zeigen die Idee von Abstimmung und Auswahl, keine Signalstärke, keinen kalibrierten Pegel und keine aktuelle Funkaktivität in Luzern.
Analoge Modulationsarten
AM, FM, SSB und CW erfordern unterschiedliche Verarbeitung. Bei AM trägt die Amplitude die Information, bei FM die Frequenzänderung. SSB verwendet ein Seitenband; bei CW wird eine getastete Trägeraussendung hörbar gemacht. OpenWebRX+ stellt entsprechende Demodulatoren bereit.
Frequenz, Modus und Filter müssen zusammenpassen. Ein zu enges Filter beschneidet die Information, ein unnötig breites lässt zusätzliche Störungen passieren. Die Auswahl allein garantiert keinen guten Empfang: Antenne, Pegel und Störumgebung bleiben entscheidend.
Digitale Sprachdecoder und CodecServer
DMR, D-STAR, YSF und NXDN sind als unterstützte digitale Sprachverfahren dokumentiert. Zum Softwareaufbau gehören SoftMBE/libmbe und CodecServer. Die Verarbeitung digitaler Sprache umfasst mehr als eine andere Audiofilterung: Aus dem Funksignal müssen zunächst verwertbare digitale Daten gewonnen werden.
CodecServer stellt Codec-Funktionen als getrennten Dienst bereit. Ob Sprache tatsächlich decodiert werden kann, hängt vom Format, der Signalqualität und dem verfügbaren Codec ab. Das ist keine Entschlüsselungsfunktion und kein Nachweis, dass gerade eine Verbindung empfangen wird.
Frequency Far Jump
Frequency Far Jump gehört zu den dokumentierten Erweiterungen. Die Funktion erleichtert den Sprung zu Frequenzen ausserhalb des gerade gewählten Ausschnitts. Der Wechsel bleibt an die vorhandenen Empfangsprofile und Gerätebereiche gebunden.
Die Demonstration zeigt diesen Gedanken mit einem Wechsel zwischen HF, VHF und UHF. Die Beispiele sind keine belegten Stationsprofile. Ein Sprung über mehrere Bänder bedeutet auch nicht, dass eine einzelne Antenne dort gleich gut arbeitet.
Frequency Scanner
Der Scanner von OpenWebRX+ beobachtet Bookmarks im angezeigten Profil. Er kann bei einer Aktivität oberhalb der Rauschsperre auf einen Eintrag abstimmen und anschliessend weitersuchen. Es ist kein beliebiger Vollbereichsscan des gesamten Hardware-Abstimmumfangs.
Dauerhaft vorhandene digitale Träger sind dabei ein wichtiger Grenzfall: Ein Signal kann bestehen, obwohl gerade keine Sprache übertragen wird. Im Showcase lässt sich ein rein illustrativer Scan schrittweise bedienen; daraus entsteht weder ein Empfangsprotokoll noch ein QSO.
Browserbasierte Bedienung
Die Bedienoberfläche bringt Frequenzwahl, Modus und Empfangsdarstellung in den Browser. Für ausgewählte Benutzer ist damit kein eigener USB-Empfänger am Endgerät erforderlich. Die Hardware und die serverseitige Verarbeitung bleiben am Standort der Station.
Zuerst muss der berechtigte Zugang zur privaten Umgebung bestehen. Diese öffentliche Website ist davon getrennt: Sie lädt weder die Empfangsoberfläche noch Audio nach. Auch die interaktiven Zeichnungen bauen keine Verbindung zur Station auf.
Mehrbenutzerarchitektur
OpenWebRX+ ist für die Nutzung geteilter SDR-Ressourcen ausgelegt. Mehrere Hörsitzungen bedeuten nicht automatisch mehrere vollständig unabhängige physische Empfänger. Insbesondere die Hardware-Abstimmung ist eine gemeinsame Grundlage.
Für diese Station ist ein ausgewählter Benutzerkreis bestätigt, aber keine maximale Benutzerzahl. Ohne einen belastbaren Lasttest wären Angaben zu garantierter Parallelität oder Latenz irreführend. Die Darstellung trennt deshalb Systemprinzip und gemessene Leistung.
WireGuard, Firewall und Zugriffskontrolle
WireGuard VPN, eine nftables-Firewall und Cloudflare Dynamic DNS sind als Infrastruktur dokumentiert. Sie haben unterschiedliche Aufgaben: geschützter Netztransport, Kontrolle erlaubter Verbindungen und Aktualisierung einer Namenszuordnung.
Dynamic DNS ist keine Zugangsberechtigung. Ein VPN ersetzt wiederum nicht die bewusste Auswahl von Benutzern und freigegebenen Diensten. Hier werden nur diese Rollen erklärt; konkrete Adressen, Regeln, Schlüssel und Zugangswege bleiben privat.
Betriebssystem, Wartung und Monitoring
Dokumentierte Basis ist Raspberry Pi OS Lite 64-bit auf Debian 13. Ohne Desktop liegt der Schwerpunkt auf Empfangsdiensten und ihrer Betreuung. Die native Installation verbindet Betriebssystempflege mit der Pflege von Hardware API, Treibern und Decoderkomponenten.
Sinnvolle Prüfpunkte sind Dienstzustand, Fehlerprotokolle, Speicherplatz und Rechenlast. Welches Monitoring-Werkzeug hier eingesetzt wird, ist nicht bestätigt. Deshalb gibt es auf dieser Seite weder erfundene Uptime noch Temperatur-, CPU- oder Verfügbarkeitsanzeigen.
Automatisierte Backups und Wiederherstellung
Automatisierte Backup-Mechanismen und ein Recovery-Konzept mit Bootstrap-Skript gehören zum dokumentierten Projekt. Das Ziel ist ein nachvollziehbarer Weg zurück zu einem betreibbaren System, statt im Fehlerfall sämtliche Einrichtungsschritte neu erfinden zu müssen.
Ein Bootstrap-Skript stellt Abläufe bereit; eine Sicherung bewahrt benötigte Daten. Beides muss zusammenpassen. Zeitplan, Aufbewahrung, Sicherungsziel und letzter Wiederherstellungstest sind hier nicht belegt. Eine garantierte Wiederanlaufzeit lässt sich daraus nicht ableiten.
Phase 1 – Infrastruktur
Die erste Phase bündelt System und Infrastruktur. Dazu gehören der Raspberry Pi mit SSD-Betrieb, das Linux-Fundament sowie die dokumentierten Bausteine für Netzwerkzugang und Wiederherstellung. Ihr Abschluss wurde am 15. Oktober 2026 festgehalten.
Dieser Meilenstein beschreibt den Projektverlauf. Er ist kein automatischer Gesundheitscheck der heute laufenden Installation. Betrieb und Wartung bleiben auch nach einer abgeschlossenen Aufbauphase fortlaufende Aufgaben.
Phase 2 – Empfang und Erweiterungen
Die zweite Phase umfasst SDR-Empfang, Profile, Decoder und Erweiterungen. Beide Empfänger und die zugehörigen Softwarebausteine bilden den dokumentierten Ausbau. Auch diese Phase wurde am 15. Oktober 2026 als abgeschlossen vermerkt.
Frequency Far Jump, Frequency Scanner und die Schweizer Frequenzsammlung machen die Bedienung gezielter. Der dokumentierte Funktionsumfang wird nicht mit verifizierten Empfangserfolgen gleichgesetzt; solche Berichte müssten separat belegt werden.
Technische Spezifikationen
Rechner: Raspberry Pi 4, 8 GB RAM. Speicher: Samsung SSD 860 EVO, 500 GB. Empfänger: Nooelec NESDR SMArt v5 und SDRplay RSP1B. Betriebssystem: Raspberry Pi OS Lite 64-bit / Debian 13. Installation: natives OpenWebRX+.
Anbindung: SDRplay Hardware API 3.15, SoapySDR und RTL-SDR-Treiber. Digitale Sprachkomponenten: SoftMBE/libmbe und CodecServer. Infrastruktur: WireGuard, nftables, Cloudflare Dynamic DNS, automatisierte Sicherungen und Bootstrap-Recovery. Konkrete Paketstände darüber hinaus sind nicht belegt.
Privater Betrieb und rechtliche Hinweise
Die Empfangsstation ist nicht als öffentliches WebSDR vorgesehen. Diese Seite veröffentlicht keine Kommunikationsinhalte, Empfangsaufzeichnungen oder Zugänge. Die Unterstützung eines Modus beschreibt eine technische Fähigkeit und keine Berechtigung, beliebige Kommunikation abzuhören oder zu verbreiten.
Software, Codecs und externe Dienste haben eigene Nutzungs- und Lizenzbedingungen. Diese Projektpräsentation ersetzt weder deren Prüfung noch eine rechtliche Beurteilung einer konkreten Nutzung. Sie bleibt bei der technischen Dokumentation des privaten Aufbaus.
Persönliches Fazit und zukünftige Entwicklung
Dieses Projekt verbindet meine Interessen an Funktechnik, Software und selbst betriebener IT. Nicht allein das Hören steht im Mittelpunkt, sondern der Weg vom Empfänger über die Verarbeitung bis zur bedienbaren Oberfläche. Genau diesen Zusammenhang möchte ich hier sichtbar machen.
Der dokumentierte Aufbau ist abgeschlossen, die Weiterentwicklung bleibt offen. Zukünftige Änderungen erhalten eigene datierte Einträge in der Projektchronik. Mögliche Erweiterungen werden erst dann als umgesetzt beschrieben, wenn ihr tatsächlicher Stand bestätigt ist.
Vom Fundament zum Empfang.
Dokumentierter Meilenstein
Zwei Phasen. Ein dokumentierter Aufbau.
- Phase 1 abgeschlossen: System und Infrastruktur.
- Phase 2 abgeschlossen: SDR-Empfang, Profile, Decoder und Erweiterungen.
- Schweizer Frequenzsammlung: zuletzt dokumentierter Stand von 464 Einträgen.
Kein aktueller Betriebsnachweis. Spätere Änderungen werden mit eigenem Datum und, falls vergeben, einer Projektversion ergänzt.