Problem managing two data stream from SDRplay RSPduo

[AugustoMarziani]

Hi everybody!
I am working on a project. The aim of this is to measure the power of the two signals at the same frequency coming from the RSPduo (diversity mode). I need to filter the two channels to reduce the noise bandwidth before measuring the power.
The problem is that, when I try to filter the data through the FFT low pass filter block, the processing crash.
If I use only one filter, and the other channel without, and setting the option of 4 threads, it goes on. If I use a filter on both channels it gets stuck.
I do not understand why it happens. It does not generate errors on the gr console, but I only see a horizontal line in the graphs and the code seems to be stuck (other operations are not working).

Attached the block diagram of the first part of the project.

The first block is a python custom block. It is a pass thorugh for the two signal, while it retrieve the frequency for the tuner from an external file.

Any suggestion to solve this problem? Can someone help me closing this project?
Thanks in advance!!

[fventuri]

@AugustoMarziani
Since I don't have your custom block, I ran a test for a couple of minutes with the attached flowgraph (RSPduo -> dual FFT low pass filters -> GUI Frequency Sink), and it seems to work for me.

I used the gr-sdrplay3 code from the new branch fix_race_condition_on_ring_buffer (https://github.com/fventuri/gr-sdrplay3/tree/fix_race_condition_on_ring_buffer).

Please try building and running your workflow using this latest branch, and let me know how it goes.

If you still are having problems, please try to run a simple test with just three blocks: the RSPduo source, your custom block, and a GUI frequency sink, to see if it works.

If that very simple test still gets stuck, see if you can generate a core dump and analyze it with gdb/coredumpctl, as I mentioned in the other thread here: #9 (comment)

In bocca al lupo,
Franco

simple_test.grc.gz

[AugustoMarziani]

@fventuri thanks a lot. So now the original error seems to be solved. But another one appeared. It seems that in this way the SDR only work with the Automatic Gain Control setting turned on. If I disable it, I get the error:
gr::log :ERROR: rspduo0 - sdrplay_api_Init() Error: sdrplay_api_Fail
I tried it with the "fix_race_condition_on_ring_buffer" branch and the simplified code. With the same configuration but single channel it works. Advanced options are: IF att =40, RF att =70, AGC set point = -30.

I just realized that in dual channel mode, the attenuation levels are not the same as for the single channel. There is a maximum level of RF att = 40 dB, more than this generate the above error. Is there a way to bypass that?

[AugustoMarziani]

@fventuri
Ciao Franco,
if you think it could be easier and you would like to help me even more, we could get in touch and show you remotely the project. Maybe it's a a problem with an easier solution than what it seems. I would need to solve this problem as soon as possible.. you know how it works at the university.. :-(

[fventuri]

@AugustoMarziani

Ciao Augusto,
I didn't do very extensive testing with the RSPduo (I mostly use the RSPdx, but I do have an RSPduo to check things out), so it is very possible that my code is sending an invalid configuration before invoking sdrplay_api_Init() (https://github.com/fventuri/gr-sdrplay3/blob/master/lib/rsp_impl.cc#L524); this is what normally triggers the error you are seeing sdrplay_api_Init() Error: sdrplay_api_Fail.

To understand the exact reason of that invalid configuration (so I can fix the bug), I need you to do two things:

• uncomment the line with print_device_config() (https://github.com/fventuri/gr-sdrplay3/blob/master/lib/rsp_impl.cc#L506), so that the module will print the full configuration send to the RSPduo right before calling sdrplay_api_Init(); rebuild and reinstall the gr-sdrplay3 module after this change
• next in the RSPduo source block in gnuradio-companion, go to Properties -> Other Options and enable the option 'SDRplay API debug mode (DEBUG)`

After that, rerun your GNU Radio flowchart; it will fail again, but it will print the full configuration on the terminal.
Finally in either /var/log/messages or in journalctl, you should see lines with the actual reason of that failure; they look like these:

Jul 27 20:39:08 fvdesktop sdrplay_apiService[3669]: [6722]: devIdx0: sdrplay_apiService_rsp: checkTunerParamLimits: ERROR: gain gRdB out of range (1:20) = 59
Jul 27 20:39:08 fvdesktop sdrplay_apiService[3669]: [6722]: devIdx0: sdrplay_apiService_rsp: Init: ERROR: Tuner1: checkDeviceParamLimits returns error 3

(as you can see in this case the value of the gain reduction was out of range).

Having the information should allow me to understand exactly what's going on and hopefully be able to fix this problem quickly.

Unfortunately between work and family, I don't have much time to get in touch directly, but if you send me the information above, I should be able to help you.

Saluti,
Franco

[AugustoMarziani]

@fventuri
Thanks again. It seems there is something wrong with the initialization for sure. What I get from the same test you did it's:

ott 07 11:27:39 mekap-Milan sdrplay_apiService[689]: [26954]: devIdx0: sdrplay_apiService_rsp: bridge_Bypass001Trim: bridge_Bypass001Trim: reg13=0xd reg14=0xe ott 07 11:27:39 mekap-Milan sdrplay_apiService[689]: [26954]: devIdx0: sdrplay_apiService_rsp: setGr: ERROR: parameter out of range (absolute gRdB=1 LNAstate=40) ott 07 11:27:39 mekap-Milan sdrplay_apiService[689]: [26954]: devIdx0: sdrplay_apiService_rsp: setGr: ERROR: minGr=1 maxGr=20 band=59 AmPortSel=0 numStates=0 numStatesAMPort=10 numStatesAM=5 numStatesLBand=7 ott 07 11:27:39 mekap-Milan sdrplay_apiService[689]: [26954]: devIdx0: sdrplay_apiService_rsp: initHw: Tuner3: initHw: setGr() Error 0x00000003 ott 07 11:27:39 mekap-Milan sdrplay_apiService[689]: [26954]: devIdx0: sdrplay_apiService_rsp: Init: ERROR: Tuner3: initHw returned error 3 ott 07 11:27:39 mekap-Milan python3[26923]: [26960]: sdrplay_api: Init: ERROR: Failed to initialise device

Attached the full debug info.
Another thing I noticed it's that looking at the output on the gr-companion shell, if I change the attenuation from 20 to 30 for example, it seems like the setting are always the same. Maybe there is some misconfiguration in sending parameters for dual channel mode.

Tuner3 refers to dual channel mode?

Saluti,
Augusto

debug_mekap.txt

[fventuri]

@AugustoMarziani - thanks for the debug info; it helps me understand what is the problem.

The LNA state is not a gain (or gain reduction), but it is rather a value/index that tells the RSPduo what the the gain reduction in the RF stage should be (and it is dependent on the RSP model, on the frequency range, and on the antenna input).

To better understand what I mean, please take a look at the tables in section 5 (page 38) of the SDRplary API Specification Guide (I think the latest version is this one: https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.07.pdf): as you can see for the RSPduo the LNAstate value can only be in the range [0-9] (depending on the frequency), and therefore the value of 40 is out of range.

Also another document that you might find useful is the 'RSPduo Technical Information' (https://www.sdrplay.com/wp-content/uploads/2018/06/RSPDuo-Technical-Information-R1P1.pdf); in that document at pages 14-16 you'll find a block diagram of the RSPduo that should help you have a good idea of how all the various components of the RSPduo work together.

Ciao,
Franco

[AugustoMarziani]

@fventuri
Ciao Franco,
I already saw that table. What I am setting into the SDRplay menu is the Attenuation, so I expect it to be the sum of LNA and Mixer Attenuation, that results in the LNA state variable. What I do not understand is that the value 70 that I put in, is good when using a single channel, but not when I use both of them. Even other values, less then the maximum of 62. Anyway, if it's the maximum, why is it acceptable for the single channel?
I will make a try to see if the attenuation for some reason is translated into LNA state, even if also the value of 30 should be rejected.

[fventuri]

@AugustoMarziani
Ciao Augusto,
first of all, sorry for the confusion: I use the direct value of the LNA state in a different project (the SoapySDR driver SoapySDRPlay3), while in this GNU Radio module gr-sdrplay3 the user selects both IF and RF attenuation in dB; I should have checked that before writing my previous comment.

Anyway, in the properties for the gr-sdrplay3 block, under 'Gain Options', I see two attenuation settings:

• IF attenuation
• RF attenuation (which gets translated to LNA state inside the module code)

I just ran the RSPduo dual tuner example from the repository (https://github.com/fventuri/gr-sdrplay3/blob/master/examples/rspduo_dual_tuner.grc), changing the dual tuner configuration to 'diversity reception', and setting the IF attenuation to 40dB and the RF attenuation to 70dB (as shown in the picture above), and in my case the flowchart ran without any errors (I can see the RF spectrum changing in the frequency sink window).

Franco

[AugustoMarziani]

Hi Franco,
during these days I was on leave, and I will not be available also during this week.. I will try to test again everything tomorrow. Can you please tell me which API and gnuradio version are you using?
Thanks in advance,
Augusto

[fventuri]

@AugustoMarziani - no problem if you are on leave; you always know how to reach me here on GitHub if you need help.

Here I run the Linux distribution Fedora version 34, SDRplay API version 3.07 (which I think is the latest available for Linux), and GNU Radio built directly from the master branch of their repository (right now the exact version I have is v3.10.0.0git-565-ge50c3f80).

Ciao,
Franco