Post Go back to editing

Initial Pluto+ SDR USB connection issue

Thread Summary

The user is unable to connect a HamGeek ADI Pluto+ SDR to a laptop via USB, with the device showing a solid light between the OTG and DEBUG ports, suggesting DFU mode. The device is not recognized on a Linux laptop and does not show the expected 'usbmodem' entry on a Macbook. The final answer indicates that Analog Devices does not support the Pluto+ and suggests contacting the vendor for further assistance.
AI Generated Content
Category: Hardware

Hello,

I've recently received a HamGeek ADI Pluto+ SDR (www.hgeek.com/.../hamgeek-adi-pluto-70mhz-6ghz-sdr-software-defined-radio-ad936x-for-libiio-iioscope-sdrsharp-matlab) and am attempting to connect it to a laptop via USB to complete the initial setup.

After going through the quickstart I appear to be stuck at step 2. The light between the OTG and DEBUG ports on the Pluto+ is solid, indicating that it is perhaps in DFU mode.

After much troubleshooting, it seems that there is some issue with the laptop even recognizing that the Pluto+ was connected.

On a linux machine, running `sudo dmesg -w` does not show any logging when I connect or disconnect a USB cable from the OTG port on the Pluto+. However, dmesg logs do show up when plugging a USB cable into the DEBUG port. These logs refer to "FTDI USB Serial Device". I've tried multiple USB cables, multiple USB ports on the linux laptop itself, multiple ports on a powered USB hub, and powering on the Pluto+ with or without the DFU button pressed - no change.

To rule out the linux laptop being the issue, I attempted to get the Pluto+ SDR connected to a macbook. 

When the macbook is connected to the OTG port on the Pluto+, the output of `ls -l /dev/tty.*` does not show anything related to "usbmodem" as mentioned on wiki.analog.com/.../osx

However, when the macbook is connected to the DEBUG port on the Pluto+, the output indicates that it is detecting something from the Pluto+ and seems to match the linux laptop behavior:

$ ls -l /dev/tty.*
crw-rw-rw-  1 root  wheel  0x9000000 Jun 28 14:44 /dev/tty.BLTH
crw-rw-rw-  1 root  wheel  0x9000002 Jun 28 14:44 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel  0x9000004 Jun 28 15:14 /dev/tty.usbserial-DebugChannel0
crw-rw-rw-  1 root  wheel  0x9000006 Jun 28 15:14 /dev/tty.usbserial-DebugChannel1
crw-rw-rw-  1 root  wheel  0x9000008 Jun 28 15:14 /dev/tty.usbserial-DebugChannel2
crw-rw-rw-  1 root  wheel  0x900000a Jun 28 15:14 /dev/tty.usbserial-DebugChannel3

Is there any way to perform a firmware reset from one of the `/dev/tty.usbserial-DebugChannel` interfaces, or does it seem like the unit itself is bad?

Any help is greatly appreciated.



Edited for fixing external links.
[edited by: gra at 3:34 PM (GMT -4) on 29 Jun 2025]