again problems using 2 RSPDuo

[Cornie8]

First thanks a lot for providing gr_SDRplay3. It must have cost you a lot of time. For me using a single rsp-duo with 2 tuners works perfect. But I have 3 RSPDuos and would like to use then for beamforming. As soon as I use 2 RSPDuos in a GNU Radio flow graph connected to simple FFT sinks then I get the following error report:

Generating: "C:\Users\Corne\Documents\DUOtest\gr-sdrplay3-3.11.0.3-conda\examples\rspduo_dual_tuner12.py" Executing: C:\Users\Corne\radioconda1\python.exe -u C:\Users\Corne\Documents\DUOtest\gr-sdrplay3-3.11.0.3-conda\examples\rspduo_dual_tuner12.py sdrplay_api :warning: sdrplay_api version: 3.15 does not equal build version: 3.14 rspduo :error: SDRplay device not found: 180602B332 Traceback (most recent call last): File "C:\Users\Corne\Documents\DUOtest\gr-sdrplay3-3.11.0.3-conda\examples\rspduo_dual_tuner12.py", line 265, in main() File "C:\Users\Corne\Documents\DUOtest\gr-sdrplay3-3.11.0.3-conda\examples\rspduo_dual_tuner12.py", line 243, in main tb = top_block_cls() ^^^^^^^^^^^^^^^ File "C:\Users\Corne\Documents\DUOtest\gr-sdrplay3-3.11.0.3-conda\examples\rspduo_dual_tuner12.py", line 71, in init self.sdrplay3_rspduo_0_0 = sdrplay3.rspduo( ^^^^^^^^^^^^^^^^ RuntimeError: sdrplay device not found or invalid mode/antenna selection Done (return code 1)

I am using Windows11 with radioconda-2024.01.26-Windows-x86_64 , gr-sdrplay3-3.11.0.3, and I installed SDRPLAY API version 3.15 Unfortunately, my main expertise is with simulation using MATLAB or GNURadio, and I am helpless with debugging GNURadio OOT modules. If you could provide code with more debug statements included then I would be happy to run it on my RSP_Duos and give you the results.

Cornie

[fventuri]

@Cornie8 - thanks for the kind words about this GNU Radio module.

I think the reason for the error message "3.15 does not equal build version: 3.14" was because the recent changes to this OOT module for the latest SDRplay API (version 3.15) were still in the sdrplay-api-3.15 branch, and not yet in the main branch.

After reading your message, since those changes have been out for about three weeks, I decided this morning it was time to merge that branch in the main branch, so anyone who now builds from the main branch (which is the default one) should pick up the updated code for SDRplay API 3.15.

From your message is not clear to me how you got the GNU Radio gr-sdrplay3 module in your radioconda installation: was it part of radioconda-2024.01.26 (in which case we may want to ask Ryan Volz if he could update this specific module) or did you compile it there (in which case you just need to run a 'git pull' to pull the latest changes from the main branch and then rebuild it)?

Franco

[Cornie8]

Hello Franco,

thank you for your quick reaction and for updating gr-SDRPlay3. I noticed that radioconda hat an update so I downloaded radioconda-2024.05.29-Windows-x86_64.exe and made a graphical install in Windows. After starting GNU Radio Companion I could only see “soapy SDRPlay source”. So, it seems that gr-SDRPlay3 is not installed in the latest Windows version and also not in the previous Windows version of radioconda.

After that I wanted to install the gr-sdrplay3 OOT module from source using the conda recipes as described in https://github.com/fventuri/gr-sdrplay3/blob/main/WINDOWS.md (you have a link to Windows.md, this file does not exist).

Unfortunately this failed. I have attached the output of the radioconda installation and the output of the gr-sdrplay3 installation attempt

Cornie

gr_SDRPlay3_install.txt

[fventuri]

Cornie, that log file shows some dependencies errors in the conda build.

I am not very familiar with conda and I use Linux most of the time, so I looked at what they did for other GNU Radio modules like 'gnuradio-satellites', and I noticed that their 'conda_build_config.yaml' has just two lines (https://github.com/conda-forge/gnuradio-satellites-feedstock/blob/main/recipe/conda_build_config.yaml).

I just did the same thing in the new 'fix-conda' branch (https://github.com/fventuri/gr-sdrplay3/tree/fix-conda), but honestly I don't know if it will work or not.

If it doesn't work, I hope @ryanvolz has time to take a quick look and suggest how to fix this conda recipe.

Franco

[Cornie8]

Hi Franco,

I have tried now the installation of 2 different combinations of Radioconda and gr-sdrplay3 on W11 1) radioconda 24.05.29 with gr-sdrplay3 fix-conda branch 2) radioconda 24.01.26 with gr-sdrplay3 main branch

both installations not successful. The outputs are attached.

Until the experts have solved this problem, I went back to my previous installation. I have installed again Windows11 with radioconda-2024.01.26-Windows-x86_64, gr-sdrplay3-3.11.0.3, but now with SDRPLAY API version 3.14. The API mismatch reports have now disappeared, but I can still only use 1 RSPDuo. As soon as I enable the second RSPDUO in the flowgraph, I get an error. GRC file, Python File and GRC output are attached.

In DragonOS_Focalx_R35 on Linux I found exactly the same problems. So, I think it is not only a Windows problem. It would be interesting to know if this is just a problem of my implementation, or if this is a general problem. Do you know if anybody has successful used multiple RSPDuo’s in GRC?

Cornie

Radioconda2024.05.29_GR_sdrplay3_fixconda.txt Radioconda2024.01.26_GR_sdrplay3_main.txt test_2rspduo_GRC output.txt test_2rspduo_grc.txt test_2rspduo_py.txt

[ryanvolz]

I think the update with the fixconda branch is a step in the right direction, but I'm puzzled that the build log shows that it's failing by trying to install gnuradio-core=3.8.2.0. The issue with the main branch is that the conda_build_config.yaml is hard-coded to specify gnuradio 3.10.9, whereas radioconda 2024.05.29 comes with gnuradio 3.10.10. The fixconda branch should fix that problem by not forcing the older version.

Perhaps it will work if you

conda install conda-forge-pinning

and then change your conda build line to be

conda build .conda\recipe -m %CONDA_PREFIX%\conda_build_config.yaml

so that it is forced to use the current gnuradio version that the conda-forge packages are built against. That's maybe not the most robust approach, but it should work.

Another non-robust approach would be to specify

gnuradio_core: 3.10.10
gnuradio_extra_pin: ''

in conda_build_config.yaml, but then that has to be updated to track the gnuradio version.

[fventuri]

@ryanvolz - tonight I followed your suggestion, and I used the very basic conda_build_config.yaml in the fix-conda branch. I just had to add the specifications for the C and C++ compilers (https://github.com/fventuri/gr-sdrplay3/blob/fix-conda/.conda/recipe/conda_build_config.yaml), and it built without any errors. Something did fail in the tests (see attached log) but I was still able to create the conda package. I'll look at that problem tomorrow because it is getting late here.

@Cornie8 , @gozillah, please unzip the attached file gnuradio-sdrplay3-conda-package.zip, install the package in your radioconda, and let me know if it works for you.

Franco

Update: problem fixed; see here: https://github.com/fventuri/gr-sdrplay3/issues/41#issuecomment-2155607136

[fventuri]

I found the problem: I had a typo in the name of the GRC block for the new RSPdx-R2 model in the conda test section. I just pushed the update to the fix-conda branch. The conda package I just created for this gr-sdrplay3 GNU Raio OOT module is attached here.

Franco

gnuradio-sdrplay3-conda-package.zip

[Cornie8]

hallo Franco ,

The good news is that installing your new gr-sdrplay3 package with the newest radioconda and SDRPlay API 3.15 works perfekt. The bad news for me is that using 2 RSPDuos still creates an error report. Do you think trying to use SoapySDRPlay3 instead of gr-sdrplay3 could be an option?

Cornie

[fventuri]

@Cornie8 - happy to hear that the gr-sdrplsy3 package worked for your conda installation.

I don't have two RSPduo's here so I can't try what you have there, but if you post here the GNU Radio Companion flowgraph (the .grc file) and the full error error report, I can take a look and we can try to troubleshoot it.

Franco

[Cornie8]

@fventuri,

thanks for your help, Unfortunately error report is only 2 lines.

Cornie test_2rspduo_GRC output.txt test_2rspduo_grc.txt

[fventuri]

@Cornie8 - thanks for the flowgraph and for the output.

Since here I have a RSPduo and a RSPdx, I changed your flowgraph to use those two RSPs instead, and I too had the same error message sdrplay_api_SelectDevice() Error: sdrplay_api_Fail.

I ran a few more tests with GNU Radio here under Linux but I couldn't see anything wrong with the code in this gr-sdrplay3 OOT module.

Eventually I wrote a very simple progam in C (attached) that just uses the SDRplay API to select two RSPs. It too fails, which makes me think that either I am not using the SDRplay API correctly or there might be a problem in the SDRplay API itself.

@SDRplay - please take a look at the attached C program, and let me know if you think it should work.

Franco

two_rsps.zip

[gozillah]

I don't have two RSP devices either and I successfully installed and tested gr-sdrplay3 for the first time only yesterday with my single RSPduo. Lacking any practical experience with RSP device programming I may nevertheless make a few suggestions:

• Serach the Internet for other people having had the same problem. I found a couple of posts dating back as far as 2015. None of those I stumbled upon had a straight solution. And even if they had, they may be outdated.
• Ask chatGPT. I did this repeatedly in the recent past and got code proposals being about 90% right most of the time (because I had not specified the entirety of my problem). At least the proposals gave me a new perspective. I asked chatGPT "How can I access two SDRplay RSP devices programmatically?" Two_RSP_chatGPT.zip
• If sdrplay_api.dll does not support more than one device, any effort may be in vain. May be you could ask sdrplay.com for advice?

[SDRplay]

The API library can only access one RSP at any one time in the same user space. If you take a look at this paper by a student at Sheffield University, you can see how they accessed multiple RSPs within the same project... https://www.sdrplay.com/wp-content/uploads/2019/05/Time-and-phase-synchronization-with-two-RSP2s.pdf

Obviously you can access the two tuners within a single RSPduo in the same user space, the API is designed for that, but not multiple RSP devices.

[gozillah]

The University of Sheffield approach seems similar to KrakenSDR with its Heimdall solution. I haven't studied Sheffield's Matlab code, but somehow they accessed two RSPs from the same computer simultaneously.

Is the sdrplay_api.dll an instance per Windows or per process? Would it be possible to access two RSPs in in two separate processes on the same Windows?

Alternative approach: Ask sdrplay.com to develop a multi-SDR sdrplay_api.dll. It may be a sales booster ;-).

[SDRplay]

You can start multiple instances of SDRuno (as an example) and they can access different RSPs at the same time, so if you start a number of SoapySDRPlay3 instances they will be able to address different RSPs. Note you'll need to do something else (like in that paper) if you need them to be time/phase coherent.

The only thing you need to be aware of is the USB bandwidth/power requirements, so you may need extra host controllers if you want to add a number of RSPs - you can use an application such as USBTreeView to visualise the USB system and you can then see how your RSPs are connected to what host controller, etc.

[fventuri]

@SDRplay - Andy thanks for the suggestion.

In a similar fashion in GNU Radio you could run two GRC flowgraphs (one for each RSP), and connect them together (or to a third flowgraph) via ZeroMQ (ZMQ) blocks: https://wiki.gnuradio.org/index.php/Understanding_ZMQ_Blocks

Of course, as Andy said, if you need phase synchronization between the streams you should have for instance an external reference like the one outlined in that paper, since there's no guarantee that the two RSPs are going to be in phase.

Franco

[gozillah]

Brilliant. I haven't been working with ZMQ yet but got the point. Is there an easy way to open multiple GRC flowgraphs running in parallel?

Alternative approach using a Windows system level perspective: Each operating system process may have its own instance of sdrplay_api.dll independently serving its single (own) RSP, right? If this is the case then one could write a GRC source block spawning multiple processes each running gr-sdrplay3 accessing its individual RSP, forwarding the samples via shared memory to the block's main process and presenting the RSP's samples seperately or even phase coherent (with block-internal synchronization) at this block's outputs?

As Windows and Linux and MacOS are time-sharing OSes: Would there be sufficient overlap between the RSP's samples (aka USB data) to allow corherency processing? Or do RSPs buffer internally a significant amount of samples while the USB is congested be the other RSPs' data?

[fventuri]

@gozillah - I am not sure the GNU Radio main engine supports multiprocessing and sharing memory and data between different processes as you suggest.

On the other hand when you run a GRC flowgraph, you are actually running a Python script (which gets compiled by GNU Radio Companion). Since Python has native modules that support both multiprocessing (https://docs.python.org/3/library/multiprocessing.html) and multithreading (https://docs.python.org/3/library/threading.html), perhaps you could look at the Python generated by GRC, and use those modules to have multiple processes (or possibly threads) running them.

Franco

[gozillah]

I wrote a threaded (i.e. not multiprocessing) OOT block which is working very well. This particular OOT block creates a Dash server in a child thread to display processing results of the OOT block's work() function in a browser tab accessed at localhost:8050, i.e. totally outside GRC's QTgui and without using ZMQ.

• All OOT block GRC-I/O must remain in the OOT main thread (= the GRC thread in which the OOT block has been started by GRC). The GRC scheduler will not / cannot communicate directly with child threads that have ben created from inside the OOT block code.
• Variables and objects allocated before creating the child thread will be shared between main thread and the child thread throughout the lifespan of the threads (but this will not be the case in multiprocessing). Data and objects to be shared have to be allocated in the OOT block's init() function before creating the child thread at the end of the OOT block's init() function. After that communication between the main thread and the child thread is bidirectional via these variables or objects. Locking is advised.
• The work() function is exclusively used by the main thread.

I am assuming that there is a wast similarity between multithreading and multiprocessing (although not having tried this in practice yet). The main difference is that no variables or obejcts (= RAM) is automatically shared between main process and child process as with multithreading. Explicit shared memory or some other mechanism (sockets?) has to be used for communication.

This leads to the following architecture of a multiple RSP OOT block:

• There must be a common OOT source block for all RSPs. This OOT block runs in the process ("main process") created by GRC.
• User input of RSP Parameter settings and sampling output to other GRC blocks must be implemented in this main process, but not USB interfacing to the RSPs as the main propcess can hold only one instance of sdrplay_api.dll. However we will not need sdrplay_api.dll in the main process at all.
• The main process will spawn one child process per connected RSP, essentially implementing gr-sdrplay3 in each of these processes, each with its own instance of sdrplay_api.dll.
• In the OOT block's init() function and in the child process's init() function a shared memory connection will have to be established over which the child process gets its RSP parameters and returns the samples.

Pretty complex but I am assuming it would work.

[Cornie8]

I can only stand back and wonder about the number of proposals generated for solving the problem. Hope you find a good solution.

Maybe I describe what I intended to do:

• Synchronize my 3 RSPDuos to a Leo Bodnar GPS stabilized 24 MHz clock.
• Using an ADALM PLUTO SDR to insert a pilot signal (CDMA or OFDM) with an extra antenna (maybe not legal) or by coupling the pilot signal on each RX input.
• Use a remote unit (e.g. Raspberry pi or mini-PC) to receive and multiplex the 6 RX streams, with GNURADIO or API commands.
• Send RX Data over 1 Gbit Ethernet connection to a home PC.
• In the home PC with GNURADIO, GNU Octave or MATLAB demultiplex the signals, analyze the pilot signals and correct the delays.
• try several beamforming algorithms.
• Insert the beamformed signal somehow in a SDR program in real-time or by file transfer.

The RSPDUO was selected because the HW seems suited for beamforming: clock input, reasonable filtering, SW and VHF-UHF coverage, 14 bit ADC, 2 RX in 1 unit. Unfortunately, it seems that the SW-API at the moment is not suited for beamforming with >2 RX. As a fallback solution I could also use a Kerberos SDR with 4 RTL-SDR.

@SDRplay
If I leave the sample frequency constant and only want to change RX frequency of the RSPDuo, is then the ADC – ADC output buffer also reinitialized or not. In other words, do I need to make a new delay correction after each frequency change or not.

For checking if the RSPDuo’s are synchronized can I connect the clock output to the 50 Ohn input of other equipment or can that damage the outputs?

Any chance of adapting the API for easier use of multiple units?

Cornie

[fventuri]

@Cornie8 - for some of your questions you may want to go though the posts in the SDRPlayUsers group on groups.io (https://groups.io/g/SDRPlayUsers). For instance I just found this topic there that perhaps will help you: https://groups.io/g/SDRPlayUsers/topic/99582899 If you don't find an answer in those messages, feel free to ask your questions in that group, since there are several highly knowledgeable people there very familiar with the RSPduo running in diversity reception mode.

Also for useful information and discussion about GNU Radio, they have a mailing list called 'discuss-gnuradio' (https://lists.gnu.org/mailman/listinfo/discuss-gnuradio). In that page you'll also find the link to the mailing list archives.

Franco