SDR++ Does Not Show an SDR Source

[Pavel]

Short answer: An empty SDR++ source or device list usually means the source module is missing, its support library cannot load, the operating system cannot access the device, or another process already owns it. Determine which layer is absent before reinstalling the whole application.

Before you start​

• First prove that the operating system and the hardware vendor's basic utility can see the SDR. An application cannot fix a missing USB, network or driver layer.
• Record the exact application build and SDR driver or support-library version. Plug-ins and source modules are often coupled to a particular build or architecture.

Step-by-step method​

1. Step 1: Check whether the source type itself appears. If RTL-SDR, HackRF, Pluto or USRP is absent from the source menu, inspect the SDR++ console or log for a module or dependency loading error.
2. Step 2: If the source type appears but no device is listed, test the device with its native utility: rtl_test for RTL-SDR, hackrf_info for HackRF, an IIO discovery tool for Pluto or uhd_find_devices for USRP.
3. Step 3: Close every other SDR application, feeder and background service, then disconnect and reconnect the device. Only one process can normally control a receiver at a time.
4. Step 4: Verify the correct Windows driver or network route, launch SDR++ with the same user account used for the native test and refresh the device list. Change only the layer that failed.

Concrete example​

If RTL-SDR is visible as a source but the device list is empty and rtl_test also cannot open it, work on WinUSB, cable and device ownership. If rtl_test works but SDR++ does not, compare the SDR++ module and support library rather than replacing the USB driver again.

How to judge the result​

The source problem is resolved when the native utility and SDR++ both identify the same device and SDR++ can start and stop a stream repeatedly. Save the exact log line if only one application still fails.

What to record​

• A clean software baseline can start and stop the device repeatedly for ten minutes without dropped samples or a device-busy error.
• Confirm the displayed center frequency, sample rate and audio device rather than assuming saved settings still match the current hardware.
• When testing a change, close other SDR programs so only one process owns the receiver.

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.
• Running several SDR programs at once can make a correctly installed receiver look missing or busy; close feeders and server processes as well as visible windows.

Final check​

Restart the application and computer once, then repeat the exact software workflow. Keep the configuration only when the correct source, device and output return without hidden manual repairs.