Raspberry Pi 5 RTL-SDR Setup

[Pavel]

Short answer: Install the RTL-SDR library, disable any DVB kernel driver that claims the dongle, verify with rtl_test and begin at a moderate sample rate. Raspberry Pi 5 has enough compute for many receive tasks, but USB power, cooling and stable device identity still determine reliability.

Before you start​

• Prove the SDR on the Raspberry Pi interactively before turning it into a service. Record the device serial, USB path, driver and sample rate.
• Use a power supply, cable and USB topology that can support the Pi and every attached SDR under sustained load.

Step-by-step method​

1. Step 1: Update the operating system, install the maintained rtl-sdr package and connect one dongle through a known powered path. Use lsusb to confirm enumeration.
2. Step 2: If rtl_test reports the device busy because a DVB driver attached, apply the distribution's supported blacklist method and reboot. Do not unload unrelated USB modules.
3. Step 3: Run rtl_test at about 2.048 or 2.4 MSPS for at least ten minutes while checking kernel logs for resets, sample loss and undervoltage.
4. Step 4: Assign a unique RTL-SDR serial for persistent services, then configure the chosen receiver or decoder by serial rather than changing bus number.

Concrete example​

A useful baseline is Raspberry Pi 5 with adequate cooling, one RTL-SDR on a direct or powered-hub port, 2.4 MSPS and no lost samples during a 30-minute rtl_test. Only then add readsb, OpenWebRX or another service.

How to judge the result​

The setup is stable when the dongle survives reboot, is selected by its intended serial and streams without USB resets or undervoltage warnings under the final power supply.

What to record​

• Run a sustained stream while monitoring undervoltage, USB resets, CPU temperature, dropped samples and storage growth.
• A headless service should restart cleanly, wait for networking and the SDR, write bounded logs and expose a health check.
• For remote access, prefer a VPN and least-privilege accounts instead of exposing receiver-control ports directly to the internet.

Common mistakes​

• Changing several hardware, software or RF variables at once, which removes the controlled comparison needed to identify the cause.
• Treating one autoscaled screenshot or one unusually good result as proof without recording the settings and repeating the test.
• Using /dev or bus-order numbering for identical dongles can make services swap radios after a reboot.

Final check​

Reboot the Raspberry Pi and reproduce the complete service or stream without an interactive login. Check power, USB, logs, storage and remote access before leaving it unattended.