Radioconda with SDRPlay OOT Module Reports TypeError: set_sample_rate(): incompatible function arguments

[philCFG]

Radioconda installation on Windows 11 desktop PC using: radioconda-2024.05.29-Windows-x86_64.exe and no upgrades.
GNURadio version 3.10.10.0, Python 3.11.9.
SDRPlay API 3.15 using: SDRplay_RSP_API-Windows-3.15.exe
SDRPlay OOT module installed using: gnuradio-sdrplay3-3.11.0.2.post2+ga4071c6-py311hf0272db_0.tar.bz2
Simple flowgraph of RSP1A into GUI Frequency Sink.
Flowgraph does not run with following report:
Generating: "C:\Users\phila\Documents\GNURadio\RSP1A_Test_Radioconda.py"
Executing: C:\Users\phila\radioconda\python.exe -u C:\Users\phila\Documents\GNURadio\RSP1A_Test_Radioconda.py
Traceback (most recent call last):
File "C:\Users\phila\Documents\GNURadio\RSP1A_Test_Radioconda.py", line 185, in
main()
File "C:\Users\phila\Documents\GNURadio\RSP1A_Test_Radioconda.py", line 163, in main
tb = top_block_cls()
^^^^^^^^^^^^^^^
File "C:\Users\phila\Documents\GNURadio\RSP1A_Test_Radioconda.py", line 75, in init
self.sdrplay3_rsp1a_1.set_sample_rate(2000000.0)
TypeError: set_sample_rate(): incompatible function arguments. The following argument types are supported:
1. (self: gnuradio.sdrplay3.sdrplay3_python.rsp, rate: float, synchronous: bool) -> float
Invoked with: <gnuradio.sdrplay3.sdrplay3_python.rsp1a object at 0x00000173160932B0>, 2000000.0
rsp1a :info: total samples: [0,0]

Done (return code 1)

Running mamba update --all -y does not help.

On a Windows 11 tablet PC and the same versions of software installed in August 2024 it works OK but the SDRPlay: RSP1A block is different. It has additional parameters:
Gain Options Tab: RF Attenuation mode: dB/LNA state
Other Options Tab: Synchronous Updates

The latestversion of the SDRPlay OOT Module using: gnuradio-sdrplay3-3.11.0.8-py311h702a0ab_0.tar.bz2 results in:
ImportError: DLL load failed while importing sdrplay3_python: The specified procedure could not be found.
as reported in ryanvolz/radioconda#116.

I use GNURadio (not Radioconda) with SDRPlay RSP1A under Linux with no problems but do not want to install dual boot on my tablet PC.

[fventuri]

Instead of using gnuradio-sdrplay3-3.11.0.2-..., you may want to try to install gnuradio-sdrplay3-3.11.0.7-... from here: https://github.com/fventuri/gr-sdrplay3/releases/tag/v3.11.0.7
That's the last version that I think should work with radioconda.

Unfortunately the latest version gnuradio-sdrplay3-3.11.0.8-... throws that error The specified procedure could not be found., but I have no idea what is causing it and how to fix it.

Franco

[philCFG]

Franco
Tried that with a fresh installation of Radioconda but with the same result. v3.11.0.7 is the same as on my tablet pc and that works. I even copied the file from my tablet pc but I get the same error and the missing parameters in the RSP1A block.
I can't understand why the same files give different blocks in GNURadio Companion.

[fventuri]

Tonight I took a better look at those error messages, and I am pretty sure you are hitting the same bug discussed in this issue: #50. I fixed the problem in this commit: d1351b1

Unfortunately that commit is in 3.11.0.8, where I have that problem with The specified procedure could not be found.

