When running OpenWebRX+ on a Raspberry Pi 5 with an RTL-SDR Blog V4, a handful of recurring problems account for most installation and configuration failures. The most important thing to investigate first is almost always the RTL-SDR Blog V4 driver and library stack — particularly when OpenWebRX+ was installed on top of an existing Raspberry Pi OS system rather than from a known-good OpenWebRX+ image. The reason is simple: Raspberry Pi OS Bookworm ships Debian’s librtlsdr0 version 0.6.0, which predates the V4 entirely.^[1] The dongle will enumerate, rtl_test will find a tuner, and HF will be dead or on the wrong frequency. Raspberry Pi OS Trixie (the current release) ships 2.0.2, which does support the V4^[2] — so the first thing to establish is which OS release you are on.

This guide assumes a 2 GB Raspberry Pi 5 running 64-bit Raspberry Pi OS with OpenWebRX+ installed from the project’s apt repository (which has separate Bookworm and Trixie channels).^[3,4] Most of it applies equally to the 4 GB and 8 GB models and to the official OpenWebRX+ SD-card image — note that only the 64-bit image runs on a Pi 5; the 32-bit image does not.^[3]

Before You Start: Command-Line Prerequisites

Every check below is done at a terminal. If that is unfamiliar territory, here is the minimum you need. Nothing here will damage anything; the only commands that change the system are clearly marked in the driver-install section.

Most Likely Causes

1. Wrong RTL-SDR Blog V4 Driver

The RTL-SDR Blog V4 differs from earlier RTL-SDR models because it uses the R828D tuner and a built-in HF signal path. A system may detect the USB device correctly while still using an incompatible or outdated software stack. RTL-SDR Blog’s own guidance is blunt: without an updated driver the V4 simply will not function correctly — either no signals, signals at the wrong frequency, or signals that appear corrupted.^[5]

Typical symptoms

• The dongle appears in lsusb but receives no useful signals.
• HF reception does not work.
• Frequencies appear incorrect.
• Reception is distorted or erratic.

Start with:

lsusb
rtl_test -t

What a healthy result looks like

With a current driver, rtl_test -t prints something close to this — the two lines that matter are the tuner and the V4 detection:

Found 1 device(s):
  0:  RTLSDRBlog, Blog V4, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 ...
[R82XX] PLL not locked!
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.

The PLL not locked and No E4000 tuner found lines are normal — -t is an E4000 tuning test and every R828D dongle prints them. What you must see is Found Rafael Micro R828D tuner followed by RTL-SDR Blog V4 Detected — both strings come straight from the upstream driver source.^[6] If you get the R828D line but no V4 line, the library is the old 0.6.0 build: the dongle “works” on VHF but HF is dead. Go straight to the driver-install section below.

Check which library you actually have before building anything:

grep VERSION_CODENAME /etc/os-release
dpkg -l librtlsdr0 | tail -1

Installing the Correct V4 Driver on Raspberry Pi OS Bookworm

Two facts decide how this should be done. First, Debian Bookworm’s packaged librtlsdr0 is 0.6.0-4 and has no V4 support.^[1] Second, OpenWebRX+ is installed from Debian packages, and its rtl_connector^[8] is dynamically linked against whatever librtlsdr.so.0 the loader finds. If you follow the common “make install” recipe, the new library lands in /usr/local/lib while apt’s old copy stays in /usr/lib — which is precisely the two-library conflict described in section 3.

The method RTL-SDR Blog recommends for package-based systems (it names FlightRadar24, FlightAware, ADSBExchange and OpenWebRX+ images explicitly) is to build replacement Debian packages and install those over the old ones.^[5] That keeps apt honest and puts the library where rtl_connector already looks.

Step 1 — Stop OpenWebRX+ and remove every existing librtlsdr

sudo systemctl stop openwebrx
sudo apt purge ^librtlsdr
sudo rm -rvf /usr/lib/librtlsdr* /usr/include/rtl-sdr* /usr/local/lib/librtlsdr* /usr/local/include/rtl-sdr* /usr/local/include/rtl_* /usr/local/bin/rtl_*

Success looks like: apt purge may warn that it will also remove owrx-connector or rtl-sdr because they depend on the library. That is expected — say yes; they are reinstalled in Step 4 and your OpenWebRX+ settings in /etc/openwebrx and /var/lib/openwebrx are not touched. If rm prints nothing, there was no manually installed copy, which is fine.

Step 2 — Build the replacement packages

sudo apt update
sudo apt install -y libusb-1.0-0-dev git cmake build-essential pkg-config debhelper
cd ~
git clone https://github.com/osmocom/rtl-sdr
cd rtl-sdr
dpkg-buildpackage -b --no-sign
cd ..

