Re: problem porting OOT to gr_3.9 : gr_modtool bind error

[Tom McDermott]

Thanks, Josh.The OOT should be pretty standard.  It was built with
gr_modtool in 3.7,
then ported over to 3.8.  All the modules are in the normal places.
My guess is NoneType means that the module was not found, then trying to
append .h to
that fails.

I tried running gr_modtool bind inside the gr_3.9/gr-hpsdr directory and it
fails in the exact same way.

I guess at this point I'll have to see if there is some way to run
gr_modtool in a debugger and step through
what it is trying to do and how it is trying to find the modules.

-- Tom, N5EG


On Fri, Apr 9, 2021 at 1:23 PM Josh Morman  wrote:

> I haven't been able to replicate this on my system with Ubuntu 20.04 and
> Python 3.8.5  - created a 3.8 OOT with one block, and followed the steps to
> copy the 3.9 content back in, and it got past the `gr_modtool bind` step.
>
> Is there anything non-standard about your 3.8 OOT - e.g. are the files in
> the usual place as generated by modtool?
>
> On Fri, Apr 9, 2021 at 1:49 PM Tom McDermott  wrote:
>
>> Hi Josh - for creating the new 3.9 skeleton, I ran gr_modtool from within
>> the 3.9 directory.
>> For step 4, I ran gr_modtool from within the 3.8 directory (as per the
>> guide).
>>
>> Quite frankly, it looks like gr_modtool is throwing an error when trying
>> to
>> concatenate the module name and path and the .h suffix and suffering
>> a type mismatch  (NoneType vs. str).  Is this possibly a Python 3.x
>> version dependency?
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>> On Fri, Apr 9, 2021 at 10:37 AM Josh Morman  wrote:
>>
>>> You are right - that is an easier process than merging the 3.8 code into
>>> 3.9.  The wiki should be correct in this case.
>>>
>>> Which directory are you running gr_modtool from?  Same directory as you
>>> would for doing things like gr_modtool add?
>>>
>>>
>>> On Fri, Apr 9, 2021 at 1:24 PM Tom McDermott  wrote:
>>>
 Hi Josh - thank you for your help !

 I have been following the instructions from the porting guide:

 https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide

 

 Porting from 3.8 to 3.9 can be achieved most simply by creating a new
 OOT module (with the same name as the 3.8 OOT but in a different
 directory), then performing some manual steps

 1. Use the 3.9 gr_modtool to generate a module with the same name (in
 another directory)

 2. Copy the python folder from 3.9 OOT into your 3.8 OOT

 3. (in 3.8 OOT) Add the bindings directory to the python directory
 CMakeLists

./python/CMakeLists.txt  → add the line:
add_subdirectory(bindings)

 4. (in 3.8 OOT) Call gr_modtool bind for each block in your OOT

 ...

 -
 I have not created anything in the 3.9 directory except using
 gr_modtool new and add, nor have I copied in any code
 from 3.8 directory to the 3.9 directory.  I was under the impression
 that step 4 would modify my 3.8 code so that I could
 then copy it from the 3.8 directory over to the 3.9 directory.

 There are significant file differences between the newly created 3.9
 and the existing 3.8  with conflicts in the /lib directory:
 the  hermesNB_impl.h and .cc   and hermesWB.h and .cc files differ
 significantly in content.

 Do I need to first look through the code and figure out how to merge
 the 3.8 and 3.9 .h and .cc files together?
 Then do I put those merged file into the 3.8 or the 3.9 directory?

 -- Tom, N5EG







 On Fri, Apr 9, 2021 at 9:27 AM Josh Morman  wrote:

