PlutoSDR support

Little add to the text above: With the Pluto not plugged into the Pi I get the same result.

Have you set up udev rules for pluto?

Hi,
did not, have now, removed the Pluto, plugged it back in, rebooted the Pi, now testing.

Thanks,

Ben

Sorry but that made no difference.
Apr 21 16:25:51 raspberrypi satnogs-client[313]: RuntimeError: SoapySDR::Device::make() no match

Have you installed soapy-plutosdr lib?


They provide debs also

Yes, I have, the detection utility at the end of the instructions detects the Pluto, I can run it as server on the Pi and connect to it remotely from SoapySDR on windows machine.

Hi all, I ran into exactly the same issues as Ben.
Has there been a solution in the meantime?
Thank you!

Sven

1 Like

Hi everybody,
just doing some tests with my Plutosdr, but now way, neither in a simple gnuradio flowgraph nor with this:

When started the previous code I obtain:

satnogs@raspberrypi:/home/pi $ satnogs_cw_decoder.py --soapy-rx-device=“driver=plutosdr” --rx-freq=433e6 --samp-rate-rx=2e6 --antenna=A_BALANCED
[INFO] Opening plutosdr #0 192.168.2.1…
ERROR: READ LINE: -32
[ERROR] Unable to set BB rate.
ERROR: READ LINE: -32
[INFO] Auto setting Buffer Size: 536870912
… and so on the same …

… and I’ve to stop the flowgraph by keyboard

Any infos??? I’m planning an SatNOGS station dedicated to L / S band, so the Plutosdr!

Tnx in advance,

Vittorio

EDIT: killing the running app kills the Plutosdr too! power cycle to get it back…

Yes, months later … but I am also about to set up an S-band GS using Pluto. Was this issue solved to everybody’s satisfaction?
Cheers, David.

No, unfortunately, at least based on my latest testing over the past two weeks.
At the moment I’m trying a Hackrf, that works, but that has other problems: high intrinsic noise / need of an external 10 MHz reference… I’m working on it :face_with_raised_eyebrow: :grinning_face_with_smiling_eyes:

Victor I3VFJ

Hi Victor,
The current SatNOGS ‘Software defined Radio’ page here still treats the HackRF as technically unsupported, but with some progress being made. You could update the Wiki page if you have managed to get it working reliably.

With regard to the Pluto, I met all sorts of problems during installation of the Soapy module - missing dependencies, wrong paths in scripts, insufficient directory read/write/execute permissions etc. Using this receiver is not for the faint-hearted! I also get the “SoapySDR::Device::make() no match” error … and hoping that someone will find an answer to the problem before I do !

1 Like

Hi!
If someone wants to debug the PlutoSDR support but is lacking the hardware, there is the SDR Testbed, providing real hardware (running 24/7 in hackerspace.gr) to interested projects via a Gitlab runner. See the presentation by @Acinonyx in the linked repo.

Sincerely,
Fabian / kerel

3 Likes

Hello all,

I’m facing the same issue with the latest SatNOGS Raspberry Pi Image (2023111400).

I installed the dependencies and running SoapySDRUtil --probe="driver=plutosdr" or SoapySDRUtil --find detects my PlutoSDR without any issue.

Running satnogs_cw_decoder.py either by schedule or manually using the same parameters yields the same error message:

RuntimeError: SoapySDR::Device::make() no match

I’ve found a clue in this thread:
https://groups.google.com/g/pothos-users/c/mW_dnGqW4Z8

Supposedly having two different library versions installed causes the issue.

I’ve run sudo find / -name "libSoapy*" and in my case it was version 0.7 and 0.8.1.
I don’t know how I ended up with two versions installed. I verified that SoapySDR runs the latest version by running SoapySDRUtil --info decided to delete the older version.

Now I’m facing another issue which seems to be unrelated to this thread. Running satnogs_cw_decoder.py again yields:

AttributeError: module ‘soapy’ has no attribute ‘source’

I’ll update once I get everything working.

Make sure you only use Soapy 0.7 versions and nothing else.

The info output should be similar (this is amd64, Pi will be a bit different) to the following:

SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.2-2
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr
Search path:  /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7
Search path:  /usr/local/lib/x86_64-linux-gnu/SoapySDR/modules0.7                 (missing)
Search path:  /usr/local/lib/SoapySDR/modules0.7                                  (missing)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libHackRFSupport.so   (0.3.3)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libLMS7Support.so     (20.10.0)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libPlutoSDRSupport.so (0.2.2-03b5ae2)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libRedPitaya.so       (0.1.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libairspySupport.so   (0.2.0-a6f6d83)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libaudioSupport.so    (0.1.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libbladeRFSupport.so  (0.4.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libmiriSupport.so     (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libosmosdrSupport.so  (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libremoteSupport.so   (0.5.2)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librfspaceSupport.so  (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librtlsdrSupport.so   (0.3.3-d5119cc)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/librtltcpSupport.so   (0.1.0-3422042)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libuhdSupport.so      (0.4.1)
Available factories... airspy, audio, bladerf, hackrf, lime, miri, osmosdr, plutosdr, redpitaya, remote, rfspace, rtlsdr, rtltcp, uhd
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]

Also make sure the pluto udev rules are installed.

cat /etc/udev/rules.d/53-adi-plutosdr-usb.rules

# allow "plugdev" group read/write access to ADI PlutoSDR devices
# DFU Device
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b674", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a32", MODE="0664", GROUP="plugdev"
# SDR Device
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b673", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a02", MODE="0664", GROUP="plugdev"
# tell the ModemManager (part of the NetworkManager suite) that the device is not a modem, 
# and don't send AT commands to it
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b673", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a02", ENV{ID_MM_DEVICE_IGNORE}="1

The following commands will enable the new rules file if you had to add it.

sudo udevadm control --reload-rules
sudo udevadm trigger

Unplug the pluto and reinsert, sudo dmesg -wT will show the device being found and enabled.

Yes! It seems to be working now for me. Thank you very much.

To summarise:

In order to install the SoapyPlutoSDR plugin I originally just cloned and compiled the latest version of SoapySDR. This seems to have installed another versions of SoapySDR into my system.

Supposedly the RuntimeError: SoapySDR::Device::make() no match error is caused by having two different versions of SoapySDR installed in the system.

Uninstalling any other version than 0.7 and compiling SoapyPlutoSDR again seems to fix the issue.

1 Like

Perhaps the dependency of SatNOGS on SoapySDR 0.7 should be documented in the context of installing this plugin.
The instruction in the SoapyPlutoSDR repository just asks to install the dependency of SoapySDR without specyfing any particular version.

The install instructions might have worked while 0.7 was the latest version, but now blindly following the instructions causes two versions of SoapySDR to be installed which seems to cause the above issue.

Do note that plutosdr has since this thread was revived (2022-09-01) been included in the deb repo that satnogs uses.
The assumtion on deleting the older 0.7 was wrong. Building the latest or 0.7 from source was probably unnecessary.

$ dpkg -l '*pluto*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                              Version      Architecture Description
+++-=================================-============-============-=======================================================
ii  soapysdr-module-plutosdr:arm64    0.2.1-2      arm64        Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
ii  soapysdr0.7-module-plutosdr:arm64 0.2.1-2      arm64        Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
1 Like

Thanks for the information, I completely missed this.

sudo apt-cache search pluto

soapysdr-module-plutosdr - Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
soapysdr0.7-module-plutosdr - Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
soapysdr0.7-module-plutosdr-dbgsym - debug symbols for soapysdr0.7-module-plutosdr

After install the module from the repository I was checking /etc/udev/rules.d and didn’t find a rules file for the pluto sdr, shouldn’t this be installed also?

yes Jan, you’re right, somehow these rules are nowhere to be found.
When running docker and no sdr software on the host, all the rules could be simply packaged to one file, this is what I have collected in 10-satnogs.rules
A special case on pluto and docker is that you can allow the host to configure the usb-nic and skip the usb sharing to the container, just use IP for access. This depends a bit on the host and how it is configured…

cat /etc/udev/rules.d/53-adi-plutosdr-usb.rules

# allow "plugdev" group read/write access to ADI PlutoSDR devices
# DFU Device
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b674", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a32", MODE="0664", GROUP="plugdev"
# SDR Device
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b673", MODE="0664", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a02", MODE="0664", GROUP="plugdev"
# tell the ModemManager (part of the NetworkManager suite) that the device is not a modem, 
# and don't send AT commands to it
SUBSYSTEM=="usb", ATTRS{idVendor}=="0456", ATTRS{idProduct}=="b673", ENV{ID_MM_DEVICE_IGNORE}="1"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2fa2", ATTRS{idProduct}=="5a02", ENV{ID_MM_DEVICE_IGNORE}="1"

I side note, with my debian testing/trixie install, I am unable to get the Pluto TCP/IP stack working.
Maybe with bullseye I will able to get this working, I need to spend some time on this.