Success looks like: several minutes of compiler output on a Pi 5, ending with dpkg-deb: building package lines and three .deb files in your home directory: librtlsdr0_*.deb, librtlsdr-dev_*.deb and rtl-sdr_*.deb. If it stops with a missing-dependency message, sudo apt install whatever it names and run dpkg-buildpackage again.

Step 3 — Install them and hold them

sudo dpkg -i librtlsdr0_*.deb
sudo dpkg -i librtlsdr-dev_*.deb
sudo dpkg -i rtl-sdr_*.deb
sudo apt-mark hold librtlsdr0 librtlsdr-dev rtl-sdr
sudo ldconfig

Why the hold: the packages you just built carry a version number higher than Debian’s, but a future apt upgrade can still replace them if the archive ships something newer or the version comparison goes the wrong way. apt-mark hold pins them. Check with apt-mark showhold. Without this, HF quietly dies again after the next system update and you are back at section 1.

Step 4 — Reinstall the OpenWebRX+ connector, udev rules and DVB blacklist

sudo apt install --reinstall owrx-connector openwebrx
sudo cp ~/rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger
echo 'blacklist dvb_usb_rtl28xxu' | sudo tee /etc/modprobe.d/blacklist-dvb_usb_rtl28xxu.conf
sudo reboot

What each line does: owrx-connector (and openwebrx, if apt removed it in Step 1) is reinstalled and relinked against the new library (RTL-SDR Blog notes that Soapy and Osmocom-based software may need reinstalling after a driver swap,^[5] and this is OpenWebRX+’s equivalent). The librtlsdr0 package you built already installs its udev rules as /lib/udev/rules.d/librtlsdr0.rules; copying rtl-sdr.rules into /etc/udev/rules.d/ as well is belt-and-braces and harmless. Either way the rule sets the device to mode 0660, group plugdev,^[6] so the openwebrx service user (which the OpenWebRX+ package adds to plugdev on install^[11]) can open it without sudo. The blacklist stops the TV driver claiming the device at boot.

Step 5 — Verify

rtl_test -t
lsmod | grep -E 'dvb|rtl28'
ldd $(which rtl_connector) | grep rtlsdr
apt-mark showhold
sudo systemctl status openwebrx --no-pager

Success looks like: rtl_test prints RTL-SDR Blog V4 Detected; lsmod prints nothing; ldd shows one librtlsdr.so.0 path under /usr/lib (or /lib) and nothing under /usr/local; the hold list shows the three packages; the service is active (running). Now open http://<IP>:8073/, and only now start adjusting OpenWebRX+ profiles.

2. The Linux DVB Driver Has Claimed the SDR

Linux may automatically load the DVB television driver for RTL2832 hardware. When that happens, OpenWebRX+ may be unable to access the device at all. Common errors include:

usb_claim_interface error
Device or resource busy
No SDR devices available

Check:

lsmod | grep -E 'dvb|rtl28'

If dvb_usb_rtl28xxu is present, unload it now and blacklist it so it stays gone across reboots:

sudo rmmod dvb_usb_rtl28xxu
echo 'blacklist dvb_usb_rtl28xxu' | sudo tee /etc/modprobe.d/blacklist-dvb_usb_rtl28xxu.conf
sudo systemctl restart openwebrx

rmmod takes effect immediately, so you can test with rtl_test -t without rebooting; the blacklist file is what makes it permanent. If rmmod refuses with Module is in use, stop OpenWebRX+ first.

3. Conflicting librtlsdr Installations

A Raspberry Pi can easily end up with multiple RTL-SDR libraries installed at the same time. For example:

Debian librtlsdr 0.6.0        in /usr/lib
+
manually compiled librtlsdr   in /usr/local/lib
+
OpenWebRX+ dependencies       pulling the Debian copy back in

This can cause one SDR application to work while OpenWebRX+ fails, or can cause HF to fail while VHF appears normal — the command-line tools resolve to one copy and the connector to another.

Useful diagnostics are:

which rtl_test
rtl_test -t
ldconfig -p | grep rtlsdr
dpkg -l | grep -E 'rtl-sdr|librtlsdr'
ldd $(which rtl_test) | grep rtlsdr
ldd $(which rtl_connector) | grep rtlsdr

The last two lines are the decisive ones. ldd prints the exact library file each binary will load. If rtl_test and rtl_connector point at different files, or ldconfig -p lists two librtlsdr.so.0 entries, you have the conflict. The clean fix is the driver-install section above, which removes every copy and reinstalls one.

