Re: European GNU Radio Days conference now live streaming

[Franco VENTURI]

To answer my own question, I saw this morning that yesterday afternoon's dev 
tutorials by Alex Krimm were posted on YouTube.
This is the link: https://www.youtube.com/watch?v=ce496ZCwlqA

Franco


> On 08/27/2024 7:39 PM EDT Franco VENTURI  wrote:
> 
>  
> Jean Michel,
> it looks like the YouTube link you sent out this morning does not cover the 
> dev tutorials presented by Alexander Krimm at 15:30 (Core API and Block 
> Development) and at 16:15 (Modern C++ and Advanced Techniques).
> 
> Were they recorded and do you or Alexander have the link for those as well?
> 
> Thanks,
> Franco
> 
> 
> > On 08/27/2024 2:44 AM EDT jmfriedt  wrote:
> > 
> >  
> > The European GNU Radio Days is now streaming at 
> > https://www.youtube.com/live/Pt77jXpzwFU
> > do not miss the introductory presentation and Eric Blossom's
> > perspective on GNU Radio development.

Re: European GNU Radio Days conference now live streaming

[Franco VENTURI]

Jean Michel,
it looks like the YouTube link you sent out this morning does not cover the dev 
tutorials presented by Alexander Krimm at 15:30 (Core API and Block 
Development) and at 16:15 (Modern C++ and Advanced Techniques).

Were they recorded and do you or Alexander have the link for those as well?

Thanks,
Franco


> On 08/27/2024 2:44 AM EDT jmfriedt  wrote:
> 
>  
> The European GNU Radio Days is now streaming at 
> https://www.youtube.com/live/Pt77jXpzwFU
> do not miss the introductory presentation and Eric Blossom's
> perspective on GNU Radio development.

European GNU Radio 4.0 Days 2024 video stream?

[Franco VENTURI]

