Sdrplay support via Sdrplay binary API

[alphafox02]

So I got around to building sdrangel from source, which included soapysdr modules + the soapysdrplay module for api 3.x and up.

Now SDRAngel works with my rsp1a and the rspduo. What I’m requesting, which both CubicSDR and SigDigger support is the dual tuner mode of the rspduo. You see, in cubicSDR you can pick the master radio, use it, then open another instance or Cubicsdr and you will see the slave radio. In this mode you are limited to 2Mhz bandwidth and of course it’s all running on soapysdr.

In both cubicsdr and SigDigger it’s also possible to tell which connection method is being used, I.e local or via remote soapysdr. In Sdrangel the radio shows up twice with the same name, not really giving you a quick way of knowing which connection method is being used. I’ll take some screen shots if I’m not making any sense.

Thanks.

[f4exb]

I do not intend to develop much more around Soapy SDR. I would do something if this is simple and yes please elaborate more since I don't know really what you are talking about. It may turn out that Soapy SDR support is removed altogether since I think this was a big mistake.

[alphafox02]

It's possible it could be a simple fix, but I'm not sure. What I will say is overall it works great and I appreciate you having the option to add soapysdr in. It's allowed my RSP1A, RSPDUO, and the B205mini-i to function, and function rather well it seems.

I figured instead of trying to type everything out and me not making much sense, I'd do a quick video trying to show exactly what I'm talking about. If there's some way I could better capture what I'm trying to convey - I'm all ears. I just want to be helpful. Thanks.

https://youtu.be/LZTW2Ji7CI8

[f4exb]

OK much more clear now. Identifying the remote should be possible using the driver name as you show in the video.

For the SDRduo thing I don't know. I don't have a SDRduo and it is difficult for me to figure out how SoapySDR handles this. The SoapySDR plugin is of course totally dependent on SoapySDR interface. Also by construction it is not possible to duplicate a single I/Q stream coming from the device (if this is what master/slave is) or one should write a special plugin that does so but SoapySDR being a "generalized API" as they say if this is not implemented inside SoapySDR then this cannot happen in the present SoapySDR plugin.

[f4exb]

It is difficult to guess the principle of operation because very little detail is shared with the end user (alike the support library is not open source) but this phrase in the "key features" of the datasheet sheds some light:
" • Up to 10MHz visible bandwidth (single tuner mode) or 2 slices of 2MHz spectrum (dual tuner mode) "

If it was a dual ADC and therefore 2 independent I/Q streams then we would have 2x10 MHz bandwidth. Here I guess (only guess) that there are indeed two independent tuner chains that are merged into two adjacent bands before applying the ADC and carry both channels in a sort of FDM configuration in the same I/Q stream.

If this is the case it is too specific to be handled by the SoapySDR plugin.

This lack of transparency and share of how the thing really works is a choice of the SDRplay business and one of the reasons I am not too keen in supporting it.

[alphafox02]

I wish I new. I could ask the sdrplay people to chime in if that’s okay? So far all I’ve seen is two instances of Cubicsdr handle it or I can start SigDigger up and use soapy to start the “primary” interface and then open up CubicSdr and I will see the “slave”. This combo works. I don’t recall two instances of SigDigger working.

To be honest I’m just glad it works period, plus my b205 works. The other day I used your DATV plugin and the rsp1a to learn how to view DVB-S transmitted from gnuradio. If it’s simple to differentiate the devices like you mentioned with the driver name, that’d be perfect.

[alphafox02]

Maybe this will shed some light on dual tuner?

pothosware/SoapySDRPlay3#62

I use this for the api 3.x

https://github.com/fventuri/SoapySDRPlay3

[alphafox02]

This seems like a lot of work for the duo part of the initial request. I should mention again, I’m happy with the current support, maybe just a way to know which device is which and call it good? Unless there’s something in those links that make duo support easy I don’t want to waste your time. From what I can tell it appears you are right, it’s required a lot within cubicsdr and not just soapy to make it work.

[f4exb]

I don't have a Duo to check myself but if the Duo was implemented the Soapy way then you would see 2 different devices for the 2 different streams and you could use each of them in its own "device set" (R0 and R1). If this is not the case there is not much to be done. Again if there is anything specific to the Duo to be considered that maybe CubicSDR does consider then it defeats the very idea of SoapySDR. In fact if there is too much inter dependency between slave and master this will probably not work very well anyway only true dual channel devices like LimeSDR or BladeRF micro can be handled properly and have their own native plugins anyway.

[alphafox02]