4. USB Permissions: the Service Can’t Open the Dongle

This one is easy to miss because everything works when you run rtl_test, yet OpenWebRX+ logs:

usb_open error -3
Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules

The service runs as the unprivileged openwebrx user,^[11] and by default a USB device node is owned by root. The rtl-sdr.rules udev file (shipped in the osmocom source tree and installed by the Debian librtlsdr0 package) grants the plugdev group read/write access.^[6] Check:

ls /etc/udev/rules.d/ /lib/udev/rules.d/ | grep -i rtl
lsusb -d 0bda:2838
ls -l /dev/bus/usb/$(lsusb -d 0bda:2838 | awk '{print $2}')/
groups openwebrx

You want a rules file present, the device node showing group plugdev with rw permissions, and plugdev in the service user’s groups. Fix with:

sudo cp ~/rtl-sdr/rtl-sdr.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger
sudo usermod -aG plugdev openwebrx
sudo systemctl restart openwebrx

Unplug and re-plug the dongle after reloading rules; udev only applies them at enumeration.

5. OpenWebRX+ Is Running but the SDR Source Is Misconfigured

Being able to open the OpenWebRX+ web interface does not prove that the SDR itself is configured correctly. The browser interface may work while the receiver still reports:

Receiver unavailable
No SDR devices available

In Settings → SDR device settings, verify that the device type is RTL-SDR (not SoapySDR unless you installed a Soapy module deliberately), that the device selector matches the V4’s serial, and that Direct sampling is off. Begin with a conservative sample rate such as 2.048 MS/s (OpenWebRX+’s own default profile uses 2.4 MS/s; either is fine on a Pi 5) and moderate manual gain.

6. OpenWebRX+ Service Is Not Running

If the web interface itself will not load, check the service directly:

systemctl status openwebrx --no-pager

Then inspect the logs:

journalctl -u openwebrx -n 200 --no-pager

Confirm that TCP port 8073 is listening:

ss -lntp | grep 8073

This quickly distinguishes a web-service failure from an SDR hardware or driver failure. A service that starts and immediately stops usually has a syntax error in a hand-edited config file or a Python traceback in the log — read the first error, not the last.

7. VHF/UHF Works but HF Does Not

This is an important diagnostic clue. If FM broadcast, 2 metres, or other VHF/UHF signals can be received but HF cannot, investigate:

• RTL-SDR Blog V4 driver compatibility — specifically, the missing V4 Detected line in section 1.
• HF receiver profile settings.
• Incorrect legacy direct-sampling configuration.
• Antenna or feedline suitability for HF.
• Front-end overload from strong local signals.

8. Gain Is Configured Incorrectly

Maximum RF gain is not always best. Excessive gain, especially on HF, can create:

• Overload.
• Images and phantom carriers.
• Broadcast breakthrough.
• An excessively high noise floor.
• Loss of weak-signal readability.

Start with moderate manual gain (around 20–30 dB is a reasonable HF starting point). Increase it until weak signals improve, then stop increasing gain when the noise floor rises without a corresponding improvement in usable signals.

9. Raspberry Pi Generated RFI

The Raspberry Pi, USB subsystem, Ethernet interface, power supply, HDMI circuitry, and connected cables can all generate RF interference. The Pi 5’s USB 3 ports (the blue ones) are the usual offender.

Symptoms

• Regularly spaced vertical lines on the waterfall.
• Broadband noise.
• Weak HF signals disappearing when the SDR is connected to the Pi.

The A/B test

1. Use the same RTL-SDR.
2. Use the same antenna and coax.
3. Tune the same frequency.
4. Compare reception on a laptop or desktop computer.

If reception becomes dramatically cleaner, investigate Pi-related RFI rather than OpenWebRX+ itself.

First moves that usually help

• Move the dongle to a USB 2 port (black) — USB 3 signalling is a broadband noise source.
• Put the dongle on a short, good-quality USB extension with a clip-on ferrite at the Pi end, so the dongle and its SMA are physically away from the board.
• Use shielded Ethernet rather than Wi-Fi, and route the antenna coax away from the Pi and its power lead.
• Use the official 27 W supply; cheap USB-C supplies are frequently the noisiest thing in the room.

10. USB or Power Instability

An SDR continuously streams USB data, so weak power supplies, poor USB extensions, and unpowered hubs can cause intermittent failures. Typical symptoms include:

USB disconnect
USB reconnect
device disappeared
receiver stopped
OpenWebRX+ restarted

Check the kernel log:

dmesg | tail -100

Also check Pi throttling and undervoltage history:

