Ask · Share · Build

PlutoSDR Not Found over USB: Recovery Checklist

Pavel

SDRstore_Pavel
Administrator
Staff member
Joined
Jul 30, 2026
Messages
121
Short answer: Separate power, USB enumeration, storage, USB networking and IIO discovery. Recovery firmware is appropriate only after identifying which function fails; a missing IIO context with working USB storage may be a host network or driver problem, not corrupted firmware.

Before you start​

  • Prove Pluto discovery through the Industrial I/O stack before opening GNU Radio or another SDR application.
  • Separate USB mass storage, USB networking and I/Q streaming because each function can fail independently.

Step-by-step method​

  1. Step 1: Use a verified data cable and direct port, then observe which Pluto USB functions enumerate. Record whether storage, serial and network interfaces appear and whether they reset repeatedly.
  2. Step 2: Check the host's USB network adapter and address route, then test the normal Pluto hostname or IIO context. Temporarily remove VPN route conflicts and firewall blocks only as a controlled test.
  3. Step 3: Run IIO discovery and save the exact error. If storage and network work but IIO does not, reinstall or repair the compatible libiio host layer before flashing.
  4. Step 4: If official recovery is required, use the image and mass-storage procedure for the exact device, keep power stable and wait for the documented completion rather than disconnecting when file copy appears finished.

Concrete example​

If the Pluto storage volume opens and its USB network interface answers but GNU Radio lists no source, the hardware is already communicating. Test libiio discovery and application modules. If no USB function appears on two hosts, focus on cable, connector, power and hardware.

How to judge the result​

Recovery is successful when all expected USB functions enumerate, IIO attributes can be queried and a receive stream survives several reconnects. Record the recovered firmware and host-library versions.

What to record​

  • Start with a moderate sample rate such as 1 to 2 MSPS for receive tests, then increase only after the baseline streams without loss.
  • Record IIO context URI, local oscillator frequency, RF bandwidth, sample rate and gain mode for a reproducible Pluto setup.
  • Treat any frequency-extension change as removal of software limits, not a guarantee of sensitivity, output power or filtering outside the original specification.

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.
  • Repeated firmware flashing can mask a route or host-driver issue and adds risk without testing the layer that actually failed.

Final check​

Reconnect Pluto and repeat IIO discovery before starting the application. Save the context, firmware, sample rate, RF bandwidth and gain mode that reproduce the result.
 
Top