HB3YAQLucerne
PRIVATE RECEIVING STATION / LUCERNE
HB3YAQOpenWebRX+My signal. My system.
Self-hosted Software Defined Radio · Raspberry Pi 4 · SDRplay RSP1B · Nooelec NESDR SMArt v5
Radio becomes data. Data becomes sound. In between is infrastructure I run myself – from USB receiver to protected browser access.
01 / COMPUTE
02SDR receivers
8 GBRAM / Raspberry Pi 4
500 GBSamsung SSD
464Entries · documented count
Project record: both build phases documented as complete on 15 October 2026. Private access for selected users; no live availability indicator.
01 / HARDWARE
Four components. One system.
Processing, storage and two separate routes to radio signals. Original schematic drawings, not invented station photographs.
01 / 8 GB RAM
8 GB RAM
Raspberry Pi 4
The compact processing centre.
Role in the system
One shared host for the operating system, receiver software and signal processing. The SSD adds persistent storage.
Technical background ↗02 / 500 GB SSD
500 GB SSD
Samsung 860 EVO
The persistent foundation.
Role in the system
Documented storage for SSD operation. Adapter and boot layout are unconfirmed; backups remain a separate responsibility.
Technical background ↗03 / RTL-SDR
RTL-SDR
Nooelec NESDR SMArt v5
Compact. A separate reception branch.
Role in the system
Integrated through RTL-SDR drivers. The receiver is part of a complete system; its tuning range does not promise reception everywhere.
Technical background ↗04 / Hardware API 3.15
Hardware API 3.15
SDRplay RSP1B
A second route to the signal.
Role in the system
An independent SDR branch with documented API integration. SoapySDR is part of the software stack. No diversity combining is claimed.
Technical background ↗02 / SIGNAL PATH
From receiver to browser.
Open a component. The diagram separates functions, not necessarily physical devices. Access protection and operations support the whole chain.
01SDR receiversNESDR v5 / RSP1B→
Two separate hardware sources turn received signals into digital data. Their antenna feeds are not specified here.
02Raspberry PiLinux / SSD / USB→
Raspberry Pi OS Lite 64-bit on Debian 13 provides the system base. The hardware API, SoapySDR and RTL-SDR drivers integrate the devices.
03OpenWebRX+PROFILES / SESSIONS→
The native application organises profiles, reception sources and user sessions. Shared hardware remains a shared resource.
04Signal processingFILTER / DEMOD / CODEC→
Within the software chain, signals are filtered and demodulated. Decoders and CodecServer add digital voice processing. This step is drawn separately by function, not as an extra physical server.
05Web browserAUTHORISED USERS+
Selected users operate the private receiver in a browser. This public showcase is not connected to their session.
+Protected accessWIREGUARD / NFTABLES+
VPN and firewall protect system access. Dynamic DNS updates a name mapping but grants no access rights. Actual endpoints remain private.
+Operations & recoveryBACKUP / BOOTSTRAP+
Automated backups and the bootstrap concept support recovery. Maintenance covers the system and receiver software; a current restore test is not documented here.
NESDR SMArt v5RSP1B
→Shared hostSeparate sources · shared resources
03 / RECEPTION WORKBENCH
See what tuning means.
Frequency jumps, filters and scanning as an interactive illustration. Every change stays in your browser.
Illustration · not live receptionRX / HF
7.100 MHzLSB · Illustrative scan step 1/3
ANALOG
AM / FM / SSB / CW
Filter → Demodulate → Audio
DIGITAL VOICE
DMR / D-STAR / YSF / NXDN
Signal → digital data → voice codec → audio
04 / FIELD NOTES
The build, in detail.
25 chapters. Confirmed equipment, technical context and the limits of what is documented.
Introduction and project idea
Receiving radio, understanding the processing and running the infrastructure myself: that is the purpose of my private station in Lucerne. A Raspberry Pi connects two USB receivers to a browser interface. The receiving hardware stays on site while selected users operate it remotely.
This showcase documents the design. It provides no listening access and displays no current reception data. Unlike the public Swiss-SDR receiver directory, this is one privately operated station.
What is OpenWebRX+?
OpenWebRX+ extends the open-source OpenWebRX receiver software. It connects SDR hardware, signal processing and a web interface. The browser is the control surface; it does not replace the antenna or receiver.
In this project OpenWebRX+ is installed natively on the Raspberry Pi. Receiver software, dependencies and hardware drivers are maintained as part of the Linux system. The installation is not a service embedded in this website.
Hardware and physical layout
Four components form the documented core: a Raspberry Pi 4 with 8 GB RAM, a 500 GB Samsung SSD 860 EVO, a Nooelec NESDR SMArt v5 and an SDRplay RSP1B. The Pi handles processing, the SSD provides storage and the two SDRs digitise received signals.
The drawings show roles and connections, not a scale model of the installation. Antenna model, splitters, cable routing, cooling and power supply are not fully documented here. Two receivers do not imply a confirmed shared antenna distribution system.
Raspberry Pi 4 and SSD operation
The Pi is the shared host for OpenWebRX+, drivers and decoders. Its 8 GB of memory is a confirmed specification, not a statement about simultaneous listener capacity. Sustainable load also depends on sample rates, decoders and concurrent tasks.
SSD operation is documented with a 500 GB Samsung 860 EVO. The exact adapter, partition layout and boot configuration are neither published nor assumed here. An SSD is not a separate backup: data loss and incorrect changes remain possible failure modes.
Nooelec NESDR SMArt v5
The compact RTL-SDR receiver adds a separate reception branch. The manufacturer specifies a tuning range of 100 kHz to 1.75 GHz. The lower range uses direct sampling, which is distinct from normal tuner operation.
RTL-SDR drivers are documented for this project. The manufacturer range does not mean the station covers every band with the same antenna, quality or an active profile. The whole receiving chain matters, not just the quoted tuning range.
SDRplay RSP1B
The RSP1B forms the second independent SDR branch. SDRplay specifies continuous tuning from 1 kHz to 2 GHz. The station documentation includes SDRplay Hardware API 3.15 and SoapySDR in the software integration.
The hardware API, driver integration and OpenWebRX+ serve different roles: accessing the device, providing a common interface and exposing receiver controls. No measured sensitivity or actual maximum capture bandwidth is documented here.
How both receivers work together
Two SDRs provide separate reception branches on the same computer. They can serve different tasks and profiles. Permanent band assignments for this installation have not been fully documented and are therefore not asserted.
The signals are not automatically combined into a more capable receiver. This is not documented diversity reception or a phase-synchronised system. Both branches share processing power, USB resources and the available network connection.
Reception ranges and frequency management
Three levels must be distinguished: a device’s tuning range, the range made useful by antenna and surroundings, and the configured capture window. A stored frequency entry says nothing by itself about whether a signal can be received.
Frequency management links profiles to understandable names, frequencies and suitable modes. The demonstration above uses examples only. It is not an export of my configuration and does not retune either real receiver.
Swiss frequency collection and bookmarks
The last documented collection contains 464 entries. This number describes the curated collection at that project stage, not a live database or 464 confirmed reception opportunities. An entry provides orientation and a starting point for tuning.
Maintaining names, frequencies, modes and currency together keeps the collection useful. Duplicate or outdated entries make operation harder. The private collection is not offered for download here, and no confidential communication targets are published.
SDR reception profiles
A profile defines a prepared capture window for an SDR device. It helps switch tasks without rebuilding every setting. Profiles for different frequency ranges are part of the documented project.
The visible window is not the receiver’s entire tuning range. Changing a profile can affect other users of the same device. Profile selection is therefore also a decision about shared resources.
Spectrum and waterfall
The spectrum arranges signal components by frequency. The waterfall adds time: persistent signals leave trails, while short transmissions leave short segments. A bright patch does not automatically mean intelligible speech.
In this showcase the curve and colour strips are designed illustrations. They explain tuning and selection, not signal strength, calibrated levels or current radio activity in Lucerne.
Analogue modulation modes
AM, FM, SSB and CW need different processing. AM carries information in amplitude, while FM uses frequency variation. SSB uses one sideband; CW reception makes a keyed carrier audible. OpenWebRX+ provides the corresponding demodulators.
Frequency, mode and filter must fit together. An overly narrow filter removes wanted information; an unnecessarily wide one admits more interference. Selecting a mode alone does not guarantee reception: antenna, level and interference still matter.
Digital voice decoders and CodecServer
DMR, D-STAR, YSF and NXDN are documented supported digital voice modes. The software stack includes SoftMBE/libmbe and CodecServer. Digital voice processing involves more than a different audio filter: usable digital data must first be recovered from the radio signal.
CodecServer exposes codec functions as a separate service. Successful voice decoding depends on format, signal quality and the available codec. This is not a decryption feature or evidence that a transmission is currently being received.
Frequency Far Jump
Frequency Far Jump is among the documented extensions. It makes it easier to move to frequencies outside the selected capture window. Switching remains constrained by available profiles and device ranges.
The demonstration illustrates this idea by switching between HF, VHF and UHF. The examples are not documented station profiles. Moving across bands does not imply that one antenna performs equally well on all of them.
Frequency Scanner
The OpenWebRX+ scanner watches bookmarks in the displayed profile. It can tune to an entry above the squelch threshold and continue searching afterwards. It is not an unrestricted sweep of the hardware’s entire tuning range.
Continuous digital carriers are an important limitation: a signal may persist without voice traffic. The showcase offers a purely illustrative scan controlled one step at a time; it produces neither a reception log nor a QSO.
Browser-based operation
The interface brings tuning, mode selection and reception displays into the browser. Selected users do not need a USB receiver attached to their own device. Hardware and server-side processing remain at the station location.
Authorised access to the private environment must be established first. This public website is separate: it loads neither the receiver interface nor audio. Its interactive drawings do not connect to the station either.
Multi-user architecture
OpenWebRX+ is designed around shared SDR resources. Multiple listening sessions do not automatically mean fully independent physical receivers. Hardware tuning in particular provides a shared foundation.
A selected user group is confirmed for this station, but no maximum user count. Without a reliable load test, guaranteed concurrency or latency figures would be misleading. The presentation therefore separates system principles from measured performance.
WireGuard, firewall and access control
WireGuard VPN, an nftables firewall and Cloudflare Dynamic DNS are documented infrastructure components. They serve different roles: protected network transport, control over allowed connections and updating a name-to-address mapping.
Dynamic DNS is not access authorisation. A VPN does not replace deliberate selection of users and permitted services. Only these roles are explained here; actual addresses, rules, keys and access paths remain private.
Operating system, maintenance and monitoring
The documented base is Raspberry Pi OS Lite 64-bit on Debian 13. Without a desktop, the focus is on receiver services and their maintenance. The native installation links operating-system upkeep with the hardware API, drivers and decoder components.
Useful checks include service state, error logs, storage space and processing load. The monitoring tool used here is not confirmed. This page therefore contains no invented uptime, temperature, CPU or availability readouts.
Automated backups and recovery
Automated backup mechanisms and a recovery concept using a bootstrap script belong to the documented project. The aim is a traceable path back to an operable system rather than reconstructing every setup decision after a failure.
A bootstrap script provides procedures; a backup preserves required data. Both must match. Schedule, retention, destination and the latest restore test are not documented here. No guaranteed recovery time can be inferred.
Phase 1 – infrastructure
The first phase covers the system and infrastructure: the Raspberry Pi with SSD operation, the Linux base and the documented network-access and recovery components. Completion was recorded on 15 October 2026.
This milestone describes project history. It is not an automatic health check of the installation running today. Operation and maintenance remain ongoing tasks after the initial build is complete.
Phase 2 – reception and extensions
The second phase covers SDR reception, profiles, decoders and extensions. Both receivers and their software components form the documented expansion. This phase was also recorded as complete on 15 October 2026.
Frequency Far Jump, Frequency Scanner and the Swiss frequency collection make operation more focused. Documented features are not treated as verified reception results; such reports would need separate evidence.
Technical specifications
Host: Raspberry Pi 4, 8 GB RAM. Storage: Samsung SSD 860 EVO, 500 GB. Receivers: Nooelec NESDR SMArt v5 and SDRplay RSP1B. Operating system: Raspberry Pi OS Lite 64-bit / Debian 13. Installation: native OpenWebRX+.
Integration: SDRplay Hardware API 3.15, SoapySDR and RTL-SDR drivers. Digital voice components: SoftMBE/libmbe and CodecServer. Infrastructure: WireGuard, nftables, Cloudflare Dynamic DNS, automated backups and bootstrap recovery. Further exact package versions are not documented.
Private operation and use boundaries
The station is not intended as a public WebSDR. This page publishes no communication content, reception recordings or access credentials. Supporting a mode describes a technical capability, not permission to listen to or redistribute arbitrary communications.
Software, codecs and external services have their own terms and licences. This showcase does not replace reviewing those terms or assessing the legality of a particular use. It documents the technical design of the private installation.
Personal perspective and future development
This project connects my interests in radio, software and self-hosted IT. Listening is only part of it; the path from receiver through processing to a usable interface matters just as much. That connection is what this showcase makes visible.
The documented build is complete, while future development remains open. Changes will receive their own dated entries in the project history. Possible extensions will be described as implemented only once their actual state is confirmed.
From foundation to reception.
Documented milestone
Two phases. One documented build.
- Phase 1 complete: system and infrastructure.
- Phase 2 complete: SDR reception, profiles, decoders and extensions.
- Swiss frequency collection: last documented count of 464 entries.
Not a current operational check. Future changes will carry their own date and, when assigned, a project version.