vcgencmd get_throttled

0x0 means no undervoltage or throttling has been logged since boot. Any other value is a hex bit-field; the low 16 bits are the current state and the high 16 bits are “has happened since boot”. 0x50005 is the classic result: under-voltage and throttling right now (bits 0 and 2) and also earlier (bits 16 and 18).^[13]

During fault isolation, connect the RTL-SDR directly to the Raspberry Pi (no hub, no extension) and use the official Pi 5 power supply.

11. Too Much Workload for a 2 GB Raspberry Pi

The Raspberry Pi 5 processor is capable, but 2 GB of RAM places practical limits on the number of simultaneous decoders, users, and other services. Check:

free -h
htop

Look for out-of-memory events:

journalctl -k | grep -i -E 'oom|out of memory|killed process'

1 RTL-SDR
2.048 MS/s
1 active receiver profile
minimal digital decoders
Ethernet preferred

Add FT8, WSPR, APRS, and other decoding functions one at a time after the receiver is stable.

12. Antenna or Feedline Problems

Sometimes the software is working correctly and the real problem is at the RF input. Check:

• Antenna connection.
• Coax continuity.
• Adapters and connectors.
• Antenna suitability for the selected band.
• Whether an amplifier, filter, or bias-powered device is installed incorrectly — and whether the bias tee is on when it should not be (see section 2).

Test a known strong signal such as a local FM broadcast station or local VHF transmission to verify basic receiver operation.

13. Networking or Browser Access Problems

If OpenWebRX+ appears to be running but cannot be reached from another computer, verify that port 8073 is listening and confirm the Pi’s IP address:

ss -lntp | grep 8073
hostname -I

Then connect using:

http://<PI-IP-ADDRESS>:8073/

If the IP address works but raspberrypi.local does not, the problem is mDNS resolution on the client (common on Windows without Bonjour) rather than OpenWebRX+. If neither works from another machine but curl http://localhost:8073/ succeeds on the Pi itself, look at the network, not the receiver.

Fastest Diagnostic Sequence

Before reinstalling anything, collect the following output. It takes under a minute and answers most questions on the OpenWebRX groups.io list^[17] or the OpenWebRX+ Telegram chat^[18] before they are asked:

uname -a
grep -E 'PRETTY_NAME|VERSION_CODENAME' /etc/os-release

lsusb -d 0bda:2838
rtl_eeprom 2>&1 | head -12

which rtl_test
rtl_test -t 2>&1 | head -8

lsmod | grep -E 'dvb|rtl28'

dpkg -l | grep -E 'rtl-sdr|librtlsdr|owrx'
apt-mark showhold
ldconfig -p | grep rtlsdr
ldd $(which rtl_connector) | grep rtlsdr

ls /etc/udev/rules.d/ | grep -i rtl
groups openwebrx

systemctl status openwebrx --no-pager
journalctl -u openwebrx -n 100 --no-pager

free -h
vcgencmd get_throttled
vcgencmd get_config usb_max_current_enable
vcgencmd pmic_read_adc 2>/dev/null | head -3

Then establish four basic facts

1. Can the OpenWebRX+ webpage be opened?
2. Does rtl_test -t print RTL-SDR Blog V4 Detected, not just the R828D tuner line?
3. Does VHF/UHF work while HF fails, or does nothing receive?
4. What exact error appears in the OpenWebRX+ log?

Four Main Fault Categories

Most problems can then be placed into one of four categories:

Recommended First Action

rtl_test -t

In most installations, the highest-priority suspects are the RTL-SDR Blog V4 driver stack and the Linux DVB driver claiming the SDR. Verify both before performing a complete software reinstall.

Notes and Sources

Numbered references are cited in the text above. Library, package and installer links point at the canonical upstream repository or the official Debian package tracker, not at mirrors or personal forks.

