Multiple RSPduo devices not evenly weighted

[L-Coleman]

Hey fventuri!
Thanks for all that you have done with this OOT module, its opened the door for a lot of cool projects. Your efforts are definitely appreciated. I ran into an issue on a current project where I run two RSPduo devices off of a Pi 4. Right now the flowgraph is just taking IQ data to dump to file. The API works as expected in recognizing and starting both devices; however, one takes about a factor of a hundred more samples of the other one. I tried breaking the system into two separate python scripts, but one gets full cpu power and the other gets next to nothing, same sample number result. The Pi 4 is running ubuntu server with GNU radio 3.10. Your OOT is built with the independent tuner fix applied the library files, though each RSP is running single tuner in this case to get a larger bandwidth.

Is there a way that I can fix this to evenly weight the radios so they can run concurrently?

[fventuri]

@L-Coleman - first of all thanks for the nice words!

I only have one RSPduo here, and I am leaving tomorrow morning for a couple of weeks of vacation, so my suggestion for now is to try to figure out if this problem is due to this specific GNU Radio block, to how GNU Radio works, or something else.

What I would like you to try if you have time is to build and run a little utility I wrote a few months ago called dual_tuner_recorder in the repository dual-tuner-experiments (https://github.com/fventuri/dual-tuner-experiments).
That program allows you to record the I/Q stream(s) directly from the RSPduo, and can be used with both tuners set to the same value (for instance '-f 100e6' to set the center frequency to 100MHz for both tuners) or with different values ('-f 100e6,200e6' sets the first tuner to 100MHz and the second one to 200MHz) - this applies also to many other parameters like gains, AGC notch filters, etc
The only thing to be aware is that it wants the 'internal' sample rate; i.e. for an output sample rate of 2Msps in dual tuner mode, you have to set the sample rate to 6Msps (6e6) and the IF frequency to 1620kHz (see the usage examples in the README in that repository).

Once you have it running for the first RSPduo, then start a second instance for the second RSPduo - if you see the same problem of one instance taking much more CPU and writing many more output samples than the other one, then it is possible that there is a problem with the SDRplay API.

If instead using dual_tuner_recorder everything works as expected, then my suspicion is that it could be a GNU Radio problem, and we'll have to look at that when I am back.

Franco

[L-Coleman]

Thank you for the response, Franco! Please don't stop your vacation to look at this, but I am posting an update now while its fresh in my head. I have tested your utility program on a couple of setups and I have some more information. If I run both RSP devices simultaneously on my laptop with either the utility or gnu radio there are no problems. If I run the utility program on the same raspberry pi that I failed to run GNU radio script on, I get tons of dropped samples on the second device. This happens regardless of how conservative I make the settings. The Pi is writing the files to /dev/shm (to use RAM speeds instead of writing to the microSD) and I'm not taking up even half of the RAM allocation with the file size.

This seems like it could be an issue with the API and the ARM architecture of the Pi. It also could just be the processor chip on these Pi4's, but I dont think I'm at the limit yet. I might try overclocking it to see what happens. I'll keep you updated about anything else I find.

[fventuri]

@L-Coleman - I am back from vacation and catching up on my emails and messages.

From your findings it does look like it might be an issue with the SDRplay API (or perhaps with the USB implementation in the Raspberry Pi; it would be interesting to try with a different type of SBC to see if it happens there too).

You may want to create a technical support case with SDRplay with all this information (especially running the very simple utility program since it just calls SDRplay API functions) to see if they can reproduce the problem, and perhaps come up with suggestions or a fix in the next version of the API.

Franco

[djl2020-ddd]

Hello, I was wondering what version of API you are using, I can't even use two rspduo at the same time, please share if you can. (Or is there a way to share your image file?)