fventuri/gr-sdrplay3

Out-of-tree GNU Radio module for SDRplay RSP devices - SDRplay API V3.X

gr-sdrplay3: GNU Radio OOT module for SDRplay RSP devices (SDRplay API V3.x)

This OOT GNU Radio module supports the following SDRplay RSP devices:

• RSP1
• RSP1A
• RSP1B
• RSP2
• RSPduo (all modes of operation)
• RSPdx
• RSPdx-R2

This module uses some features of GNU Radio (like pybind11 for Pythin bindings) that are only found in GNU Radio 3.9 and newer versions (it should build and run without problems using GNU Radio 'main' branch).

Important notices

• As mentioned above this module requires GNU Radio version 3.9 or a newer version (ideally GNU Radio 'main' branch).

• For GNU Radio versions 3.10.x and higher (for instance on Ubuntu), please use the code in the 'main' branch. The 'maint-3.10' branch is there only for historical reasons, but I don't see any good reasons to use it.

• The code in the 'main' branch requires the latest version of the SDRplay API (v3.15 at the time of writing). If you have to run this module with an older version of the SDRplay API, please use the code in the 'sdrplay-api-3.07' branch (which will not have further updates).

• detailed instructions on how to run this OOT module 'gr-sdrplay3' on Windows with the radioconda GNU Radio installation are in this document.

Dependencies

This module requires SDRplay API V3.X (prefereably the most recent version).

The latest API can be downloaded from SDRplay here: https://www.sdrplay.com/api

The SDRplay API should be installed before this module is built.

Build and installation

cd gr-sdrplay3
mkdir build && cd build && cmake .. && make
sudo make install
sudo ldconfig

Credits

• Tom Breyer, DJ6TB for providing the very useful FM receiver example

License

GNU GPL V3 (see LICENSE)

gr-sdrplay3's Issues

How do I change frequency while the flowgraph is running?

Hi @fventuri
I was (and still am) using an older version of the GNURadio API on my Raspberry Pi.
I need to change the frequency of the radio after a certain interval of time and I was doing right after tb.Start(True).
I did not want to use threads because I also want to get binary dumps in a different file each time I change the frequency, using the file_sink block.
I made this work in python by

1. Locking the flowgraph
2. Changing the frequency
3. Disconnecting the file sink block
4. Changing the output filename
5. Re-connecting the file sink block
6. Unlocking the flowgraph
7. Let it run for a certain amount of time and then repeat the above steps

I am doing this in a loop
Now I have started working on a Ubuntu Machine that has the latest API version and thus the blocks and the python code generated are also changed a lot.
The logic I was using previously isn't working anymore. I see a lot of things in the main() function - qa.exec(), tb.show(), signals, etc.
That is not an issue, my problem is - I am unable to change the frequency like I was able to, using the above logic

Could you please
First - suggest a better way, if there is, to do the above steps
second - help me solve this problem of not being able to change the frequency and save it on a different file each time

USE_LOWIF

Thank you for providing this package! I had a problem using it to receive WWVB on 60 kHz. That resolved when I disabled USE_LOWIF and the agc initializations. The flowgraph tunes the RSP to 250 kHz with 300 kHz bandwidth, 500 kHz sample rate. Without this I saw an approximately 2 Hz modulation that swamped the weak signal.

diff --git a/lib/rsp_impl.cc b/lib/rsp_impl.cc
index 312999a..4e288a1 100644
--- a/lib/rsp_impl.cc
+++ b/lib/rsp_impl.cc
@@ -13,7 +13,7 @@
 #include "rsp_impl.h"
 #include "sdrplay_api.h"

-#define USE_LOWIF    // to be consistent with the current behavior
+//#define USE_LOWIF    // to be consistent with the current behavior

 namespace gr {
 namespace sdrplay3 {
@@ -171,7 +172,9 @@ double rsp_impl::set_sample_rate(const double rate)
         }
         sample_rate = rate;
         if_type = sdrplay_api_IF_Zero;
+#ifdef USE_LOWIF
     }
+#endif /* USE_LOWIF */
     update_sample_rate_and_decimation(fsHz, decimation, if_type);
     return get_sample_rate();
 }