1. Debian package tracker, rtl-sdr in bookworm. packages.debian.org/source/bookworm/rtl-sdr — Bookworm ships librtlsdr0 / rtl-sdr 0.6.0-4.
2. Debian package tracker, librtlsdr0 in trixie. packages.debian.org/trixie/librtlsdr0 — Trixie ships 2.0.2-2. Packaging maintained by the Debian Hamradio Maintainers (A. Maitland Bottoms).
3. Marat Fayzullin, OpenWebRX+ Home Page. fms.komkon.org/OWRX/ — Installation channels for Debian Bookworm and Trixie, SD-card image notes (64-bit image for Pi 5; 32-bit image excludes RPi5).
4. OpenWebRX+ package repository (PPA). luarvique.github.io/ppa/ — Official apt channels for Debian/Ubuntu and the link to the project-endorsed Docker image.
5. RTL-SDR Blog, RTL-SDR Blog V4 Users Guide (revised 1 September 2026). www.rtl-sdr.com/v4/ — Driver requirement, Debian-package install method, HF mode (no direct sampling), bias-tee behaviour of the DVB-T driver, EEPROM strings, the recommendation to build from osmocom/rtl-sdr.
6. Osmocom project, rtl-sdr source repository. gitea.osmocom.org/sdr/rtl-sdr — Canonical upstream (GitHub mirror at github.com/osmocom/rtl-sdr). src/librtlsdr.c prints Found Rafael Micro R828D tuner and RTL-SDR Blog V4 Detected / V4 Lite Detected keyed on the EEPROM strings; debian/changelog is at 2.0.3; rtl-sdr.rules sets mode 0660, group plugdev.
7. RTL-SDR Blog, RTL-SDR Blog V4L (Lite) Now Available. www.rtl-sdr.com/… — Announcement of the V4 Lite variant.
8. luarvique/owrx_connector on GitHub. github.com/luarvique/owrx_connector — Source of rtl_connector, the process OpenWebRX+ uses to talk to librtlsdr.
9. RTL-SDR Blog, rtl-sdr-blog driver fork. github.com/rtlsdrblog/rtl-sdr-blog — The vendor’s own fork with V3/V4 additions (bias-tee EEPROM flag, rtl_biast). Referenced by many older tutorials.
10. n4cra, RTL-SDR V4 on Raspberry Pi OS Bookworm. github.com/n4cra/RTL-SDR-v4-on-Raspberry-Pi — Reports the rtlsdrblog fork failing to compile on Bookworm with an rtlsdr_check_dongle_model implicit-declaration error and recommends the osmocom tree.
11. luarvique/openwebrx on GitHub. github.com/luarvique/openwebrx — OpenWebRX+ source. systemd/openwebrx.service runs as User=openwebrx; debian/openwebrx.postinst creates the user and adds it to plugdev.
12. Stanislav LZ2SLL, slechev/openwebrxplus on Docker Hub. hub.docker.com/r/slechev/openwebrxplus — Project-endorsed image built from the official OpenWebRX+ .deb packages; builder at 0xAF/openwebrxplus-docker-builder.
13. Raspberry Pi Ltd, vcgencmd documentation. www.raspberrypi.com/documentation/computers/os.html#vcgencmd — Bit meanings of get_throttled.
14. Raspberry Pi Ltd, Raspberry Pi hardware documentation — Power supply. www.raspberrypi.com/… — Pi 5 restricts downstream USB to 600 mA unless a 5 A supply is negotiated, then 1.6 A.
15. Raspberry Pi Ltd, config.txt documentation. www.raspberrypi.com/documentation/computers/config_txt.html — usb_max_current_enable; file lives at /boot/firmware/config.txt on current Raspberry Pi OS.
16. Raspberry Pi Ltd, white paper USB Power Delivery on Raspberry Pi 5 (RP-009856, March 2026). pip-assets.raspberrypi.com/… — PD negotiation, PSU_MAX_CURRENT=5000 EEPROM setting, automatic setting of usb_max_current_enable.
17. OpenWebRX mailing list on groups.io. groups.io/g/openwebrx — Community support; the thread history on V4 dongles is where most of the failure patterns above were first reported.
18. OpenWebRX+ Telegram chat. t.me/openwebrx_chat — Developer-attended support channel for OpenWebRX+.

Credits

• OpenWebRX was created by András Retzler HA7ILM and is maintained in its original form by Jakob Ketterl DD5JFK at openwebrx.de.
• OpenWebRX+ is Marat Fayzullin’s fork (fms.komkon.org/OWRX, github.com/luarvique/openwebrx), released under the AGPL-3.0. The Raspberry Pi SD-card images and the project Docker image are built by Stanislav LZ2SLL.
• librtlsdr and the rtl_* tools are the work of the Osmocom project (Steve Markgraf and contributors); the RTL-SDR Blog V4 support in the upstream tree was contributed by RTL-SDR Blog.
• The RTL-SDR Blog V4 hardware, drivers and user guide are by RTL-SDR Blog.
• Debian packaging of rtl-sdr is maintained by the Debian Hamradio Maintainers team (A. Maitland Bottoms). Raspberry Pi OS, firmware and documentation are by Raspberry Pi Ltd.
• Sample-rate, gain and RFI observations are the author’s own, drawn from bench work and from the reports of many operators on the OpenWebRX groups.io list. Corrections are welcome via the contact details on r-390a.net.