I figured for now I will disable the soapy remote service as I don’t see a need for it to always be on. Now when I sdrangel I see one entry for my sdrplay equipment and it works well. While dual tuner support would be a nice to have, I don’t know if all the effort to make changes in sdrangel is worth it be maybe someone just going for a native sdrplay api approach? For example qt-dab has native support and also universal radio hacker is looking at adding the newer 3.x api support. I suspect this would perform better than soapy?

[f4exb]

SoapySDR local/remote differentiation done through prefixing label by the Soapy driver name. Implemented in v4.15.0

[f4exb]

Changed the title as a consequence of the discussion. SDRplay support via Soapy is not ideal although it hides the SDRplay binary blob interface away from the core of SDRangel. I am not sure I want to incorporate it directly in the build which would be a prerequisite for creating a SDRplay plugin in its own right. This issue is left open waiting on decision based on how easy or ugly it is to incorporate SDRplay binary blob.

[alphafox02]

Greatly appreciated.

[f4exb]

Moving compilation instructions to an Ansible playbook would probably make the specific steps of binary blob inclusion easier. Thus this may be a prerequisite.

[alphafox02]

Thought maybe this would be somewhat helpful. I see someone is trying to use the native sdrplay api in another project.

DSheirer/sdrtrunk#933

[Sammy1Am]

DSheirer/sdrtrunk#933

Just now noticed this mention (getting a Java wrapper around the SDRplay API took forever so I wasn't paying attention to that issue), and figured I'd chime in incase this information is useful to anyone else who comes across this:

The 3.x SDRplay API passes i/q streams through callbacks, with a separate callback for the stream from "Tuner A" and "Tuner B". Likewise, the API exposes two sets of tuner controls (A and B) for changing settings, frequency, etc.. I don't know on the hardware side of things exactly which components are actually discrete versus shared between the two tuners, but from an API standpoint they are largely treated as two distinct tuners connected to a single shared "device".

For what it's worth, aside from Java wrappers being a pain, the v3 API has been fairly straightforward to use. Most of the functionality is common between different models, so adding support for any of their hardware would allow the other models to at least work (but without any of the model-specific features).

[alphafox02]

I thought maybe this would be of help for native sdrplay api 3.x support,

https://github.com/szpajder/dumpvdl2/blob/master/src/sdrplay3.c

[fventuri]

Hi, I just found out about this thread today.

I wanted to let you know that I also wrote a GNU Radio module for the SDRplay family of RSP devices (https://github.com/fventuri/gr-sdrplay3); the code for that GNU Radio OOT module is much cleaner IMHO because I rewrote it from scratch (the code for the SoapySDRPlay driver instead is just modification after modification of the original code, and it shows).

I am not familiar with SDRangel (yet), but the RSPduo has basically four different ways that it can be used:

1. in single tuner mode; in this case it behaves exactly like all the other SDRplay RSPs (similar to a RSP2, since it has multiple tuners and antennas)
2. in dual tuner mode, which is typically used for diversity reception (but can also be used with different tuner frequencies); in this case the RSPduo can be seen as two different receivers (or one receiver with two channels, or ports; not sure what is the approach used in SDRangel)
3. as a 'master' device; in this case your application gets to use only "one half" of the RSPduo (with certain limitations, see below), and therefore can share the same physical hardware with another independent application
4. as a 'slave' device; your application gets to use only the other "half" of the RSPduo (same limitations a the 'master' case)

As I mentioned above, for use modes 2, 3, and 4, the main limitation is that the sample rate can only be one of 62.5kHz, 125kHz, 250kHz, 500kHz, 1MHz, and 2MHz; the sample rate can be different between say master and slave (it is achieved via decimation after all).

I don't know much details about how this is achieved in the hardware and how this is processed inside the libsdrplay_api library and in the sdrplay_api service, since they are all proprietary code of SDRplay, but if you have questions about that part, you can always ask your question to @SDRplay

As per how to use their library and the API (version 3.X), I have become pretty familiar with it after writing the SoapySDRPlay driver and the GNU Radio OOT module, so feel free to ask; in the meanwhile, I'll try to learn a little bit more about SDRangel (looks very nice!), and play around with it.

Franco

[Sammy1Am]

I don't want to derail this thread too far, but this may be a relevant discussion:

@fventuri , do you know off hand at what point in the API selection process the duo's modes can/should be selected? In other words, after I call GetDevices should I try to set the duo mode before calling SelectDevice? And for modes 2, 3, and 4, how does SelectDevice work? I'm guessing it still shows up as a single "device" from the API, but presumably with modes 3 and 4 it's still available to other applications even after you call SelecteDevice (if it's in 'master' mode).

Sorry if that's a bit of a haphazard collection of questions. Just figured I would try to take advantage of your experience before I dive into updating my own code to support the duo. (And hopefully it's useful information for SDRangel as well)