@@ -452,12 +455,14 @@ const int (&rsp_impl::get_lna_state_range(const std::vector<int> rf_gRs) const)[
 bool rsp_impl::set_gain_mode(bool automatic)
 {
     sdrplay_api_AgcT *agc = &rx_channel_params->ctrlParams.agc;
+#if 0
     agc->setPoint_dBfs = 0;
     agc->attack_ms = 0;
     agc->decay_ms = 0;
     agc->decay_delay_ms = 0;
     agc->decay_threshold_dB = 0;
     agc->syncUpdate = 0;
+#endif
     if (automatic && agc->enable != sdrplay_api_AGC_CTRL_EN) {
         // enable AGC
         agc->enable = sdrplay_api_AGC_CTRL_EN;

RSPdx with gnuradio 3.10.6.0 from homebrew on Mac M2 arm64 Ventura 13.3.1

example rspdx.grc file: replace star characters in `rsp_selector` parameter with empty string

gr-sdrplay3/examples/rspdx.grc

Line 152 in 2fe5e83

rsp_selector: '**********'

Currently, in example rspdx.grc, rsp_selector has the following value:

rsp_selector: '**********'

Because of this, running this example with e.g. gnuradio-companion /usr/local/share/gr-sdrplay3/examples/rspdx.grc will fail with

Generating: '/tmp/rspdx.py'

Executing: /usr/bin/python3 -u /tmp/rspdx.py

rspdx :error: SDRplay device not found: **********
Traceback (most recent call last):
  File "/tmp/rspdx.py", line 208, in <module>
    main()
  File "/tmp/rspdx.py", line 186, in main
    tb = top_block_cls()
         ^^^^^^^^^^^^^^^
  File "/tmp/rspdx.py", line 85, in __init__
    self.sdrplay3_rspdx_0 = sdrplay3.rspdx(
                            ^^^^^^^^^^^^^^^
RuntimeError: sdrplay device not found or invalid mode/antenna selection

>>> Done (return code 1)

FindLibSDRplay.cmake registry path (win32)

https://github.com/fventuri/gr-sdrplay3/blob/master/cmake/Modules/FindLibSDRplay.cmake also needs the path fixed

Query - support for dynamic frequency changing at runtime

Hi Franco,

I am writing a program called SPECTRE, which is a Python-based framework for recording and visualising radio spectrograms. With the help of your repository, I have integrated (so far!) an RSP1A and RSPduo into the program and I am currently using them for solar radio observations.

I am now looking to implement one of the program's critical functionalities: a receiver-agnostic frequency sweep, which will allow the program to capture spectrograms over a large frequency range. However, I cannot find any obvious way to dynamically change the centre frequency of the receivers at runtime. I have noted that message passing may be a route forward. I was hoping for your insight into:

1. Is it feasible to integrate message passing into gr-sdrplay3 source blocks?
2. Could this be used to update the centre frequency at run time?
3. If there is any way to do this currently (with no modifications to the gr-sdrplay3 block code)

I require good performance, in the sense that delay should be minimised between updating the centre frequency in the running flowchart and propagating to the receiver itself (I am looking to tag individual samples with the appropriate center frequency it was collected at). Currently, the program is limited to a fixed centre frequency, with the bandwidth capped by the sample rate of the receiver. So, being able to dynamically update the center frequency of the receivers would be a massive help in improving SPECTRE.

If you need any more information, please let me know.

For your interest, I have included an example image of a solar radio burst captured with SPECTRE and an RSPduo, thanks to gr-sdrplay3 :)

No module named 'sdrplay3' error

Hi!

I'm trying to make the SDRplay RSPdx module work in GNU Radio but, after installing the latest app version for Ubuntu and following the instructions of the readme file to build the block, I try to run a very simple example and get the error: ModuleNotFoundError:

Any ideas what might I be doing wrong?

Thanks!

I have to initially connect then disconnect a SDRconnect client after a reboot on the target to allow the gnuradio graph to work for a RSPdx-R2.

Hi,

I get an an invalid device or antenna error (have a RSPdx-R2) in the source block after a rebbot.

This stays the case until I start and the stop a SDRconnect client.

Any ideas as to why this might happen, have looked at the API and all looks good to me.

RSPDuo: startup frequencies

Hi!

Just noticed that at flowgraph startup RSPDuo in DualTuner & IndependentRX mode both channels uses same frequency, even if they are different. Looks like channel 2 always use frequency from channel 1. When you change frequency later, in realtime, all works fine.

In this animation, we see that at the beginning frequencies are different (8e6 and 18e6), but signals looks the same. Also we see that after changing frequency from 8e6 to 9e6 and then return back to 8e6 - signals now different, all works fine

Here is rspduo options:

And example flowgraph:
rspduo_test.grc.zip

tunerParams->ifType?

Is tunerParams->ifType accessible from my python app?

thanks

Use of boost::format() in GR 3.10

I've checked out the gnuradio-3.10 branch of this project like this:

git clone https://github.com/fventuri/gr-sdrplay3.git --single-branch --branch gnuradio-3.10 <MY_GR_ROOT>\gr-sdrplay3 

Correct?

But I've big troubles compiling it due to the use of boost::format() etc. From a clang-cl compile:

rsp_impl.cc(47,39): error: no member named 'format' in namespace 'boost'
        GR_LOG_ERROR(d_logger, boost::format("sdrplay_api_LockDeviceApi() Error: %s") % sdrplay_api_GetErrorString(err));
                               ~~~~~~~^
F:/gv/dx-radio/gnuradio/gv-build/include\gnuradio/logger.h(251,30): note: expanded from macro 'GR_LOG_ERROR'
        log->d_logger->error(msg); \
                             ^~~

etc. etc.

Shouldn't this really be:

--- a/rsp_impl.cc 2022-03-23 10:04:01
+++ b/rsp_impl.cc                                  2022-03-23 10:32:05
@@ -44,7 +44,7 @@
     sdrplay_api_ErrT err;
     err = sdrplay_api_LockDeviceApi();
     if (err != sdrplay_api_Success) {
-        GR_LOG_ERROR(d_logger, boost::format("sdrplay_api_LockDeviceApi() Error: %s") % sdrplay_api_GetErrorString(err));
+        d_logger->error("sdrplay_api_LockDeviceApi() Error: {:s}", sdrplay_api_GetErrorString(err));
     }

These errors happened recently. So perhaps there's was another breaking commit in GR-master repo that caused this?

Output stdout to GRC message port

This feature would be nice to have:

• Output of stdout to a gnuradio message port for further processing inside the python script

sdrplay3 not properly compiled

Hi.
I'm trying to compile master gr-sdrplay3 and everything works, however after doing a make install and running gqrx I'm not able to see in builtin source types sdrplay, while typing in Other sdrplay=0 or whatever to start the receiver it just doesn't work. Do I need to compile the whole gnuradio manually and patch CMakeFiles in gnuradio and all source files to get a working version of gr-sdrplay3 for gqrx? Unless I am unnecessarily changing the installation prefix from -DCMAKE_INSTALL_PREFIX=/usr.
Could this be the cause?

Timestamp with gr-sdrplay3

I'm trying to use the gr-sdrplay3 module with python and it's generally going well. I was wondering if there is a command for timestamping ? I'm trying to find the equivalent of this line for UHD / USRP

self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS)

Thanks!

Deadlock when staring sdrplay3 and sdrplay_api_server in state "ApiVersion Error: sdrplay_api_ServiceNotResponding"

Olá Franco,

Here an other deadlock. Opened a new issue because it is not related to the first deadlock I opened days ago.
To understand how I get in this situations. I am building a server that will control SDRs. As server it should stays online all the time and absolutely avoid crashes or deadlocks. That's why I am testing intensively start-stop-delete of sdrs. The first deadlock I mentioned days ago was occurring between1 and 100 cycles. This one occurred after 1317 cycles. Back to the problem.

From time to time sdrplay_api stops and responds "ApiVersion Error: sdrplay_api_ServiceNotResponding". Seems to be in this state, when trying to call sdrplay3, that this lock happens. sdrplay3 logged this lines just before the deadlock. So I suppose it occurres within the sdrplay3 code:
gr::log :ERROR: rsp1a0 - sdrplay_api_Init() Error: sdrplay_api_Fail
gr::log :INFO: rsp1a0 - total samples: [0,0]
gr::log :ERROR: rsp1a0 - sdrplay_api_ReleaseDevice() Error: sdrplay_api_ServiceNotResponding

I called ctrl+c and dumped the following trace hopping it will help.

Stack trace of thread 483136:
#0 0x00007fd82cb39d8d ___pthread_mutex_trylock (libc.so.6 + 0x9cd8d)
#1 0x00007fd829128918 _Z17sdrplay_MutexLockPvm (libsdrplay_api.so.3.07 + 0x5918)
#2 0x00007fd829128a08 sdrplay_api_LockDeviceApi (libsdrplay_api.so.3.07 + 0x5a08)
#3 0x00007fd82934dabf ZN2gr8sdrplay38rsp_implC2EhRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_13stream_args_tESt8functionIFbvEE (libgnuradio-sdrplay3.so.1.0.0git + 0x1babf)
#4 0x00007fd82935fe52 _ZN2gr8sdrplay310rsp1a_implC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_13stream_args_tE (libgnuradio-sdrplay3.so.1.0.0git + 0x2de52)
#5 0x00007fd82935ff70 _ZN2gr8sdrplay35rsp1a4makeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_13stream_args_tE (libgnuradio-sdrplay3.so.1.0.0git + 0x2df70)
#6 0x00007fd8293a3d80 n/a (sdrplay3_python.cpython-39-x86_64-linux-gnu.so + 0x24d80)
#7 0x00007fd82939bc21 n/a (sdrplay3_python.cpython-39-x86_64-linux-gnu.so + 0x1cc21)
#8 0x000000000053a8eb cfunction_call (python3.9 + 0x13a8eb)
#9 0x000000000051c24b _PyObject_MakeTpCall (python3.9 + 0x11c24b)
#10 0x0000000000537bb0 method_vectorcall.lto_priv.0 (python3.9 + 0x137bb0)
#11 0x000000000053430e slot_tp_init (python3.9 + 0x13430e)
#12 0x000000000051c6e7 type_call (python3.9 + 0x11c6e7)
#13 0x00007fd82c18af27 n/a (gr_python.cpython-39-x86_64-linux-gnu.so + 0x40f27)
#14 0x00000000005380a1 PyObject_Call (python3.9 + 0x1380a1)
#15 0x0000000000512d15 _PyEval_EvalFrameDefault (python3.9 + 0x112d15)
#16 0x000000000050f5e9 _PyEval_EvalCode (python3.9 + 0x10f5e9)
#17 0x0000000000526e6b _PyFunction_Vectorcall (python3.9 + 0x126e6b)
#18 0x0000000000512d15 _PyEval_EvalFrameDefault (python3.9 + 0x112d15)
#19 0x000000000050f5e9 _PyEval_EvalCode (python3.9 + 0x10f5e9)
#20 0x0000000000526e6b _PyFunction_Vectorcall (python3.9 + 0x126e6b)
#21 0x0000000000510da9 _PyEval_EvalFrameDefault (python3.9 + 0x110da9)
#22 0x0000000000526c43 _PyFunction_Vectorcall (python3.9 + 0x126c43)
#23 0x0000000000533e7a slot_tp_init.lto_priv.0 (python3.9 + 0x133e7a)
#24 0x000000000051c187 _PyObject_MakeTpCall (python3.9 + 0x11c187)
#25 0x0000000000516021 _PyEval_EvalFrameDefault (python3.9 + 0x116021)
#26 0x0000000000526c43 _PyFunction_Vectorcall (python3.9 + 0x126c43)
#27 0x000000000053799d method_vectorcall.lto_priv.0 (python3.9 + 0x13799d)
#28 0x0000000000515de0 _PyEval_EvalFrameDefault (python3.9 + 0x115de0)
#29 0x0000000000526c43 _PyFunction_Vectorcall (python3.9 + 0x126c43)
#30 0x0000000000510f92 _PyEval_EvalFrameDefault (python3.9 + 0x110f92)
#31 0x0000000000526c43 _PyFunction_Vectorcall (python3.9 + 0x126c43)
#32 0x0000000000510f92 _PyEval_EvalFrameDefault (python3.9 + 0x110f92)
#33 0x0000000000526c43 _PyFunction_Vectorcall (python3.9 + 0x126c43)
#34 0x0000000000537a44 method_vectorcall.lto_priv.0 (python3.9 + 0x137a44)
#35 0x0000000000634a0a t_bootstrap (python3.9 + 0x234a0a)
#36 0x000000000062a698 pythread_wrapper (python3.9 + 0x22a698)
#37 0x00007fd82cb35927 start_thread (libc.so.6 + 0x98927)
#38 0x00007fd82cbc59e4 __clone (libc.so.6 + 0x1289e4)

Problem installing SDRPlay API for Jetson Nano (ARM Ubuntu)

I have installed SDRPlay API 3.07, updated by GNURadio to latest, and followed the workflow given for Installation, still now able to successfully get SDRPlay working in conjunction with GNURadio Companion, for RSP1A.

Was successful in getting it to work for Raspberry Pi, but couldn't get the SDRPlay modules in the GNURadio Companion.

Automatic Gain Control (AGC) not working properly

Hello Franco

Playing with the AGC right now.

I did not checked your code and do not know how it is implemented but AGC is creating noise when jumping around trying to reduce or increase the gain. This is obviously not coming through in FM mode. But in AM it is absolutely problematic.

Test is simple. Disabling AGC stops this audible spikes.

Further more it seems that the SDR reacts to gain changes even in AGC mode. In this mode gain settings should not affect the gain at all.

Cmake issue

I'm trying to install gr-sdrplay3 on Ubuntu 22.04, and encounter the following error when I run cmake:

cmake ..
-- Build type not specified: defaulting to release.
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.65") found components: filesystem program_options regex thread
-- Using GMP.
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.74.0") found components: date_time program_options system regex thread unit_test_framework
-- Extracting version information from git describe...
-- Found pybind11: /usr/include (found version "2.9.1")
-- Using install prefix: /usr/local
-- Building for version: v3.11.0.4-0-gcaab7f71 / 3.11.0git
-- No C++ unit tests... skipping
-- User set python executable /usr/bin/python3.10
-- PYTHON and GRC components are disabled
-- Configuring donecmake ..
-- Build type not specified: defaulting to release.
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.65") found components: filesystem program_options regex thread
-- Using GMP.
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found suitable version "1.74.0", minimum required is "1.74.0") found components: date_time program_options system regex thread unit_test_framework
-- Extracting version information from git describe...
-- Found pybind11: /usr/include (found version "2.9.1")
-- Using install prefix: /usr/local
-- Building for version: v3.11.0.4-0-gcaab7f71 / 3.11.0git
-- No C++ unit tests... skipping
-- User set python executable /usr/bin/python3.10
-- PYTHON and GRC components are disabled
-- Configuring done
CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "gnuradio::gnuradio-runtime"
configuration "Release".

-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "gnuradio::gnuradio-runtime"
configuration "Release".

-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.

I have re-installed gnuradio and all of the dependencies, I think. I appreciate any suggestions.
Thanks!
-George

Isssues installing gr-osmocom with SDRPlay 3 and GNURadio 3.9

Hi @fventuri
I want to connect a HackRF One device with my NVIDIA Jetson nano. I have GNURadio 3.9 and SDRPay API 3.07 currently installed.
I used "https://github.com/osmocom/gr-osmosdr" and followed the instructions but got numerous errors
Do you suggest a different source/repo?
I am attaching the text file with the errors.
osmocom_errors.txt

Accessing agc->enable

Is agc->enable accessible from my python app? I'd like to be able to get the state of this flag.

thanks

Multiple RSPduo devices not evenly weighted

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?

'gnuradio.sdrplay3' has no attribute 'rspdxr2'

Fresh install Ubuntu 22.04, gnuradio and SDRPlay V1.3 API.

Get this error for example RSPdx-R2 block (SDRConnect app works ok and API is up and running)

Traceback (most recent call last):
File "/home/jetsondev/Documents/gr-sdrplay3/examples/rspdx_r2.py", line 207, in
main()
File "/home/jetsondev/Documents/gr-sdrplay3/examples/rspdx_r2.py", line 185, in main
tb = top_block_cls()
File "/home/jetsondev/Documents/gr-sdrplay3/examples/rspdx_r2.py", line 84, in init
self.sdrplay3_rspdxr2_0 = sdrplay3.rspdxr2(
AttributeError: module 'gnuradio.sdrplay3' has no attribute 'rspdxr2'. Did you mean: 'rspdx'

Thanks for any help you can give.

functions get_gain_range and get_freq_range should return an array

This two functions return a float. Expected an array of 2 values.

Scan spectrum

Hi again

This might not be an issue of your software, but I have implemented a simple flow to try to change the center frequency of the RSPdx device in real time and it crashes (after some time running, during which I am unsure as to whether it actually tunes to different frequencies).

Do you know if your implementation of the device allows for the center frequency to be changed in real time?

Thanks!

Do these blocks support remote operation?

Hi, not urgent but was wondering if these blocks support connection to a remote sdrplay device running as a server.

Have tried SoapyRemote but am having issues getting that working as documented here:

pothosware/SoapyRemote#106

Actual RSPduo center frequency is different than commanded frequency

When starting a flow graph, the initial frequency and often when changing the center frequency within the same band, is correct.

When changing the RSPduo center frequency for a different band, or back to the initial band, there is an offset in the RSPduo's actual center frequency, along with this error:

"rspduo :error: sdrplay_api_Update(Tuner_Frf) Error: sdrplay_api_RfUpdateError"

Further attempts would cause the band to be stuck one one band, as well as the same error message.

Changing from 80 to 40 meter selections, I have gone back and forth without issue. Changing from 80 to 20 or 40 to 20, I have consistency replicated this issue. I wonder if this has something to do with the RSPduo changing from its 2-12MHz band pass filter to its 12-30MHz band pass filter.

Setting the initial value for 20 meters, I can create the same error going to 40/80.

Varying the frequency using a transmitter into a dummy load, offsets of approximately 14KHz to 48KHz were observed. I have not been to determine what causes variation in offset.

Restarting the flow graph is successful in restoring the RSPduo center frequency back to it's initial value.

I have also observed that tuning the RSPduo like a direct conversion receiver causes stuttering and the same errors. Don't know if it is related. I have been using the RSPduo as an LO and then do the VFO tuning using the Frequency Xlating FIR filter.

Attached is a flow graph that can be used to replicate this problem.

test6.txt

ImportError: libgnuradio-sdrplay3.so.3.11.0git

Hello,

I have Ubuntu 22.04
1.installAPI.sh
2.buildsoapy.sh
3.gr-sdrplay3 OOT

I can get my RSPduo with the API but I have an error with GNU Radio :
File “/usr/local/lib/python3.10/dist-packages/gnuradio/sdrplay3/init.py”, line 24, in
from .sdrplay3_python import *
ImportError: libgnuradio-sdrplay3.so.3.11.0git: cannot open shared object file: No such file or directory

I don't really understand the problem so I move the libgnuradio-sdrplay3.so.3.11.0git file to /usr/local/lib/python3.10/dist-packages/gnuradio/sdrplay3/, but the problem remains the same.

Do you have some advice ?

Running on a pi5

I recently switched operating systems on a laptop from Ubuntu to the current stable Debian. I cloned this repository yesterday. I built it for Debian on the Intel laptop. It works fine. Since bookworm requires that I use a virtual environment if I want to install python modules, I had to set PYTHONPATH for the venv:
export PYTHONPATH=/usr/lib/python3/dist-packages
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.11/dist-packages

I also built this on the pi5 the same way.

When I run my python program on the pi5 it works up to the point when a set() function is called. I've tried:
set_center_freq(freq)
set_gain(-20.0, 'IF')

either of these calls give this exception or similar:

exception: set_center_freq(): incompatible function arguments. The following argument types are supported:
1. (self: gnuradio.sdrplay3.sdrplay3_python.rsp, freq: float, synchronous: bool) -> float

Invoked with: <gnuradio.sdrplay3.sdrplay3_python.rsp1b object at 0x7ffefd14e7b0>, 1380000.0

I call 'getters' before this and they all work.

thank you,
Bob

RSPDuo dual tuner independent rx - center_frequency in tuner 2 always identical to tuner 1

Hi Franco,

Firstly, thank you so much for your work on this repository, it has been hugely helpful for the project I am working on.

I have spent the evening trying to resolve an issue regarding the RSPDuo in dual tuner (independent rx) mode. I noticed that for a very simple flow graph:

which connects each output directly to a waterfall plot, that even when tuner 2 is set to a different frequency, it will be picking up an identical signal to that set for tuner 1.

With my antenna plugged in to tuner 1:

and tuner 2:

What's odd is that this is a very similar problem raised before: #8 , which you have already resolved! I am using the latest version of the API 3.14.0, however, I was running into the same issue using an older version 3.07.1. I have also verified I am using the latest version of the code from this repository, with the fix you listed in the previous issue.

Any guidance on how I can solve this is much appreciated.

Problem managing two data stream from SDRplay RSPduo

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!!

RSPduo RF and IF gain

First, thanks for creating this! Enjoyed some 80m CW this morning in stereo!

I understand that the RF and IF gain values are listed as attenuation instead of gain like on the SDRduo chart and on the chart, I believe the gain to be the combination of RF and IF gain. I've read that the IF gain has a range of +20dB to +59dB, How are is this expressed as attenuation, what are acceptable values for RF and IF gain in gr-sdrplay3?

Also, I tried using variables in the RF and IF attenuation fields, and got errors. Maybe my variables were set to invalid values?

Dead lock

Hello there,

Thank you for providing this useful code!

I am experiencing a dead lock when the destructor of sdrplay3 is called and after the function "void rsp_impl::stream_callback" acquired the lock. In this situation the call of the API function "sdrplay_api_ReleaseDevice" get blocked and just an api server restart can remove it what is very problematic.

You can reproduce it try it in the python interpreter as follow:

import sdrplay3
sdr = sdrplay3.rsp1a('',s = sdrplay3.rsp1a('', sdrplay3.stream_args( output_type='fc32', channels_size=1 )) sdrplay3.stream_args( output_type='fc32', channels_size=1 ))
del sdr

The destructor will not return.

Removing "ring_buffer.overflow.wait(lock," solves apparently the problem.

If you could help to resolve this issue, it would be great.

Thank you for your attention !!!

Module sdrplay3 not found

Hi everyone,
I've already installed gr-sdrplay3 and the API without any problem. However, when trying to execute gr-sdrplay3/examples/FM-Receiver-SDRplay with an RSPduo I get a ModuleNotFoundError: No module named 'sdrplay3'.
I'm using Ubuntu20.04 & GNURadio 3.9.3.

Can anyone help me with this?

The gnuradio console response:

Generating: '/home/user/Dev/gr-sdrplay3/examples/top_block.py'

Executing: /usr/bin/python3 -u /home/user/Dev/gr-sdrplay3/examples/top_block.py

Traceback (most recent call last):
  File "/home/user/Dev/gr-sdrplay3/examples/top_block.py", line 38, in <module>
    import sdrplay3
ModuleNotFoundError: No module named 'sdrplay3'

Using two RSPduo at the same time, the raspberry pi 4b connection was unsuccessful

Hi, I'm using your program to run an experiment that requires at least two rspduo to run at the same time, but I got an error connecting to raspberry pi 4b using two rspduo, i have therefore come to you for a solution.
I've seen questioners ask similar questions before, but since I'm not particularly familiar with all the RSPDUO, raspberry pie 4b, and gnuradio operations, I don't quite understand your solution. My version of gnuradio is 3.10.
thank you very much！
dingo-2020

Gain controls for LNA state

@flocentblack
As we discussed a few weeks ago, I just created a new branch called lnastate_gain_control (https://github.com/fventuri/gr-sdrplay3/tree/lnastate_gain_control) that allows direct control of the LNA state (instead of having to go though the RF gain reduction).

In order to use it, I created a new gain name called LNAstate so that you can now assign directly the LNA state by using something like this in Python:

    set_gain(3, 'LNAstate')

Its equivalent in C++ would be something like this:

    set_gain(3, "LNAstate");

I also modified the GNU Radio Companion blocks so that if you use an RF gain that begins with the prefix 'LNA' (for instance 'LNA3'), it will invoke set_gain(value, 'LNAstate') - you can find an example of this way of passing the LNA state in the example rspduo_dual_tuner_diversity_reception-LNA.grc (https://github.com/fventuri/gr-sdrplay3/blob/lnastate_gain_control/examples/rspduo_dual_tuner_diversity_reception-LNA.grc).

Please give it a try when you have some time, and let me know if it works for you.

Franco

Issue with mamba update and GNU Radio Companion

I was having an issue installing and running GNU Radio Companion on Windows 11 after running the following command as indicated in the install procedure:
.\mamba.bat update --all -y

The error was:
"The procedure entry point libintl_bindtextdomain could not be located in the dynamic link library C:\User\ [user] \radioconda\Library\bin\gdk_pixbuf-2.0-0.dll"

If I did not update mamba, then the install procedure worked fine and I could run GNU Radio Companion without error.

Building on headless pi5 / bookworm

I've installed SDRplay_RSP_API-Linux-3.14.0. That works.
I installed gnuradio from the bookworm repository.
gnuradio-config-info --version
3.10.5.1
so far, so good.

I built and installed gr-sdrplay3. I didn't notice any fatal errors.

When I run a no-gui python script it fails on this line:
from gnuradio import sdrplay3:
Traceback (most recent call last):
File "/usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/init.py", line 24, in
from .sdrplay3_python import *
ImportError: libgnuradio-sdrplay3.so.3.11.0git: cannot open shared object file: No such file or directory

Here's the output of the sudo make install:
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/cmake/sdrplay3/sdrplay3Config.cmake
-- Installing: /usr/local/include/gnuradio/sdrplay3/api.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rsp.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rsp1.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rsp1a.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rsp1b.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rsp2.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rspduo.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/rspdx.h
-- Installing: /usr/local/include/gnuradio/sdrplay3/sdrplay3_types.h
-- Installing: /usr/local/lib/aarch64-linux-gnu/libgnuradio-sdrplay3.so.v3.11-compat-xxx-xunknown
-- Installing: /usr/local/lib/aarch64-linux-gnu/libgnuradio-sdrplay3.so.3.11.0git
-- Set runtime path of "/usr/local/lib/aarch64-linux-gnu/libgnuradio-sdrplay3.so.v3.11-compat-xxx-xunknown" to ""
-- Installing: /usr/local/lib/aarch64-linux-gnu/libgnuradio-sdrplay3.so
-- Installing: /usr/local/lib/cmake/gnuradio-sdrplay3/gnuradio-sdrplay3Targets.cmake
-- Installing: /usr/local/lib/cmake/gnuradio-sdrplay3/gnuradio-sdrplay3Targets-release.cmake
-- Installing: /usr/local/lib/cmake/gnuradio-sdrplay3/gnuradio-sdrplay3Config.cmake
-- Installing: /usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/init.py
-- Installing: /usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/init.pyc
-- Installing: /usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/init.pyo
-- Installing: /usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/sdrplay3_python.cpython-311-aarch64-linux-gnu.so
-- Set runtime path of "/usr/local/lib/python3.11/dist-packages/gnuradio/sdrplay3/sdrplay3_python.cpython-311-aarch64-linux-gnu.so" to ""
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rsp1.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rsp1a.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rsp1b.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rsp2.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rspduo.block.yml
-- Installing: /usr/local/share/gnuradio/grc/blocks/sdrplay3_rspdx.block.yml
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/FM-Receiver-SDRplay.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rsp1a.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rsp1b.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rsp2.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rspduo_dual_tuner_diversity_reception-LNA.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rspduo_slave.grc
-- Installing: /usr/local/share/gnuradio/examples/gr-sdrplay3/rspdx-LNA.grc

Maybe the repository version of gnuradio is not the 'main' branch?

Thank you

No module named 'gnuradio.sdrplay3.sdrplay3_python'

After installing gr-sdrplay3 on Windows 10 and running a simple GNU Radio test I get the following error message:

Traceback (most recent call last):
File "C:\Users\Ime\miniforge3\envs\gnuradio\Lib\site-packages\gnuradio\sdrplay3_init_.py", line 24, in
from .sdrplay3_python import *
ModuleNotFoundError: No module named 'gnuradio.sdrplay3.sdrplay3_python'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "C:\Users\me\gr-examples\FM\FM_Receiver.py", line 26, in
from gnuradio import sdrplay3
File "C:\Users\me\miniforge3\envs\gnuradio\Lib\site-packages\gnuradio\sdrplay3_init_.py", line 28, in
from .sdrplay3_python import *
ModuleNotFoundError: No module named 'gnuradio.sdrplay3.sdrplay3_python'

I could not find a module named sdrplay3_python anywhere in the Internet. Please help.

again problems using 2 RSPDuo

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 ⚠️ 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

Problem with `dynamic initializer for 'antennas'

First off, I'm a bit confused whether this is the last / most up-to-date version of this block.

But my issue building this on Win-10 using MSVC, was plainly this C++ exception (from CDB after generating rsp1.py):

ModLoad: 5c790000 5c809000   f:\gv\dx-radio\gnuradio\gv-build\lib\site-packages\sdrplay3\sdrplay3_python.pyd
ModLoad: 5c970000 5c9b6000   f:\gv\dx-radio\gnuradio\gv-build\bin\gnuradio-sdrplay3.dll
ModLoad: 5ca00000 5ca0b000   f:\gv\dx-radio\gnuradio\gv-build\bin\sdrplay_api.dll
ModLoad: 74510000 745b3000   C:\WINDOWS\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9619_none_508d9c7abcbd32b6\MSVCR90.dll
(db0.d08): C++ EH exception - code e06d7363 (first chance)
(db0.d08): C++ EH exception - code e06d7363 (!!! second chance !!!)
eax=0084e278 ebx=0084e328 ecx=00000003 edx=00000000 esi=69f014a0 edi=5c9ab8dc
eip=769b46d2 esp=0084e278 ebp=0084e2d4 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200216
KERNELBASE!RaiseException+0x62:
769b46d2 8b4c2454        mov     ecx,dword ptr [esp+54h] ss:002b:0084e2cc=ea1bd2d3

At first (when running w/o the debugger), I thought it had something to do with mixing CRTs; MSVCR90.dll in SDRPLAY_API.dll
and vcruntime140.dll in my Python 3.6. But no. The ugly call-stack (deep inside a Python-call) shows it:

....
(Inline) -------- gnuradio_sdrplay3!std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,
gr::sdrplay3::_antenna,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,gr::sdrplay3::_antenna> > >::{ctor}+0x4a
0084e480 75fb9b77 gnuradio_sdrplay3!gr::sdrplay3::`dynamic initializer for 'antennas''(void)+0x19f

Since you had 3 equally named struct _antenna, I renamed them to become unique (struct _antenna_rsp1, etc.).
That seemed to have fixed it. No crash from MSVC's STL-code. I have a RSP1A which works fine.

Edit: my patch:

--- a/rsp2_impl.cc 2020-12-18 11:27:05
+++ b/rsp2_impl.cc 2020-12-18 15:10:34
@@ -33,12 +33,12 @@


 // Antenna methods
-struct _antenna {
+struct _antenna_rsp2 {
     sdrplay_api_Rsp2_AntennaSelectT select;
     bool high_z;
 };

-static const std::map<std::string, struct _antenna> antennas = {
+static const std::map<std::string, struct _antenna_rsp2> antennas = {
     { "Antenna A", { sdrplay_api_Rsp2_ANTENNA_A, false } },
     { "Antenna B", { sdrplay_api_Rsp2_ANTENNA_B, false } },
     { "Hi-Z",      { sdrplay_api_Rsp2_ANTENNA_A, true } }
--- a/rspduo_impl.cc 2020-12-18 11:27:05
+++ b/rspduo_impl.cc 2020-12-18 15:09:55
@@ -107,12 +107,12 @@


 // Antenna methods
-struct _antenna {
+struct _antenna_duo {
     sdrplay_api_TunerSelectT tuner;
     bool high_z;
 };

-static const std::map<std::string, struct _antenna> antennas = {
+static const std::map<std::string, struct _antenna_duo> antennas = {
     { "Tuner 1 50 ohm", { sdrplay_api_Tuner_A,    false } },
     { "Tuner 2 50 ohm", { sdrplay_api_Tuner_B,    false } },
     { "High Z",         { sdrplay_api_Tuner_A,    true } },
--- a/rspdx_impl.cc 2020-12-18 11:27:05
+++ b/rspdx_impl.cc 2020-12-18 15:10:15
@@ -33,11 +33,11 @@


 // Antenna methods
-struct _antenna {
+struct _antenna_dx1 {
     sdrplay_api_RspDx_AntennaSelectT select;
 };

-static const std::map<std::string, struct _antenna> antennas = {
+static const std::map<std::string, struct _antenna_dx1> antennas = {
     { "Antenna A", { sdrplay_api_RspDx_ANTENNA_A } },
     { "Antenna B", { sdrplay_api_RspDx_ANTENNA_B } },
     { "Antenna C", { sdrplay_api_RspDx_ANTENNA_C } }

Problems when using QT GUI Widgets to adjust RSP gains

I would like to use QT GUI Range widgets to adjust the RSPduo gains dynamically.

May be there is a reason, but I have no explanation for the RF gains' type to be string. Never mind, as long as I enter numerical gains there the flowgraph is working. However, if I input the ID of a QT GUI Range widget (e.g. 'rfatten0' in the above example) I get the following error message:

Traceback (most recent call last):
  File "C:\Users\me\gr-examples\sdrplay\Test.py", line 220, in <module>
    main()
  File "C:\Users\me\gr-examples\sdrplay\Test.py", line 198, in main
    tb = top_block_cls()
         ^^^^^^^^^^^^^^^
  File "C:\Users\me\gr-examples\sdrplay\Test.py", line 103, in __init__
    self.sdrplay3_rspduo_0.set_gain(-float('rfatten0'), -float('rfatten1'), 'RF')
                                     ^^^^^^^^^^^^^^^^^
ValueError: could not convert string to float: 'rfatten0'
rspduo :info: total samples: [0,0]

>>> Done (return code 1)

Whether the QT GUI Range value in 'rfatten0' is of type float or int does not seem to be relevant.

So for the time being I am remaining with the numerical values in the RF gains:

Starting this flowgraph provides the expected results (with some overload warnings). But as soon as I am interactively lowering the QT GUI Range value of 'ifatten0', the flowgraph stops with the following error message:

Traceback (most recent call last):
  File "C:\Users\me\radioconda\Lib\site-packages\gnuradio\qtgui\range.py", line 242, in changed
    self.notifyChanged(self.rangeType(value))
  File "C:\Users\me\gr-examples\sdrplay\Test.py", line 183, in set_ifatten0
    self.sdrplay3_rspduo_0.set_gain(-self.ifatten0, -{if_gRdB1}, 'IF')
                                                      ^^^^^^^^
NameError: name 'if_gRdB1' is not defined

>>> Done (return code 3221226505)

test.zip

Output type

For the Output type the user can choose between complex int16 and complex float32. To my knowledge the maximum bit number of the ADC for sdrplay devices is 14. Is there any benefit using 32 bit?

ImportError: generic_type: type "rsp" referenced unknown base type "gr::sync_block"

Background

System: Windows 11 64bit.
SDR device: SDRplay RSPdx

Radioconda installer (radioconda-2024.05.29-Windows-x86_64.exe) downloaded from:
https://github.com/ryanvolz/radioconda
(GNU Radio Companion working ok.)

SDRplay API 3.15 (SDRplay_RSP_API-Windows-3.15.exe) downloaded from:
https://www.sdrplay.com/api/
(SDRuno and SDRconnect working ok.)

GNU Radio OOT module for SDRplay RSP devices
(gnuradio-sdrplay3-3.11.0.2.post2+ga4071c6-py311hf0272db_0.tar.bz2)
downloaded and installed from:
https://github.com/fventuri/gr-sdrplay3/releases

Example flow graph file (rspdx.grc) downloaded from:
https://github.com/fventuri/gr-sdrplay3/tree/main/examples
(Flow graph displayed ok in GNU Radio Companion.)

Python file (rspdx.py) created ok.

Error Messages

However, when executing the flow graph the following errors are reported:

ImportError: generic_type: type "rsp" referenced unknown base type "gr::sync_block"
ImportError: generic_type: type "stream_args" is already registered!

The full messages are:

Executing: C:\Users\Alast\radioconda\python.exe -u C:\Users\Alast\Documents\GNU Radio\rspdx.py

Traceback (most recent call last):
  File "C:\Users\Alast\radioconda\Lib\site-packages\gnuradio\sdrplay3\__init__.py", line 24, in <module>
    from .sdrplay3_python import *
ImportError: generic_type: type "rsp" referenced unknown base type "gr::sync_block"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Alast\Documents\GNU Radio\rspdx.py", line 25, in <module>
    from gnuradio import sdrplay3
  File "C:\Users\Alast\radioconda\Lib\site-packages\gnuradio\sdrplay3\__init__.py", line 28, in <module>
    from .sdrplay3_python import *
ImportError: generic_type: type "stream_args" is already registered!

>>> Done (return code 1)

In addition, it produces the same error from a python prompt with:

from gnuradio import sdrplay3

I was really interested to hear about GNU Radio recently, and your module for SDRplay devices.
It will be a great way to demonstrate to school pupils how radio signals are processed.
So, a big thank you for making this available.

Alastair

Problem building gr_sdrplay3

Hello Franco,
I am trying to build gr_sdrplay3 on a Raspberry pi. It seems to be tricky as I do have to build almost everything from srcatch as the
packages I can download via APT are quite old.
Nevertheless afte a while I managed to build gnuradio (and a lot of dependencies boost gnuradio gr-osmosdr gr-sdrplay3 pybind11 pygccxml SoapySDR SoapySDRPlay spdlog volk) from the git repos.

Only gr-sdrplay3 throws errors during Cmake and I have no idea why. The build process seems to be quite complicated and
I have no Idea where to start.
Maybe You are able to give some hints.
Kind regards
Harald

I do get the following error messages running "cmake .." from the build directory:

...
-- Configuring done
CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:165 (add_library):
Target "sdrplay3_python" links to target "Python::Module" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
/usr/local/lib/cmake/gnuradio/GrPybind.cmake:260 (pybind11_add_module)
python/bindings/CMakeLists.txt:32 (GR_PYBIND_MAKE_OOT)

CMake Error at /usr/local/share/cmake/pybind11/pybind11Tools.cmake:165 (add_library):
Target "sdrplay3_python" links to target "Python::Module" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
/usr/local/lib/cmake/gnuradio/GrPybind.cmake:260 (pybind11_add_module)
python/bindings/CMakeLists.txt:32 (GR_PYBIND_MAKE_OOT)

CMake Error at lib/CMakeLists.txt:42 (add_library):
Target "gnuradio-sdrplay3" links to target "Python::Module" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?

CMake Error at lib/CMakeLists.txt:42 (add_library):
Target "gnuradio-sdrplay3" links to target "Python::Module" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?

-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly._

Problem compiling gr-sdrplay3 on Mac

@bob-uk reported the following problem:

On the issue of the gr-sdrplay OOT modules, I hadn't clocked their import so am looking at them now. As I said I have gr 3.8 loaded and running so have built 3.9 and installed it to a diffefent location, hopefully they won't trample on each other. I am running on mac Catalina and have some problems compiling gr-sdrplay3, both with clang and gcc/g++

in rsp_impl.h this construct fails "const double (&get_freq_range() const override)[2];" with a compiler error requesting a ')' before the override?
and then it is failing deep in the Xcode includes
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:1547:38: error:
implicit instantiation of undefined template
'std::__1::hash<sdrplay_api_ReasonForUpdateT>'
: public integral_constant<bool, __is_empty(_Tp)> {};

so a bit stuck on this route at present

Bob

Bandwidth setting AUTO does not "set the bandwidth to the largest value below the sample rate"

Hello Franco

Would be nice if you could check this issue. Setting Bandwidth to AUTO takes the lowest value of the allowed bandwidths and NOT "the largest value below the sample rate".

Test settings:
Sample rate = 5E6
Bandwidth = Auto

Result: Bandwidth = 2E5
Expected: Bandwidth = 5E6

Otherwise working very good. Thank you very much !!!

'gr-sdrplay3' module changes to defaults for AGC, DC offset correction, IQ imbalance correction

This topic is to discuss changing the defaults for AGC, DC offset correction, IQ imbalance correction in the 'gr-sdrplay3' module to be consistent with other SDRplay applications like SDRconnect and SDRuno.

These are the exact changes that would be implemented (depending on the feedback):

• IF AGC: the current default is disabled; it would be changed to enabled (with a speed of 50Hz)
• DC offset correction loop: the current default is disabled; it would be changed to enabled
• IQ imbalance correction loop: the current default is disabled; it would be changed to enabled

I imagine the choice between these options would depend on your use case for the 'gr-sdrplay3' OOT module. If you use GNU Radio and this module as a receiver to listen to a radio station, you might prefer having these useful features enabled by default; if you instead use your SDRplay RSP with GNU Radio for research and measurement purposes, you might prefer to leave the defaults unchanged.

You comments, suggestions, and ideas for improvement are most welcome!

Adjusting LNAstate

I'm trying to use a QT GUI Range (type int) to adjust RF Attenuation in a flowgraph.
I have the id for this variable defined as 'lna' and the default value is 0.
When I start the flowgraph it prints this in the console:

Traceback (most recent call last):
File "nbfm_gui.py", line 329, in
main()
File "nbfm_gui.py", line 307, in main
tb = top_block_cls()
File "nbfm_gui.py", line 145, in init
self.sdrplay3_rspdx_0.set_gain(int('lna'[3:]), 'LNAstate')
ValueError: invalid literal for int() with base 10: ''

Bulk/Isochronous transfer mode

Hey Franco :),
I'm trying to get my sdrplay rspduo to change the data transfer mode, which is part of the API. I found it quite difficult to find and had to go through a lot of trouble with the bindings and cmake builds on Windows. I think im close to achieve it .. But maybe it can be added as another instance or for the init parameters of the sdr such as: set antenna or bandwidht.. it is at the end just a 1 or 0 flag. Maybe I dindnt see something or maybe I'm totally wrong and there is a way to change the transfer mode. Please correct me if I'm wrong.

Have a nice day and thanks for the good work you guys have been doing !
Sincerly,
Pablo

RSPduo "Dual Tuner (diversity receiption)" Large Data Set Coherent Processing

I am reading data from gr-sdrplay3 RSPduo in "Dual Tuner (diversity receiption)" mode for large data set correlation processing (typically 2^20 samples per batch or even more). To maintain both processing batch size as well as correlation my processing needs vector input (vector size 2^20 samples or even more). So far I have been using two GRC "Stream to Vector" blocks to convert RSPduo's stream outputs into my processing's vector inputs. This is working quite well with a correlation S/N of rougly 30 dB at 2^20 samples per batch (or less dB with lower batch sizes), measured while feeding both tuners from the same antenna.

Collecting and processing 2^20 samples is creating several seconds of latency down my processing chain. In order to reduce latency introduced by the GRC "Stream to Vector" blocks I integrated the "Stream to Vector" conversion into the first block of my GRC processing chain (written in Python, sorry), but so far without success. Since doing this I have completely lost correlation. My (unsuccessful) approach is as follows:

• Instead of a sync block (as when using the GRC "Stream to Vector" blocks) I am using a basic block for my processing.
• "input_items[]" stream input from the RSPduo seems to be available in chunks of much less than 2^20 samples, typically variable between about 2^8 and 2^13 maximum.
• So in the general_work() function I created two buffers into which I am accumulating stream input samples of the respective inputs until they reach my processing batch (= former vector) size of 2^20. I am doing this in a Python while-loop where I am reading (per loop) all currently available input from one input and then all available input form the other input. After each step I am calling self.consume(which_input, how_many_items) to signal GRC the consumed samples.
• I then present these buffers to my block's correlation processing.

I suspect that I am loosing coherence in the abovementioned while-loop. Could it be that my Python implementation is so slow that it misses some samples on one input while processing the other? What could be a successful strategy to accumulate the stream samples without loosing coherence?