> Tom,
>
> If I am following correctly, it looks like you are running gr_modtool
> (which is the 3.9 version since that is what you have installed in the VM)
> in the 3.8 OOT directory?
> What happens when you run `gr_modtool bind` in the gr-hpsdr_3.9
> directory
>
> The process you are following seems sound to have created a 3.9 OOT
> with 3.9 modtool, and then copied code in from 3.8.
>
> Josh
>
> On Fri, Apr 9, 2021 at 12:08 PM Tom McDermott 
> wrote:
>
>> I am having difficulty porting an OOT module to gr 3.9.
>> * VM with only gnuradio 3.9.0.0 installed.
>> *The functional 3.8 OOT module is cloned into this VM.
>>
>> Installed is 3.9.0.0
>> Python 3.8.5
>> pygccxml 2.1.0
>> pybind11 2.6.2
>>
>> *  Created the gr-hpsdr_3.9  directory, populated it using gr_modtool
>> newmod, added the
>> two modules hermesNB and hermesWB with constructor parameters.
>>
>> In the 3.8 directory:
>>  hermesNB.h and hermesWB.h  both exist in the /include directory, and
>>  hermesWB_impl.cc and hermesNB_impl.cc both  exist in the /lib
>> directory
>>  Edited the ./python/Cmakelists.txt file to add the bindings
>> subdirectory.
>>  From the directory gr-hpsdr_3.8/gr-hpsdr, I execute gr_modtool

Re: Error message in fm_rx and fm_tx example

[Christophe Seguinot]

  
  
I'm not used to Python bindings and don't really konws how to
  debug this. It look like your install is nor importing the right
  "window" class. 

