Open Cornie8 opened 3 months ago
@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
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
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
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
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.
@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
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
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
@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
@fventuri,
thanks for your help, Unfortunately error report is only 2 lines.
@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
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:
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.
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 ;-).
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.
@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
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?
@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
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.
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:
Pretty complex but I am assuming it would work.
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:
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
@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
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