This said, do double check the Python script generated by GNU Radio Companion from your flowgraph (RSP1A_Test_Radioconda.py).
I just looked at the block definition for the RSP1A (https://github.com/fventuri/gr-sdrplay3/blob/main/grc/sdrplay3_rsp1a.block.yml), and I see that all the calls there to set_sample_rate() pass two arguments, so I am kind of surprised your Python script calls set_sample_rate() with only one argument (unless you created or modified that code by hand, of course) .

Franco

[philCFG]

Franco
I confirm that the installation that does not work calls set_sample rate with a single arguement while the one that works has two arguments. The same is true for set_center_freq and set_gain. The installation that works has the second boolean arguement. I have not edited the generated scripts. Here is an extract of the Python script generated by GNU Radio Companion for the installation that fails:
self.sdrplay3_rsp1a_0 = sdrplay3.rsp1a(
'',
stream_args=sdrplay3.stream_args(
output_type='fc32',
channels_size=1
),
)
self.sdrplay3_rsp1a_0.set_sample_rate(2e6)
self.sdrplay3_rsp1a_0.set_center_freq(100e6)
self.sdrplay3_rsp1a_0.set_bandwidth(0)
self.sdrplay3_rsp1a_0.set_gain_mode(False)
self.sdrplay3_rsp1a_0.set_gain(-40, 'IF')
self.sdrplay3_rsp1a_0.set_gain(-float('0'), 'RF')
self.sdrplay3_rsp1a_0.set_freq_corr(0)
self.sdrplay3_rsp1a_0.set_dc_offset_mode(False)
self.sdrplay3_rsp1a_0.set_iq_balance_mode(False)
self.sdrplay3_rsp1a_0.set_agc_setpoint((-30))
self.sdrplay3_rsp1a_0.set_rf_notch_filter(False)
self.sdrplay3_rsp1a_0.set_dab_notch_filter(False)
self.sdrplay3_rsp1a_0.set_biasT(False)
self.sdrplay3_rsp1a_0.set_debug_mode(False)
self.sdrplay3_rsp1a_0.set_sample_sequence_gaps_check(False)
self.sdrplay3_rsp1a_0.set_show_gain_changes(False)
self.qtgui_freq_sink_x_0 = qtgui.freq_sink_c(
1024, #size
window.WIN_BLACKMAN_hARRIS, #wintype
0, #fc
2e6, #bw
"", #name
1,
None # parent
)

If I add the boolean parameters to the .grc file and run it from the Radioconda prompt it runs OK. This indicates that the SDRPlay block in Radio Companion is wrong but I installed the SDRPlay module using the same conda package file on both PCs. Could it be that running the conda package does not install the new files but picks up files still present from an earlier installation even though I uninstalled Radioconda and all other GNU Radio versions before doing a clean installation? This would account for the blocks missing the entries for RF Attenuation Mode and Synchronous Updates, which I expect are the missing boolean parameters. The installation on the PC that works was a first time installation of GNU Radio on that PC. Maybe there are a few files that I can copy from the working to the non-working system.

Phil

[fventuri]

Phil,
I think you hit the nail on the head.
Those Python scripts are actually generated by GNU Radio Companion using templates that are stored in YAML files in the grc subdirectory of your gnuradio-sdrplay3 module installation.
In that subdirectory you'll find a file called sdrplay3_rsp1a.block.yml; if you look in that file, you'll easily see how set_sample_rate() (and set_center_freq() and set_gain()) are called. Since you said you didn't edit the Python scripts by hand, I am 100% sure that those YAML files with the templates are different.

If they are, you may want to look at the timestamp of when the bad ones were created, and perhaps that might give you a better idea of what happened.

As you have already figured out, you could simply copy those YAML from the computer with the good ones to the other one with the bad ones (you may want to backup the old ones, just in case), regenerate the Python scripts, and I am pretty certain that the error message would go away.

Franco

[philCFG]

Franco
This is weird. I have searched my entire PC with the non-working SDRPlay blocks for sdrplay3_rsp1a.block.yml and there are only 2 instances, both of which are identical to the file on my working system and dated 08/07/24 and containing callbacks for set_sample_rate etc. that requires the parameter synchronous_updates. But when I view the block in Radio Companion I get a different one to that on the working system and without the field for setting synchronous updates true/false. It seems that Radio Companion has compiled a different YML file and does not compile the file loaded by the installation of a new conda package. I have tried the Radio Companion Reload Blocks function but it makes no difference. I also tried clearing Windows cache and temp files before installing Radioconda. I confirm that Radio Companion has no SDRplay blocks before installing the conda package.
I do have the workaround of editing the grc file but it is a bit clumsy to do it every time I edit the flowgraph.

Phil

[fventuri]

Phil,
please take a look at this message I posted in this repo almost three years ago: #21 (comment)
It looks like GNU Radio Companion has its own cache.

Franco

[philCFG]

Franco

Fixed, although I am still puzzled. It seems that the relevant cache is not within the Radioconda folder so is not deleted when Radioconda is uninstalled.
I could not find the file ...grc_gnuradio/cache.json. I found other cache.json files and many python cache files in Radioconda. I deleted them all. Now the flowgraph runs. The RSP1A block is still missing the option to set synchronous updates true/false but the flowgraph .py file includes the parameter for it in set_sample_rate etc. I can also see that the grc file contains the line synchronous_updates: 'False' in the sdrplay3_rsp1a_0 parameters list. Flowgraphs that did not run did not include this line.

Can you tell me which version of the block I should see: the one with the option for synchronous updates true/false or the one without it. My guess is the latter as the RSP1a probably does not support this feature.

Thanks
Phil

[fventuri]

Phil,
the term 'synchronous updates' actually refers to how the gr-sdrplay3 module calls the SDRplay API functions to change sample rate, center frequency, and gains.
In the default 'asynchronous' mode (when synchronous updates = false), the method is 'set-and-forget', i.e. the gr-sdrplay3 module makes the call to the API to update the value and it returns immediately. In 'synchronous' mode there's additional code in the gr-sdrplay3 module that waits for the SDRplay API to actually change the value (by checking a flag in the RX callback function arguments).
This 'synchronous' mode is only used in a few specialized cases where the GNU Radio application code needs to be absolutely certain that the sample rate or frequency or gain has actually changed before doing something else.
These two settings apply to any RSP model controlled by the SDRplay API, including the RSP1A.

To check the gr-sdrplay3 code and YAML files that were used and installed in say version v3.11.0.7, you can just run this git command in the gr-sdrplay3 folder:

git checkout v3.11.0.7

git will switch the files there to exactly what they were when the commit tagged with v3.11.0.7 was made.

Franco