search

pothosware / SoapyPlutoSDR

Soapy SDR plugin for PlutoSDR
https://github.com/pothosware/SoapyPlutoSDR/wiki
GNU Lesser General Public License v2.1
53 stars 22 forks source link

Ensure that discovered libiio context is a PlutoSDR #42

Closed Jeija closed 2 years ago

Jeija commented 3 years ago

Problem

Some new laptops contain sensors (e.g. accelerometers) that are handled by libiio. This causes SoapySDR to discover a PlutoSDR in the local libiio context, even though it is only some other internal sensor of the laptop.

Here, for example, there is no PlutoSDR connected to the computer:

[florian@thinkbook ~]$ SoapySDRUtil --find
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found device 0
  device = plutosdr
  driver = plutosdr
  uri = local:

What is worse, this makes SoapyPlutoSDR unusable on such devices. Even when specifying a uri in the arguments to SoapySDR::Device::make, this parameter is simply ignored and instead, SoapyPlutoSDR tries to open the first discovered local device, which is just some sensor:

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device uri=usb:3.7.5
[ERROR] no device found in this context.
Error probing device: no device found in this context

This issue was also previously reported in https://github.com/pothosware/SoapyPlutoSDR/issues/37 .

Solution

This PR changes two things:

guruofquality commented 3 years ago

This seems like a great idea. I just wanted to add that there has been an open issue with the discovery opening devices with other USB vid/pids (ones not know to be associated with pluto sdr): https://github.com/analogdevicesinc/libiio/issues/586 If libiio has a way to filter by USB vid/pid that would probably be another amazing way to limit the device discovery.

zuckschwerdt commented 3 years ago

Looks good to me. I'll test and merge.

I've been thinking about the libiio discovery issue: libiio devices could be on any vid/pid, so libiio opens all to test and thus blocks other concurrent driver enumeration. But we might know the Pluto vid/pid and could prefer to open only those. Then as fallback block for say 500ms to give other drivers a chance to clear, then use the libiio discovery. Does that make sense?

zuckschwerdt commented 3 years ago

To the point is there any other implementation of the ADALM Pluto than 0456:b673?

zuckschwerdt commented 3 years ago

Ah, well if a Pluto vid/pid is present we still need to prevent the race condition. The other way around makes more sense. Just quit and thus prevent a fixed delay for the majority of users without a Pluto.

Jeija commented 3 years ago

To the point is there any other implementation of the ADALM Pluto than 0456:b673?

I don't know to be honest. There are certainly some commercially available PlutoSDR clones (https://github.com/kangyuzhe666/ZYNQ7010-7020_AD9363 and "Pluto+", search on ebay / Aliexpress), but I do not own any of them, so I can't tell...

robcazzaro commented 2 years ago

I'm running Ubuntu 20.4 on a Microsoft Surface 3, and getting this error, I think because of the IMU sensor present in the Surface

I tried 

~/SDR/SoapyPlutoSDRnew/build$ iio_info -s
Library version: 0.23 (git tag: 92d6a35)
Compiled with backends: local xml ip usb serial
Available contexts:
    0: (magn_3d, gyro_3d, dev_rotation, incli_3d, accel_3d, als on Microsoft Corporation) [local:]
    1: 0456:b673 (Analog Devices Inc. PlutoSDR (ADALM-PLUTO)), serial=1044734c9605000df9ff0500deb64f2518 [usb:1.12.5]
    2: 192.168.2.1 (Analog Devices PlutoSDR Rev.C (Z7010-AD9364)), serial=1044734c9605000df9ff0500deb64f2518 [ip:pluto.local]

~/SDR/SoapyPlutoSDRnew/build$ SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.8.1-g722207a2
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.8
Module found: /usr/local/lib/SoapySDR/modules0.8/libPlutoSDRSupport.so (0.2.1)
Available factories... plutosdr
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

~/SDR/SoapyPlutoSDRnew/build$ SoapySDRUtil --find
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found device 0
  device = PlutoSDR
  driver = plutosdr
  label = PlutoSDR #0 local:
  uri = local:

Found device 1
  device = PlutoSDR
  driver = plutosdr
  label = PlutoSDR #0 usb:1.12.5
  uri = usb:1.12.5

Found device 2
  device = PlutoSDR
  driver = plutosdr
  label = PlutoSDR #0 ip:pluto.local
  uri = ip:pluto.local

~/SDR/SoapyPlutoSDRnew/build$ SoapySDRUtil --probe="driver=plutosdr,usb:1.12.5"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=plutosdr,usb:1.12.5
[INFO] Opening PlutoSDR #0 local:...
[ERROR] no device found in this context.
Error probing device: no device found in this context

~/SDR/SoapyPlutoSDRnew/build$ SoapySDRUtil --probe="driver=plutosdr"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=plutosdr
[INFO] Opening PlutoSDR #0 local:...
[ERROR] no device found in this context.
Error probing device: no device found in this context

But compiling the suggested commit, seems to make no difference... anything I can try?

UPDATE: I tried the workaround suggested by @LamaBleu in the linked issue (recompile libiiio with cmake -DWITH_LOCAL_BACKEND=NO -DWITH_IIOD=NO ../) and that worked. I get an error message about not being able to scan local, but then it works. Thanks for suggesting that!

SoapyPlutoSDR has a problem with built-in sensors...

zuckschwerdt commented 2 years ago

I need to finish feat-libusb to accept only the known ADALM-Pluto USB VID:PID (0456:b673) when enumerating USB (but using just libusb_get_device_list() and libusb_get_device_descriptor() instead of libusb_open_device_with_vid_pid()). Then this filtering should go on top, which is what the constructor already does anyway, but we really want to limit it to plausible candidates.

alphafox02 commented 2 years ago

On a Rock Pi X I’m running into this issue where SoapySDRUtil is seeing a pluto due to an on board sensor (confirmed with the iio tool). Looking at using this pull request but it sounds like work is still being done, is that still the case? I also have an AntSDR E310, pluto like device, that I could test this with.

alphafox02 commented 2 years ago

I’ve also seen this be an issue with, I think it was the Ettus b200. It’s seen as a pluto due to the components it has onboard.

zuckschwerdt commented 2 years ago

You might want to try #50 first -- it needs community testing, I can't reproduce the bug. This PR might be added on top, but we really don't want to enumerate non-Pluto IIO devices in the first place (due to #24).

alphafox02 commented 2 years ago

I’ll try this evening, before seeing this PR I went so far as doing a bit pull of the latest libiio and libad9361 with same results. I’ll try #50 with what’s currently in place and then try all sorts of other combos from there if it’s still an issue.

zuckschwerdt commented 2 years ago

Thanks! Will be interesting to hear if filtering the USB interface is enough or if the non-Pluto hardware is on the "local" interface.

alphafox02 commented 2 years ago

Good news, I rebuilt libiio without the cmake changes. Then confirmed SoapySDRUtil saw the onboard sensor as a PlutoSDR. I then pulled master, rebuilt Soapy Pluto, installed, and can confirm the onboard sensor is no longer coming up as a “Pluto”. iio_info does see the sensor, so now off to find my actually Pluto or antsdr and make sure it’s seen. It looks like this has resolved the issue.