Can you please run this python code and the linux command: 


  locate fft_python (available if you installed locate package
with sudo apt-get install locate, answer below
  
  
/usr/lib/python3/dist-packages/gnuradio/fft/fft_python.cpython-38-x86_64-linux-gnu.so
  


  python3 fm_rx3.py (only import window class and list its
attributes
  

you should get for the python code,
  something like this


  ['WIN_BARTLETT', 'WIN_BLACKMAN',
'WIN_BLACKMAN_HARRIS', 'WIN_BLACKMAN_hARRIS', 'WIN_FLATTOP',
'WIN_HAMMING', 'WIN_HANN', 'WIN_KAISER', 'WIN_RECTANGULAR',
'__class__', '__delattr__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__gt__',
'__hash__', '__init__', '__init_subclass__', '__le__', '__lt__',
'__module__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__', '__subclasshook__', 'bartlett', 'blackman',
'blackman2', 'blackman3', 'blackman4', 'blackman_harris',
'blackman_nuttal', 'blackman_nuttall', 'blackmanharris',
'build', 'coswindow', 'exponential', 'flattop', 'hamming',
'hann', 'hanning', 'kaiser', 'max_attenuation', 'nuttal',
'nuttal_cfd', 'nuttall', 'nuttall_cfd', 'parzen', 'rectangular',
'riemann', 'welch', 'win_type'] 
  
pybind11_builtins.pybind11_type 

window.__init_subclass__=  

window.__init__= 
  



Regards 



On 09/04/2021 22:17, Clark Chiu wrote:


  
  Hi Christophe,


After I run "python3 fm_rx.py", I got this message:
  ==
  Traceback (most recent call last):
  File "fm_rx.py", line 508, in 
    main()
  File "fm_rx.py", line 486, in main
    tb = top_block_cls()
  File "fm_rx.py", line 252, in __init__
    window.WIN_BLACKMAN_hARRIS, #wintype
AttributeError: type object 'gnuradio.fft.fft_python.window'
has no attribute 'WIN_BLACKMAN_hARRIS'
  
  ==
  
  
  
  Seems like it couldn't find the correct window type...?
  
  
  
  
  Best regards,
  Clark
  
  

  
  
  
On Fri, Apr 9, 2021 at 12:50
  PM Christophe Seguinot 
  wrote:


  
Could you please copy these files for som folder: 


  dummy.dat is generated by fm_tx.grc
  fm_rx.py is generated from frm;_rx.grc flowgraph

and try to run the .py file: 


  python3 fm_rx.py
  

may be you could get a more explicit error  for line with
  firdes.low_pass_2(self.volume...)



On 09/04/2021 18:11, Clark Chiu wrote:


  Hi Christophe and Marcus,


Thank you for the reply. I tried the fm_tx_2.grc
  and it has the same error message as below.

===
Block: pfb_arb_resampler_xxx_0
Aspect: Param 'Taps'
Message: _expression_ None is invalid for
  type'real_vector'.
===

Also the files between master and maint-3.9 are
  identical.
"git diff maint-3.9 master
  gr-analog/examples/fm_?x.grc"


I don't think I had a previous version of GNU Radio
  before. I installed GNU Radio from the binary package.
  I tried to delete the cache file and the cache folder
  then restart GRC but it is the same. 


Any other suggestions?




Best regards,
Clark


  
  
  
On Fri, Apr 9, 2021 at
  9:19 AM Christophe Seguinot 
  wrote:


  
Hi Clark 

I'm running under Ubuntu 20.04 and GNURadio 3.9
  fresh install (my Computer and HDD were out for
  

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: problem porting OOT to gr_3.9 : gr_modtool bind error

[Tom McDermott]

I tried adding a new super simple OOT project.  Of type general, adding one
module (cpp) with one parameter.
No code added anywhere.  I noticed that when adding the dummy module to
this dummy OOT that I get 3 errors from gr_modtool add:

Failed to run clang-format %s [Errno 2] no such file or directory:
'clang-format'

But the .cc and .h files for the module are created.  Trying to run
gr_modtool against that fails the same as before.

Do I have multiple problems here?
Am I missing some dependency for clang-format ?

-- Tom, N5EG






On Sat, Apr 10, 2021 at 12:22 AM Tom McDermott  wrote:

> Thanks, Josh.The OOT should be pretty standard.  It was built with
> gr_modtool in 3.7,
> then ported over to 3.8.  All the modules are in the normal places.
> My guess is NoneType means that the module was not found, then trying to
> append .h to
> that fails.
>
> I tried running gr_modtool bind inside the gr_3.9/gr-hpsdr directory and
> it fails in the exact same way.
>
> I guess at this point I'll have to see if there is some way to run
> gr_modtool in a debugger and step through
> what it is trying to do and how it is trying to find the modules.
>
> -- Tom, N5EG
>
>
> On Fri, Apr 9, 2021 at 1:23 PM Josh Morman  wrote:
>
>> I haven't been able to replicate this on my system with Ubuntu 20.04 and
>> Python 3.8.5  - created a 3.8 OOT with one block, and followed the steps to
>> copy the 3.9 content back in, and it got past the `gr_modtool bind` step.
>>
>> Is there anything non-standard about your 3.8 OOT - e.g. are the files in
>> the usual place as generated by modtool?
>>
>> On Fri, Apr 9, 2021 at 1:49 PM Tom McDermott  wrote:
>>
>>> Hi Josh - for creating the new 3.9 skeleton, I ran gr_modtool from
>>> within the 3.9 directory.
>>> For step 4, I ran gr_modtool from within the 3.8 directory (as per the
>>> guide).
>>>
>>> Quite frankly, it looks like gr_modtool is throwing an error when trying
>>> to
>>> concatenate the module name and path and the .h suffix and suffering
>>> a type mismatch  (NoneType vs. str).  Is this possibly a Python 3.x
>>> version dependency?
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 9, 2021 at 10:37 AM Josh Morman  wrote:
>>>
 You are right - that is an easier process than merging the 3.8 code
 into 3.9.  The wiki should be correct in this case.

 Which directory are you running gr_modtool from?  Same directory as you
 would for doing things like gr_modtool add?


 On Fri, Apr 9, 2021 at 1:24 PM Tom McDermott 
 wrote:

> Hi Josh - thank you for your help !
>
> I have been following the instructions from the porting guide:
>
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
>
> 
>
> Porting from 3.8 to 3.9 can be achieved most simply by creating a new
> OOT module (with the same name as the 3.8 OOT but in a different
> directory), then performing some manual steps
>
> 1. Use the 3.9 gr_modtool to generate a module with the same name (in
> another directory)
>
> 2. Copy the python folder from 3.9 OOT into your 3.8 OOT
>
> 3. (in 3.8 OOT) Add the bindings directory to the python directory
> CMakeLists
>
>./python/CMakeLists.txt  → add the line:
>add_subdirectory(bindings)
>
> 4. (in 3.8 OOT) Call gr_modtool bind for each block in your OOT
>
> ...
>
> -
> I have not created anything in the 3.9 directory except using
> gr_modtool new and add, nor have I copied in any code
> from 3.8 directory to the 3.9 directory.  I was under the impression
> that step 4 would modify my 3.8 code so that I could
> then copy it from the 3.8 directory over to the 3.9 directory.
>
> There are significant file differences between the newly created 3.9
> and the existing 3.8  with conflicts in the /lib directory:
> the  hermesNB_impl.h and .cc   and hermesWB.h and .cc files differ
> significantly in content.
>
> Do I need to first look through the code and figure out how to merge
> the 3.8 and 3.9 .h and .cc files together?
> Then do I put those merged file into the 3.8 or the 3.9 directory?
>
> -- Tom, N5EG
>
>
>
>
>
>
>
> On Fri, Apr 9, 2021 at 9:27 AM Josh Morman  wrote:
>
>> Tom,
>>
>> If I am following correctly, it looks like you are running gr_modtool
>> (which is the 3.9 version since that is what you have installed in the 
>> VM)
>> in the 3.8 OOT directory?
>> What happens when you run `gr_modtool bind` in the gr-hpsdr_3.9
>> directory
>>
>> The process you are following seems sound to have created a 3.9 OOT
>> with 3.9 modtool, and then copied code in from 3.8.
>>
>> Josh
>>
>> On Fri, Apr 9, 2021 at 12:08 PM Tom McDermott 
>> wrote:
>>
>>> I am having difficulty porting an OOT module to gr 3.9.

Re: problem porting OOT to gr_3.9 : gr_modtool bind error

[Ron Economos]

clang-format is optional. But you can install it with:

sudo apt-get install clang-format

As for your primary issue, are you running on an ARM cpu (like RPi4)? I 
was never able to get binding to work on my armv7 based platform.


Ron

On 4/10/21 11:24, Tom McDermott wrote:
I tried adding a new super simple OOT project.  Of type general, 
adding one module (cpp) with one parameter.
No code added anywhere.  I noticed that when adding the dummy module 
to this dummy OOT that I get 3 errors from gr_modtool add:


Failed to run clang-format %s [Errno 2] no such file or directory: 
'clang-format'


But the .cc and .h files for the module are created. Trying to run 
gr_modtool against that fails the same as before.


Do I have multiple problems here?
Am I missing some dependency for clang-format ?

-- Tom, N5EG






On Sat, Apr 10, 2021 at 12:22 AM Tom McDermott > wrote:


Thanks, Josh.    The OOT should be pretty standard.  It was built
with gr_modtool in 3.7,
then ported over to 3.8.  All the modules are in the normal places.
My guess is NoneType means that the module was not found, then
trying to append .h to
that fails.

I tried running gr_modtool bind inside the gr_3.9/gr-hpsdr
directory and it fails in the exact same way.

I guess at this point I'll have to see if there is some way to run
gr_modtool in a debugger and step through
what it is trying to do and how it is trying to find the modules.

-- Tom, N5EG


On Fri, Apr 9, 2021 at 1:23 PM Josh Morman mailto:mor...@gmail.com>> wrote:

I haven't been able to replicate this on my system with Ubuntu
20.04 and Python 3.8.5  - created a 3.8 OOT with one block,
and followed the steps to copy the 3.9 content back in, and it
got past the `gr_modtool bind` step.

Is there anything non-standard about your 3.8 OOT - e.g. are
the files in the usual place as generated by modtool?

On Fri, Apr 9, 2021 at 1:49 PM Tom McDermott
mailto:tom.n...@gmail.com>> wrote:

Hi Josh - for creating the new 3.9 skeleton, I ran
gr_modtool from within the 3.9 directory.
For step 4, I ran gr_modtool from within the 3.8 directory
(as per the guide).

Quite frankly, it looks like gr_modtool is throwing an
error when trying to
concatenate the module name and path and the .h suffix and
suffering
a type mismatch  (NoneType vs. str).  Is this possibly a
Python 3.x version dependency?

-- Tom, N5EG





On Fri, Apr 9, 2021 at 10:37 AM Josh Morman
mailto:mor...@gmail.com>> wrote:

You are right - that is an easier process than merging
the 3.8 code into 3.9.  The wiki should be correct in
this case.

Which directory are you running gr_modtool from?  Same
directory as you would for doing things like
gr_modtool add?


On Fri, Apr 9, 2021 at 1:24 PM Tom McDermott
mailto:tom.n...@gmail.com>> wrote:

Hi Josh - thank you for your help !

I have been following the instructions from the
porting guide:

https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide



Porting from 3.8 to 3.9 can be achieved most
simply by creating a new OOT module (with the same
name as the 3.8 OOT but in a different directory),
then performing some manual steps

1. Use the 3.9 gr_modtool to generate a module
with the same name (in another directory)

2. Copy the python folder from 3.9 OOT into your
3.8 OOT

3. (in 3.8 OOT) Add the bindings directory to the
python directory CMakeLists

./python/CMakeLists.txt  → add the line:
add_subdirectory(bindings)

4. (in 3.8 OOT) Call gr_modtool bind for each
block in your OOT

...

-

I have not created anything in the 3.9 directory
except using gr_modtool new and add, nor have I
copied in any code
from 3.8 directory to the 3.9 directory.  I was
under the impression that step 4 would modify my
3.8 code so that I could
then copy it from the 3.8 directory over to the
3.9 directory.

There are significant file differences between the
newly created 3.9 and the existing 3.8  with
  

Gnuradio / Ubuntu 20.10

[Alberto Alletto]

Hi!
I’m new on ubuntu world.
Today i have installed ubuntu 20.10 and i want install Gnuradio to work with 
RTL-SDR receiver.

what is the correct procedure to install gnuradio to work with the rtl-sdr 
receiver?

Tnx
Alberto

Inviato da iPhone

Re: Gnuradio / Ubuntu 20.10

[Fabian Schwartau]

Hi Alberto,
Just open a terminal and run
sudo apt install gnuradio
And you should be fine. The dependencies for the rtl-sdr are already included.
It is probably not the latest&greatest version of gnuradio, but IT should get 
you started. 

Fabian

Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto 
:
>Hi!
>I’m new on ubuntu world.
>Today i have installed ubuntu 20.10 and i want install Gnuradio to work
>with RTL-SDR receiver.
>
>what is the correct procedure to install gnuradio to work with the
>rtl-sdr receiver?
>
>Tnx
>Alberto
>
>Inviato da iPhone

Re: missing AudioToolbox.h , UHD

[J R]

I managed the compile of gnuradio after installation of a gnu package giving 
the AudioToolbox lib.
Now I'd like to move onto gr-iqbal ,  gr-osmosdr and gqrx as specified in the 
guide. I hit

celltower@celltower-desktop:~$ pybombs -p install  gr-iqbal gr-osmosdr gqrx

CMake Error at swig/CMakeLists.txt:36 (include):
  include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:53 (GR_SWIG_MAKE):
  Unknown CMake command "GR_SWIG_MAKE".
-- Configuring incomplete, errors occurred!
[ERROR] Error installing package gr-osmosdr. Aborting.

which occurs also after sudo apt-get install swig​ .



From: J R
Sent: Friday, April 9, 2021 6:11 PM
To: discuss-gnuradio@gnu.org 
Subject: Re: missing AudioToolbox.h , UHD

The guide I'm using is
https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Linux#Checking_basic_device_operation
[https://avatars.githubusercontent.com/u/3625151?s=400&v=4]
Nuand/bladeRF
bladeRF USB 3.0 Superspeed Software Defined Radio Source Code - Nuand/bladeRF
github.com

which didn't specifically mention that there were ready packages. I assumed 
that the compile was needed due to some specific configuration or extra 
packages needed.
So after yet another failed compile, on your advice I tried
sudo apt  install gnu-radio
sudo apt install gqrx-sdr
on my ubuntu system, which seemed to complete fine.
But for the 'checking basic device operation' I hit errors:

jr@desktop:~/uhd/uhd/host/build$ osmocom_siggen -a bladerf=0 -s 250 -f 
44600 -g 4 --sine -x 25000
osmocom_siggen: command not found
jr@desktop:~/uhd/uhd/host/build$ osmocom_fft -a bladerf=0 -s 250 -f 
44600
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace 
airspy airspyhf soapy redpitaya freesrp
[bladeRF common] init: DEBUG: entering initialization
[bladeRF source] init: Opening Nuand bladeRF with device identifier string 
'*:instance=0'
[bladeRF source] Device: Nuand bladeRF 2.0 Serial # ab3d...ca8c FW v2.3.2 
FPGA v0.11.0
[bladeRF source] init: Buffers: 512, samples per buffer: 4096, active 
transfers: 32
[bladeRF source] bladerf_source_c: DEBUG: initialization complete
Traceback (most recent call last):
File "/usr/bin/osmocom_fft", line 714, in 
main()
File "/usr/bin/osmocom_fft", line 690, in main
tb = app_top_block(qapp.arguments(), "osmocom Spectrum Browser")
File "/usr/bin/osmocom_fft", line 301, in __init__
self.connect((self.src, 0), (self.scope, 0))
File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 37, 
in wrapped
func(self, src, src_port, dst, dst_port)
File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line 100, 
in connect
self.primitive_connect(*args)
  TypeError: primitive_connect(): incompatible function arguments. The 
following argument types are supported:
1. (self: gnuradio.gr.gr_python.hier_block2_pb, block: 
gnuradio.gr.gr_python.basic_block) -> None
2. (self: gnuradio.gr.gr_python.hier_block2_pb, src: 
gnuradio.gr.gr_python.basic_block, src_port: int, dst: 
gnuradio.gr.gr_python.basic_bloc
k, dst_port: int) -> None

  Invoked with: , , 0
, , 0
swig/python detected a memory leak of type 'gr::basic_block_sptr *', no 
destructor found.
Segmentation fault (core dumped)

I realize its somewhat off-base from a gnuradio issue but if you have any clues 
I would greatly appreciate it.
Thanks
JR


From: Discuss-gnuradio on behalf of Marcus Müller
Sent: Friday, April 9, 2021 11:26 AM
To: discuss-gnuradio@gnu.org
Subject: Re: missing AudioToolbox.h , UHD

First question would be: what particular guide? A particular reason why you're 
following
it? On a wild guess, this looks like you want to build a custom GNU Radio and 
libbladerf
because you want to do something with a BladeRF, but if that's the case, you 
might not
even care about USRPs, and thus UHD.

Other than that, if you don't need any special version of anything, the easiest 
version is
usually just going through your operating system's package manager – hence my 
question why
you're following the path you're on :)

Best regards,
Marcus

On 09.04.21 07:49, J R wrote:
> Hi All,
>
> I was needing to install gnuradio while following a certain guide , which I 
> tried using
>
> pybombs prefix init ~/pybombs/bladeRF4 -a bladeRF -R gnuradio-default
>
> during this process I hit a missing 'AudioToolbox/AudioToolbox.h' file, so I 
> dl the lib
> from github and put it in /usr/lib.
> While re-running I saw :
>
>
> -- Configuring gr-uhd support...
> --   Dependency Boost_FOUND = TRUE
> --   Dependency UHD_FOUND = 0
>
> and so 

Re: Error message in fm_rx and fm_tx example

[Clark Chiu]

Hi Christophe,

I think I got the same result as you mentioned.

$ locate fft_python: (it's more or less the same, the difference is the
version of python3)

/usr/lib/python3/dist-packages/gnuradio/fft/
fft_python.cpython-36m-x86_64-linux-gnu.so


$ python3 fm_rx3.py

['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__',
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__', '__subclasshook__', 'bartlett', 'blackman', 'blackman2',
'blackman3', 'blackman4', 'blackman_harris', 'blackman_nuttal',
'blackman_nuttall', 'blackmanharris', 'build', 'coswindow', 'exponential',
'flattop', 'hamming', 'hann', 'hanning', 'kaiser', 'max_attenuation',
'nuttal', 'nuttal_cfd', 'nuttall', 'nuttall_cfd', 'parzen', 'rectangular',
'riemann', 'welch']


pybind11_builtins.pybind11_type


window.__init_subclass__= 


window.__init__= 



I got a suggestion from Jay, which is to change the last argument of Taps
from "window.WIN_KAISER" to "firdes.WIN_KAISER".
This works for the fm_rx! It can run  with the dummy.dat you sent earlier.
However, for fm_tx, it is supposed to generate dummy.dat, it generates an
empty file instead...


Best regards,
Clark

On Sat, Apr 10, 2021 at 8:40 AM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> I'm not used to Python bindings and don't really konws how to debug this.
> It look like your install is nor importing the right "window" class.
>
> Can you please run this python code and the linux command:
>
>- locate fft_python (available if you installed locate package with *sudo
>apt-get install locate*, answer below
>- /usr/lib/python3/dist-packages/gnuradio/fft/
>   fft_python.cpython-38-x86_64-linux-gnu.so
>
>
>- python3 fm_rx3.py (only import window class and list its attributes
>
> you should get for the python code, something like this
>
> ['WIN_BARTLETT', 'WIN_BLACKMAN', 'WIN_BLACKMAN_HARRIS',
> 'WIN_BLACKMAN_hARRIS', 'WIN_FLATTOP', 'WIN_HAMMING', 'WIN_HANN',
> 'WIN_KAISER', 'WIN_RECTANGULAR', '__class__', '__delattr__', '__dir__',
> '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__',
> '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__',
> '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
> '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
> 'bartlett', 'blackman', 'blackman2', 'blackman3', 'blackman4',
> 'blackman_harris', 'blackman_nuttal', 'blackman_nuttall', 'blackmanharris',
> 'build', 'coswindow', 'exponential', 'flattop', 'hamming', 'hann',
> 'hanning', 'kaiser', 'max_attenuation', 'nuttal', 'nuttal_cfd', 'nuttall',
> 'nuttall_cfd', 'parzen', 'rectangular', 'riemann', 'welch', 'win_type']
>
> pybind11_builtins.pybind11_type
>
> window.__init_subclass__=  pybind11_type object at 0x1753260>
>
> window.__init__=  'gnuradio.fft.fft_python.window' objects>
>
>
> Regards
>
> On 09/04/2021 22:17, Clark Chiu wrote:
>
> Hi Christophe,
>
> After I run "python3 fm_rx.py", I got this message:
> ==
> Traceback (most recent call last):
>   File "fm_rx.py", line 508, in 
> main()
>   File "fm_rx.py", line 486, in main
> tb = top_block_cls()
>   File "fm_rx.py", line 252, in __init__
> window.WIN_BLACKMAN_hARRIS, #wintype
> AttributeError: type object 'gnuradio.fft.fft_python.window' has no
> attribute 'WIN_BLACKMAN_hARRIS'
> ==
>
> Seems like it couldn't find the correct window type...?
>
>
> Best regards,
> Clark
>
>
> On Fri, Apr 9, 2021 at 12:50 PM Christophe Seguinot <
> christophe.segui...@orange.fr> wrote:
>
>> Could you please copy these files for som folder:
>>
>>- dummy.dat is generated by fm_tx.grc
>>- fm_rx.py is generated from frm;_rx.grc flowgraph
>>
>> and try to run the .py file:
>>
>>- python3 fm_rx.py
>>
>> may be you could get a more explicit error  for line with
>> firdes.low_pass_2(self.volume...)
>>
>>
>> On 09/04/2021 18:11, Clark Chiu wrote:
>>
>> Hi Christophe and Marcus,
>>
>> Thank you for the reply. I tried the fm_tx_2.grc and it has the same
>> error message as below.
>> ===
>> Block: pfb_arb_resampler_xxx_0
>> Aspect: Param 'Taps'
>> Message: Expression None is invalid for type'real_vector'.
>> ===
>> Also the files between master and maint-3.9 are identical.
>> "git diff maint-3.9 master gr-analog/examples/fm_?x.grc"
>>
>> I don't think I had a previous version of GNU Radio before. I installed
>> GNU Radio from the binary package. I tried to delete the cache file and the
>> cache folder then restart GRC but it is the same.
>>
>> Any other suggestions?
>>
>>
>> Best regards,
>> Clark
>>
>>
>> On Fri, Apr 9, 2021 at 9:19 AM Christophe Seguinot <
>> christophe.segui...@orange.fr> wrote:
>>
>>> Hi Clark
>>>
>>> I'm running under Ubuntu 20.04 and GNURadio 3.9 fresh install (my
>>> Computer and HDD were out for several days an I had to reins