The Pluto boots, allows logon through ssh and populates as a mass storage device. That's where any functionality ends. The IIO_Oscilloscope program recognizes the device but no channels populate and two warning triangles appear in the toolbar. The various fields under DMM in that application do function and fluctuate in what seems to be a normal manner. There are two devices available to capture data from and a sample of the measurements is below.
adm1177:current0 = 243.319336 Milliampere
adm1177:voltage0 = 5.069287 Volts
xadc:temp0 = 48.97 °C
xadc:vccaux = 1.793701 Volts
xadc:vccbram = 1.007812 Volts
xadc:vccint = 1.009277 Volts
xadc:vccoddr = 1.342529 Volts
xadc:vccpaux = 1.795166 Volts
xadc:vccpint = 1.004883 Volts
xadc:voltage8 = 0.895996 Volts
xadc:vrefn = 0.000000 Volts
xadc:vrefp = 1.250244 Volts
SDRAngel on Linux recognizes the device but once it's selected and capture button clicked, the frequency is locked at 9,999,999 with nothing in the spectrum or waterfall. The console is a bit more enlightening:
2020-10-15 15:42:46.056 (I) WebAPIServer::start: starting web API server at http://127.0.0.1:8091
2020-10-15 15:44:41.547 (C) PlutoSDRInput::openDevice: cannot open Rx channel
2020-10-15 15:44:41.547 (C) PlutoSDRInput::PlutoSDRInput: cannot open device
2020-10-15 15:44:41.557 (C) PlutoSDRInput::applySettings: device not open
2020-10-15 15:44:41.654 (C) PlutoSDRInput::applySettings: device not open
2020-10-15 15:44:43.454 (C) PlutoSDRInput::applySettings: device not open
2020-10-15 15:44:43.455 (W) PlutoSDRInputThread::run: error refilling buf (1) 0 / 32768
2020-10-15 15:44:43.655 (W) PlutoSDRInputThread::run: error refilling buf (1) 0 / 32768
(...This continues a while...)
The output of iio_info -s
Library version: 0.21 (git tag: v0.21)
Compiled with backends: local xml ip usb serial
Unable to create Local IIO context : No such file or directory
Available contexts:
0: 0456:b673 (Analog Devices Inc. PlutoSDR (ADALM-PLUTO)), serial=1044739659930006080031003fdc278679 [usb:2.19.5]
Up until 20 minutes ago, there were actually two contexts with the second being the expected ip: uri (ip:192.168.2.1). SSH is still up at that address. Rebooted the Pluto, still only showing the usb context. Either way, the main issue is the same.
Moved it over to the W10 machine and ran SDR-Console.
"One or more devices not found. This device did not start properly, possibly due to insufficient USB power. Reset the device and try again."
Ok, for giggles I unplugged it, plugged in a USB power supply to the right port and then the USB to the laptop. Same message.
SDRAngel on W10: Exact same issue, but no console for this one.
IIO_Oscilloscope on W10: Same but without the warning triangles. No channels available, clicking the capture (play?) button crashes the program.
The output of iio_info -u ip:192.168.2.1 (Yes, this somehow works even though, now, the ip context is no longer being listed.)
[16:31:32]root@SoRad-M:~# iio_info -u ip:192.168.2.1
Library version: 0.21 (git tag: v0.21)
Compiled with backends: local xml ip usb serial
IIO context created with network backend.
Backend version: 0.18 (git tag: v0.18 )
Backend description string: 192.168.2.1 Linux (none) 4.14.0-42540-g387d584 #301 SMP PREEMPT Wed Jul 3 15:06:53 CEST 2019 armv7l
IIO context has 9 attributes:
hw_model: Analog Devices PlutoSDR Rev.B (Z7010-)
hw_model_variant: 0
hw_serial: 1044739659930006080031003fdc278679
fw_version: v0.31
ad9361-phy,xo_correction:
ad9361-phy,model:
local,kernel: 4.14.0-42540-g387d584
ip,ip-addr: 192.168.2.1
uri: ip:192.168.2.1
IIO context has 2 devices:
iio:device0: adm1177
2 channels found:
voltage0: (input)
2 channel-specific attributes found:
attr 0: raw value: 782
attr 1: scale value: 6.433105468
current0: (input)
2 channel-specific attributes found:
attr 0: raw value: 445
attr 1: scale value: 0.516601562
No trigger on this device
iio:device1: xadc
10 channels found:
voltage5: vccoddr (input)
2 channel-specific attributes found:
attr 0: raw value: 1833
attr 1: scale value: 0.732421875
voltage0: vccint (input)
2 channel-specific attributes found:
attr 0: raw value: 1378
attr 1: scale value: 0.732421875
voltage4: vccpaux (input)
2 channel-specific attributes found:
attr 0: raw value: 2445
attr 1: scale value: 0.732421875
temp0: (input)
3 channel-specific attributes found:
attr 0: offset value: -2219
attr 1: raw value: 2611
attr 2: scale value: 123.040771484
voltage7: vrefn (input)
2 channel-specific attributes found:
attr 0: raw value: 1
attr 1: scale value: 0.732421875
voltage1: vccaux (input)
2 channel-specific attributes found:
attr 0: raw value: 2451
attr 1: scale value: 0.732421875
voltage2: vccbram (input)
2 channel-specific attributes found:
attr 0: raw value: 1375
attr 1: scale value: 0.732421875
voltage3: vccpint (input)
2 channel-specific attributes found:
attr 0: raw value: 1371
attr 1: scale value: 0.732421875
voltage8: (input)
2 channel-specific attributes found:
attr 0: raw value: 3672
attr 1: scale value: 0.244140625
voltage6: vrefp (input)
2 channel-specific attributes found:
attr 0: raw value: 1704
attr 1: scale value: 0.732421875
1 device-specific attributes found:
attr 0: sampling_frequency value: 961538
No trigger on this device
[16:38:53]root@SoRad-M:~# iio_attr -u ip:192.168.2.1 -C
IIO context with 9 attributes:
hw_model: Analog Devices PlutoSDR Rev.B (Z7010-)
hw_model_variant: 0
hw_serial: 1044739659930006080031003fdc278679
fw_version: v0.31
ad9361-phy,xo_correction:
ad9361-phy,model:
local,kernel: 4.14.0-42540-g387d584
ip,ip-addr: 192.168.2.1
uri: ip:192.168.2.1
I can also provide the output dmesg.
To make a long story short: There's definitely something wrong with this device but lacking anything to compare my results with (though I vaugely recall there being some logs posted that suggest I'm missing a device initialization in here somewhere) and no errors being thrown on the device itself I'm leaning toward this being an issue with the hardware itself.
Any suggestions or where do I mail this for a replacement (it was purchased from Mouser)?
(I originally updated the firmware from the .31 that shipped to .32. I have since downgraded to .31 in an attempt to resolve the issue but there has been no change, other than .32 having an unrelated error loading the 802.11 regulatory database that .31 does not have.)