[fventuri]

@Sammy1Am , feel free to ask me questions about the RSPduo, since I have been through that a few months ago, and know very well what it is like to figure these things out (I really have to thank @SDRplay for his patience explaining these important details to me).

The various modes of the RSPduo work this way (I skipped a few details like the calls to sdrplay_api_LockDeviceApi() and sdrplay_api_UnlockDeviceApi() to try to keep things simple):

• first you use sdrplay_api_GetDevices() to get the list of available RSPs; the RSPduo is returned as a single device with a device id of 3 (SDRPLAY_RSPduo_ID)
• next you check the value of the 'rspDuoMode' field in that device struct; this value will tell you which of the many modes are available to your application: for instance if the single tuner, dual tuner, and master mode are available, this value will be: sdrplay_api_RspDuoMode_Single_Tuner | sdrplay_api_RspDuoMode_Dual_Tuner | sdrplay_api_RspDuoMode_Master
• same thing for the value of the 'tuner' field: it will be an 'or' of the tuners that are available for your application (TunerA or TunerB; or Tuner_Both in case of dual tuner mode)
• at this point you (or your user) chooses what mode/tuner among those available you want to select; for instance master mode with TunerA
• based on that choice you set the value for rspDuoMode, tuner (and rspDuoSampleFreq - either 6,000,000 or 8,000,000; typically 6,000,000) and finally call sdrplay_api_SelectDevice() by passing the pointer to your chosen device (which includes the selected mode/tuner) as the argument
• if another application (or another instance of your application) is already using the RSPduo in 'master' mode, then only the 'slave' mode will be available (i.e. rspDuoMode will only have sdrplay_api_RspDuoMode_Slave) and only the tuner that is not already used will be available. You also won't be able to change the already selected value of rspDuoSampleFreq, and several other parameters of your "half" of the RSPduo, since they are controlled by the master

Hope this helps getting you started,
Franco

[alphafox02]

This is exciting. Hoping the duo helps! @Sammy1Am

@fventuri off topic, but is there a version of your gr-sdrplay3 for gnuradio 3.8 (20.04)?I’ve been using gr-soapy with good success but I’d like to see how usage of the api works compared to soapy within gnuradio.

[fventuri]

@alphafox02 - no, unfortunately the version of gr-sdrplay3 only works with GNU Radio 3.9 (and above, since I try to keep track of the master branch there).

The reason is that when I started writing that code from scratch, GNU Radio 3.9 was already out, and one of the changes they made in that version was to switch from SWIG to Pybind11 for the Python bindings; my experience with SWIG has been non that great (to put it very mildly), so I decided to just write the pybind11 bindings.

According to this page: https://wiki.gnuradio.org/index.php/InstallingGR there is a way to install GNU Radio 3.9 on Ubuntu via a PPA, but it looks like the different ppas are not compatible, i.e. you can't have GNU Radio 3.8 and GNU Radio 3.9 at the same time.

Franco

[f4exb]

SDRPlay is unsupportive of Open Source and thus will not be supported in SDRangel. Period.

[SDRplay]

@f4exb You are obviously free to support or not support whatever hardware you want to. I am confused by your statement though. We support quite a number of developers of both closed and open source applications without any problems.

[alphafox02]

@f4exb hope all is well, sdrplay api3 is actually in a few open source applications natively. Still hoping to see you add as the equipment works okay with SDRangel via soapy, but surely better with native support. Here’s just a few examples of other projects with api support.

dumpvdl2
https://github.com/szpajder/dumpvdl2

qt-dab
https://github.com/JvanKatwijk/qt-dab

Via a wrapper
Sdrtrunk DSheirer/sdrtrunk#972

Plus, as mentioned above I believe, someone wrote a gnuradio native module.

[alphafox02]

At any rate, happy new year and great work on all the awesome updates.

[alphafox02]

Just a follow up, I can see native sdrplay support is now working in SDR++. That leads me to believe SDRPlay is pretty supportive of open source, maybe this will be of help for SDRAngel

https://github.com/AlexandreRouma/SDRPlusPlus/tree/master/sdrplay_source

[fventuri]

I noticed that SDRangel has now support for SDRplay API version 3.07, thanks to this pull request #839 - I tried it here last night and it worked like a charm (I was able to listen to a 2m D-STAR repeater nearby).

Many thanks to @f4exb and @srcejon for this welcome addition!

Franco

[alphafox02]

Well dang, that’s awesome. Now I can remove my source version and go with one build! @SDRplay