Feature request: Support for SoapySDR.

[ast]

Support for SoapySDR, and SoapyRemote in particular, would be really nice.

[f4exb]

While the support of SoapySDR which has been already invoked in tickets like this one: #105 and would be an interesting addition I don't see the point of SoapyRemote since you can operate SDRangel as a remote headless server more specifically since version 4.1. If it can fit just like another SoapySDR device this is fine but I don't think this is a must.

The support of SoapySDR needs a bit of thinking and as I imagine it as a very high level design breaks into two essential parts:

• Dynamic addition of a SoapySDR virtual device at core level so that it is seen by the application just like another device possibly with multiple input and output ports (like BladeRF v2 or LimeSDR USB)
• Addition of a pair of plugins (source and sink) that can handle a stream of a virtual SoapySDR device. As far as I remember from looking at SoapySDR implementation details the streaming is muxed between Rx or Tx channels so that would be more something along the lines of the plugin for BladerRF v2 just being developed with a single thread to support the streaming of all channels.

[idl0r]

I second this as it would add support for several devices and adding new ones might be even easier. Including remote device support etc.

[f4exb]

At the risk of repeating myself you do arleady have remote device support. See:

• https://github.com/f4exb/sdrangel/releases/tag/v4.1.0
• https://github.com/f4exb/sdrangel/wiki/SDRangel-server
• https://github.com/f4exb/sdrangel/wiki/SDRangel-server-with-supervisor-in-Arch-Linux (and the like for other disto flavors)

I've made a quick peek into the SoapySDR repository (Pothos that is) and at this time from the devices supported by SoapySDR only the devices in the related closed issues above are missing from SDRangel. And I did not see support for Perseus and the FCDs.

I do not like the idea of a "vendor and platform neutral SDR support library" because in my opinion there is no and can't be such thing but it can fill the gap for expensive devices like the USRP or closed source supported ones like the newer SDRplay devices.

[ast]

The "server mode version" sdrangelsrv will not run on any ARM machine in particular the Raspberry Pi. It will work only on x86_64 architecture and you will need a server based on Intel Xeon E5 series or better.

Thank you for the feedback on my request! I was under the impression that the SDRangel server only runs on more powerful hardware, maybe this is incorrect? I'm not so experienced with SDRangel. The only advantage of having a SoapySDR plugin would be the possibility of using more narrowband SDRs remote with a Raspberry Pi or similar board.

We are in the process of developing a 96kHz bandwidth Pi based SDR transceiver, but with very high dynamic range so we were interested in adding support for this in SDRangel, and since we already have a Soapy module and use SoapyRemote with GQRX (without tx of course), it seemed like a good way with some additional advantages.

I will look into what it takes to implement this as a plugin. Perhaps I can just do it myself.

[f4exb]

The server variant of SDRangel runs well on a Rpi3B using a 64 bit O/S like Arch Linux or OpenSUSE Leap 15.0. It would probably still work with a Raspbian armv7 O/S flavor since there is some processing margin although I would not recommend it.

I currently run two remote receivers using RPi3B on Arch Linux and RTLSDR with 48 and 24 KS/s rate and a 136/8 FEC. It has been running for a few weeks without issues.

The readme you quote is wrong in saying this wouldn't work on smallish SBC hardware and will get corrected in next version. I have had troubles with a RPi3B+ due to USB/Ethernet conflicts that I think have nothing to do with SDRangel.

For ARM devices I would still recommend the armv8 type with at least 4 A57 cores and an armv8 (64 bit) O/S. So far the following have been running successfully:

• Raspberry Pi 3B (not 3b+ due to above mentioned problems)
• RockPro64
• Pine A64

[ast]

Ok, that's great news. I will look into writing an SDRangel plugin for our device.

I have had troubles with a RPi3B+ due to USB/Ethernet conflicts that I think have nothing to do with SDRangel.

I have also experienced this... it really only works for limited bandwidth, up to 192ksps has worked well for me. It's a shame they put ethernet and USB on the same bus. Our device use i2s and I have found that to work much better.

[f4exb]

It appears that a pair of plugins (source and sink) is enough. SoapySDR acts as a wrapper with an arbitrary number of Rx and Tx channels and thus stream handling will be very much like BladeRF v.2. Allocating SoapySDR devices at top level is unnecessary.

[f4exb]

Implemented in v 4.3.0

[f4exb]

Will be ...

[f4exb]

Now Implemented in v 4.3.0

[ast]

Awesome work! Thanks!

[erichahn]

I understand soapy is now supported, and UHD/USRP is supported under soapy. What is the status of getting a usrp b200 mini working under sdrangel at this point? I've been able to load the usrp b200 mini with cubicsdr utilizing soapy, but have not been successful with sdrangel.

Should clarify: status on windows and linux.

[f4exb]

I don't have a b200 mini so the status is unknown to me. You may try to find help from other users at the SDRangel discussion group: https://groups.io/g/sdrangel