Re: gr_modtool rm in v3.9

[Josh Morman]

Jeff,

I'm guessing the issue is with the tool.  Modtool went through some changes
3.8-->3.9 as Swig was removed and the extra step of `modtool bind` was
added.

Josh

On Tue, Mar 22, 2022 at 11:28 AM Jeff S  wrote:

> I tried using gr_modtool in v3.9.5.0 to add a block, including python and
> C++ QA code.  I then did a gr_modtool rm on that block, but the C++ QA code
> file was not removed, and the file shows up in the lib/CMakeLists.txt file.
>
>
>
> I tried a test with the same thing in v3.8.5.0, and it seems like the C++
> file and reference were removed.  I couldn’t find any reference to it being
> changed, so I guess I’m just checking to see if there is an issue with me,
> or the tool.
>
>
>
> Regards,
>
> Jeff
>

RE: gr_modtool rm in v3.9

[Jeff S]

Thanks, Josh.  Nice to confirm.  I was having some trouble finding what I was 
looking for in the change history, so I thought I’d just ask.

Jeff

From: Josh Morman 
Sent: Wednesday, March 23, 2022 4:35 AM
To: Jeff S 
Cc: discuss-gnuradio@gnu.org
Subject: Re: gr_modtool rm in v3.9

Jeff,

I'm guessing the issue is with the tool.  Modtool went through some changes 
3.8-->3.9 as Swig was removed and the extra step of `modtool bind` was added.

Josh

On Tue, Mar 22, 2022 at 11:28 AM Jeff S 
mailto:e070...@hotmail.com>> wrote:
I tried using gr_modtool in v3.9.5.0 to add a block, including python and C++ 
QA code.  I then did a gr_modtool rm on that block, but the C++ QA code file 
was not removed, and the file shows up in the lib/CMakeLists.txt file.

I tried a test with the same thing in v3.8.5.0, and it seems like the C++ file 
and reference were removed.  I couldn’t find any reference to it being changed, 
so I guess I’m just checking to see if there is an issue with me, or the tool.

Regards,
Jeff

Trying to understand simple example

[Alexander Plotnikov]

Greetings to all!

I am a very new GNU Radio user.

For now I am trying to get simple example with spectrum analyzer.

I am encountering problems with understanding the result of the results 
I get. I am attaching to screens - one for the schematic and one for Qt 
FFT block result.


As for now I do not understand - why do I get some strange -15dB value 
on spectrum for I am using a simple gen with 1 volt amplitude. And how 
to customize the y-scale correctly.


I hope if anybody can help me with this and clarify those questions.

Thank everyone in advance.

Alex

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

[Ryan Volz]

Hi Franco,

Thanks for trying this out! The more people that use it, the better we can make 
it work.

What you've run into is indeed a pybind11 incompatibility. It's happening not because the 
pybind11 version has changed between building GNU Radio and the OOT, but because the 
version of GCC has changed between the two builds. Conda-forge has recently migrated from 
GCC 9 to 10, the existing `gnuradio` packages were built with GCC 9, and your fresh OOT 
build from a recipe is using GCC 10. It works the "normal" way without a recipe 
because `gnuradio-build-deps` installs GCC 9.

I was hoping that no one would run into this until the next releases of GNU 
Radio, at which time I could upgrade to GCC 10 and not break existing OOT 
packages built with GCC 9. As a temporary fix until that time, you can add the 
following lines to a `conda_build_config.yaml` file in the same directory as 
`meta.yaml` in your OOT recipe:

c_compiler_version:
  - 9  # [linux]
cxx_compiler_version:
  - 9  # [linux]

That will override conda-forge's global compiler settings and use GCC 9, which 
will give you compatible Python bindings.

Cheers,
Ryan

P.S.

As it so happens, I have just started playing around with adding a conda recipe 
to the gr-newmod OOT template created by gr_modtool:

https://github.com/ryanvolz/gnuradio/tree/05568f8f2937f9fc613cc9d518a771dd0f06a5ae/gr-utils/modtool/templates/gr-newmod/.conda

You could copy that whole .conda directory into a module's source tree, modify 
the .conda/recipe/meta.yaml, and get results very similar to what you've shared 
at the Google drive link. Of course, this still also needs the GCC version fix 
described above!

On 3/22/22 9:52 PM, Franco VENTURI wrote:

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

Why is OFDM_loopback slow with Random Source

[Taylor Clark]

Good evening,
I have been doing some work with packet modulation and I ran across the
OFDM_Loopback.grc file. I initially did some test with my ZMQ Server and
the data rate was terrible. Thinking it was my datasource, I did some other
test until I decided to use GNU Radios random Source block as an input. To
my surprise, it was just as slow and I really can't figure out why. My CPU
isnt terrible, is this GNURADIOS internal data processing at work or am I
not understanding how it was meant to be used?

Any feedback would be greatly appreciated!

Respectfully,
Taylor Clark