Do you know if the European GNU Radio 4.0 Days 2024 
(https://events.gnuradio.org/event/23/) taking place next week at FAIR in 
Germany will be streamed somewhere for those who can't attend in person?
 
I am especially interested in the GNU Radio 4.0 presentations and tutorials for 
developers.
 
I looked on the page above and I couldn't find info about streaming, but 
perhaps I missed it.
 
Thanks,
Franco Venturi
 

Re: Cleaning up a git repository

[Franco VENTURI]

Thanks Marcus for the very useful information about git!
 
Another piece of advice I would like to give to those who start with to git is 
to make sure not to store passwords, credentials, API keys, or other 
confidential information in git.
 
While having 'build/' stored in git is an annoyance, having secrets and 
confidential information in git can be a very serious security risk, especially 
if those credentials allow access to a much wider (and perhaps expensive) set 
of resources than those you are actually using (I am thinking AWS tokens and 
similar secrets).
Once they are out on the Internet for everyone to grab, there's no going back; 
the best thing to do is to change those passwords/secrets immediately and hope 
for the best.
 
The safest thing to do is to store those confidential information outside of 
your git tree.
I also always append 'private' to my '.gitignore' (even if I don't use it), and 
use a directory called 'private' to store personal notes and other pieces of 
possibly related code that I don't want to share.
 
I also have the habit of running 'git status -u' before a commit, just to make 
sure I am not leaking something that shouldn't be out there.
 
Franco
 

> On 06/09/2024 8:04 AM EDT Marcus Müller  wrote:
>  
>  
> 
> Hi,
> 
> so as promised, my email about git.
> 
> Unless you and your advisors have explicitly said you should do that for now 
> to debug some build issue, you should not have your build/ folder in your git 
> (and you should not use git add --all / git commit --all unless you know 
> you're only commiting the files you worked on). The build directory is 
> regenerated by your CMake and Compiler runs, and is useless for other people. 
> On the contrary, if I check out your module, and try to build it, I suddenly 
> have git conflicts in build/!
> 
> So, to remove that from git's index, without deleting if from disk, you'd
> 
> cd gr-fec-_dev
> git rm -r --cached build
> 
> Because you don't want to see all the changes in there all the time, you 
> would add it to the "git ignore" file. That's easy:
> 
> echo build/ >> .gitignore
> 
> in the same directory. Now, because you're using VS Code, and other tools, 
> and macos leaves .DS_Store files all over the place, my whole approach to 
> getting rid of the files from the list of tracked files that you shouldn't be 
> tracking in git:
> Let someone else be diligent, and get a ready-made .gitigignore from them:
> 
> curl 
> 'https://www.toptal.com/developers/gitignore/api/VisualStudioCode,cmake,python,macos'
>  | grep -v '^lib/' > .gitignore
> # ^  ^
>^ ^  ^  ^ ^
> # |  |
>| |  |  | |
> # \--use the "curl" program to download "something"  |
>| |  |  | |
> #from a webserver to standard output \-- the "something" 
> being the URL   | |  |  | |
> # of  a  service  
> that  generates| |  |  | |
> # .gitigone files for 
>| |  |  | |
> # 
>| |  |  | |
> #   we use "|", the "pipe" symbol, to pipe the output of curl into the input 
> of "grep". -/ |  |  | |
> #   grep is a "regular expression filter";  you can tell it what to look for 
> in a line,|  |  | |
> #   and it will only output lines that match that.
>  |  |  | |
> # 
>  |  |  | |
> #   we're looking for lines starting with "lib/" 
> -/  | |
> # 
>  | | |
> #   actually, we inVert that match, so we're looking for lines NOT starting 
> with "lib/" ---/ | |
> #   (the generated .gitignore erroneously ignores "lib/", and we need to undo 
> that)  | |
> # 
>| |
> #   We redirect ">" the output of grep into the file ".gitignore".  
> -+-/
> 
> 
> 
> 
> Finally, I'd check that I'm now ignoring the files I want to ignore:
> 
> git ls-files --ignored --cached --exclude-from=.gitignore | grep -v '^build/'
> #   ^^ ^^^
> #   || |||
> #   \---  git: list 
> files
> #|   

Re: OOT module 'gr-sdrplay3' and SDRplay API update (supports new model RSP1B)

[Franco VENTURI]

Happy to hear from you Glen!

The other day when I pulled out my Raspberry Pi 4 from the drawer, it didn't 
seem to be working: only the red LED comes on, and nothing else (not even the 
rainbow RGB screen at the very beginning of the bootloader). I am going to try 
a couple more things, but I think I'll order one of the new Raspberry Pi 5's in 
the next few days, since I saw they are only $80 + S/H.

Since I am temporarily pi-less, can you tell me in some more details what you 
mean with "it is tricky to start with the previous Pi4B code and go to Pi5"?
Are you getting a specific error message (or messages)?

Franco 


> On 02/27/2024 2:04 PM EST Glen Langston  wrote:
> 
>  
> Dear Franco,
> 
> Thanks again for your efforts, two years ago, to get the SDRPlay RSP1A
> fully supported in Gnuradio 3.10.   This was for the Raspberry Pi4B and 400.
> 
> These are working great.
> 
> But now there’s the Pi 5.   It seems like it is tricky to start with the 
> previous
> Pi4B code and go to Pi5.   I’m wondering if you’ve (or anybody) has thought 
> about
> the Pi5 and SDRPlay install?
> 
> Thanks!
> 
> Glen
> 
> FYI the latest Lightwork memo is more about telescope construction but also
> mentions Gnuradio aspects.
> 
> https://github.com/WVURAIL/lightwork/blob/master/LightWorkMemo32-PailOfMilkyWay-r5.pdf
> 
> 
> > On Feb 11, 2024, at 11:23 AM, Franco VENTURI  wrote:
> > 
> > A few weeks ago SDRplay announced a new model, the RSP1B 
> > (https://www.sdrplay.com/rsp1b/); at the same time they also upgraded their 
> > API to version 3.14 in order to support the new hardware.   I have been 
> > working on a new branch ('sdrplay-api-3.14') for the OOT module 
> > 'gr-sdrplay3' to work with the new SDRplay API and to support the RSP1B: 
> > https://github.com/fventuri/gr-sdrplay3/tree/sdrplay-api-3.14   Our initial 
> > tests are successful, and we are are able to use it with both the existing 
> > RSP modules and with the new RSP1B; I would like to have a few more people 
> > give it a try, and in a week or so merge these changes into the 'main' 
> > branch (the code in the current 'main' branch will become the branch 
> > 'sdrplay-api-3.07' for those who have to keep the old SDRplay API for some 
> > reason, and it won't have any more changes), unless someone finds major 
> > problems in the new version.   Also we started a discussion with SDRplay 
> > about changing the defaults for AGC, DC offset correction, and IQ imbalance 
> > correction (they are currently disabled; they would become enabled be 
> > default). Regarding this last item I would like to receive some feedback 
> > before making the changes; especially regarding what kind of application 
> > you use the 'gr-sdrplay3' OOT module for: if it is more for scientific 
> > research/measurement purposes as opposed to listening to radio stations, or 
> > other use case scenarios. I just created an 'issue' in my repository where 
> > you can write a couple of lines (or more, of course) about your use case, 
> > feedback, and suggestions: 
> > https://github.com/fventuri/gr-sdrplay3/issues/30 - if you don't have an 
> > account on GitHub or prefer email, you can email me directly.   73, Franco 
> > K4VZ

OOT module 'gr-sdrplay3' and SDRplay API update (supports new model RSP1B)

[Franco VENTURI]

A few weeks ago SDRplay announced a new model, the RSP1B 
(https://www.sdrplay.com/rsp1b/); at the same time they also upgraded their API 
to version 3.14 in order to support the new hardware.
 
I have been working on a new branch ('sdrplay-api-3.14') for the OOT module 
'gr-sdrplay3' to work with the new SDRplay API and to support the RSP1B: 
https://github.com/fventuri/gr-sdrplay3/tree/sdrplay-api-3.14
 
Our initial tests are successful, and we are are able to use it with both the 
existing RSP modules and with the new RSP1B; I would like to have a few more 
people give it a try, and in a week or so merge these changes into the 'main' 
branch (the code in the current 'main' branch will become the branch 
'sdrplay-api-3.07' for those who have to keep the old SDRplay API for some 
reason, and it won't have any more changes), unless someone finds major 
problems in the new version.
 
Also we started a discussion with SDRplay about changing the defaults for AGC, 
DC offset correction, and IQ imbalance correction (they are currently disabled; 
they would become enabled be default).
Regarding this last item I would like to receive some feedback before making 
the changes; especially regarding what kind of application you use the 
'gr-sdrplay3' OOT module for: if it is more for scientific research/measurement 
purposes as opposed to listening to radio stations, or other use case scenarios.
I just created an 'issue' in my repository where you can write a couple of 
lines (or more, of course) about your use case, feedback, and suggestions: 
https://github.com/fventuri/gr-sdrplay3/issues/30 - if you don't have an 
account on GitHub or prefer email, you can email me directly.
 
73,
Franco K4VZ

Re: Failed to open SDRPlay device

[Franco VENTURI]

Claudio,
GNU Radio 3.7.13 is a little old and I think you would be missing out of many 
new features and bug fixes of more modern versions of GNU Radio.

For Windows I would recommend using Ryan Volz radioconda distribution (see here 
for the instructions: https://wiki.gnuradio.org/index.php/CondaInstall) that 
would give you GNU Radio version 3.10.4

Once you have radioconda installed, there are two ways you can connect GNU 
Radio to your SDRplay RSP:

- using the native 'gr-sdrplay3' OOT module (see here: 
https://lists.gnu.org/archive/html/discuss-gnuradio/2022-03/msg00144.html)
- using the SoapySDR module SoapySDRPlay3 (for the build instructions see here: 
https://github.com/pothosware/SoapySDR/wiki/BuildGuide and here: 
https://github.com/pothosware/SoapySDRPlay3/wiki)

Let me know if you have problems with the installation or running it and I'll 
be happy to help you.

Ciao,
Franco


> On 12/16/2022 8:34 AM claudio.franch...@tlrnet.eu wrote:
> 
> 
> 
> Good morning everyone,
> 
> I state that I am new to GNUradio, but I need to re-install in WIN10 a 
> .grc program written by a colleague a couple of years ago, which uses the 
> RSPduo SDR.
> 
> The hardware is fully functional, also tested with SDRplay's SDRuno 
> native SW, but when I install it on the new PC with GNUradio, I always get an 
> HW unreachable error.
> 
> GNUradio is in version 3.7.13.5_win64 which is the one suggested by 
> SDRplay, I installed the API ver. 3.11 (SDRplay_RSP_API_Windows-3.11.exe), 
> but when I try to run the program, I get a "Failed to open SDRPlay device" 
> error.
> 
> I then tried the sdrplay_test.grc test program, which is a simple FM 
> receiver accompanying HW, but I still get the same error.
> 
> I really need someone who can help me. If there is a volunteer, I attach 
> the sdrplay_test file, the generated python file and the error message.
> 
> 
> Thanks in advance for any suggestions and help you can give me.
> 
> Claudio
> 
> 

Re: Use /dev/swradioN (v4l2 api) as source

[Franco VENTURI]

Stefan,
if I were you I would contact the author of that SoapyMiri driver on GitHub 
about your problems with it, since to me he seems interested in improving it 
and he probably would be able to run some tests on his setup to troubleshoot 
and fix those issues.

As per my comment about using the kernel API directly, the word 'directly' was 
not a good choice; I meant it in the sense of connecting from your userland 
application 'directly' to the kernel (as opposed via a library or a module like 
SoapyMiri).
This said, if you just want to stream directly from that device /dev/swradioN, 
I believe it is a character device that streams I/Q samples as 16bit shorts 
(this is what I remember from long ago; please double check it). In this case I 
think you should be able to read from it using a GNU Radio file source block 
with a type of 'complex short' (you shouldn't need a throttle block because the 
sample rate is decided by your /dev/swradioN device).
The limitation of this approach is that it is good only for the streaming part; 
the control part (like selecting sample rate, frequency, possibly filters, etc) 
is probably through specialized ioctl() calls to that device (again you may 
want to double check that), so either you rely on an external application for 
that or you would have to write an OOT GNU Radio module (or perhaps someone 
already did, I am not sure).

Franco


> On 06/13/2022 8:47 PM Stefan Oltmanns  wrote:
> 
>  
> Thank you very much for that information, haven't seen that somebody
> continued the work on libmirisdr.
> I was able to get it working with an OsmoSDR Source using
> soapy=0,driver=soapyMiri
> 
> I had to modify the SoapyMiri driver, as OsmoSDR sets the bandwidth to
> 3/4 of the sample rate, but there are only certain fixed bandwidth
> values allowed, otherwise SoapyMiri will throw a runtime error (maybe it
> should find the closest allowed value). For now I hardcoded a bandwidth
> value and it works, but...
> 
> I get a lot of dropped samples, not suitable for practical use. This
> doesn't happen with the kernel driver.
> 
> You said "instead of using the kernel API directly", is there anything
> that is using the kernel API indirectly? I couldn't find any GNURadio
> plug-in that is using the SDR kernel API provided by v4l2 at all.
> 
> Best regards
> Stefan
> 
> 
> > gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.3.0-rc1
> > built-in source types: file rtl rtl_tcp rfspace soapy redpitaya
> > [INFO] Opening Mirics MSi2500 default (e.g. VTX3D card) :: 0001...
> > failed to open miri usb device 0 with code -3
> > Traceback (most recent call last):
> >   File "/home/stefan/miri_test.py", line 188, in 
> > main()
> >   File "/home/stefan/miri_test.py", line 166, in main
> > tb = top_block_cls()
> >   File "/home/stefan/miri_test.py", line 117, in __init__
> > self.osmosdr_source_0 = osmosdr.source(
> > RuntimeError: Unable to open LibMiriSDR device.
> 
> 
> 
> Am 14.06.22 um 00:28 schrieb Franco VENTURI:
> > Stefan, instead of using the kernel API directly you may want to look into 
> > a SoapySDR source in GNU Radio, since the SoapySDR block is now a first 
> > class citizen in GNU Radio 3.9/3.10
> >
> > According to this recent discussion in the SoapySDR GitHub repository 
> > (https://github.com/pothosware/SoapySDR/issues/359) there's a SoapyMiri 
> > driver (https://github.com/ericek111/SoapyMiri) that might work for you.
> > A comment in the same thread 
> > (https://github.com/pothosware/SoapySDR/issues/359#issuecomment-1150982319) 
> > has also instructions about integrating his fixes in OsmoSDR, if I 
> > understand correctly.
> >
> > I personally haven't tried this approach so I don't really know if it works 
> > or not, but I thought you might find this information useful.
> >
> > Franco
> >
> >
> >
> >> On 06/13/2022 3:26 PM Stefan Oltmanns  wrote:
> >>
> >>
> >> Hello,
> >>
> >> is there any way to use devices exposed as /dev/swradioN by the v4l2
> >> Linux kernel API with GNURadio directly?
> >>
> >> At the moment there are only two in-tree kernel drivers, one for the
> >> RTL2832U and the other for the Mirics MSi2500. For the RTL2832U
> >> librtlsdr seems to be the better option, as it offers more features to
> >> control the device, but libmirisdr seems to unmaintained and not stable
> >> (at least for me), support has been removed from OsmoSDR years ago.
> >> I do have such a Dongle and with the kernel driver it seems to work just
> >> fine.
> >>
> >> I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2
> >> source block could be very useful. Is there any specific reason, why
> >> such a source block doesn't exist yet?
> >> Or is it just that nobody needed it and therefore no one bothered
> >> writing one?
> >>
> >> Best regards
> >> Stefan

Re: Use /dev/swradioN (v4l2 api) as source

[Franco VENTURI]

Stefan, instead of using the kernel API directly you may want to look into a 
SoapySDR source in GNU Radio, since the SoapySDR block is now a first class 
citizen in GNU Radio 3.9/3.10

According to this recent discussion in the SoapySDR GitHub repository 
(https://github.com/pothosware/SoapySDR/issues/359) there's a SoapyMiri driver 
(https://github.com/ericek111/SoapyMiri) that might work for you.
A comment in the same thread 
(https://github.com/pothosware/SoapySDR/issues/359#issuecomment-1150982319) has 
also instructions about integrating his fixes in OsmoSDR, if I understand 
correctly.

I personally haven't tried this approach so I don't really know if it works or 
not, but I thought you might find this information useful.

Franco



> On 06/13/2022 3:26 PM Stefan Oltmanns  wrote:
> 
>  
> Hello,
> 
> is there any way to use devices exposed as /dev/swradioN by the v4l2
> Linux kernel API with GNURadio directly?
> 
> At the moment there are only two in-tree kernel drivers, one for the
> RTL2832U and the other for the Mirics MSi2500. For the RTL2832U
> librtlsdr seems to be the better option, as it offers more features to
> control the device, but libmirisdr seems to unmaintained and not stable
> (at least for me), support has been removed from OsmoSDR years ago.
> I do have such a Dongle and with the kernel driver it seems to work just
> fine.
> 
> I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2
> source block could be very useful. Is there any specific reason, why
> such a source block doesn't exist yet?
> Or is it just that nobody needed it and therefore no one bothered
> writing one?
> 
> Best regards
> Stefan

Re: Streaming int16 samples from usb device to gnu radio

[Franco VENTURI]

Hello Ruslan!

For the RX888/sddc device I think you would have to write a source block that 
uses the libsddc library as the backend for all the functions.

You can start from this tutorial on how to do it using 'gr_modtool': 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C++#Creating_our_OOT_module.

If you already have a SoapySDR module for the RX888, you can also use it in GNU 
Radio directly as a SoapySDR block.

Feel free to contact me for any questions and I'll be happy to help you.

Franco


> On 06/03/2022 6:30 AM Ruslan Migirov  wrote:
> 
> 
> Hello!
> I would like something like audio card source block to stream integers 
> directly from ADC , but with high sample rates.
> Can you give me some thoughts how i can implement it?
> 

Re: FunCube Pro+ with Soapy SDRPlay Source block

[Franco VENTURI]

Barry,
since you have a FunCube Pro+, I would try to install the SoapyFCDPP plugin for 
SoapySDR (https://github.com/pothosware/SoapyFCDPP/wiki), and then use a 
regular SoapySDR source in GNU Radio.

I found also useful to first make sure that the plugin sees the SDR using the 
'SoapySDRUtil' program that comes with SoapySDR).

Franco K4VZ



> On 04/02/2022 9:14 PM Barry Duggan  wrote:
> 
> 
> I have a FunCube Pro+ and am trying to use a Soapy SDRPlay Source block. 
> I have tried quite a few combinations of parameters, but always get "Error 
> setting HW params." I have also tried using a Soapy Custom Source with 
> similar results.
> 
> Does anyone have a working flowgraph using a FunCube Pro+ and Soapy?
> 
> My system:
> Ubuntu 20.04.4
> GR 3.10.1.1
> 
> Thank you for any help.
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
> 
> 
> 
> 

Conda package for gr-sdrplay3 OOT module for Windows

[Franco VENTURI]

Good news - with Ryan's help a few days ago I was able to create a recipe and a 
conda package for the gr-sdrplay3 OOT module for Windows.

For those not familiar with it, the gr-sdrplay3 OOT module adds support for the 
SDRplay RSP devices as native GNU Radio sources, using directly the SDRplay 
APIs (i.e. without going through SoapySDR).
Up to now it was only available on Linux (and probably Mac), but with this 
conda package it is possible to run it on Windows (it requires the most current 
GNU Radio installation using conda - see here: 
https://wiki.gnuradio.org/index.php/CondaInstall).

For those interested in trying it out, this is the link to the conda package on 
my Google Drive: 
https://drive.google.com/file/d/1ZTUeYyOpms0rx7yU2Q5fOqElKIKgyJwK/view?usp=sharing
 (the conda recipe is in the package).

One important notice - conda's Python on Windows loads any dependent DLL from a 
limited set of folders (i.e. it does not use the %PATH% environment variable to 
search for dependent DLLs, as I think most of the other Windows applications 
do).
This means that the proprietary DLL for the SDRplay API 'sdrplay_api.dll' 
(which is typically installed under 'C:\Program Files\SDRplay\API\x64\') needs 
to be copied to one of these folders for things to work:

- %CONDA_PREFIX%\Lib\site-packages\gnuradio\sdrplay3
- %CONDA_PREFIX%
- %CONDA_PREFIX%\Library\mingw-w64\bin
- %CONDA_PREFIX%\Library\bin
- %CONDA_PREFIX%\Scripts
- C:\Windows\System32

Alternatively setting the environment variable 
CONDA_DLL_SEARCH_MODIFICATION_ENABLE to '1' makes conda Python look into all 
the folders listed in %PATH%, and it should work too.

If conda Python is not able to find the 'sdrplay_api.dll' file, it will throw 
an 'ImportError' exception for the line 'from gnuradio import sdrplay3'.

I am not sure of the best way to distribute this package after this initial 
'beta' version, since it is not straightforward to build it automatically on 
conda-forge because of its dependence on SDRplay proprietary DLL and include 
files.
I am open to ideas and suggestions on how to find a good long-term solution 
(also, if this is not the best forum to discuss this specific conda related 
topic, please let me know, and we can continue this conversation elsewhere).

Franco

conda build fails with: ImportError: generic_type: type "square_ff" referenced unknown base type "gr::block"

[Franco VENTURI]

In order to learn how conda recipes and conda build work, I did the following 
steps on my computer:

- created a VM running the latest version of Ubuntu (21.10); I did all the 
remaining steps inside this VM
- installed conda (miniforge3), created the 'gnuradio' environment, installed 
the latest version of gnuradio from conda (3.10.1.1), ran 'conda upgrade -all', 
ran a quick check with 'gnuradio-compantion' - for this part I followed the 
instructions in the GNU Radio Wiki 
(https://wiki.gnuradio.org/index.php/CondaInstall)
- ran 'conda install gnuradio-build-deps' and 'conda activate 
$CONDA_DEFAULT_ENV' as per the instructions here: 
https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio
- followed the GNU Radio OOT Modules tutorial 
(https://wiki.gnuradio.org/index.php/OutOfTreeModules) to create the sample 
'gr-howto' OOT module with the two blocks 'square_ff' and 'square2_ff'
- in the sample OOT howto module I ran the commands:
mkdir build
cd build
cmake -G Ninja -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX 
-DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DLIB_SUFFIX="" ..
cmake --build .
cmake --build . --target install
and I was able to build the sample 'gr-howto' module, and ran the QA tests 
without any errors
- I then created a conda recipe following the steps in Ryan Volz template 
(https://github.com/ryanvolz/gnuradio-oot-template-feedstock); modified the 
meta.yaml file, and the build.sh file (didn't touch bld.bat since my build/host 
environment is Ubuntu)
- I installed conda-build and ran the command 'conda build .' in the directory 
with the recipe
- After a few minutes the compile/link part ran without errors, however the QA 
tests failed with the error message:

ImportError: generic_type: type "square_ff" referenced unknown base type 
"gr::block"

For those interested in seeing all the files (howto module, meta.yaml, 
build.sh), I uploaded them to my Google drive and this is the link: 
https://drive.google.com/file/d/1rkMcrsF9jLxUvgOU1F3kpbCRij4e9qa-/view?usp=sharing

I know that error message is due to pybind11 and I saw it was mentioned in this 
mailing list before 
(https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00056.html and 
https://github.com/gnuradio/gnuradio/issues/4841), but in this case the module 
does work with the conda gnuradio environment if built the 'normal' way using 
the 'cmake' commands above; it fails when run inside a 'conda build' recipe.

Thanks in advance,
Franco

Re: segfault in 3.10.1.1

[Franco VENTURI]

y2=52, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=76, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=75, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=74, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )g: 
> /usr/bin/python3 -u /UNUSED/testing123.py
> ...
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=5, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=4, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=3, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> >>> Done
> g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=3, 
> dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0, 
> padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
> sh-5.1#
> 
> one last question, i've never paid attention to a running 
> gnuradio-companion, it launces several other processes:
>  6456 tty2 Sl 0:02 /usr/bin/python3 /usr/bin/gnuradio-companion
>  6473 tty2 S  0:00 dbus-launch --autolaunch 
> 95afc6e6d7a14382a620df11724dd0ec --binary-syntax --close-stderr
>  6474 ?Ss 0:00 /usr/bin/dbus-daemon --syslog-only --fork 
> --print-pid 5 --print-address 7 --session
>  6476 ?Sl 0:00 /usr/libexec/at-spi-bus-launcher
>  6480 ?S  0:00 /usr/bin/dbus-daemon 
> --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
> --print-address 3
>  6534 ?Sl 0:00 /usr/libexec/at-spi2-registryd 
> --use-gnome-session
> 
> seems a few of these may not normally needed...?
> 
> Thanks for for your continued patience and help.
> 
> 
> 
> On Tue, Feb 8, 2022 at 1:26 PM Franco VENTURI  mailto:fvent...@comcast.net > wrote:
> 
> > > Steve,
> > I run Fedora version 35 here, and the version of 
> > goobject-introspection I have is 1.70:
> > 
> > $ rpm -q gobject-introspection
> > gobject-introspection-1.70.0-1.fc35.x86_64
> > 
> > I have GNU Radio 3.10 (actually 3.11 from master) and GNU Radio 
> > Companion running here without any problem, so perhaps you may just want to 
> > remove the older 1.69 version from your system, rebuild GNU Radio (or just 
> > GRC), and see if it works.
> > 
> > Franco
> > 
> > 
> > > > > On 02/08/2022 1:57 PM Steven Barbo 
> > mailto:ba...@umn.edu > wrote:
> > > 
> > > 
> > > Hi Franco.
> > > think i've built trying both versions, 1 at a time obviously.
> > > didn't seem to make a difference.
> > > on that front, 
> > > https://gitlab.gnome.org/GNOME/gobject-introspection sports only 1.69 and 
> > > 1.70 in releases section.
> > > https://download.gnome.org/sources/gobject-introspection/  
> > > has all
> > > maybe the ones on gitlab are somehow different?...
> > > will try rebuild with  older version assuming that still 
> > > plays well with glib-2.70.2 - anyone using gobject-introspection-1.70 ?
> > > hunting source is always an adventure.
> > > Thank you for looking at this, much appreciated.
> > > 
> > > On Tue, Feb 8, 2022 at 12:29 PM Franco VENTURI 
> > > mailto:fvent...@comcast.net > wrote:
> > > 
> > > > > > > Steve,
> > > > in your list I see tw

Re: segfault in 3.10.1.1

[Franco VENTURI]

Steve,
I run Fedora version 35 here, and the version of goobject-introspection I have 
is 1.70:

$ rpm -q gobject-introspection
gobject-introspection-1.70.0-1.fc35.x86_64

I have GNU Radio 3.10 (actually 3.11 from master) and GNU Radio Companion 
running here without any problem, so perhaps you may just want to remove the 
older 1.69 version from your system, rebuild GNU Radio (or just GRC), and see 
if it works.

Franco


> On 02/08/2022 1:57 PM Steven Barbo  wrote:
> 
> 
> Hi Franco.
> think i've built trying both versions, 1 at a time obviously.
> didn't seem to make a difference.
> on that front, https://gitlab.gnome.org/GNOME/gobject-introspection 
> sports only 1.69 and 1.70 in releases section.
> https://download.gnome.org/sources/gobject-introspection/  has all
> maybe the ones on gitlab are somehow different?...
> will try rebuild with  older version assuming that still plays well with 
> glib-2.70.2 - anyone using gobject-introspection-1.70 ?
> hunting source is always an adventure.
> Thank you for looking at this, much appreciated.
> 
> On Tue, Feb 8, 2022 at 12:29 PM Franco VENTURI  mailto:fvent...@comcast.net > wrote:
> 
> > > Steve,
> > in your list I see two different version of the 
> > 'gobject-introspection' package:
> > 
> > - gobject-introspection-1.69.0
> > - gobject-introspection-1.70.0
> > 
> > Perhaps one of them was used during the build of GNU Radio 
> > Companion, while the other one is used at runtime when you run 
> > 'gnuradio-companion'?
> > 
> > Franco
> > 
> > 
> > > > > On 02/08/2022 10:10 AM Steven Barbo via GNU 
> > Radio, the Free & Open-Source Toolkit for Software Radio 
> > mailto:discuss-gnuradio@gnu.org > wrote:
> > > 
> > > 
> > > Howdy Josh.
> > > Thank you for your reply, sorry i should have provided more 
> > > detail.
> > > OS is bootstrapped, "always roll your own" (tm) , old school 
> > > stubborn :) i've several iterations done this way over the years.
> > > As a minimalist, ever amazed at all the bloat that can 
> > > accompany various packages, the myriad option available to configure such.
> > > We all know headaches associated  the cruft of stale headers 
> > > and whatnot.
> > > My goal, absolute minimum to have gnuradio - no "unnecessary" 
> > >  -  especially, the overhead of desktops and doctools, systemd and ... 
> > > getting more difficult as time passes... an appliance so to speak.
> > > i've told myself i'd document the steps and order but, alas, 
> > > i never seem to have the patience.
> > > pip3 seems to work it's magic, all other packages were 
> > > compiled accordingly - think all dependencies have been met.
> > > attached gr config and a (partial) list of packages if that's 
> > > of any help.
> > > as i said, GUI shows up briefly. way over my head all things 
> > > things work together.   
> > > Thank you are all you patience and help.
> > > 
> > > 
> > > 
> > > On Tue, Feb 8, 2022 at 5:39 AM Josh Morman 
> > > mailto:jmor...@gnuradio.org > wrote:
> > > 
> > > > > > > Hi Steve,
> > > > 
> > > > Can you please share more information about how GR is 
> > > > installed in your case
> > > > - OS/distribution?
> > > > - Installation method (compiled from source, distro 
> > > > packages?
> > > > 
> > > > Thanks!
> > > > Josh
> > > > 
> > > > On Mon, Feb 7, 2022 at 7:58 PM Steven Barbo 
> > > > mailto:ba...@umn.edu > wrote:
> > > > 
> > > > > > > > > Hello all, hope this 
> > > > day finds you well.
> > > > > Having issue with gnuradio-companion, GUI comes 
> > > > > up briefly...
> > > > > 
> > > > > dmesg 
> > > > > [ 1341.843803] traps: gnuradio-compan[372] 
> > > > > general protection fault ip:7f81ca4f77c8 sp:7f81c713

Re: segfault in 3.10.1.1

[Franco VENTURI]

Steve,
in your list I see two different version of the 'gobject-introspection' package:

- gobject-introspection-1.69.0
- gobject-introspection-1.70.0

Perhaps one of them was used during the build of GNU Radio Companion, while the 
other one is used at runtime when you run 'gnuradio-companion'?

Franco


> On 02/08/2022 10:10 AM Steven Barbo via GNU Radio, the Free & Open-Source 
> Toolkit for Software Radio  wrote:
> 
> 
> Howdy Josh.
> Thank you for your reply, sorry i should have provided more detail.
> OS is bootstrapped, "always roll your own" (tm) , old school stubborn :) 
> i've several iterations done this way over the years.
> As a minimalist, ever amazed at all the bloat that can accompany various 
> packages, the myriad option available to configure such.
> We all know headaches associated  the cruft of stale headers and whatnot.
> My goal, absolute minimum to have gnuradio - no "unnecessary"  -  
> especially, the overhead of desktops and doctools, systemd and ... getting 
> more difficult as time passes... an appliance so to speak.
> i've told myself i'd document the steps and order but, alas, i never seem 
> to have the patience.
> pip3 seems to work it's magic, all other packages were compiled 
> accordingly - think all dependencies have been met.
> attached gr config and a (partial) list of packages if that's of any help.
> as i said, GUI shows up briefly. way over my head all things things work 
> together.   
> Thank you are all you patience and help.
> 
> 
> 
> On Tue, Feb 8, 2022 at 5:39 AM Josh Morman  mailto:jmor...@gnuradio.org > wrote:
> 
> > > Hi Steve,
> > 
> > Can you please share more information about how GR is installed in 
> > your case
> > - OS/distribution?
> > - Installation method (compiled from source, distro packages?
> > 
> > Thanks!
> > Josh
> > 
> > On Mon, Feb 7, 2022 at 7:58 PM Steven Barbo  > mailto:ba...@umn.edu > wrote:
> > 
> > > > > Hello all, hope this day finds you well.
> > > Having issue with gnuradio-companion, GUI comes up briefly...
> > > 
> > > dmesg 
> > > [ 1341.843803] traps: gnuradio-compan[372] general protection 
> > > fault ip:7f81ca4f77c8 sp:7f81c7137010 error:0 in 
> > > libgirepository-1.0.so.1.0.0[7f81ca4ed000+2]
> > > 
> > > 
> > > have compiled various gr versions over the years, they have 
> > > always just worked :)
> > > 
> > > any help or pointers are very much appreciated. what an 
> > > amazing tool,
> > > thank you.
> > > 
> > > gnuradio-config --print-all
> > > /usr/
> > > /etc
> > > /etc/gnuradio/conf.d
> > > /.gnuradio
> > > Mon, 07 Feb 2022 03:07:35Z
> > > 
> > > testing-support;python-support;post-install;man-pages;gnuradio-runtime;common-precompiled-headers;gr-ctrlport;*
> > >  
> > > thrift;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;*
> > >  alsa;* 
> > > oss;gr-channels;gr-pdu;gr-qtgui;gr-trellis;gr-utils;gr_modtool;gr_blocktool;gr-video-sdl;gr-vocoder;*
> > >  gsm;gr-wavelet;gr-network;gr-soapy
> > > 3.10.1.1
> > > cc (The Illustrious Industries, Ltd.) 10.3.0
> > > Copyright (C) 2020 Free Software Foundation, Inc.
> > > This is free software see the source for copying conditions.  
> > > There is NO
> > > warranty not even for MERCHANTABILITY or FITNESS FOR A 
> > > PARTICULAR PURPOSE.
> > > c++ (The Illustrious Industries, Ltd.) 10.3.0
> > > Copyright (C) 2020 Free Software Foundation, Inc.
> > > This is free software see the source for copying conditions.  
> > > There is NO
> > > warranty not even for MERCHANTABILITY or FITNESS FOR A 
> > > PARTICULAR PURPOSE.
> > > /usr/bin/cc:::-g -O2  -fvisibility=hidden -Wsign-compare 
> > > -Wall -Wno-uninitialized
> > > /usr/bin/c++:::-g -O2  -fvisibility=hidden -Wsign-compare 
> > > -Wall -Wno-uninitialized
> > > 2.9.0
> > > 
> > > 
> > > apologies for the ugly script and gdb output, tried to 
> > > disable control characters...
> > > shorten so as to not pollute 
> > > 
> > > sh-5.1# gdb -q /bin/python3 core
> > > ^[[?2004l^MReading symbols from ^[[32m/bin/python3^[[m...
> > > ^M
> > > warning: Can't open file /SYSV (deleted) during 
> > > file-backed mapping note processing^M
> > > ^M
> > > warning: core file may not match specified executable file.^M
> > > [New LWP 372]^M
> > > [New LWP 358]^M
> > > [New LWP 359]^M
> > > [New LWP 361]^M
> > > [New LWP 360]^M
> > > [New LWP 363]^M
> > > [New LWP 362]^M
> > >

Opinions on running GNU Radio 3.9+ on Windows

[Franco VENTURI]

I am the developer of the GNU Radio OOT module 'gr-sdrplay3' to support the 
SDRplay RSPs as native GNU Radio sources, and I received some inquiries about 
running it on Windows (I run Linux here and that's what I use for GNU Radio and 
other SDR applications).

Since I wrote that OOT module for GNU Radio 3.9+ (i.e. 3.9 and 3.10) because of 
the pybind11 bindings (no SWIG), I took a quick look at this page in the Wiki 
(https://wiki.gnuradio.org/index.php/WindowsInstall), and I see that there are 
a few options:
- Geof Nieboer's binary installer for Windows (but it looks like there's only a 
version 3.9.0.0 beta, and the last commit to that GitHub repo was from about a 
year and a half ago)
- radioconda (latest release October of last year, GNU Radio version 3.9.3.0)
- Pothos SDR development environment (not sure of the version of GNU Radio 
there)
- various ways of building from source (MSYS, Cygwin, WSL)

Since I would like to give it a try and see if the 'gr-sdrplay3' OOT module can 
run on Windows (and perhaps package it somehow), I was wondering for those of 
you who are running on a daily basis a recent version (3.9+) of GNU Radio on 
Windows, what is the preferred option both in terms of day-to-day usage and 
development?

Thanks in advance,
Franco Venturi

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Franco VENTURI]

To add another piece of information to this discussion, last night I built the 
whole GNU Radio 3.9-maint on my Raspberry Pi, and it wasn't too bad.

I followed the instructions from here:
- https://wiki.gnuradio.org/index.php/InstallingGRFromSource_on_Raspberry_Pi
- 
https://wiki.gnuradio.org/index.php/InstallingGR#For_GNU_Radio_3.9_and_Master_Branch
- 
https://github.com/gnuradio/volk#building-on-raspberry-pi-and-other-arm-boards-32-bit

The heavy step, which was the 'make' in the GNU Radio 'build' directory, took 
about 2 hours and 10 minutes on the Raspberry Pi using 'make -j 3' - I think it 
is a reasonable time considering I built all of the in-tree modules except for 
gr-uhd.

73,
Franco K4VZ


> On 11/24/2021 12:44 PM Gregory Ratcliff  wrote:
> 
> 
> Marcus,
> 
> 
> "..I don't have an RPi4, so can't test.”
> 
> You really should get one, if only to monitor ADSB from airplanes on your 
> own.  
> 
> 
> All,
> 
> Oh my.  Many of us have always had Marcus on the "Marcus pedestal", 
> thinking he knew or more importantly experimented with all things tech + 
> Linux.
> Maybe we need to create a crowdfund for him?
> 
> 
> Why?  I think the RPi is the most influential STEM tool ever created. RPi 
> + DSP = new converts and experts
> 
> Years ago, Fred Martin (Media Lab) designed the coolest SBC called the 
> miniboard for undergrads for the MIT 6.170 course; he shared the board layout 
> with me and while at Ohio State a small group of us made thousands of them. 
> Fred was the first Ebon in my book.
> 
> At the same time I was working on the TAPR DSP59 project and was holding 
> both the mini board and my recently hand assembled DSP59 in my hands thinking 
> there _had_to_a_way.   There wasn’t. 
> A lot has changed.
> 
> Why2? 
> 
> I think the world of computing is becoming more level. By this I mean 
> that in core middle range of mainstream computing, they are all getting 
> closer from a performance standpoint, only differing by factors of ten or so.
> 
> Think about what the performance of the RPi 12 will be- it will be 
> limited, but likely perfectly capable of doing some magical work for us.
> These fringe (and fun) SBCs and projects help produce the needed experts 
> that we need.
> 
> Apologies for evangelizing a bit on the gnuradio list-please keep up the 
> great work.
> 
> Greg
> nz8r
> 
> 

Re: Releases v3.8.4.0 and v3.9.3.0

[Franco VENTURI]

Gle,
the GNU Radio Wiki mentions a distribution specifically for the Raspberry Pi 
called PiSDR: https://wiki.gnuradio.org/index.php/InstallingGR#Raspberry_Pi

I just looked at the PiSDR GitHub page here: 
https://github.com/luigifcruz/pisdr-image but I am not 100% sure if it supports 
the SDRplay RSP devices.

Franco


> On 11/23/2021 5:04 PM Glen Langston  wrote:
> 
>  
> Thanks to everyone for your various attempts to help me get an SDRPlay RSP1A 
> working properly on
> a raspberry PI and gnuradio 3.8
> 
> So far I’ve failed completely.   Following your instructions, many version 
> have been installed but I continue
> to find incompatibilities, crashing due to different assumptions about
> the coding environment., It seems most folks have left 3.8 and are at 3.9. 
> 
> Does anyone have a Raspberry PI OS image that includes gnuradio 3.9 and also
> support for SDRPlay’s RSP1A?
> 
> I’d greatly appreciate being able to download a copy of that version.
> 
> Best regards
> 
> Glen

Re: Releases v3.8.4.0 and v3.9.3.0

[Franco VENTURI]

Glen,
using the 'gr-soapy' source and the latest SoapySDRPlay module 
(https://github.com/pothosware/SoapySDRPlay3), you should be able to control 
biasT by using this argument:

  biasT_ctrl=true

(see here for some more details here: 
https://github.com/pothosware/SoapySDRPlay3/issues/21)

As per the gains (or gain reductions, as they are defined int the SDRplay API), 
select 'Specific' in the 'gr-soapy' block, and then set the value of 'IFGR' (IF 
gain reduction) to a value in the range 20-59 (dB of gain reduction) and 'RFGR' 
(RF gain reduction) to a value between 0 and N - this value is the so called 
'LNA state', which is explained in detail in SDRplay API Specification Guide 
(https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.08.pdf); look for 
'Gain Reduction Tables' in that document.

Hope this helps,
Franco


> On 11/20/2021 1:12 PM Glen Langston  wrote:
> 
>  
> Hi Chris,
> 
> Thanks for  your reply.
> 
> After countless hours of messing around, I partially have 
> SDRPlay supported on a Raspberry PI 4 with gnuradio 3.8.2
> 
> Within gnuradio and osmosdr source blocks, I have SDRPlay data streaming, but 
> I’ve not been
> able to turn the bias-tee on or make any sense of the gain settings.
> 
> With gr-soapy source
> 
> I’ve got trouble getting the stream of data to flow.
> 
> with  SoapySDRUtil —find  I do find the device with reasonable values
> 
> ##
> ## Soapy SDR -- the SDR abstraction library ##
> ##
> 
> Found device 0
>   driver = sdrplay
>   label = SDRplay Dev0 RSP1A 190316E696
>   serial = 190316E696
> 
> So, my question is:
> 
> Do you (or anyone) have examples of the values to put in
> either of the source blocks to control the bias-tee 
> gains and notch filters?
> 
> Thanks again!
> 
> Best regards
> 
> Glen
> 
> Again this was working perfectly in gnuradio 3.7.13 but is huge headache
> in later version.
> 
> > On Nov 20, 2021, at 7:54 AM, Chris Vine  wrote:
> > 
> > On Fri, 19 Nov 2021 10:04:06 -0500
> > Glen Langston  wrote:
> >> Hello Chris,
> >> 
> >> I’ve seen your emails concerning SDRPlay and gnuradio 3.8 and 3.9
> >> 
> >> So far, after countless hours, I’ve yet to get SDRPlay working on a
> >> raspberry pi with gnuradio 3.8.
> >> 
> >> My code works fine with gnuradio 3.7, but all the documentation for
> >> 3.8 seems to be out of date as everything was broken in the move to 3.9.
> >> 
> >> Do you happen to have a Raspberry PI OS complete image that works
> >> with gnuradio 3.8 and SDRPlay?
> >> 
> >> If so would you consider posting a copy of the entire OS?
> >> 
> >> Thanks
> > 
> > Hi Glen,
> > 
> > I am afraid I don't have a raspberry pi so I can't help you with that.
> > I am now using gnuradio-3.9, but I had a RSP1A working well on x86_64
> > hardware with gnuradio-3.8 with the following:
> > 
> > * gnuradio-3.8.2.0
> > 
> > * soapy-sdr (repo https://github.com/pothosware/SoapySDR) master branch
> >  as at the commit of 2020-07-13
> > 
> > * gr-soapy (repo https://gitlab.com/librespacefoundation/gr-soapy)
> >  master branch as at the commit of 2021-02-16
> > 
> > * sdrplay-2.13.1
> > 
> > * soapy-sdrplay (repo https://github.com/pothosware/SoapySDRPlay2)
> >  master branch as at the commit of 2020-06-29
> > 
> > As an alternative to the last two I have also used:
> > 
> > * sdrplay-3.7.1
> > 
> > * soapy-sdrplay (repo https://github.com/pothosware/SoapySDRPlay3),
> >  master branch as at commit of 2021-01-12
> > 
> > gr-osmosdr does not work correctly with gnuradio-3.8 with the RSP1A (nor
> > very well with gnuradio-3.7 either).  Use gr-soapy instead, or if you
> > are using gqrx, use gr-osmosder with the soapy backend (not the "unfree"
> > sdrplay backend).
> > 
> > Hope this helps.
> > 
> > Chris

Re: v3.7 End of Maintenance

[Franco VENTURI]

Glen,
for SDRplay devices you should be able to use the gr-soapy OOT module 
(https://gitlab.com/librespacefoundation/gr-soapy), that should work with GNU 
Radio >= 3.8.
There was a post by Chris Vine to this mailing list about this approach less 
than two months ago 
(https://lists.gnu.org/archive/html/discuss-gnuradio/2021-10/msg0.html).

If you have any technical problem with the SoapySDRPlay module, I'll be happy 
to help.

Franco


> On 11/18/2021 6:03 PM Glen Langston  wrote:
> 
>  
> Thanks for all your efforts.
> 
> However still there are MANY external packages that don’t work beyond 3.7,
> so we're stuck in 3.7 world.  (We have inched to 3.8 but SDRPlay was not well 
> supported).
> 
> I know this is difficult, but please try to ADD capabilities without 
> destroying
> old capabilities.  From the Nubi point of view, it is easier for an expert to 
> enable
> both SWIG and PYBIND than it is to figure out the transition, when the Nubi 
> does not 
> care a bit what the difference is.
> 
> Thanks again,
> 
> Glen
> 
> 
> > On Nov 18, 2021, at 5:32 PM, Jeff Long  wrote:
> > 
> > We are officially ending maintenance of v3.7. There will be no further 
> > v3.7.X.X releases, and pull requests will no longer be accepted for the 
> > maint-3.7 branch.
> > 
> > The last v3.7 release (v3.7.14.0) was over 18 months ago and there are only 
> > a handful of unreleased commits on the maint-3.7 branch. 
> > Packagers/distributions have moved on to newer versions. Additionally, we 
> > are not set up to do automated testing on maint-3.7 and need to apply our 
> > development/maintenance efforts to v3.8, v3.9 and the upcoming v3.10.
> > 
> > Of course, this is open source, so there is no End of Life if packagers are 
> > still interested in v3.7. If you still package v3.7, please let us know.
> >

Re: Releases v3.8.4.0 and v3.9.3.0

[Franco VENTURI]

Marcus,
I understand your point, however when writing a generic module for SoapySDR 
like SoapySDRPlay you have to try to be "everything for everybody", and that 
sometimes leads to tradeoff and 'opinionated choices' you have to make in 
module.

For instance when writing the SoapySDRPlay module, I mostly used CubicSDR as my 
'target' application, and in that case we had to make several choices (see for 
instance this thread: https://github.com/pothosware/SoapySDRPlay2/issues/62), 
which are well summarized in this sentence by Vincent Sonnier, one of the 
developers of CubicSDR 
(https://github.com/pothosware/SoapySDRPlay2/issues/62#issuecomment-571432329):

   I suppose that if we want to plug the square of RSP into the round of a 
Soapy module, we must cut corners eventually.

On the other hand, when I wrote the gr-sdrplay3 GNU Radio OOT module, I worked 
on the assumption of a more advanced user that wants to have full control of 
the capabilities of these RSP SDRs, while choosing sensible defaults that would 
still allow anyone familiar with GRC to use them in their flowgraphs easily.

Franco


> On 10/01/2021 9:58 AM Marcus D. Leech  wrote:
> 
>  
> On 2021-10-01 7:34 a.m., Franco VENTURI wrote:
> > If you are running GNU Radio >= 3.9, there's also the native SDRplay module 
> > I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you can find 
> > the announcement to this mailing list here: 
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg1.html
> >
> > Unfortunately it won't build on GNU Radio 3.8 because of SWIG.
> >
> > Since it interfaces to the native SDRplay API (version 3.X), it doesn't 
> > require SoapySDR or gr-osmocom; I haven't done any comparison with the 
> > other approaches of interfacing with the SDRplay RSP devices (SoapySDR and 
> > gr-osmocom), but if someone does, I would be really interested in hearing 
> > their results.
> >
> > Franco
> >
> >
> My personal preference when writing applications is to make them 
> hardware-agnostic whenever possible, which is why I and am sure lots of 
> others
>    prefer the gr-osmosdr or gr-soapysdr approach of abstracting the 
> hardware interface.  This is particularly important when the flow-graphs 
> you've
>    developed are going to be used by non-GR people, or even people who 
> have no particular expertise in modifying software.

Re: Releases v3.8.4.0 and v3.9.3.0

[Franco VENTURI]

If you are running GNU Radio >= 3.9, there's also the native SDRplay module I 
wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you can find the 
announcement to this mailing list here: 
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg1.html

Unfortunately it won't build on GNU Radio 3.8 because of SWIG.

Since it interfaces to the native SDRplay API (version 3.X), it doesn't require 
SoapySDR or gr-osmocom; I haven't done any comparison with the other approaches 
of interfacing with the SDRplay RSP devices (SoapySDR and gr-osmocom), but if 
someone does, I would be really interested in hearing their results.

Franco


> On 10/01/2021 6:47 AM Chris Vine  wrote:
> 
>  
> On Thu, 30 Sep 2021 20:46:50 -0400
> Glen Langston  wrote:
> > Thanks for all everyone's efforts.   
> > 
> > We hope to give them a try.
> > 
> > I’ve got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
> > with Gnuradio 3.8.  I’ve not been able to find a running example.
> > 
> > Please send a link, if you’ve got a good example.
> 
> I don't have a link to offer you as my gnuradio installation is home-
> compiled from a number of scripts.  However, I did have my RSP1A
> working fine with gnuradio-3.8.2.0 using the out-of-tree gr-soapy block.
> I have now moved on to gnuradio-3.9.2.0, which has the advantage of
> providing an in-tree soapy block as part of the gnuradio distribution.
> 
> If you are using gnuradio-3.8 and can't move to gnuradio-3.9, I found
> that the out-of-tree gr-soapy block, wrapping SoapySDR and SoapySDRPlay,
> worked far better than trying to use the gr-osmosdr block's unfree
> backend for the RSP driver directly.  gr-osmosdr's soapy backend worked
> OK with the RSP driver and is what you will need if you are using gqrx,
> otherwise that adds an unnecessary level of indirection: instead of
> using gr-osmosdr's soapy backend you might just as well use gr-soapy
> directly, and the latter enables you to configure for example the
> RSP1A's MF/AM and VHF/DAB filters, which I never managed to do with
> gr-osmosdr.
> 
> SoapySDRPlay seemed to work fine with both the 2.13.1 and 3.05.1
> versions of the RSP driver; since the RSP1A only has a single hardware
> sampler there is no advantage in using the 3.05.1 driver so I stuck with
> version 2.13.1, which avoids having to start a daemon.
> 
> My main issue was in working out which gr-osmosdr and gr-soapy
> repository worked with which version of gnuradio.  With gnuradio-3.9's
> in-tree soapy block that is now obviated.  If you need help with
> versions/repositories for gnuradio-3.8 I should be able to help.
> 
> Hope that helps.

Building GNU Radio from source on Windows 10 - link problem in uhd build

[Franco VENTURI]

I am trying to build GNU Radio from source on Windows 10 (20H2 build 19042.906) 
following the instructions here: 
https://github.com/gnieboer/gnuradio_windows_build_scripts#installation--build 
(I used the 'master' branch of that repository)

The build process runs for a few hours building all the dependencies (including 
boost), but when it gets to building the uhd dependency, it fails.

The log file 
C:\gr-build\src-stage1-dependencies\uhd\host\build\CMakeFiles\CMakeError.log 
has this error message:

Link:
C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\link.exe 
/ERRORREPORT:QUEUE /OUT:".\CompilerIdCXX.exe" /INCREMENTAL:NO /NOLOGO 
/LIBPATH:"C:\gr-build\src-stage1-dependencies\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x64-windows\debug\lib"
 
/LIBPATH:"C:\gr-build\src-stage1-dependencies\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x64-windows\debug\lib\manual-link"
 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib 
shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib 
"C:\gr-build\src-stage1-dependencies\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x64-windows\debug\lib\*.lib"
 /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed 
/PDB:".\CompilerIdCXX.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT 
/IMPLIB:".\CompilerIdCXX.lib" /MACHINE:X64 Debug\CMakeCXXCompilerId.obj
LINK : fatal error LNK1181: cannot open input file 'boost_chrono-vc140-mt.lib' 
[C:\gr-build\src-stage1-dependencies\uhd\host\build\CMakeFiles\3.19.4\CompilerIdCXX\CompilerIdCXX.vcxproj]
Done Building Project 
"C:\gr-build\src-stage1-dependencies\uhd\host\build\CMakeFiles\3.19.4\CompilerIdCXX\CompilerIdCXX.vcxproj"
 (default targets) -- FAILED.

Build FAILED.



The problem seems to be that the boost build installed the library 
'boost_chrono-vc140-mt.lib' under 
C:\gr-build\src-stage1-dependencies\vcpkg\installed\x64-windows\lib\boost_chrono-vc140-mt.lib,
 while the link command is instead looking for 
C:\gr-build\src-stage1-dependencies\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x64-windows\debug\lib\*.lib
 (in other words, it has an extra 'debug' in the path before 'lib').


I also looked in the directory searched for by the link command above (i.e. 
C:\gr-build\src-stage1-dependencies\vcpkg\installed\x64-windows\debug\lib), and 
I do see a library with a very similar name: boost_chrono-vc140-mt-gd.lib (note 
the extra '-gd' at the end of its name), so perhaps the link command should 
have tried to look for that instead. Not really sure.


Since I am not very familiar with the way GNU Radio and its dependencies get 
built under Windows, at this point I am wondering if I should try to either:
- figure out how to remove the extra 'debug' directory in the uhd link command 
(probably by changing something in the cmake configuration), or
- figure out why the boost build installed the library 
'boost_chrono-vc140-mt.lib' in the wrong path, or
- figure out if in this case the uhd link command is correct, but the uhd build 
should have been looking for the library with a slightly different name: 
boost_chrono-vc140-mt-gd.lib (and where that gets selected in the uhd config)


It is very possibly something I did wrong, but I wanted to ask if anyone has 
seen a similar problem when building GNU Radio from source on Windows, and if 
so how they solved it.


Thanks in advance,
Franco Venturi - K4VZ

Re: Overloaded make() with pybind11

[Franco VENTURI]

If I understand correctly what you are trying to do, I think I had a similar 
problem with the pybind11 bindings when I wrote the 'gr-sdrplay3' OOT module 
for GNU Radio 3.9.

I just took a quick look at the code and I see I used 
'py::detail::overload_cast_impl' (see here: 
https://github.com/fventuri/gr-sdrplay3/blob/master/python/bindings/rspduo_python.cc).

Hope it helps,
Franco


> On 01/22/2021 4:38 PM Marcus Müller  wrote:
> 
>  
> Hi Daniel,
> engineer's finest remark:
> 
> "That is an *interesting* problem"
> 
> The problem here is that the arguments don't really allow for deduction with 
> "make" you
> meant, so:
> 
> I'd quickly work around that using a lambda function; try something like
> 
>   .def(py::init(
> [](int dual_basis, int interleave) {
> return decode_rs::make(dual_basis, int interleave);
> }),
>py::arg("dual_basis"),
>py::arg("interleave"),
>D(decode_rs,make)
> );
> 
> On 22.01.21 19:09, Daniel Estévez wrote:
> > Hi,
> > 
> > I'm porting gr-satellites to GNU Radio 3.9. I have some blocks that have an 
> > overloaded
> > make() method, for example:
> > 
> > https://github.com/daniestevez/gr-satellites/blob/master/include/satellites/decode_rs.h
> > 
> > Maybe this wasn't a very wise design decision on my side.
> > 
> > Now I'm wondering if it's possible to use this with pybind11, and if so how 
> > to do it.
> > 
> > gr_modtool bind (with pygccxml installed) is generating this:
> > 
> > https://gist.github.com/daniestevez/a3d0aaf7e6b2a68933ebb30e9043e7ac
> > 
> > which gives build problems like
> > 
> > /home/daniel/gr-satellites/python/bindings/decode_rs_python.cc: In function 
> > 'void
> > bind_decode_rs(pybind11::module&)':
> > /home/daniel/gr-satellites/python/bindings/decode_rs_python.cc:39:39: 
> > error: no matching
> > function for call to 'init()'
> >    39 | .def(py::init(&decode_rs::make),
> >   |   ^
> > 
> > 
> > Best,
> > 
> > Daniel.
> >

Re: GNU Radio on Raspberry Pi 4?

[Franco VENTURI]

Gisle,
I just ran these commands here (I am on Fedora Linux version 33), and I didn't 
receive any error or warning:

git clone https://github.com/fventuri/gr-sdrplay.git
cd gr-sdrplay/
git checkout API3+RSPduo

This said, I don't think this thread called "GNU Radio on Raspberry Pi 4?" is 
the right place to further discuss build problems with the gr-sdrplay OOT 
module (besides the words 'MSVC building' make me think you are probably not 
using a Raspberry Pi), so I suggest creating a new issue about those here: 
https://github.com/fventuri/gr-sdrplay/issues

Franco


> On 12/18/2020 4:34 AM Gisle Vanem  wrote:
> 
>  
> Franco VENTURI wrote:
> 
> > if you are interested in using SDRplay API version 3.X (I think the latest 
> > version of their API is 3.07), and you are on GNU Radio 3.7, you may want 
> > to take a look at the gr-sdrplay GNU Radio OOT module I modified to work 
> > with SDRplay API version 3.X: 
> > https://github.com/fventuri/gr-sdrplay/tree/API3+RSPduo (notice the 
> > non-default branch name: 'API3+RSPduo').
> 
> I tried your 'master' branch. No problem building that.
> But I have problems with the 'API3+RSPduo' branch:
> 
> git checkout API3+RSPduo
> error: pathspec 'API3+RSPduo' did not match any file(s) known to git.
> 
> What??
> 
> Besides there are *many* warning '4250' in MSVC building
> this module:
>rsp1a_impl.h(33): warning C4250: 'gr::sdrplay3::rsp1a_impl':
>inherits 'gr::sdrplay3::rsp_impl::gr::sdrplay3::rsp_impl::start'
>via dominance
> 
> etc.

Re: GNU Radio on Raspberry Pi 4?

[Franco VENTURI]

Glen,
if you are interested in using SDRplay API version 3.X (I think the latest 
version of their API is 3.07), and you are on GNU Radio 3.7, you may want to 
take a look at the gr-sdrplay GNU Radio OOT module I modified to work with 
SDRplay API version 3.X: 
https://github.com/fventuri/gr-sdrplay/tree/API3+RSPduo (notice the non-default 
branch name: 'API3+RSPduo').

If instead you are on GNU Radio 3.9/master, I rewrote that OOT module from 
scratch, called it 'gr-sdrplay3', and you'll find it here: 
https://github.com/fventuri/gr-sdrplay3

Let me know if you have problems building or running those modules (possibly by 
creating a new issue in GitHub to avoid hijacking this thread).

Franco
 

> On 12/17/2020 1:34 PM Glen Langston  wrote:
> 
>  
> Concerning Full Raspberry Pi OS software installed on a single Raspberry Pi 
> image,
> we’re encouraging high schools to use this installation document.
> https://docs.google.com/document/d/1hfS7cRx3emlZz0sTs583zN8o-35nKtIej6BYMKCJLXY/edit?usp=sharing
> 
> The document includes the links to the OS and hardware to purchase.
> 
> Unfortunately this is a 3.7.13.4 Gnuradio release, as we’ve not had the 
> strength
> to get the SDRPlay software support working for newer gnuradio Releases.
> 
> Best regards, 
> 
> Glen
> 
> > On Dec 17, 2020, at 12:03 PM, Kyeong Su Shin  wrote:
> > 
> > To whom it may concern:
> > 
> > Just a tip: If you are building GNU Radio from the source, dependencies and 
> > build procedures for Raspberry Pi is available at the GNU Radio Wiki. It 
> > assumes that you are doing on-board compile.
> > 
> > See: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
> > 
> > 
> > Regards,
> > Kyeong Su Shin
> > 보낸 사람: Albin Stigö  대신 Discuss-gnuradio 
> > 
> > 보낸 날짜: 2020년 12월 18일 금요일 오전 1:13
> > 받는 사람: Kristoff ; GNURadio Discussion List 
> > 
> > 제목: Re: GNU Radio on Raspberry Pi 4?
> >  
> > There's no special configuration. Just install dependencies and build from 
> > source. Put root on SSD or it will be very slow. Ubuntu 65bit is fine. In 
> > general GNURadio is hell to build and get dependencies right, but in the 
> > end it works well.
> > 
> > --Albin
> > 
> > On Thu, Dec 17, 2020, 16:37 Kristoff  wrote:
> > Albin,
> > 
> > 
> > Can you share your configuration for this? Do you need to set up 
> > something special?
> > Can you do this on standard ubuntu 64 bit (20.04LTS or 20.10) on a pi4b 
> > or do you need another distro for this?
> > 
> > 
> > I read somewhere opengl on the pi4 has not been released yes as it has 
> > the pi4 has a more recent GPU.
> > Or am I completely wrong?
> > 
> > 
> > 73
> > kristoff - ON1ARF
> > 
> > 
> > On 17/12/2020 1:22 p.m., Albin Stigö wrote:
> > > I suspect a lot of the graphics could run perfectly fine if they took 
> > > advantage of the gpu better. A lot of the current rendering in 
> > > GNURadio (and GQRX) is very cpu bound.
> > >
> > > I had a spectrum and waterfall running easily at 60fps on a pi3 by 
> > > using opengl properly. Using vulkan on pi4 the sky is the limit.
> > >
> > > --Albin
> > >
> > > On Thu, Dec 17, 2020, 13:18 Marcus Müller  > > > wrote:
> > >
> > > Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
> > > like running Windows 98 on a modern PC and expecting top performance
> > > from the CPU. You're not making use of the CPU you have, you're only
> > > making use of a legacy mode that it still supports.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On 17.12.20 10:53, Albin Stigö wrote:
> > > > 64bit mode is most likely better because in addition to being
> > > 64bit it
> > > > enables additional cpu features (certain new instructions and
> > > more SIMD
> > > > NEON registers)
> > > >
> > > > On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr
> > > 
> > > >  > > >
> > >  > > 
> > > >  > > >> wrote:
> > > >
> > > > The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> > > > https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
> > > > 
> > > > last page. I get 3 to 7-fold improvement by volk_config on a
> > > dedicated
> > > > toolchain for 64-bit CPU.
> > > >
> > > > JM
> > > >
> > > > --
> > > > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe,
> > > 25000
> > > > Besancon, France
> > > >
> > > > December 17, 2020 10:28 AM, "Kristoff"  > > 
> > > > >> wrote:
> > > >
> > > > > HI all,
> > > > >
> > > 

New OOT module for SDRplay RSP devices

[Franco VENTURI]

I just pushed a new OOT module for SDRplay RSP devices on Github here: 
https://github.com/fventuri/gr-sdrplay3

A few important notes:
- the module uses SDRplay API V3
- the module builds with the latest version of GNU Radio (3.9 - master branch) 
- Python bindings use pybind11
- the module supports the following RSP models:
- RSP1
- RSP1A
- RSP2
- RSPduo (all modes of operation)
- RSPdx

This is still a work in progress - I only ran a few basic tests with a few of 
them (RSP2, RSPduo, and RSPdx), and I just checked that it was streaming 
without crashes or other major problems.

Please feel free to give it a try - let me know if you find any problem (I am 
pretty sure there are still a few bugs).

Regards,
Franco Venturi - K4VZ