RE: Getting "referenced unknown base type gr::block"

[Tom McDermott]

> From: Nikoloz Glonti 
> To: "discuss-gnuradio@gnu.org" 
> Cc:
> Bcc:
> Date: Thu, 26 May 2022 17:11:50 +0200
> Subject: Getting "referenced unknown base type gr::block"
> Hi everyone,
>
> I have newest gnuradio 3.10, and I'm compiling example QPSK block -
>
https://wiki.gnuradio.org/index.php?title=Guided_Tutorial_GNU_Radio_in_C%2B%2B

> But when trying to run it i get following error.
>
>   File
> "/home/ng/Desktop/bloczki/gr-spektralsi/build/python/testFiltru.py",
> line 35, in 
> from gnuradio import pec
>   File
> "/usr/local/lib/python3.10/site-packages/gnuradio/pec/__init__.py", line
> 18, in 
>  from .pec_python import *
> ImportError: generic_type: type "qpsk_demod_cb" referenced unknown base
> type "gr::block"
>
> How can i fix it?
>
> Thank You in advance
> Niko

My experience is that this is commonly caused by pybind11-dev version
incompatibility.
At least version 2.5.0 is needed. Ubuntu 20.04 provides version 2.4.3
and I have not
been successful in updating to a later version on that specific OS
release.   Ubuntu 22.04 provides
more recent versions of a bunch of tools, and for me that was what was
needed.

-- Tom, N5EG

[SOLVED] pybind11 problems, gr::block undefined in gnuradio 3.10

[Tom McDermott]

>>> import hpsdr
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", line
18, in 
from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base type
"gr::block"
>>>

The only way I found to solve this problem was to stop using Ubuntu 20.04
Focal and move to Ubuntu 22.04 Jammy.
22.04 seems to have the latest versions of the key tools, it all built, and
runs correctly.

I suspect this just affects pybind11,  if so folks probably would still be
able to install the OOT
on the older version of Ubuntu, they just couldn't change anything that
would require re-binding.

-- Tom, N5EG

gr::block unknown base type (was: What version of pybind for 3.10.1.1 )

[Tom McDermott]

> In porting over my 3.9 OOT to 3.10,  I have the import error:
>
> >>> import hpsdr
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py",
line 18, in 
> from .hpsdr_python import *
> ImportError: generic_type: type "hermesNB" referenced unknown base type
"gr::block"
> >>>
>
> When I went through this back in 3.9, it was due to a version problem in
pybind11.
>
> I have installed pybind11-dev version 2.5.0 from the tarball.   Ubuntu
20.04 package manager
> has reverted to 2.4.3 (after having been at 2.5.0 for awhile).
>
> Is this still a pybind11 versioning problem?  If so, what version of
pybind11 should I be
> using to build my OOT for 3.10.1.1 ?
>

Update

Using Ubuntu 20.04 (focal).

The module has been tried using pybind11-dev  ver. 2.5.0 and  ver 2.9.2
from tarball without success
(gr_modtool bind works OK, cmake, make, make install works OK.  Trying to
run causes the python
exception gr::block not found).

The Ubuntu 20.04 package manager provides pybind11-dev v 2.4.3 only.

Then uninstalled v 2.9.2 (which is a proper superset of 2.5.0) since 2.9.2
tarball creates an uninstall rule
( 2.5.0 does not create an uninstall rule).

Next pulled pybind11-dev  2.6.2 in from Ubuntu Impish by manipulating APT
and installed
only that from the package manager, then cleaned up APT to prevent anything
else from updating.

The 2.6.2 installed via APT gives exactly the same problem, gr::block
exception.

Does anyone have advice on how to fix?

-- Tom, N5EG



Message ID: 

>
>

What version of pybind11 is 3.10.1.1 built against?

[Tom McDermott]

In porting over my 3.9 OOT to 3.10,  I have the import error:

>>> import hpsdr
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", line
18, in 
from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base type
"gr::block"
>>>

When I went through this back in 3.9, it was due to a version problem in
pybind11.

I have installed pybind11-dev version 2.5.0 from the tarball.   Ubuntu
20.04 package manager
has reverted to 2.4.3 (after having been at 2.5.0 for awhile).

Is this still a pybind11 versioning problem?  If so, what version of
pybind11 should I be
using to build my OOT for 3.10.1.1 ?


-- Tom, N5EG

Re: OOT port to 3.10 - bind error

[Tom McDermott]

Thank you Ryan - that was indeed the problem.  I updated to latest 2.2.1
via:

$ python -m pip install --upgrade pygccxml

which brought this Ubuntu 20.04 system up to pygccxml version 2.2.1

-- Tom, N5EG





On Fri, Apr 29, 2022 at 11:10 AM Ryan Volz  wrote:

> Hi Tom,
>
> A little more searching brought me here, where it becomes clear that
> your problem is actually a too-old pygccxml!:
>
>
> https://sources.debian.org/src/pygccxml/1.9.1-1/pygccxml/utils/utils.py/#L322
>
> I remember seeing this somewhere on the mailing list/chat before, and I
> think that the solution is to use pip to install a newer pygccxml since
> nothing packaged for Ubuntu is new enough. Maybe someone else will chime
> in who knows better.
>
> Cheers,
> Ryan
>
> On 4/29/22 1:07 PM, Tom McDermott wrote:
> > Thanks, Ryan. The system has GCC 9.3.0 installed (Ubuntu 20.04)
> > which the docs say supports c++17.
> >
> > pybind11 package manager version for Ubuntu 20.04 used to be 2.5.0.  The
> > package manager has now reverted the standard version
> > to 2.4.3  (which used to not work).   I installed pybind 2.5.0 using the
> > tarball (link on the wiki for 3.9 OOT porting).   That
> > pybind11 build might not support c++17, perhaps c++14 (based on strings
> > in the pybind build directory)?
> >
> > Is some different version of pybind11 needed now for gnuradio 3.10 ?
> >
> > -- Tom, N5EG
> >
> >
> >
> > On Fri, Apr 29, 2022 at 9:40 AM Ryan Volz  > <mailto:ryan.v...@gmail.com>> wrote:
> >
> > Hi Tom,
> >
> > GR 3.10 increased the CXX standard to c++17. Perhaps your compiler
> > doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?
> >
> > My suspicion is that the following line has something to do with it:
> >
> >
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
> > <
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
> >
> >
> > Cheers,
> > Ryan
> >
> > On 4/29/22 11:35 AM, Tom McDermott wrote:
> >  > I am trying to port an existing 3.9 OOT to 3.10.   After the
> > conversion
> >  > and edits based on the 3.10 directories,
> >  > the command to gr_modtool bind my_module fails with the error:
> >  >
> >  > Unknown -std=c++xx flag used
> >  >
> >  > I've greped the entire 3.10 project from its root and that string
> >  > is not in any of the project modules except in the
> >  > failed_conversions.txt file in the python bind output directory).
> >  >
> >  > The only place I can see an include pointing outside the OOT
> > directory
> >  > is in the api.h file in the project include directory:
> >  > #include 
> >  >
> >  > That attributes.h file cannot be found anywhere  on my system.
> >  >
> >  > -- Tom, N5EG
> >  >
> >  >
> >  >
> >  >
> >
>

Re: OOT port to 3.10 - bind error

[Tom McDermott]

Thanks, Ryan. The system has GCC 9.3.0 installed (Ubuntu 20.04) which
the docs say supports c++17.

pybind11 package manager version for Ubuntu 20.04 used to be 2.5.0.  The
package manager has now reverted the standard version
to 2.4.3  (which used to not work).   I installed pybind 2.5.0 using the
tarball (link on the wiki for 3.9 OOT porting).   That
pybind11 build might not support c++17, perhaps c++14 (based on strings in
the pybind build directory)?

Is some different version of pybind11 needed now for gnuradio 3.10 ?

-- Tom, N5EG



On Fri, Apr 29, 2022 at 9:40 AM Ryan Volz  wrote:

> Hi Tom,
>
> GR 3.10 increased the CXX standard to c++17. Perhaps your compiler
> doesn't recognize -std=c++17, but did allow -std=c++14 with GR 3.9?
>
> My suspicion is that the following line has something to do with it:
>
>
> https://github.com/gnuradio/gnuradio/blob/main/gr-utils/blocktool/core/parseheader_generic.py#L323
>
> Cheers,
> Ryan
>
> On 4/29/22 11:35 AM, Tom McDermott wrote:
> > I am trying to port an existing 3.9 OOT to 3.10.   After the conversion
> > and edits based on the 3.10 directories,
> > the command to gr_modtool bind my_module fails with the error:
> >
> > Unknown -std=c++xx flag used
> >
> > I've greped the entire 3.10 project from its root and that string
> > is not in any of the project modules except in the
> > failed_conversions.txt file in the python bind output directory).
> >
> > The only place I can see an include pointing outside the OOT directory
> > is in the api.h file in the project include directory:
> > #include 
> >
> > That attributes.h file cannot be found anywhere  on my system.
> >
> > -- Tom, N5EG
> >
> >
> >
> >
>

OOT port to 3.10 - bind error

[Tom McDermott]

I am trying to port an existing 3.9 OOT to 3.10.   After the conversion and
edits based on the 3.10 directories,
the command to gr_modtool bind my_module fails with the error:

Unknown -std=c++xx flag used

I've greped the entire 3.10 project from its root and that string
is not in any of the project modules except in the failed_conversions.txt
file in the python bind output directory).

The only place I can see an include pointing outside the OOT directory is
in the api.h file in the project include directory:
#include 

That attributes.h file cannot be found anywhere  on my system.

-- Tom, N5EG

Re: Releases v3.8.4.0 and v3.9.3.0

[Tom McDermott]

Hi Glen - you may want to take a look at Dan Babcock N4XWE's github page.
He has a long list of Raspberry Pi installer scripts for various radio
applications
including gnuradio.  https://github.com/n4xwe/Raspberry-Pi-Scripts

-- Tom, N5EG



-- Forwarded message --
From: Glen Langston 
To: GNURadio Discussion List 
Cc:
Bcc:
Date: Tue, 23 Nov 2021 17:04:21 -0500
Subject: Re: Releases v3.8.4.0 and v3.9.3.0
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

gr_3.9 OOT generates strange .so files

[Tom McDermott]

I have successfully built my OOT in gnuradio 3.9.  This was done with a
plain vanilla gr_modtool
constructed build, and built using cmake, make, make install, etc.

One of the folks who uses my module and packages it for one of the linux
distributions noticed that
it is generating some strange output files, and I can confirm on my own
system.

The .so filenames are installed in /usr/lib (for that specific person)  or
/usr/x86-64-linux-gnu/   (for my system)

The correct .so is being generated and used without any issues:
libgnuradio.grhpsdr.so

But it is also generating:
libgnuradio.grhpsdr.so.1.0.0git
libgnuradio.grhpsdr.so.e487bf33

I noticed that other modules have a series of versioned soft links. For
example:

libgnuradio.analog.so -> libgnuradio.analog.so.3.9.1
libgnuradio.analog.so.3.9.1 -> libgnuradio.analog.so.3.9.1.0
libgnuradio.analog.so.3.9.1.0

Is the way my OOT's  .so files (and no soft links) being generated a
problem?
Will this fail on a subsequent update to my OOT?
Is there some sort of extra configuration I need to do to the
auto-generated make or cmake files ?

-- Tom, N5EG

Re: issues porting C++ OOT to 3.9 - fails at runtime import

[Tom McDermott]

Hi Josh - you da man!

This fixes the problem, and the 3.9 OOT runs now.

Of note for anyone else following along:  the 2.4.3 tarball for pybind11
listed in the 3.9 OOT porting guide instructions
does not create a make uninstall target. It does however produce an install
manifest.  I went through that and deleted
what it installed before proceeding.

Then sudo apt install pybind11-dev   This installed 2.5.0

-- Tom, N5EG




On Mon, May 10, 2021 at 4:01 AM Josh Morman  wrote:

> Tom,
>
> It looks like the OOT might be using a different version of pybind11 than
> the ppa version of gnuradio was built against.  The PPA for 20.04 appears
> to have been built using pybind11 v2.5.0, but the default with Ubuntu 20.04
> is 2.4.3.
>
> I can repeat the symptom you see when creating a docker that has
> pybind11-dev v.2.4.3 from the main Ubuntu repos, but then pull gnuradio
> from ppa:gnuradio-releases.  After installing gnuradio from the ppa, if I
> then do:
> apt upgrade pybind11-dev
>
> then the OOT will compile and load properly.
>
> I can probably fix this in the PPA by removing the pybind11 packages and
> just relying on what gets shipped with Ubuntu, but for now, maybe a ` apt
> upgrade pybind11-dev ` will fix the issue.
>
> Josh
>
> On Sun, May 9, 2021 at 7:18 PM Tom McDermott  wrote:
>
>> I built a new VM from zero.  Ubuntu 20.04
>> apt install build-essential
>> apt install git
>> apt install cmake
>> apt install python3-pip
>> pip3 install pygccxml
>> build, install pybind11 from 2.4.3 tarball
>> setup gnuradio repository to releases
>> apt install gnuradio
>>This gives gnuradio 3.9.1.0
>>
>> git-cloning both Ron's gr-iqlevels and my gr-hpsdr, going through cmake,
>> make, sudo make install, sudo ldconfig
>> yields exactly the same results as before:  the gr:sync_block
>> (gr-iqlevels)  or the gr::block (gr-hpsdr)  are not imported.
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>>
>> On Sun, May 9, 2021 at 11:44 AM Tom McDermott  wrote:
>>
>>> Hi Ron - thank you for sending me the link to your 3.9 gr-iqlevels
>>> module !
>>> It builds and installs OK, but when trying to run it gives me the same
>>> type of error as my own module:
>>>
>>> Note: cmake .. -DCMAKE_INSTALL_PREFIX=/usr   was used for for gr-iqlevels
>>>
>>> $ python3
>>> Python 3.8.5 (default, Jan 27 2021, 15:41:15)
>>> [GCC 9.3.0] on linux
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import gnuradio
>>> >>> import iqlevels
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "/usr/lib/python3/dist-packages/iqlevels/__init__.py", line 18,
>>> in 
>>> from .iqlevels_python import *
>>> ImportError: generic_type: type "iqlevels" referenced unknown base type
>>> "gr::sync_block"
>>> >>>
>>>
>>> And when run from GRC:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/tom/Desktop/iqlevels.py", line 142, in 
>>> main()
>>>   File "/home/tom/Desktop/iqlevels.py", line 120, in main
>>> tb = top_block_cls()
>>>   File "/home/tom/Desktop/iqlevels.py", line 81, in __init__
>>> self.iqlevels_iqlevels_0 = iqlevels.iqlevels(samp_rate, 1)
>>> AttributeError: type object 'iqlevels' has no attribute 'iqlevels'
>>>
>>>
>>> So it appears there is something wrong or misconfigured in my system.
>>> I am baffled as to what that might be.
>>>
>>> Ubuntu 20.04
>>> Gnuradio 3.9.0.0
>>> Python 3.8.5
>>> Cmake 3.16.3
>>> GCC 9.3.0
>>> pygccxml  2.1.0  installed using pip3
>>> pybind11-2.4.3 installed from tarball according to the OOT 3.9
>>> instructions
>>>   pybind11 build, cmake, make, make install by the above directions.
>>>it put the various pybind headers into /usr/local/include/pybind11/
>>>
>>> Is there some other configuration, path, or other thing that needs to be
>>> setup?
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>

Re: issues porting C++ OOT to 3.9 - fails at runtime import

[Tom McDermott]

I built a new VM from zero.  Ubuntu 20.04
apt install build-essential
apt install git
apt install cmake
apt install python3-pip
pip3 install pygccxml
build, install pybind11 from 2.4.3 tarball
setup gnuradio repository to releases
apt install gnuradio
   This gives gnuradio 3.9.1.0

git-cloning both Ron's gr-iqlevels and my gr-hpsdr, going through cmake,
make, sudo make install, sudo ldconfig
yields exactly the same results as before:  the gr:sync_block
(gr-iqlevels)  or the gr::block (gr-hpsdr)  are not imported.

-- Tom, N5EG






On Sun, May 9, 2021 at 11:44 AM Tom McDermott  wrote:

> Hi Ron - thank you for sending me the link to your 3.9 gr-iqlevels module !
> It builds and installs OK, but when trying to run it gives me the same
> type of error as my own module:
>
> Note: cmake .. -DCMAKE_INSTALL_PREFIX=/usr   was used for for gr-iqlevels
>
> $ python3
> Python 3.8.5 (default, Jan 27 2021, 15:41:15)
> [GCC 9.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import gnuradio
> >>> import iqlevels
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/iqlevels/__init__.py", line 18, in
> 
> from .iqlevels_python import *
> ImportError: generic_type: type "iqlevels" referenced unknown base type
> "gr::sync_block"
> >>>
>
> And when run from GRC:
>
> Traceback (most recent call last):
>   File "/home/tom/Desktop/iqlevels.py", line 142, in 
> main()
>   File "/home/tom/Desktop/iqlevels.py", line 120, in main
> tb = top_block_cls()
>   File "/home/tom/Desktop/iqlevels.py", line 81, in __init__
> self.iqlevels_iqlevels_0 = iqlevels.iqlevels(samp_rate, 1)
> AttributeError: type object 'iqlevels' has no attribute 'iqlevels'
>
>
> So it appears there is something wrong or misconfigured in my system.
> I am baffled as to what that might be.
>
> Ubuntu 20.04
> Gnuradio 3.9.0.0
> Python 3.8.5
> Cmake 3.16.3
> GCC 9.3.0
> pygccxml  2.1.0  installed using pip3
> pybind11-2.4.3 installed from tarball according to the OOT 3.9 instructions
>   pybind11 build, cmake, make, make install by the above directions.
>it put the various pybind headers into /usr/local/include/pybind11/
>
> Is there some other configuration, path, or other thing that needs to be
> setup?
>
> -- Tom, N5EG
>
>
>
>
>

re: issues porting C++ OOT to 3.9 - fails at runtime import

[Tom McDermott]

Hi Ron - thank you for sending me the link to your 3.9 gr-iqlevels module !
It builds and installs OK, but when trying to run it gives me the same type
of error as my own module:

Note: cmake .. -DCMAKE_INSTALL_PREFIX=/usr   was used for for gr-iqlevels

$ python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnuradio
>>> import iqlevels
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/iqlevels/__init__.py", line 18, in

from .iqlevels_python import *
ImportError: generic_type: type "iqlevels" referenced unknown base type
"gr::sync_block"
>>>

And when run from GRC:

Traceback (most recent call last):
  File "/home/tom/Desktop/iqlevels.py", line 142, in 
main()
  File "/home/tom/Desktop/iqlevels.py", line 120, in main
tb = top_block_cls()
  File "/home/tom/Desktop/iqlevels.py", line 81, in __init__
self.iqlevels_iqlevels_0 = iqlevels.iqlevels(samp_rate, 1)
AttributeError: type object 'iqlevels' has no attribute 'iqlevels'


So it appears there is something wrong or misconfigured in my system.
I am baffled as to what that might be.

Ubuntu 20.04
Gnuradio 3.9.0.0
Python 3.8.5
Cmake 3.16.3
GCC 9.3.0
pygccxml  2.1.0  installed using pip3
pybind11-2.4.3 installed from tarball according to the OOT 3.9 instructions
  pybind11 build, cmake, make, make install by the above directions.
   it put the various pybind headers into /usr/local/include/pybind11/

Is there some other configuration, path, or other thing that needs to be
setup?

-- Tom, N5EG

issues porting C++ OOT to 3.9 - fails at runtime import

[Tom McDermott]

I am continuing to have issues porting my 3.8 code over to 3.9.   (Ubuntu
20.04)
By request I've posted the code on github:

https://github.com/Tom-McDermott/gr-hpsdr   branch: gr_3.9_broken

I know it is asking a lot to look over someone's code.

Alternatively, is there a simple C++ OOT on 3.9 that has the source code
tree available?  Something like  how_to_square that can be built,  builds,
installs,
and runs correctly?  This would allow testing to see if the environment,
tooling,
etc. is working correctly on that known-good OOT.

My source code cmakes, makes, installs OK.. GRC can instantiate the module
OK graphically.
But it fails at runtime due to gr::block not being found.  Josh looked over
one or two
snippets of code which seem correct.  I've poured over the build files,
'readelf' and 'nm' the .SO file, etc,
but do not know how the python inheritance gets inserted.

A couple of observations:

1. bind fails on certain valid path names.  I copied my entire OOT
repository to another directory
and Ubuntu created a copy with the ASCII (copy) in the directory name.
Having the ASCII
characters  ' (copy)' embedded within the directory name causes bind to
throw an error pointing
at that first parenthesis. Changing the directory name to not have the
parenthesis characters fixes that.

2. When I open python3 from the command line and import hpsdr, I get the
same error
 as when trying to run the flowgraph from GRC:

$ python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnuradio
>>> import hpsdr
An exception of type ImportError occurred. Arguments:
('generic_type: type "hermesNB" referenced unknown base type "gr::block"',)
> /usr/lib/python3/dist-packages/hpsdr/__init__.py(19)()
-> from .hpsdr_python import *

Any help would be much appreciated.

-- Tom, N5EG

Re: gr 3.9 OOT execution error: unknown base type gr::block

[Tom McDermott]

I rebuilt the OOT from scratch - new directory, gr_modtool newmod, add, etc.
Then copied over just the edited source code, leaving all the other files
intact.
Except to edit /lib/CMakelist.txt to include my c++ (non impl) code.  It
still fails in the exact
same way.

I modified /usr/lib/python3/dist-packages/hpsdr/__init__.py to print some
more details about the
exception thrown, type, arguments, then doing a pdb post_mortem.  Here is
the output of that:

An exception of type ImportError occurred. Arguments:
('generic_type: type "hermesNB" referenced unknown base type "gr::block"',)
> /usr/lib/python3/dist-packages/hpsdr/__init__.py(19)()
-> from .hpsdr_python import *
(Pdb)
Traceback (most recent call last):
  File "/home/tom/Desktop/Test_AM.py", line 210, in 
main()
  File "/home/tom/Desktop/Test_AM.py", line 188, in main
tb = top_block_cls()
  File "/home/tom/Desktop/Test_AM.py", line 140, in __init__
self.hpsdr_hermesNB_0 = hpsdr.hermesNB(Frequency, 720, 720,
720, 720, 720, 720, 720, 720, 0, 0, 1, 1, 0,
192000, "eth0", "0xF8", 0, 0, 0x00, 0x00, 0, 1, "*")
AttributeError: module 'hpsdr' has no attribute 'hermesNB'

-- Tom, N5EG



On Wed, May 5, 2021 at 11:09 AM Tom McDermott  wrote:

> HI Josh - here is the entire file ./python/bindings/python_bindings.cc:
>
> /*
>  * Copyright 2020 Free Software Foundation, Inc.
>  *
>  * This file is part of GNU Radio
>  *
>  * SPDX-License-Identifier: GPL-3.0-or-later
>  *
>  */
>
> #include 
>
> #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
> #include 
>
> namespace py = pybind11;
>
> // Headers for binding functions
> /**/
> /* The following comment block is used for
> /* gr_modtool to insert function prototypes
> /* Please do not delete
> /**/
> // BINDING_FUNCTION_PROTOTYPES(
> void bind_hermesNB(py::module& m);
> void bind_hermesWB(py::module& m);
> // ) END BINDING_FUNCTION_PROTOTYPES
>
>
> // We need this hack because import_array() returns NULL
> // for newer Python versions.
> // This function is also necessary because it ensures access to the C API
> // and removes a warning.
> void* init_numpy()
> {
> import_array();
> return NULL;
> }
>
> PYBIND11_MODULE(hpsdr_python, m)
> {
> // Initialize the numpy C API
> // (otherwise we will see segmentation faults)
> init_numpy();
>
> // Allow access to base block methods
> py::module::import("gnuradio.gr");
>
> /**/
> /* The following comment block is used for
> /* gr_modtool to insert binding function calls
> /* Please do not delete
> /**/
> // BINDING_FUNCTION_CALLS(
> bind_hermesNB(m);
> bind_hermesWB(m);
> // ) END BINDING_FUNCTION_CALLS
> }
>
> -- Tom, N5EG
>
>
>
>
> On Wed, May 5, 2021 at 9:41 AM Josh Morman  wrote:
>
>> That looks right.  And in python_bindings.cc, do you see the import of
>> base block methods like:
>>
>> PYBIND11_MODULE(blocks_python, m)
>> {
>> // Initialize the numpy C API
>> // (otherwise we will see segmentation faults)
>> init_numpy();
>>
>> // Allow access to base block methods
>> py::module::import("gnuradio.gr");
>>
>> On Wed, May 5, 2021 at 11:21 AM Tom McDermott  wrote:
>>
>>> Hi Josh - thanks for your help.
>>>
>>> from ./python/bindings/hermesNB_python.cc:
>>>
>>> void bind_hermesNB(py::module& m)
>>> {
>>>
>>> using hermesNB= ::gr::hpsdr::hermesNB;
>>>
>>>
>>> py::class_>> std::shared_ptr>(m, "hermesNB", D(hermesNB))
>>>
>>> .def(py::init(&hermesNB::make),
>>>py::arg("RxFreq0"),
>>> ... long list of arguments...
>>>   D(hermesNB,make)
>>> )
>>>
>>> -- Tom, N5EG
>>>
>>>
>>> On Wed, May 5, 2021 at 7:26 AM Josh Morman  wrote:
>>>
>>>> Tom,
>>>>
>>>> What does your hermesNB_python.cc look like?
>>>>
>>>> There should be a declaration for the binding in there that looks like:
>>>> py::class_>>>gr::sync_block,
>>>>gr::block,
>>>>gr::basic_block,
>>>>
>>>> or something to that effect.  It could be that modtool 

Re: gr 3.9 OOT execution error: unknown base type gr::block

[Tom McDermott]

HI Josh - here is the entire file ./python/bindings/python_bindings.cc:

/*
 * Copyright 2020 Free Software Foundation, Inc.
 *
 * This file is part of GNU Radio
 *
 * SPDX-License-Identifier: GPL-3.0-or-later
 *
 */

#include 

#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
#include 

namespace py = pybind11;

// Headers for binding functions
/**/
/* The following comment block is used for
/* gr_modtool to insert function prototypes
/* Please do not delete
/**/
// BINDING_FUNCTION_PROTOTYPES(
void bind_hermesNB(py::module& m);
void bind_hermesWB(py::module& m);
// ) END BINDING_FUNCTION_PROTOTYPES


// We need this hack because import_array() returns NULL
// for newer Python versions.
// This function is also necessary because it ensures access to the C API
// and removes a warning.
void* init_numpy()
{
import_array();
return NULL;
}

PYBIND11_MODULE(hpsdr_python, m)
{
// Initialize the numpy C API
// (otherwise we will see segmentation faults)
init_numpy();

// Allow access to base block methods
py::module::import("gnuradio.gr");

/**/
/* The following comment block is used for
/* gr_modtool to insert binding function calls
/* Please do not delete
/**/
// BINDING_FUNCTION_CALLS(
bind_hermesNB(m);
bind_hermesWB(m);
// ) END BINDING_FUNCTION_CALLS
}

-- Tom, N5EG




On Wed, May 5, 2021 at 9:41 AM Josh Morman  wrote:

> That looks right.  And in python_bindings.cc, do you see the import of
> base block methods like:
>
> PYBIND11_MODULE(blocks_python, m)
> {
> // Initialize the numpy C API
> // (otherwise we will see segmentation faults)
> init_numpy();
>
> // Allow access to base block methods
> py::module::import("gnuradio.gr");
>
> On Wed, May 5, 2021 at 11:21 AM Tom McDermott  wrote:
>
>> Hi Josh - thanks for your help.
>>
>> from ./python/bindings/hermesNB_python.cc:
>>
>> void bind_hermesNB(py::module& m)
>> {
>>
>> using hermesNB= ::gr::hpsdr::hermesNB;
>>
>>
>> py::class_> std::shared_ptr>(m, "hermesNB", D(hermesNB))
>>
>> .def(py::init(&hermesNB::make),
>>py::arg("RxFreq0"),
>> ... long list of arguments...
>>   D(hermesNB,make)
>> )
>>
>> -- Tom, N5EG
>>
>>
>> On Wed, May 5, 2021 at 7:26 AM Josh Morman  wrote:
>>
>>> Tom,
>>>
>>> What does your hermesNB_python.cc look like?
>>>
>>> There should be a declaration for the binding in there that looks like:
>>> py::class_>>gr::sync_block,
>>>gr::block,
>>>gr::basic_block,
>>>
>>> or something to that effect.  It could be that modtool didn't add the
>>> parent classes so that the inherited methods show up in the bindings.  If
>>> so, that is a bug.  I'm just thinking that what you are seeing would be the
>>> case if gr:;block wasn't a part of the declaration of the binding (which
>>> should happen automatically)
>>>
>>> I don't think it is related to the capitalization of the category name -
>>> in the code, the module is all lowercase.
>>>
>>> Josh
>>>
>>> On Wed, May 5, 2021 at 10:20 AM Tom McDermott 
>>> wrote:
>>>
>>>> I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work
>>>> fine.
>>>> The ported code is compiled and make installed.  My OOT is visible in
>>>> GRC, and
>>>> I've added to a new flowgraph.
>>>>
>>>> My OOT is in category HPSDR  and the module is hermesNB (of several).
>>>>
>>>> When I try to execute a simple flowgraph in GRC with this OOT I get the
>>>> following error:
>>>>
>>>> Traceback (most recent call last):
>>>>   File "/home/tom/Desktop/Test_AM.py", line 38, in 
>>>> import hpsdr
>>>>   File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in
>>>> 
>>>> from .hpsdr_python import *
>>>> ImportError: generic_type: type "hermesNB" referenced unknown base type
>>>> "gr::block"
>>>>
>>>> Do I need to add code somewhere to import gr::block   ??
>>>>
>>>> Is there an issue with capitalization of  hpsdr  vs. category name of
>>>> HPSDR  ??
>>>>
>>>> -- Tom, N5EG
>>>>
>>>>
>>>>
>>>>
>>>>

Re: gr 3.9 OOT execution error: unknown base type gr::block

[Tom McDermott]

Hi Josh - thanks for your help.

from ./python/bindings/hermesNB_python.cc:

void bind_hermesNB(py::module& m)
{

using hermesNB= ::gr::hpsdr::hermesNB;


py::class_>(m, "hermesNB", D(hermesNB))

.def(py::init(&hermesNB::make),
   py::arg("RxFreq0"),
... long list of arguments...
  D(hermesNB,make)
)

-- Tom, N5EG


On Wed, May 5, 2021 at 7:26 AM Josh Morman  wrote:

> Tom,
>
> What does your hermesNB_python.cc look like?
>
> There should be a declaration for the binding in there that looks like:
> py::class_gr::sync_block,
>gr::block,
>gr::basic_block,
>
> or something to that effect.  It could be that modtool didn't add the
> parent classes so that the inherited methods show up in the bindings.  If
> so, that is a bug.  I'm just thinking that what you are seeing would be the
> case if gr:;block wasn't a part of the declaration of the binding (which
> should happen automatically)
>
> I don't think it is related to the capitalization of the category name -
> in the code, the module is all lowercase.
>
> Josh
>
> On Wed, May 5, 2021 at 10:20 AM Tom McDermott  wrote:
>
>> I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work
>> fine.
>> The ported code is compiled and make installed.  My OOT is visible in
>> GRC, and
>> I've added to a new flowgraph.
>>
>> My OOT is in category HPSDR  and the module is hermesNB (of several).
>>
>> When I try to execute a simple flowgraph in GRC with this OOT I get the
>> following error:
>>
>> Traceback (most recent call last):
>>   File "/home/tom/Desktop/Test_AM.py", line 38, in 
>> import hpsdr
>>   File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in
>> 
>> from .hpsdr_python import *
>> ImportError: generic_type: type "hermesNB" referenced unknown base type
>> "gr::block"
>>
>> Do I need to add code somewhere to import gr::block   ??
>>
>> Is there an issue with capitalization of  hpsdr  vs. category name of
>> HPSDR  ??
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>

gr 3.9 OOT execution error: unknown base type gr::block

[Tom McDermott]

I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work fine.
The ported code is compiled and make installed.  My OOT is visible in GRC,
and
I've added to a new flowgraph.

My OOT is in category HPSDR  and the module is hermesNB (of several).

When I try to execute a simple flowgraph in GRC with this OOT I get the
following error:

Traceback (most recent call last):
  File "/home/tom/Desktop/Test_AM.py", line 38, in 
import hpsdr
  File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in

from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base type
"gr::block"

Do I need to add code somewhere to import gr::block   ??

Is there an issue with capitalization of  hpsdr  vs. category name of
HPSDR  ??

-- Tom, N5EG

Re: 3.9 -->3.8 downgrade - a few GRC keyboard keys don't work correctly.

[Tom McDermott]

Thanks Josh, you are a gentleman and a scholar.
That was exactly the problem.

-- Tom, N5EG





On Wed, Apr 21, 2021 at 9:26 AM Josh Morman  wrote:

> Is it possible that the "Hide Disabled Blocks" option is enabled in GRC?
> This would make disabling appear to delete the block.
>
> Josh
>
> On Wed, Apr 21, 2021 at 12:16 PM Tom McDermott  wrote:
>
>> On Ubuntu 20.04, I downgraded a gnuradio 3.9 installation to gnuradio 3.8.
>> Using sudo apt remove.
>>
>> I had to manually delete the ~/.cache/grc_gnuradio/cache.json file to
>> remove some
>> cached block parameters left over from 3.9 that were different from 3.8
>>
>> However even after that I have a few keystrokes in 3.8 that used to work
>> but now
>> do not.  Particularly trying to Disable a selected block now deleted that
>> block rather
>> than deselecting it - whether the disable command is invoked typing the
>> keyboard D character
>> or the mouse on the context-menu.
>>
>> Is there perhaps some other cached file or config file left over from the
>> 3.9 installation
>> that is changing the nominal 3.8 GRC keyboard functions?
>>
>> -- Tom, N5EG
>>
>>
>>

3.9 -->3.8 downgrade - a few GRC keyboard keys don't work correctly.

[Tom McDermott]

On Ubuntu 20.04, I downgraded a gnuradio 3.9 installation to gnuradio 3.8.
Using sudo apt remove.

I had to manually delete the ~/.cache/grc_gnuradio/cache.json file to
remove some
cached block parameters left over from 3.9 that were different from 3.8

However even after that I have a few keystrokes in 3.8 that used to work
but now
do not.  Particularly trying to Disable a selected block now deleted that
block rather
than deselecting it - whether the disable command is invoked typing the
keyboard D character
or the mouse on the context-menu.

Is there perhaps some other cached file or config file left over from the
3.9 installation
that is changing the nominal 3.8 GRC keyboard functions?

-- Tom, N5EG

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

[Tom McDermott]

I solved the bind python exception as follows:

1. The bind command cannot be used with a blank argument, or (I think) with
multiple arguments.

Running the command this way:
$gr_modtool bind
GNU Radio module name identified: test01
Which blocks do you want to parse? (Regex):

there does not appear to be any answer that works when the command is
invoked this way. All
attempts throw the python exception. They also leave cruft in the
.python/bindings directory.

2. Instead:
 A) empty out the  ./python/bindings directory
 B) then invoke the bind command using one and only one block name with the
full command:

$gr_modtool bind the_one_block_name

This worked running through my list of blocks.

-- Tom, N5EG







On Sat, Apr 10, 2021 at 11:24 AM 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  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
>>&g

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

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

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

[Tom McDermott]

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 bind
>>>>  It prompts for the block name. I used the base module name without any
>>>> suffixes:
>>>>
>>>> hermesNB
>>>>
>>>> (also tried  hermesNB.h, hermesNB_impl.cc, hermesWB, hermewWB.h,
>>>> hermesWB_impl.cc)
>>>>
>>>> I always get the following error message:
>>>>
>>>>
>>>> tom@tom-Standard-PC-Q35-ICH9-2009:~/gr-hpsdr_3.8/gr-hpsdr$ gr_modtool
>>>> bind
>>>> GNU Radio module

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

[Tom McDermott]

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 bind
>>  It prompts for the block name. I used the base module name without any
>> suffixes:
>>
>> hermesNB
>>
>> (also tried  hermesNB.h, hermesNB_impl.cc, hermesWB, hermewWB.h,
>> hermesWB_impl.cc)
>>
>> I always get the following error message:
>>
>>
>> tom@tom-Standard-PC-Q35-ICH9-2009:~/gr-hpsdr_3.8/gr-hpsdr$ gr_modtool
>> bind
>> GNU Radio module name identified: hpsdr
>> Which blocks do you want to parse? (Regex): hermesNB
>> /usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning:
>> the imp module is deprecated in favour of importlib; see the module's
>> documentation for alternative uses
>>   import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
>> Traceback (most recent call last):
>>   File "/usr/bin/gr_modtool", line 18, in 
>> cli()
>>   File "/usr/lib/python3/dist-packages/click/core.py", line 764, in
>> __call__
>> return self.main(*args, **kwargs)
>>   File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
>> rv = self.invoke(ctx)
>>   File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in
>> invoke
>> return _process_result(sub_ctx.command.invoke(sub_ctx))
>>   File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
>> return ctx.invoke(self.callback, **ctx.params)
>>   File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
>> return callback(*args, **kwargs)
>>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py",
>> line 133, in wrapper
>> return func(*args, **kwargs)
>>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/bind.py",
>> line 46, in cli
>> run(self)
>>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py",
>> line 152, in run
>> module.run()
>>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/bind.py",
>> line 61, in run
>> file_to_process = os.path.join(self.dir, self.info['includedir'],
>> self.info['blockname'] + '.h')
>> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
>>
>> Thus am stuck at this time.Is there a new or revised gr_modtool ?
>>
>> -- Tom, N5EG
>>
>>
>>
>>

problem porting OOT to gr_3.9 : gr_modtool bind error

[Tom McDermott]

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 bind
 It prompts for the block name. I used the base module name without any
suffixes:

hermesNB

(also tried  hermesNB.h, hermesNB_impl.cc, hermesWB, hermewWB.h,
hermesWB_impl.cc)

I always get the following error message:


tom@tom-Standard-PC-Q35-ICH9-2009:~/gr-hpsdr_3.8/gr-hpsdr$ gr_modtool bind
GNU Radio module name identified: hpsdr
Which blocks do you want to parse? (Regex): hermesNB
/usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning: the
imp module is deprecated in favour of importlib; see the module's
documentation for alternative uses
  import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
Traceback (most recent call last):
  File "/usr/bin/gr_modtool", line 18, in 
cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
133, in wrapper
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/bind.py", line
46, in cli
run(self)
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
152, in run
module.run()
  File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/bind.py", line
61, in run
file_to_process = os.path.join(self.dir, self.info['includedir'],
self.info['blockname'] + '.h')
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Thus am stuck at this time.Is there a new or revised gr_modtool ?

-- Tom, N5EG

Re: release repository changed names, unwanted forced update to 3.9.0, broke all flowgraphs

[Tom McDermott]

Hi Josh, Nick.My panic level has declined now that I was able to get
3.8.2 back up
and running in time for tomorrow !   I am grateful to the very talented
folks that provide
good advice (and solutions) here on the list and on the project.

-- Tom, N5EG




On Fri, Feb 19, 2021 at 3:45 PM Josh  wrote:

> Tom,
>
> This was an unfortunate consequence of updating the main gnuradio-releases
> PPA to 3.9 (since it is the latest release).  Clearly we need a strategy
> here and to learn how PPAs are handled on other projects.
>
> There is currently a gnuradio-releases-3.8 repository, so if you are
> planning to stay with 3.8 (currently 3.8.2.0) and the supported 3.8 OOTs,
> this would be the PPA to switch over to.
> see:
> https://wiki.gnuradio.org/index.php/InstallingGR#Ubuntu_PPA_Installation
>
> I apologize for the lack of communication in this shift.  One of our goals
> going forward is to make installation of GNU Radio easier and more
> straightforward, and the Ubuntu PPA has been one of our main installation
> channels.  Ideally .deb packages will be built as part of the CI in the
> future as well to keep master builds up to date as well.  If anyone has
> insight or experience with doing this in an automated way, please reach out.
> Nick - thank you for the recommendation to create the version specific
> metapackage.  Would this be preferable to a separate PPA?  The separate PPA
> was done out of convenience more than anything.
>
> In the main Ubuntu repository, only the pre 3.8 release candidate made it
> there in time, so without a PPA specified, that what gets installed from
> apt-get.
>
> Josh
>
>
>
>
>
>
> On Fri, Feb 19, 2021 at 1:35 PM Nick Foster  wrote:
>
>> I went into this assuming it would be easy to downgrade to 3.8, and
>> discovered it was not. All of the individual 3.8.[1,2] packages are in
>> there labeled with their version in the name, but the main 'gnuradio'
>> package installs 3.9.
>>
>> Maybe it's a good opportunity to create a gnuradio-3.8 metapackage in the
>> PPA? If we're going to be providing long-term support for 3.8, that should
>> probably include supporting its installation and update as well.
>>
>> That said, you should be able to specifically install 3.8 and prevent it
>> from updating by doing:
>>
>> $ apt-cache policy gnuradio
>> gnuradio:
>>   Installed: (none)
>>   Candidate: 3.9.0.0-0~gnuradio~focal-1
>>   Version table:
>>  3.9.0.0-0~gnuradio~focal-1 500
>> 500 http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu
>> focal/main amd64 Packages
>>  3.8.1.0~rc1-2build2 500
>> 500 http://us.archive.ubuntu.com/ubuntu focal/universe amd64
>> Packages
>> 100 /var/lib/dpkg/status
>> $ sudo apt remove gnuradio
>> $ sudo apt install gnuradio=3.8.1.0~rc1-2build2
>>
>> I don't know why 3.8.2 packages exist if the other installation candidate
>> for the main package is only 3.8.1. Ideally we would have a 3.8 package
>> which would receive updates from the maint-3.8 branch via PPA.
>>
>> Nick
>>
>> On Fri, Feb 19, 2021 at 7:48 AM Tom McDermott  wrote:
>>
>>> In trying to update all software in Ubuntu 20.04 using the GUI updater
>>> tool, the updater failed due to
>>> unable to access some repository.   sudo apt update identified the
>>> gnuradio PPA focal changing the
>>> name of the release from something like gnuradio releasesto
>>> gnuradio - releases
>>>
>>> I accepted the update and then continued the upgrade.
>>>
>>> This update downloaded and replaced gnuradio 3.8 with gnuradio 3.9
>>> Now all of my flowgraphs
>>> fail due to numerous errors, some of them are complaining filter
>>> parameter name errors, etc.
>>>
>>> Is there some easy way to revert this change without having to rip all
>>> of gnuradio out, find the 3.8
>>> repository, and start all over again?   If not, what did the 3.8
>>> repository change its name to?
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>

re: reversion to 3.8.2 fails [solved]

[Tom McDermott]

Thank you Ron   This fixes the issues.   A number of uninstall and purges

did not fix things, but removing that cache fixed it.

The emergency was that I am presenting a 50-minute lecture on gnuradio

and the practice session is tomorrow

-- Tom, N5EG





This is just a guess, but you could try deleting:

~/.cache/grc_gnuradio/cache.json

Ron

On 2/19/21 07:16, Tom McDermott wrote:

I removed gnuradio (3.9), changed the PPA to point to
gnuradio-release-3.8, updated, and installed.

Gnuradio got replaced with 3.8.2.However all flowgraphs are
still broken, initial problems areh the number of parameters being wrong
on lots of blocks.  For example:

Traceback (most recent call last):
  File "/home/tom/Desktop/top_block.py", line 285, in 
main()
  File "/home/tom/Desktop/top_block.py", line 261, in main
tb = top_block_cls()
  File "/home/tom/Desktop/top_block.py", line 131, in __init__

self._RxF0_win = RangeWidget(self._RxF0_range, self.set_RxF0, 'RxF0',
"counter_slider", float, QtCore.Qt.Horizontal) TypeError: __init__() takes
from 5 to 6 positional arguments but 7 were given

reversion to 3.8.2 fails

[Tom McDermott]

I removed gnuradio (3.9), changed the PPA to point to
gnuradio-release-3.8, updated, and installed.

Gnuradio got replaced with 3.8.2.However all flowgraphs are
still broken, initial problems areh the number of parameters being wrong
on lots of blocks.  For example:

Traceback (most recent call last):
  File "/home/tom/Desktop/top_block.py", line 285, in 
main()
  File "/home/tom/Desktop/top_block.py", line 261, in main
tb = top_block_cls()
  File "/home/tom/Desktop/top_block.py", line 131, in __init__
self._RxF0_win = RangeWidget(self._RxF0_range, self.set_RxF0, 'RxF0',
"counter_slider", float, QtCore.Qt.Horizontal)
TypeError: __init__() takes from 5 to 6 positional arguments but 7 were
given

release repository changed names, unwanted forced update to 3.9.0, broke all flowgraphs

[Tom McDermott]

In trying to update all software in Ubuntu 20.04 using the GUI updater
tool, the updater failed due to
unable to access some repository.   sudo apt update identified the gnuradio
PPA focal changing the
name of the release from something like gnuradio releasesto  gnuradio -
releases

I accepted the update and then continued the upgrade.

This update downloaded and replaced gnuradio 3.8 with gnuradio 3.9Now
all of my flowgraphs
fail due to numerous errors, some of them are complaining filter parameter
name errors, etc.

Is there some easy way to revert this change without having to rip all of
gnuradio out, find the 3.8
repository, and start all over again?   If not, what did the 3.8 repository
change its name to?

-- Tom, N5EG

re: memory errors in 3.8.2

[Tom McDermott]

OK, have tracked it down thanks to help from the list.

> Christophe Seguinot writes:

 >> deleting all contents of ./build, then going through cmake, make, make
install, and ldconfig.

> did you sudo make uninstall before removing the build folder (if not they
may be some remaining libgnuradio 3.8.1 librairies)

I did not sudo make uninstall before rebuilding the new version.

/usr/local/lib/x86_64-linux-gnu contained the .so for my OOT, but the
symlink pointed to the old .so, not the new one that was generated.

It appears in 3.8 that OOT shared library .so symlink does not update to
the newest installed version, but leaves it pointing to the older version.
My recollection is that this is different behavior than gnuradio 3.7.x

I went in and manually deleted all the shared libraries for my OOT
in/usr/local/lib/x86_64-linux-gnu
and then re-did sudo make install.   That created the correct symlink to
the new version, and the memory error problem seems to be gone.

-- Tom, N5EG

Re: memory errors in 3.8.2

[Tom McDermott]

Hi Marcus - thanks for the reply.   Previously I had rebuilt my OOT by
deleting all contents of ./build, then going through cmake, make, make
install, and ldconfig.

cmake reported:
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.2")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found
suitable exact version "3.8.2")

and:
usr/lib/x86_64-linux-gnu$ ls -la libpython*
lrwxrwxrwx 1 root root  55 Jul 16 07:00 libpython3.8.a ->
../python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.a
lrwxrwxrwx 1 root root  17 Jul 16 07:00 libpython3.8.so ->
libpython3.8.so.1
lrwxrwxrwx 1 root root  19 Jul 16 07:00 libpython3.8.so.1 ->
libpython3.8.so.1.0
-rw-r--r-- 1 root root 5416192 Jul 16 07:00 libpython3.8.so.1.0

So I think that the tools would have linked against 3.8.2, but I do not
know how to view the
exact linker commands when using the cmake and make tools.

-- Tom, N5EG


On Mon, Sep 7, 2020 at 4:37 AM Marcus Müller  wrote:

> Hi Tom,
>
> just to verify: You did recompile your module against 3.8.2.0 and not
> accidentally linked it against a gnuradio-something.so of 3.8.1.0 that
> lingered on your system? I ask because these things really happen often.
>
> Best regards,
> Marcus
>
> On 06/09/2020 23.48, Tom McDermott wrote:
> > My Ubuntu 20.04 updated automatically to 3.8.2.
> >
> > SInce the update I have been getting memory error messages in the
> > gnuradio-companion terminal window.
> > These errors did not occur in 3.8.1.  The error is not consistent,
> > always get one of the following three error messages:
> >
> > double free or corruption (!prev)
> >
> > malloc_consolidate(): invalid chunk size
> > Aborted (core dumped)
> >
> > corrupted size vs. prev_size while consolidating
> >
> > Have commented out all instances of delete [] in my destructors, but no
> > change to the errors. No instances of free() in my code.
> >
> > The errors occur after stopping the flowgraph from gnuradio-companion.
> > I was able to catch the "corrupted size vs. prev_size while
> > consolidating"   error using gdb  (OOT built with
> > -DCMAKE_BUYILD_TYPE=Debug).
> >
> > Thread 1 "python3" received signal SIGINT, Interrupt.
> > 0x77ed396f in __GI___poll (fds=0x22c9990, nfds=4, timeout=14712)
> >  at ../sysdeps/unix/sysv/linux/poll.c:29
> > 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
> > (gdb) bt
> > #0  0x77ed396f in __GI___poll (fds=0x22c9990, nfds=4,
> timeout=14712)
> >  at ../sysdeps/unix/sysv/linux/poll.c:29
> > #1  0x739cc1ae in ?? () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #2  0x739cc2e3 in g_main_context_iteration ()
> > from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #3  0x73770fd5 in g_application_run ()
> > from /lib/x86_64-linux-gnu/libgio-2.0.so.0
> > #4  0x7524fff5 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
> > #5  0x7524f40a in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
> > #6  0x73ae50a5 in ?? ()
> > from
> > /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
> > <http://gi.cpython-38-x86_64-linux-gnu.so>
> > #7  0x73adc25c in ?? ()
> > from
> > /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
> > <http://gi.cpython-38-x86_64-linux-gnu.so>
> > #8  0x005f118e in PyObject_Call ()
> > #9  0x00568e1f in _PyEval_EvalFrameDefault ()
> > #10 0x00565972 in _PyEval_EvalCodeWithName ()
> > #11 0x005f1d85 in _PyFunction_Vectorcall ()
> > #12 0x005677c7 in _PyEval_EvalFrameDefault ()
> > #13 0x005f1b8b in _PyFunction_Vectorcall ()
> > #14 0x0056769f in _PyEval_EvalFrameDefault ()
> > #15 0x005f1b8b in _PyFunction_Vectorcall ()
> > #16 0x0056769f in _PyEval_EvalFrameDefault ()
> > #17 0x00565972 in _PyEval_EvalCodeWithName ()
> > --Type  for more, q to quit, c to continue without paging--
> > #18 0x00686053 in PyEval_EvalCode ()
> > #19 0x006753d1 in ?? ()
> > #20 0x0067544f in ?? ()
> > #21 0x00675507 in PyRun_FileExFlags ()
> > #22 0x0067758a in PyRun_SimpleFileExFlags ()
> > #23 0x006ae99e in Py_RunMain ()
> > #24 0x006aed29 in Py_BytesMain ()
> > #25 0x77de50b3 in __libc_start_main (main=0x4ebd20 ,
> argc=2,
> >  argv=0x7fffe028, init=, fini=,
> >  rtld_fini=, stack_end=0x7fffe018) at
> > ../csu/libc-start.c:308
> > #26 0x005f62ee in _start ()
> >
> > -- Tom, N5EG
> >
>

memory errors in 3.8.2

[Tom McDermott]

My Ubuntu 20.04 updated automatically to 3.8.2.

SInce the update I have been getting memory error messages in the
gnuradio-companion terminal window.
These errors did not occur in 3.8.1.  The error is not consistent, always
get one of the following three error messages:

double free or corruption (!prev)

malloc_consolidate(): invalid chunk size
Aborted (core dumped)

corrupted size vs. prev_size while consolidating

Have commented out all instances of delete [] in my destructors, but no
change to the errors. No instances of free() in my code.

The errors occur after stopping the flowgraph from gnuradio-companion.
I was able to catch the "corrupted size vs. prev_size while consolidating"
  error using gdb  (OOT built with -DCMAKE_BUYILD_TYPE=Debug).

Thread 1 "python3" received signal SIGINT, Interrupt.
0x77ed396f in __GI___poll (fds=0x22c9990, nfds=4, timeout=14712)
at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  0x77ed396f in __GI___poll (fds=0x22c9990, nfds=4, timeout=14712)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x739cc1ae in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x739cc2e3 in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x73770fd5 in g_application_run ()
   from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x7524fff5 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#5  0x7524f40a in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#6  0x73ae50a5 in ?? ()
   from /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#7  0x73adc25c in ?? ()
   from /usr/lib/python3/dist-packages/gi/_gi.cpython-38-x86_64-linux-gnu.so
#8  0x005f118e in PyObject_Call ()
#9  0x00568e1f in _PyEval_EvalFrameDefault ()
#10 0x00565972 in _PyEval_EvalCodeWithName ()
#11 0x005f1d85 in _PyFunction_Vectorcall ()
#12 0x005677c7 in _PyEval_EvalFrameDefault ()
#13 0x005f1b8b in _PyFunction_Vectorcall ()
#14 0x0056769f in _PyEval_EvalFrameDefault ()
#15 0x005f1b8b in _PyFunction_Vectorcall ()
#16 0x0056769f in _PyEval_EvalFrameDefault ()
#17 0x00565972 in _PyEval_EvalCodeWithName ()
--Type  for more, q to quit, c to continue without paging--
#18 0x00686053 in PyEval_EvalCode ()
#19 0x006753d1 in ?? ()
#20 0x0067544f in ?? ()
#21 0x00675507 in PyRun_FileExFlags ()
#22 0x0067758a in PyRun_SimpleFileExFlags ()
#23 0x006ae99e in Py_RunMain ()
#24 0x006aed29 in Py_BytesMain ()
#25 0x77de50b3 in __libc_start_main (main=0x4ebd20 , argc=2,
argv=0x7fffe028, init=, fini=,
rtld_fini=, stack_end=0x7fffe018) at
../csu/libc-start.c:308
#26 0x005f62ee in _start ()

-- Tom, N5EG

how to run gdb with gnuradio 3.8 ?

[Tom McDermott]

I am trying to debug an OOT in gnuradio 3.8 using gdb.  It's a problem with
double free()
that seems to have popped up with 3.8.2

I rebuilt my OOT with debug symbols.  WIthout gdb, it all runs, but of
course tells me about the double free() when it shuts down.

1. I've altered the top_block.py to stop and wait after printing the
process id before continuing,
then enter to continue.  This starts up the flowgraph GUI.

2. In a different terminal window:
$ sudo gdb -p the_process_id
This makes the gui disappear, and   'System Problem Detected' window
appears asking
if I want to report the problem.

I still have the gdb window, but because I was not able to shut down my
GUI, the
backtrace does not let me look at the shutdown error I am getting.

-- Tom, N5EG

re: gr-modtool does not seem to work in gnuradio 3.8.1 package in ubuntu 20.04

[Tom McDermott]

>Message: 3
>Date: Tue, 28 Jul 2020 16:07:06 +0200
>From: Martin 
>To: discuss-gnuradio@gnu.org
>Subject: gr-modtool does not seem to work in gnuradio 3.8.1 package in
>ubuntu 20.04
>Message-ID: <2df7bef0-8270-750f-7bb4-73a112914...@olifantasia.com>
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>Hi,
>I am trying to get my out of tree module to build and work on ubuntu
>20.04 with the default gnuradio package gnuradio 3.8.1.0-rc1-2build2
>
>
>When I use gr_modtool to create an out of tree module with an empty
>source block then cmake gives an error.
>
>CMake Error at lib/CMakeLists.txt:85:
>   Parse error.  Expected a command name, got unquoted argument with text
>   "${CMAKE_CURRENT_SOURCE_DIR}/qa_testsource.cc".

I've had the same problem.   gr_modtool is generating broken cmake for .cc
qa tests.
It was necessary to strip out all cc qa tests and files for an OOT project
I ported to 3.8 to get it to build.
By looking at the cmake code, it's not clear what it should have generated,
someone skilled
in cmake would probably quickly know what was meant.

The .py qa generated cmake file is correct and builds fine, so the error is
likely in
a small area.

-- Tom, N5EG

gr-hpsdr available for gnuradio 3.8

[Tom McDermott]

The OOT module for HPSDR (Hermes, Metis, Red Pitaya) is now available for
gnuradio 3.8.
Basically no code changes other than to port to 3.8

branches:
gr_3.7
gr_3.8

https://github.com/Tom-McDermott/gr-hpsdr

-- Tom, N5EG

Re: port OOT to gr3.8: python can't find my module

[Tom McDermott]

HI Kyeong Su,  thank you for the suggestion !I also received the same
suggestion off-list.
That solves the problem.   My 6-year old Linux textbook describes the
behavior of
which file controls which environment differently than how Ubuntu 20.04
works.

-- Tom, N5EG


On Fri, May 1, 2020 at 11:06 PM Kyeong Su Shin  wrote:

> Hello Tom:
>
> Maybe you can try editing ~/.profile instead (just put the same export
> command that you putted on ~/.bashrc) and then reboot your system (I am
> assuming a Debian-like distro).
>
> Regards,
> Kyeong Su Shin
> ----------
> *보낸 사람:* Tom McDermott  대신 Discuss-gnuradio
> 
> *보낸 날짜:* 2020년 5월 2일 토요일 오전 12:06
> *받는 사람:* Discuss Gnuradio 
> *제목:* Re: port OOT to gr3.8: python can't find my module
>
> Thanks, Barry.   I edited ~/.bashrc
>
>   That allows it to be found when executing from a terminal
> (./flowgraphname.py)
> but not from gnuradio-companion.
>
> -- Tom, N5EG
>
>
> On Fri, May 1, 2020 at 7:49 AM Barry Duggan  wrote:
>
> Hi Tom,
>
> Try following the procedures in
> https://wiki.gnuradio.org/index.php/ModuleNotFoundError
>
> Note that you can have multiple paths separated by a colon (:).
>
> 73,
> --
> Barry Duggan KV4FV
>
> On Fri, 1 May 2020 07:26:11 -0700, Tom McDermott wrote:
>
> Testing out a port of an OOT into gr3.8.hpsdr
>
> I've successfully built/installed the ported OOT into gr3.8, and
> gnuradio-companion finds it and instantiates into a flowgraph.
> It's in the group  hpsdr
>
> However when executing the flowgraph, python throws an error that it
> cannot import hpsdr.   The OOT install put it into:
>/usr/local/lib/python3/dist-packages/hpsdr
>
> but apparently gnuradio-companion is not looking there.
>
> How do I tell gnuradio-companion where to look for my OOT module?
>
> -- Tom, N5EG
>
>

Re: port OOT to gr3.8: python can't find my module

[Tom McDermott]

Thanks, Barry.   I edited ~/.bashrc

  That allows it to be found when executing from a terminal
(./flowgraphname.py)
but not from gnuradio-companion.

-- Tom, N5EG


On Fri, May 1, 2020 at 7:49 AM Barry Duggan  wrote:

> Hi Tom,
>
> Try following the procedures in
> https://wiki.gnuradio.org/index.php/ModuleNotFoundError
>
> Note that you can have multiple paths separated by a colon (:).
>
> 73,
> --
> Barry Duggan KV4FV
>
> On Fri, 1 May 2020 07:26:11 -0700, Tom McDermott wrote:
>
> Testing out a port of an OOT into gr3.8.hpsdr
>
> I've successfully built/installed the ported OOT into gr3.8, and
> gnuradio-companion finds it and instantiates into a flowgraph.
> It's in the group  hpsdr
>
> However when executing the flowgraph, python throws an error that it
> cannot import hpsdr.   The OOT install put it into:
>/usr/local/lib/python3/dist-packages/hpsdr
>
> but apparently gnuradio-companion is not looking there.
>
> How do I tell gnuradio-companion where to look for my OOT module?
>
> -- Tom, N5EG
>

port OOT to gr3.8: python can't find my module

[Tom McDermott]

Testing out a port of an OOT into gr3.8.hpsdr

I've successfully built/installed the ported OOT into gr3.8, and
gnuradio-companion finds it and instantiates into a flowgraph.
It's in the group  hpsdr

However when executing the flowgraph, python throws an error that it cannot
import hpsdr.   The OOT install put it into:
  /usr/local/lib/python3/dist-packages/hpsdr

but apparently gnuradio-companion is not looking there.

How do I tell gnuradio-companion where to look for my OOT module?

-- Tom, N5EG

Re: porting OOT to gr3.8 Make failure

[Tom McDermott]

Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
It is suggested by the make failure for the ported OOT module.

Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
and make completed successfully.  Thanks for the suggestion Vasil.
Perhaps it's a dependency that is missing when installing grc on 20.04?

With that, gr-hpsdr installed successfully on gr3.8, and the module
instantiates
in the flowgraph.  Now to start testing to see if it works...

-- Tom, N5EG






On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller  wrote:

> Hi Tom,
>
> nice hearing from you! I didn't know that hpsdr needed orc?
>
> Best regards,
> Marcus
>
> On 29.04.20 22:46, Tom McDermott wrote:
> > I am porting an OOT from 3.7 to 3.8.
> > Ubuntu 20.04.  Gnuradio installed via apt install from the
> > gnuradio-releases PPA.  GR 3.8.1
> >
> > It looks like all the modules are compiling OK, but am getting an error.
> >
> > scanning dependencies of target gnuradio-hpsdr
> > [ 12%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
> > [ 25%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
> > [ 37%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
> > [ 50%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
> > [ 62%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
> > make[2]: *** No rule to make target
> > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>', needed
> > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
> > make[1]: *** [CMakeFiles/Makefile2:248:
> > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
> > make: *** [Makefile:141: all] Error 2
> >
> >
> > Not sure what liborc is.   Is this what's missing, or is it something
> else?
> > liborc-dev is listed as having no installation candidate for 20.04
> >
> > $ apt-cache policy liborc-dev
> > liborc-dev:
> >   Installed: (none)
> >   Candidate: (none)
> >   Version table:
> >
> >
> >
> > -- Tom, N5EG
> >
> >
>

porting OOT to gr3.8 Make failure

[Tom McDermott]

I am porting an OOT from 3.7 to 3.8.
Ubuntu 20.04.  Gnuradio installed via apt install from the
gnuradio-releases PPA.  GR 3.8.1

It looks like all the modules are compiling OK, but am getting an error.

scanning dependencies of target gnuradio-hpsdr
[ 12%] Building CXX object
lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
[ 25%] Building CXX object
lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
[ 37%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
[ 50%] Building CXX object
lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
[ 62%] Building CXX object
lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/liborc-0.4.so',
needed by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:248:
lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
make: *** [Makefile:141: all] Error 2


Not sure what liborc is.   Is this what's missing, or is it something else?
liborc-dev is listed as having no installation candidate for 20.04

$ apt-cache policy liborc-dev
liborc-dev:
  Installed: (none)
  Candidate: (none)
  Version table:



-- Tom, N5EG

gr3.8 gr_modtool lib/CmakeLists.txt error

[Tom McDermott]

Trying to port an OOT module to gr3.8.

I generated a new 3.8 project from scratch using gr_modtool.
Running cmake generates an error, and looking at the last mine of
lib/CmakeLists.txt it appears that the
generator may have incorrectly constructed the final line(s) of the file
where it builds the qa files.

Here's what was auto-generated by the tool:

...snip most...

# If your unit tests require special include paths, add them here
#include_directories()
# List all files that contain Boost.UTF unit tests here
list(APPEND test_hpsdr_sources
)
# Anything we need to link to for the unit tests go here
list(APPEND GR_TEST_TARGET_DEPS gnuradio-hpsdr)

if(NOT test_hpsdr_sources)
MESSAGE(STATUS "No C++ unit tests... skipping")
return()
endif(NOT test_hpsdr_sources)

foreach(qa_file ${test_hpsdr_sources})
GR_ADD_CPP_TEST("hpsdr_${qa_file}"
${CMAKE_CURRENT_SOURCE_DIR}/${qa_file}
)
endforeach(qa_file)
${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesNB.cc
 ${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesWB.cc


Cmake is complaining about the last line not containing a command.  Note
that the last line is also missing
the trailing newline character. I added that, no change to the error.

I resolved temporarily the problem by commenting out the very last line of
the lib/CmakeLists.txt file, but then of course
no tests get generated (but at least then the OOT Cmake completes).

I'm not fluent in Cmake, so is it obvious how to fix?

-- Tom, N5EG

General issue: Pybombs recipe 3.7 vs. 3.8 ??

[Tom McDermott]

I am starting the process to port an OOT over the 3.8 / Python3.
There is an existing pybombs recipe for the 3.7 version, this recipe
references my master branch on GitHub.

Question: how should my git repository be structured so that the 3.7
version or the 3.8 version is pulled correctly when someone installs
the OOT?

If the existing master branch is switched to branch 3.7 then the existing
recipe will become broken.  If a new branch 3.8 is created, how does
the pybombs pull/build know to checkout that instead of master?

I went through something similar to this problem yesterday when installing
gnuradio using pybombs - the recipe apparently pulled the wrong branch
from UHD. Fortunately Vasil helped me do a manual workaround for this.

-- Tom, N5EG

Re: pybombs grc 3.8 install fails Ubuntu 19.10

[Tom McDermott]

Thanks for your continued help !

git branch:
  UHD-3.14
* UHD-3.15.LTS

git status:
On branch UHD-3.15.LTS
Your branch is up to date with 'origin/UHD-3.15.LTS'

There is no uhd/build directory for me to delete.




I created a new VM and started over.  Then issued the
pybombs config -P uhd gitbranch UHD-3.15.LTS
just before issuing for the first time:
pybombs prefix init ~/gr38 -R gnuradio-default

Unfortunately that causes boost to fail to build with compile errors.
(pyconfig.h is missing).

-- Tom, N5EG






On Tue, Dec 10, 2019 at 12:38 PM Vasil Velichkov 
wrote:

> On 10/12/2019 22.18, Tom McDermott wrote:
> > Hi Vasil - thanks for the help.
> >
> > That did not work.  The config and refetch commands worked OK.
> > But then re-running the init command caused said:
> >
> > [WARNING] There is already a prefix in '\home\tom\gr38'
> > Continue using this path? Y/[N]?
> > I replied Y
> > and then have the exact errors as in the first post.
>
> Strange! Provide the full output of
>
> cd /home/tom/gr38/src/uhd
> git branch
> git status
>
> After that you could try removing the uhd's build directory as it's
> probably using something from the previous run and retry the pybombs prefix
> init.
>
>  rm -rvf /home/tom/gr38/src/uhd/build/
>
> Alternatively you could try removing the whole prefix directory
> (/home/tom/gr38/) and start from scratch
>
> Regards,
> Vasil
>

Re: pybombs grc 3.8 install fails Ubuntu 19.10

[Tom McDermott]

Hi Vasil - thanks for the help.

That did not work.  The config and refetch commands worked OK.
But then re-running the init command caused said:

[WARNING] There is already a prefix in '\home\tom\gr38'
Continue using this path? Y/[N]?
I replied Y
and then have the exact errors as in the first post.

If I replied N then it said:
Aborting. A prefix already exists in /home/tom/gr38


-- Tom, N5EG




On Tue, Dec 10, 2019 at 10:57 AM Vasil Velichkov 
wrote:

> Hi Tom,
>
> On 10/12/2019 20.38, Tom McDermott wrote:
> > it clones into UHD (showing all the various tags) then
> > [WARNING] Configuration failed. Re-trying with higher verbosity.
> >  various dependencies that work OK. then,
> >
> > 'import mako' failed
> > 'import requests' failed
> > 'import numpy' failed
> >
> > -- Configuring LibUHD support
> > --Dependency Boost_FOUND = 1
> > --Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
> > --Dependency HAVE_PYTHON_MODULE_MAKO = FALSE
> >
> > which starts the cmake failures...
> >
> > Any advice ?
>
> In the ~/.pybombs/recipes/gr-recipes/uhd.lwr recipe the gitbranch is set
> to UHD-3.14 but this version defaults to python2 and that is the reason for
> the above errors.
>
> Try the following
>
> pybombs config -P uhd gitbranch UHD-3.15.LTS
> pybombs refetch uhd
>
> and then retry the "pybombs prefix init ..." command you have used before.
>
> Regards,
> Vasil
>

pybombs grc 3.8 install fails Ubuntu 19.10

[Tom McDermott]

Trying to get GR 3.8 up and running on a fresh Ubuntu 19.10 VM. With git,
python3-pip installed.
python 2 pip not installed.

(Have to manually type the console output below because cut-and-paste out
of the VM not installed).

It gets to the following state:

[INFO] Phase 1 complete: all binary dependencies installed.
[INFO] Phase 2: Recursively installing source packages to prefix.
[INFO] installing package UHD.

it clones into UHD (showing all the various tags) then
[WARNING] Configuration failed. Re-trying with higher verbosity.
 various dependencies that work OK. then,

'import mako' failed
'import requests' failed
'import numpy' failed

-- Configuring LibUHD support
--Dependency Boost_FOUND = 1
--Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
--Dependency HAVE_PYTHON_MODULE_MAKO = FALSE

which starts the cmake failures...

Any advice ?

-- Tom, N5EG

Re: [Discuss-gnuradio] QT Throw Bad Alloc on flowgraph startup

[Tom McDermott]

Thanks, Marcus.  Of course it will not throw now after about 20+ attempts.
(Does that smell like mis-aligned memory?).

The display is still not showing the data traces until at run time I change
the FFT size.
I will continue playing with it until it gets back into the mode where it
throws all the time, then run gdb.

-- Tom, N5EG




On Fri, Apr 26, 2019 at 9:37 AM Marcus Müller (GNU Radio maintainer) <
mmuel...@gnuradio.org> wrote:

> Hi Tom,
>
> shoot, that sounds like we half-fixed a bug :(
> How proficient are you with GDB? Could you get a backtrace? (maybe
> based on [1]?)
> Thank you!
> Marcus
>
> [1] https://wiki.gnuradio.org/index.php/TutorialsGDB
>
> On Fri, 2019-04-26 at 09:25 -0700, Tom McDermott wrote:
> >
> > I've had this problem intermittently for about a year.  On starting
> > the flowgraph it will terminate
> > with QT Throw : Bad Alloc.   Building different versions from about
> > 3.7.10 ish to 3.7.latest will change
> > whether or not it happens 100% of the time or 30% of the time.
> >
> > Today, I noticed that disabling the QT Frequency sink causes it to
> > not throw, and the flowgraph runs
> > fine.  One input to QT Freq Sink works OK many times, two inputs
> > causes it to throw virtually every
> > time.
> >
> > After some playing around:
> > If I change the initial QT Frequency sink to start with a much
> > smaller FFT size (256), then it does not
> > QT Throw on startup even with two channels.  The original
> > configuration was to start at FFT size of 1024
> > (causing throw).  Setting the block to start with FFT size of 256
> > causes it not to throw.
> >
> > When the flowgraph starts, the QT Frequency sink does not display any
> > signals.  If, while running
> > in GRC, I change the FFT size then suddenly the signal traces start
> > displaying.  Also while running
> > I can then change the FFT size, and it keeps running, and the display
> > shows the effect of changing
> > the resolution.
> >
> > So I think the QT Throw problem has something to do with the starting
> > FFT size, and the non-display
> > seems to fix itself after changing the FFT size all related to QT
> > Frequency Sink.
> >
> > Ubuntu 16.04,  with gnuradio / GRC  3.7.13.5
> >
> > -- Tom, N5EG
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT Throw Bad Alloc on flowgraph startup

[Tom McDermott]

I've had this problem intermittently for about a year.  On starting the
flowgraph it will terminate
with QT Throw : Bad Alloc.   Building different versions from about 3.7.10
ish to 3.7.latest will change
whether or not it happens 100% of the time or 30% of the time.

Today, I noticed that disabling the QT Frequency sink causes it to not
throw, and the flowgraph runs
fine.  One input to QT Freq Sink works OK many times, two inputs causes it
to throw virtually every
time.

After some playing around:
If I change the initial QT Frequency sink to start with a much smaller FFT
size (256), then it does not
QT Throw on startup even with two channels.  The original configuration was
to start at FFT size of 1024
(causing throw).  Setting the block to start with FFT size of 256 causes it
not to throw.

When the flowgraph starts, the QT Frequency sink does not display any
signals.  If, while running
in GRC, I change the FFT size then suddenly the signal traces start
displaying.  Also while running
I can then change the FFT size, and it keeps running, and the display shows
the effect of changing
the resolution.

So I think the QT Throw problem has something to do with the starting FFT
size, and the non-display
seems to fix itself after changing the FFT size all related to QT Frequency
Sink.

Ubuntu 16.04,  with gnuradio / GRC  3.7.13.5

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] hardware impairments: phase noise generator documentation ?

[Tom McDermott]

I am trying to model 1/f phase noise.  There is a phase noise generator
block in gnuradio.  I have been unsuccessful in locating documentation
of this hierarchical block that describes what the two parameters mean.
There is just one line in the hardware impairments section listing that
it exists and take two parameters.

The GRC block shows the two parameters:

* Noise Magnitude (the level of the phase noise in db)
   Magnitude at what frequency?  One Hertz?   Something else?

* alpha:  can't find anything at all describing what this is.

Does this block generate 1/f noise in order to phase noise impair the
signal?
Is there any documentation available?

Thanks for any help folks may be able to provide.

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B205 mini on Windows 10? USB Driver not found

[Tom McDermott]

Thank you !That solved the problem.

Steps needed:

1. Plug the B205 into the computer (the step that decides installs the
driver
uses that the figure out which specific USB driver to select).

2. Run the device manager as administrator

3. Updae the driver, and search... browse...

4. For me it was located at:
C:\Program Files\GNURadio-3.7\share\uhd\images\winusb_driver\
and the set of USB drivers was there.  The Windows installer emunerated the
B205mini
then figured out which driver to choose from the set and installed.

5. After done unplug the B205, then plug it back in, to enumerate USRP.

-- Tom, N5EG



On Tue, Feb 5, 2019 at 9:46 AM Geof Nieboer  wrote:

> UHD drivers are installed with the GnuRadio windows installer.  However,
> the system may not have located them automatically and so it's installed a
> different driver instead that it thinks is compatible.
>
> There are couple UHD utilities in the installation as well... I think they
> are under Gnuradio-3.7/share/UHD perhaps?  (Not near my PC).  I would start
> with those and confirm if the issue is with the UHD drivers themselves, or
> the GnuRadio side.
>
> In there are a couple UHD driver files, and you can go to Control Panel,
> Update Driver, and Manual Choose, then navigate to that directory and pick
> the *.inf file that is closest.   I suspect this is the issue.
>
> Once it's correct the UHD probe utility should find the device, and it
> should show up in Device manager as an "Ettus USRP B205mini" or similar.
>
> Then hopefully GRC will pick that up and work as well.
>
> Geof
>
>
> On Tue, Feb 5, 2019 at 11:18 AM Tom McDermott  wrote:
>
>> I have installed the latest Windows version of Gnuradio from the MSI
>> installer on the gnuradio website.
>> It has UHD source and sink blocks. Gnuradio Companion seems to work fine
>> except for UHD device detection.
>>
>> Have plugged a B205mini into USB3 connector on the computer. The B205
>> lights up and
>> Device Manager indicates that   Westbridge   is present.  The first time
>> plugging it in, Windows
>> went through the new device detected process and claimed it installed the
>> driver.
>>
>> However Windows device manager indicates that there is no driver for
>> Westbridge, thus when I try to
>> run the flowgraph from GRC (with "" for device specifier in the UHD
>> source block which the documentation
>> indicates will search for first found device if the default empty string
>> is used).
>> Flowgraph indicates that no UHD device is found.
>>
>> Trying to do a Windows Device manager driver update for Westbridge says
>> that there is no
>> driver to be found, even when searching.
>>
>> Any suggestions as to where to find the Windows 10 USB drivers for
>> B205mini?
>>
>> -- Tom, N5EG
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] B205 mini on Windows 10? USB Driver not found

[Tom McDermott]

I have installed the latest Windows version of Gnuradio from the MSI
installer on the gnuradio website.
It has UHD source and sink blocks. Gnuradio Companion seems to work fine
except for UHD device detection.

Have plugged a B205mini into USB3 connector on the computer. The B205
lights up and
Device Manager indicates that   Westbridge   is present.  The first time
plugging it in, Windows
went through the new device detected process and claimed it installed the
driver.

However Windows device manager indicates that there is no driver for
Westbridge, thus when I try to
run the flowgraph from GRC (with "" for device specifier in the UHD source
block which the documentation
indicates will search for first found device if the default empty string is
used).
Flowgraph indicates that no UHD device is found.

Trying to do a Windows Device manager driver update for Westbridge says
that there is no
driver to be found, even when searching.

Any suggestions as to where to find the Windows 10 USB drivers for B205mini?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[Tom McDermott]

Thanks, Marcus:re-built with debug symbols.  v3.7.11.1

Attached is the flowgraph causing the problem
 - both the GRC and the resultant top_block.py

It uses an OOT module that talks to OpenHPSDR hardware
over Ethernet - should have one thread running to receive Ethernet frames.
from:https://github.com/Tom-McDermott/gr-hpsdr

Results from gdb:

(gdb) start
Temporary breakpoint 1 at 0x4934c0: file ../Modules/python.c, line 20.
Starting program: /usr/bin/python2 top_block.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=2, argv=0x7fffdfb8)
at ../Modules/python.c:20
20../Modules/python.c: No such file or directory.


(gdb) break std::bad_alloc::what()
Function "std::bad_alloc::what()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (std::bad_alloc::what()) pending.


(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/python2 top_block.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdb463700 (LWP 29362)]
[New Thread 0x7fffdac62700 (LWP 29363)]
[New Thread 0x7fffd6461700 (LWP 29364)]
[New Thread 0x7fffd5c60700 (LWP 29365)]
[New Thread 0x7fffd145f700 (LWP 29366)]
[New Thread 0x7fffcec5e700 (LWP 29367)]
[New Thread 0x7fffce45d700 (LWP 29368)]
[New Thread 0x7fffbbf5b700 (LWP 29369)]
[New Thread 0x7fffbb75a700 (LWP 29370)]
[New Thread 0x7fffbaf59700 (LWP 29371)]
[New Thread 0x7fffabfff700 (LWP 29372)]
[New Thread 0x7fffab7fe700 (LWP 29373)]
[Thread 0x7fffabfff700 (LWP 29372) exited]


   --- this is output from the OOT module, not using docker --
Looking for Metis/Hermes card on interface eth0
Interface[0]:lo  Interface[1]:eth0  Interface[2]:docker0
eth0 IP Address: 192.168.0.2
eth0 MAC Address: 90:b1:1c:6d:00:a7

[New Thread 0x7fffabfff700 (LWP 29375)]

Metis MAC address 00:04:A3:63:F9:8E
Metis IP address 192.168.0.7

gr::log :INFO: audio source - Audio sink arch: alsa
[New Thread 0x7fffa9518700 (LWP 29376)]
[New Thread 0x7fffa8d17700 (LWP 29377)]
[New Thread 0x7fff93ffd700 (LWP 29378)]
[New Thread 0x7fff937fc700 (LWP 29379)]
[New Thread 0x7fff92ffb700 (LWP 29380)]
[New Thread 0x7fff927fa700 (LWP 29381)]
[New Thread 0x7fff91ff9700 (LWP 29382)]
[New Thread 0x7fff917f8700 (LWP 29383)]
[New Thread 0x7fff90ff7700 (LWP 29384)]
[New Thread 0x7fff73fff700 (LWP 29385)]
[New Thread 0x7fff737fe700 (LWP 29386)]
[New Thread 0x7fff72ffd700 (LWP 29387)]
aUQt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Thread 1 "python2" received signal SIGABRT, Aborted.
0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.


(gdb) info threads
  Id   Target Id Frame
* 1Thread 0x77fb9700 (LWP 29361) "python2" 0x77825428 in
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
  2Thread 0x7fffdb463700 (LWP 29362) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3Thread 0x7fffdac62700 (LWP 29363) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  4Thread 0x7fffd6461700 (LWP 29364) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  5Thread 0x7fffd5c60700 (LWP 29365) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  6Thread 0x7fffd145f700 (LWP 29366) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  7Thread 0x7fffcec5e700 (LWP 29367) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  8Thread 0x7fffce45d700 (LWP 29368) "python2"
pthread_cond_wait@@GLIBC_2.3.2
() at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  9Thread 0x7fffbbf5b700 (LWP 29369) "dconf worker" 0x778eb74d
in poll () at ../sysdeps/unix/syscall-template.S:84
  10   Thread 0x7fffbb75a700 (LWP 29370) "gmain" 0x778eb74d in poll
()
at ../sysdeps/unix/syscall-template.S:84
  11   Thread 0x7fffbaf59700 (LWP 29371) "gdbus" 0x778eb74d in poll
()
at ../sysdeps/unix/syscall-template.S:84
  13   Thread 0x7fffab7fe700 (LWP 29373) "pool" syscall ()
at ../sysdeps/unix/

[Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[Tom McDermott]

Ubuntu 16.04.3
GRC 3.7.11.1   (from git)
I was on 3.7.13 couple of weeks ago, completely removed all of gnuradio
and rebuilt trying to debug this.  3.7.11.1 had same problem.


Got back to the problem of several weeks ago.

1. When I try to use a QT GUI sink (such as frequency) the invocation of
the QT Gui Frequency sink in this example throws a memory allocation error.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

2. If I remove the Row, Column GUI hints from just that one QT GUI item,
then it
comes up and runs OK. The other 9 of the QT controls (sliders, choosers,
entry,
ranges) still have their R,C hints.

3. Went back to the GRC file in step 1 that still has the R,C hints in it
and it still fails with the error as shown in step 1.  It did come up and
run
one time showing 'unable to set locale' error, but still ran.  Never seen
that before.


Is there some limitation against using R,C hints on the QT displays (time,
frequency, etc.)?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT throwing std::bad_alloc

[Tom McDermott]

I've had a problem that started about 4 months ago with Qt Gui throwing an
exception on startup.
I recently installed / rebuilt main-3.7 from git, to see if that bypassed
this issue, unfortunately not.
The problem occurs with QT GUI Frequency Sink. Disabling it prevents the
error.

GRC version 3.7.13.2Ubuntu 16.04
$ sysctl kernel.shmmax
kernel.shmmax = 2147483648

$ qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu


Here is the trace:

gr::log :INFO: audio source - Audio sink arch: alsa
[New Thread 0x7fffa36c1700 (LWP 4563)]
[New Thread 0x7fffa2ec0700 (LWP 4564)]
[New Thread 0x7fffa26bf700 (LWP 4565)]
[New Thread 0x7fffa1ebe700 (LWP 4566)]
[New Thread 0x7fffa16bd700 (LWP 4567)]
[New Thread 0x7fffa0ebc700 (LWP 4568)]
[New Thread 0x7fff97ffe700 (LWP 4569)]
[New Thread 0x7fff977fd700 (LWP 4570)]
[New Thread 0x7fff96ffc700 (LWP 4571)]
[New Thread 0x7fff967fb700 (LWP 4572)]
[New Thread 0x7fff95ffa700 (LWP 4573)]
[New Thread 0x7fff957f9700 (LWP 4574)]
aU[Thread 0x7fffaabf0700 (LWP 4559) exited]
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Thread 1 "python" received signal SIGABRT, Aborted.
0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x77825428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7782702a in __GI_abort () at abort.c:89
#2  0x74f1884d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x74f166b6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x74f16701 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x74f16969 in __cxa_rethrow ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x753946ee in QEventLoop::exec (this=this@entry=0x7fffd7e0,
flags=...) at kernel/qeventloop.cpp:218
#7  0x7539a4b9 in QCoreApplication::exec ()
at kernel/qcoreapplication.cpp:1227
#8  0x72d5522c in QApplication::exec () at
kernel/qapplication.cpp:3828
#9  0x73df2aeb in meth_QApplication_exec_ (sipArgs=)
at sipQtGuipart9.cpp:38155
#10 0x004bc3fa in call_function (oparg=,
pp_stack=0x7fffd8f0) at ../Python/ceval.c:4350
#11 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#12 0x004b9ab6 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#13 0x004c16e7 in fast_function (nk=,
na=, n=, pp_stack=0x7fffdaf0,
---Type  to continue, or q  to quit---func=___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] make maint-3.7 fails

[Tom McDermott]

Indeed that was the issue.   git submodule update fixed.
All build and runs now.   Many thanks !

Seems that git submodule is a bit confusing for me.

-- Tom, N5EG



On Fri, Jun 8, 2018 at 9:27 AM, Müller, Marcus (CEL) 
wrote:

> Hi Tom,
>
> got a bit of worries about this one:
>
> On Fri, 2018-06-08 at 09:17 -0700, Tom McDermott wrote:
> > modified:   volk (new commits)
>
> Which basically means that the Volk submodule isn't in the state the
> main module's branch expects it to be, and that's exactly what's going
> wrong there.
>
> Best guess: git `submodule update` should fix this. Afterwards, `git
> status` should not contain any info about the submodule containing any
> changes.
>
> Best regards,
> Marcus
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] make maint-3.7 fails

[Tom McDermott]

Ubuntu 16.04

I've switched to maint-3.7 branch from maint.

$ git checkout maint-3.7
$ git pull --recurse-submodules=ON

$ git status
On branch maint-3.7
Your branch is up-to-date with 'origin/maint-3.7'.
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   volk (new commits)


I then deleted all contents of /build

$ cmake -j8 ..
   successful result, all components enabled, none disabled

$ make ..
   fails with:

... snip ...

[ 65%] Building CXX object
gr-blocks/lib/CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o
[ 65%] Building CXX object
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/interp_fir_filter_ccf_impl.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_common.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_sc_list.cc.o
[ 66%] Building CXX object
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/interp_fir_filter_fcc_impl.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/scl_list.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_encoder_systematic.cc.o
[ 66%] Building CXX object
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_sc_systematic.cc.o
/home/tom/gnuradio/gr-fec/lib/polar_decoder_common.cc: In member function
‘void gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned
char*, int, int, int)’:
/home/tom/gnuradio/gr-fec/lib/polar_decoder_common.cc:128:81: error: too
few arguments to function
 volk_32f_8u_polarbutterfly_32f(llrs, u, block_power(), stage,
u_num, row);


... snip ...

It looks like perhaps volk and polar have conflicting interface somewhere.

Any advice on how to get volk / maint-3.7 to build?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pmt.to_python behaves differently in console and in gnuradio

[Tom McDermott]

Nevermind.Problem was in my code creating the np.array over on the send
side.  Sorry to waste the bandwidth.

-- Tom, N5EG





On Mon, Jan 1, 2018 at 1:23 PM, Tom McDermott  wrote:

>
> Hello, Happy New Year !
>
> I am trying to use message passing in gnuradio maint branch, 3.7.11.1
> (python 2.7 based)
>
> When just bringing up a command line window, starting python 2.7,
> importing gnuradio, numpy and pmt,
> the behavior I get (which agrees with the documentation):
>
> n = np.array([1,2,3,4,5], dtype=uint8)
> p = pmt.to_pmt(n)
> r = pmt.to_python(p)
>
> printing the types of a, p, and r yield the expected...
>
> type(n) -->  
> type(p) --> 
> type(r) -->  
>
>
>
> However when in gnuradio
> create and pass the pmt via the message port,
> I get a string type after converting to python:
>
>
> def handle_rxmsg(self, msg):
> dat = pmt.to_python(msg)  # dat is an np.array[9] of type np.uint8
> print "Type of msg: ", type(msg)
> print "Type of dat: ", type(dat)
>
>
> This prints on the gnuradio console:
>
> Type of msg:  
> Type of dat:  
>
>
> Does anyone know how do I get back a numpy array from pmt while
> running under gnuradio?
>
> Why does this work in a command line console, but not in gnuradio?
>
>
> -- Tom, N5EG
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pmt.to_python behaves differently in console and in gnuradio

[Tom McDermott]

Hello, Happy New Year !

I am trying to use message passing in gnuradio maint branch, 3.7.11.1
(python 2.7 based)

When just bringing up a command line window, starting python 2.7,
importing gnuradio, numpy and pmt,
the behavior I get (which agrees with the documentation):

n = np.array([1,2,3,4,5], dtype=uint8)
p = pmt.to_pmt(n)
r = pmt.to_python(p)

printing the types of a, p, and r yield the expected...

type(n) -->  
type(p) --> 
type(r) -->  



However when in gnuradio
create and pass the pmt via the message port,
I get a string type after converting to python:


def handle_rxmsg(self, msg):
dat = pmt.to_python(msg)  # dat is an np.array[9] of type np.uint8
print "Type of msg: ", type(msg)
print "Type of dat: ", type(dat)


This prints on the gnuradio console:

Type of msg:  
Type of dat:  


Does anyone know how do I get back a numpy array from pmt while
running under gnuradio?

Why does this work in a command line console, but not in gnuradio?


-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-osmocom source segfaults on startup roughly 90 % of the time

[Tom McDermott]

I am using gr-osmocom source module to talk to a soapy remote device.
It works correctly about 10 percent of the time. The other ~90 percent of
the time it segfaults on startup. It might run twice in a row, then it might
take 15 attempts before it starts correctly.

The value of set_if_gain is 20
The device type is  soapy=remote:rtlsdr
Here is a trace of the segfault, it seems to always be the same fault:

(gdb) run first_remote_no_gui.py
Starting program: /usr/bin/python first_remote_no_gui.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.002.000-3-g122bfae1

gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.11.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy soapy redpitaya
[New Thread 0x7fffe57a5700 (LWP 4300)]
[New Thread 0x7fffe4fa4700 (LWP 4301)]

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x7fffea3d47d9 in soapy_source_c::set_if_gain(double, unsigned long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
(gdb) bt
#0  0x7fffea3d47d9 in soapy_source_c::set_if_gain(double, unsigned
long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
#1  0x7fffea35d152 in source_impl::set_if_gain(double, unsigned long) ()
   from /usr/local/lib/libgnuradio-osmosdr-0.1.5git.so.0.0.0
#2  0x7fffea63bfd6 in _wrap_source_sptr_set_if_gain ()
   from /usr/local/lib/python2.7/dist-packages/osmosdr/_osmosdr_swig.so
#3  0x004c468a in call_function (oparg=,
pp_stack=0x7fffd1b0) at ../Python/ceval.c:4350
#4  PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#5  0x004c2765 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#6  0x004ca099 in fast_function (nk=0, na=,
n=, pp_stack=0x7fffd3c0,
func=) at ../Python/ceval.c:4445
#7  call_function (oparg=, pp_stack=0x7fffd3c0)
at ../Python/ceval.c:4370
#8  PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#9  0x004c2765 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#10 0x004de6fe in function_call.lto_priv ()
at ../Objects/funcobject.c:523
#11 0x004b0cb3 in PyObject_Call () at ../Objects/abstract.c:2546
#12 0x004f492e in instancemethod_call.lto_priv ()
at ../Objects/classobject.c:2602
#13 0x004b0cb3 in PyObject_Call () at ../Objects/abstract.c:2546

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-osmocom make failing

[Tom McDermott]

Many thanks for your help Ron.  I did a git checkout of cf954948
That resolved the rtl-sdr compiler error but introduced a blade rf compile
error.
I then re-did the cmake with -DENABLE_BLADERF=OFF and
got a clean make and clean make install.

However now at runtime I get the error:

traceback (most recent call last):
  File "/home/tom/Desktop/GRC Flowgraphs/RTL2832 + DSTAR NOAA
etc/top_block.py", line 31, in 
import osmosdr
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py", line
26, in 
from osmosdr_swig import *
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py",
line 28, in 
_osmosdr_swig = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: libboost_date_time.so.1.54.0: cannot open shared object file:
No such file or directory


I have boost 1.58 installed.  Is boost 1.54 date_time something different
that needs to be in addition to boost 1.58 ?
If so, how would one install just a part of the boost library from a
previous version?

-- Tom






On Thu, Sep 21, 2017 at 12:05 PM, Ron Economos  wrote:

> It's due to a mismatch between gr-osmosdr and the Ubuntu 16.04 rtlsdr
> library. There are a few different solutions to this problem.
>
> 1) If you're not using RTL-SDR dongles, then just purge the rtlsdr
> packages (librtlsdr-dev and librtlsdr0). Then rebuild gr-osmosdr and
> Osmocom RTLSDR should end up in the disabled components during the cmake
> phase.
>
> 2) Checkout a previous version of gr-osmosdr from before this change. git
> checkout cf954948 should work.
>
> 3) The correct solution is to build the rtl-sdr library from source and
> make sure gr-osmosdr links to that.
>
> https://github.com/osmocom/rtl-sdr
>
> Ron
>
>
> On 09/21/2017 11:40 AM, Tom McDermott wrote:
>
> Using Ubuntu 16.04, Have guradio 3.7.12git-231  master branch
> gnuradio runs fine.
>
> The old version of Osmocom no longer runs (after some years), so
> I started rebuild of gr-osmocom from scratch by cloning from
> git.osmocom.org/gr-osmosdr
> my current appliation is to get rtl-sdr running using Osmocom.
>
> Are there  packages I must install to allow gr-osmocom to compile?
>
>
> Running CMAKE succeeds, with some missing packages:
>
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> --   * Python support
> --   * Osmocom IQ Imbalance Correction
> --   * FUNcube Dongle
> --   * IQ File Source & Sink
> --   * Osmocom RTLSDR
> --   * RTLSDR TCP Client
> --   * Ettus USRP Devices
> --   * HackRF & rad1o Badge
> --   * nuand bladeRF
> --   * RFSPACE Receivers
> --   * Red Pitaya SDR
> --
> -- ##
> -- # Gnuradio disabled components
> -- ##
> --   * sysmocom OsmoSDR
> --   * FUNcube Dongle Pro+
> --   * Osmocom MiriSDR
> --   * AIRSPY Receiver
> --   * SoapySDR support
> --   * FreeSRP support
> --
> -- Building for version: v0.1.4-98-gc653754d / 0.1.5git
> -- Using install prefix: /usr/local
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/tom/gr-osmosdr/build
>
>
>
> MAKE then fails:
>
> tom@tom-XPS-8500:~/gr-osmosdr/build$ make
> Scanning dependencies of target gnuradio-osmosdr
> [  2%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/source_impl.cc.o
> [  4%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/sink_impl.cc.o
> [  6%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
> [  8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
> [ 11%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/time_spec.cc.o
> [ 13%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/fcd/fcd_source_c.cc.o
> [ 15%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/file/file_source_c.cc.o
> [ 17%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/file/file_sink_c.cc.o
> [ 20%] Building CXX object lib/CMakeFiles/gnuradio-
> osmosdr.dir/rtl/rtl_source_c.cc.o
> /home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor
> ‘rtl_source_c::rtl_source_c(const string&)’:
> /home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error:
> ‘rtlsdr_set_bias_tee’ was not declared in this scope
>ret = rtlsdr_set_bias_tee(_dev, bias_tee);
>^
> lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe for target
> 'lib/

[Discuss-gnuradio] gr-osmocom make failing

[Tom McDermott]

Using Ubuntu 16.04, Have guradio 3.7.12git-231  master branch
gnuradio runs fine.

The old version of Osmocom no longer runs (after some years), so
I started rebuild of gr-osmocom from scratch by cloning from
git.osmocom.org/gr-osmosdr
my current appliation is to get rtl-sdr running using Osmocom.

Are there  packages I must install to allow gr-osmocom to compile?


Running CMAKE succeeds, with some missing packages:


-- ##
-- # Gnuradio enabled components
-- ##
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * IQ File Source & Sink
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF & rad1o Badge
--   * nuand bladeRF
--   * RFSPACE Receivers
--   * Red Pitaya SDR
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--   * sysmocom OsmoSDR
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * AIRSPY Receiver
--   * SoapySDR support
--   * FreeSRP support
-- 
-- Building for version: v0.1.4-98-gc653754d / 0.1.5git
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tom/gr-osmosdr/build



MAKE then fails:

tom@tom-XPS-8500:~/gr-osmosdr/build$ make
Scanning dependencies of target gnuradio-osmosdr
[  2%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o
[  4%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o
[  6%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
[  8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
[ 11%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/time_spec.cc.o
[ 13%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o
[ 15%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
[ 17%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_sink_c.cc.o
[ 20%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc: In constructor
‘rtl_source_c::rtl_source_c(const string&)’:
/home/tom/gr-osmosdr/lib/rtl/rtl_source_c.cc:224:43: error:
‘rtlsdr_set_bias_tee’ was not declared in this scope
   ret = rtlsdr_set_bias_tee(_dev, bias_tee);
   ^
lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:254: recipe for target
'lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o]
Error 1
CMakeFiles/Makefile2:135: recipe for target
'lib/CMakeFiles/gnuradio-osmosdr.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
tom@tom-XPS-8500:~/gr-osmosdr/build$
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] git fetch failing

[Tom McDermott]

Thanks, Ron.

I repointed origin to github, and reset the branches to origin/,
then it updated just fine. Appears the content on github works fine, and
something fishy with the content on gnuradio.org

-- Tom, N5EG



On Tue, Aug 23, 2016 at 3:52 AM, Ron Economos  wrote:

> This is just a personal preference, but I always use Github instead of
> gnuradio.org. Github saturates my 188 Mbps Internet connection, and a git
> clone from gnuradio only takes a few moments.
>
> git clone --recursive https://github.com/gnuradio/gnuradio.git
>
> Ron
>
>
> On 08/22/2016 06:57 PM, Tom McDermott wrote:
>
>>
>> I've tried to recently update gnuradio, Getting a strange git error when
>> doing a git fetch:
>>
>> $ git fetch -v
>> error: Unable to find 7c17d1cd1daa08fc3b6613f11f553f41ae7b3bd9 under
>> http://gnuradio.org/git/gnuradio.git
>> Cannot obtain needed object 7c17d1cd1daa08fc3b6613f11f553f41ae7b3bd9
>> error: Fetch failed.
>>
>> It's been about 6 weeks since I last updated (master) from the
>> repository. Never an issue previously.
>> Any ideas?
>>
>> -- Tom, N5EG
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] git fetch failing

[Tom McDermott]

I've tried to recently update gnuradio, Getting a strange git error when
doing a git fetch:

$ git fetch -v
error: Unable to find 7c17d1cd1daa08fc3b6613f11f553f41ae7b3bd9 under
http://gnuradio.org/git/gnuradio.git
Cannot obtain needed object 7c17d1cd1daa08fc3b6613f11f553f41ae7b3bd9
error: Fetch failed.

It's been about 6 weeks since I last updated (master) from the repository.
Never an issue previously.
Any ideas?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Make fails

[Tom McDermott]

For the first time in a couple of years of successful monthly or so updates
from git on master,
I've had make fail.  Ubuntu 14.04, 64-bit architecture, using all 8 cores
for make. Volk did an update
on the pull from git tonight.
gnuradio master version a7285ea
volk master version 56c0235

Seems to be in
gr::dtv::dvbt_ofdm_sym_acquisition_impl::peak_detect_process   argument
conversion  calling into volk.

Here is the build output from make where the errors start...

[ 90%] Built target test_atsci
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/glfsr_source_f_impl.cc.o
[ 91%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_demod_reference_signals_impl.cc.o
[ 91%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_demap_impl.cc.o
[ 91%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_bit_inner_deinterleaver_impl.cc.o
[ 91%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_viterbi_decoder_impl.cc.o
[ 91%]
/home/tom/gnuradio/gr-dtv/lib/dvbt/dvbt_ofdm_sym_acquisition_impl.cc: In
member function ‘int
gr::dtv::dvbt_ofdm_sym_acquisition_impl::peak_detect_process(const float*,
int, int*, int*)’:
/home/tom/gnuradio/gr-dtv/lib/dvbt/dvbt_ofdm_sym_acquisition_impl.cc:53:68:
error: cannot convert ‘uint16_t* {aka short unsigned int*}’ to ‘unsigned
int*’ in argument passing
   volk_32f_index_max_16u(&peak_index, &datain[0], datain_length);
^
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/hdlc_deframer_bp_impl.cc.o
[ 91%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_convolutional_deinterleaver_impl.cc.o
make[2]: ***
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_ofdm_sym_acquisition_impl.cc.o]
Error 1
make[2]: *** Waiting for unfinished jobs
[ 91%] [ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/hdlc_framer_pb_impl.cc.o
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/header_payload_demux_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/kurtotic_equalizer_cc_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/lms_dd_equalizer_cc_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/map_bb_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/modulate_vector.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_receiver_cc_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_snr_est.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_snr_est_cc_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/msk_timing_recovery_cc_impl.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_carrier_allocator_cvc_impl.cc.o
[ 91%] [ 91%] [ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_chanest_vcvc_impl.cc.o
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_cyclic_prefixer_impl.cc.o
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_base.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_simpledfe.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_static.cc.o
[ 91%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_acquisition_impl.cc.o
make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_equalizer_vcvc_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_sink_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_insert_preamble_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_mapper_bcv_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_sampler_impl.cc.o
[ 92%] [ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_serializer_vcc_impl.cc.o
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_sync_sc_cfb_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_ofdm.cc.o
[ 92%] [ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_headergenerator_bb_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_headerparser_b_impl.cc.o
Building CXX object
gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_sink_impl.cc.o
[ 92%] Building CXX object
gr-digital/lib/CMakeFi

Re: [Discuss-gnuradio] Compiling Documentation with an OOT

[Tom McDermott]

Hi Richard -

When you say 'propagate through to GRC'  do you mean 'How to display on the
GRC documentation tab in the open block properties window'? (select block,
double-click, or rt-click-properties).

I do that by putting text between:


in the module's XML file (manually pasted text, with some characters not
allowed...).

-- Tom, N5EG


On Mon, Mar 28, 2016 at 5:30 PM, Richard Bell 
wrote:

> Hi all,
>
> I would like to know how I get the comments I add to my public header
> function to propagate through to the GRC Block documentation tab. Is there
> a flag I have to add when I compile the OOT?
>
> Thanks,
> Rich
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Losing sample count integrity / Source(s) slipping ?

[Tom McDermott]

Thanks, Marcus.

Your vector source looks a lot simpler!

Spent more time with it, and may have discovered what's going on.  The
drfiting
is actually sawtooth periodic, and ceases when the samp_rate is a power of
two. This suggests
that there is an NCO type of oscillator behind the source, and there is
excess phase
accumulation when the samp_rate is not a power of two.  That excess
eventually
rolls-over and resets. At higher sample rates it's easier to see.

At high samp_rate (384000) the error in time is almost, but not quite one
time sample.
The error appears to be bounded. For the application being debugged, that
bounding
is important (slipping cycles is bad).

I like Python, but use it infrequntly enough that I forget about it
capabilities until the
need to solve a specific issue arises, then its fast-re-learning time.  My
background
many years ago was in digital IC design, so that is programmed into old
neurons.

-- Tom, N5EG



On Sat, Dec 5, 2015 at 2:48 AM, Marcus Müller 
wrote:

> Hi Tom,
>
> first of all: Nice flowgraph! I especially like this part:
> [image: flowgraph]
> to give you a single 1 every 1000 samples; I'd never come up with this!
> Also, from looking at this, I'd say you're a digital designer; how far am
> I off? [1]
>
> So, to your actual problem: I guess you're right, there's a problem with
> numerical accuracy.
> I made a quick demo flow graph:
> [image: sampler]
> which, in theory, should be output constant 1, but instead shows the slow
> drifting.
> I do think this is in the range of what I'd expect of numerical accuracy,
> but as I don't have the time to test this right now, I'm attaching my test
> flow graph. The right thing to do would be calculating the angular speed of
> the output and see how large it is compared to the angular precision of
> float32 put through cos(.).
>
> Best regards,
> Marcus
>
>
>
>
> [1] My much more signal-theoretic approach would have been this:
> [image: interpolation]
> i.e. interpolating a stream of 1s with a filter that isn't actually doing
> anything, i.e. has "[1]" as taps.
> Or, even shorter:
> [image: Vector source]
> because GRC / python allows us to just specify a vector that we sample.
>
> On 05.12.2015 06:15, Tom McDermott wrote:
>
> After some further investiagation, it appears that this may be a slow,
> long term
> analog drift in the cosine wave source (perhaps due to single precision
> math?). The
> voltage values aren't the same at each point in the waveform - they slowly
> drift
> over many minutes of computer runtime.
>
> -- Tom, N5EG
>
>
>
> On Fri, Dec 4, 2015 at 3:48 PM, Tom McDermott  wrote:
>
>> In working on some waveform sampling tests, have encountered an apparent
>> drift
>> between two gnuradio sources that are run at the same rate.  I've tried
>> to structure
>> the flowgraph so that the QT GUI does not get involved in the exact
>> sample count
>> integrity between two flow graph paths.
>>
>> The attached flowgraph constructs a sampling pulse near the zero-crossing
>> time of
>> the cosine wave, then displays that sampled analog value.  Over time, the
>> cosine
>> source appears to be slipping in time compared to the square wave source.
>> The
>> analog sampling pulse samples the cosine source 'near' the zero crossing.
>> But with
>> increasing run-time of the flow graph, it appears to be drifting off. I'm
>> at a loss to
>> explain this.
>>
>> Attached is the simplest GRC flowgraph that demonstrates the effect.  It
>> needs to
>> run for a few tens of seconds before the analog sampled value starts to
>> grow.
>> The time sample at 6 milliseconds is the sampled analog value.  Even if
>> it's not exactly
>> zero, it should remain relative stable in analog value.
>>
>> Any advice on what I might be doing wrong here?
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Losing sample count integrity / Source(s) slipping ?

[Tom McDermott]

After some further investiagation, it appears that this may be a slow, long
term
analog drift in the cosine wave source (perhaps due to single precision
math?). The
voltage values aren't the same at each point in the waveform - they slowly
drift
over many minutes of computer runtime.

-- Tom, N5EG



On Fri, Dec 4, 2015 at 3:48 PM, Tom McDermott  wrote:

> In working on some waveform sampling tests, have encountered an apparent
> drift
> between two gnuradio sources that are run at the same rate.  I've tried to
> structure
> the flowgraph so that the QT GUI does not get involved in the exact sample
> count
> integrity between two flow graph paths.
>
> The attached flowgraph constructs a sampling pulse near the zero-crossing
> time of
> the cosine wave, then displays that sampled analog value.  Over time, the
> cosine
> source appears to be slipping in time compared to the square wave source.
> The
> analog sampling pulse samples the cosine source 'near' the zero crossing.
> But with
> increasing run-time of the flow graph, it appears to be drifting off. I'm
> at a loss to
> explain this.
>
> Attached is the simplest GRC flowgraph that demonstrates the effect.  It
> needs to
> run for a few tens of seconds before the analog sampled value starts to
> grow.
> The time sample at 6 milliseconds is the sampled analog value.  Even if
> it's not exactly
> zero, it should remain relative stable in analog value.
>
> Any advice on what I might be doing wrong here?
>
> -- Tom, N5EG
>
>
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Losing sample count integrity / Source(s) slipping ?

[Tom McDermott]

In working on some waveform sampling tests, have encountered an apparent
drift
between two gnuradio sources that are run at the same rate.  I've tried to
structure
the flowgraph so that the QT GUI does not get involved in the exact sample
count
integrity between two flow graph paths.

The attached flowgraph constructs a sampling pulse near the zero-crossing
time of
the cosine wave, then displays that sampled analog value.  Over time, the
cosine
source appears to be slipping in time compared to the square wave source.
The
analog sampling pulse samples the cosine source 'near' the zero crossing.
But with
increasing run-time of the flow graph, it appears to be drifting off. I'm
at a loss to
explain this.

Attached is the simplest GRC flowgraph that demonstrates the effect.  It
needs to
run for a few tens of seconds before the analog sampled value starts to
grow.
The time sample at 6 milliseconds is the sampled analog value.  Even if
it's not exactly
zero, it should remain relative stable in analog value.

Any advice on what I might be doing wrong here?

-- Tom, N5EG


timestamptester.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9git - QT GUI Frequency, Time, Waterfall - break with multiple inputs

[Tom McDermott]

Very quick response, Tom.   Confirm that this fixes the issue.

Thanks for all the effort you and your team put into gnuradio. It's been
invaluable
in an ionospheric echosounding project.  From creating a simulator to test
algorithms,
creating the test bench, capturing data, to post-processing the information.

I had a opportunity to present the results at the recent 2015 DCC:
http://www.tapr.org/~n5eg/index_files/Measuring-the-Ionosphere-paper-DCC%202015.pdf

-- Tom, N5EG



On Mon, Nov 2, 2015 at 7:57 AM, Tom Rondeau  wrote:

> On Fri, Oct 30, 2015 at 7:20 PM, Tom McDermott  wrote:
>
>> Created Issue #852
>>
>> -- Tom N5EG
>>
>
>
> Thanks, Tom. Just merged in a fix for this bug.
>
> Tom
>
>
>
>
>> On Fri, Oct 30, 2015 at 4:11 PM, Tom Rondeau  wrote:
>>
>>> On Fri, Oct 30, 2015 at 6:37 PM, Tom McDermott 
>>> wrote:
>>>
>>>>
>>>> Just updated master from git (Oct 30, 2015), 3.7.9git-261-gf8a84eb4
>>>> Three of the QT GUIs now appear broken with more than one input.
>>>> With one input they seem to work fine.
>>>>
>>>> Seleting 2 or more inputs does not display multiple inputs, just one
>>>> input,
>>>> and the GRC compiler gives an python runtime error message:
>>>> RuntimeError: check topology failed on freq_sink_c(1) using
>>>> ninputs=1, noutputs=0
>>>>
>>>> All three seem to have the same error behavior, so possibly something
>>>> common to them  might have changed.
>>>>
>>>> Anyone else encounter this issue?
>>>>
>>>> -- Tom, N5EG
>>>>
>>>
>>> Thanks for the report, Tom. Can you open an issue on our gnuradio.org
>>> Issue Tracker to remind me to get to this later. It has something to do
>>> with the new message passing support we just merged in, but I can't think
>>> of what might be the problem off the top of my head. I must have gotten
>>> some setup logic wrong because the actual work operations are completely
>>> separate.
>>>
>>> Tom
>>>
>>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9git - QT GUI Frequency, Time, Waterfall - break with multiple inputs

[Tom McDermott]

Created Issue #852

-- Tom N5EG


On Fri, Oct 30, 2015 at 4:11 PM, Tom Rondeau  wrote:

> On Fri, Oct 30, 2015 at 6:37 PM, Tom McDermott  wrote:
>
>>
>> Just updated master from git (Oct 30, 2015), 3.7.9git-261-gf8a84eb4
>> Three of the QT GUIs now appear broken with more than one input.
>> With one input they seem to work fine.
>>
>> Seleting 2 or more inputs does not display multiple inputs, just one
>> input,
>> and the GRC compiler gives an python runtime error message:
>> RuntimeError: check topology failed on freq_sink_c(1) using
>> ninputs=1, noutputs=0
>>
>> All three seem to have the same error behavior, so possibly something
>> common to them  might have changed.
>>
>> Anyone else encounter this issue?
>>
>> -- Tom, N5EG
>>
>
> Thanks for the report, Tom. Can you open an issue on our gnuradio.org
> Issue Tracker to remind me to get to this later. It has something to do
> with the new message passing support we just merged in, but I can't think
> of what might be the problem off the top of my head. I must have gotten
> some setup logic wrong because the actual work operations are completely
> separate.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 3.7.9git - QT GUI Frequency, Time, Waterfall - break with multiple inputs

[Tom McDermott]

Just updated master from git (Oct 30, 2015), 3.7.9git-261-gf8a84eb4
Three of the QT GUIs now appear broken with more than one input.
With one input they seem to work fine.

Seleting 2 or more inputs does not display multiple inputs, just one input,
and the GRC compiler gives an python runtime error message:
RuntimeError: check topology failed on freq_sink_c(1) using ninputs=1,
noutputs=0

All three seem to have the same error behavior, so possibly something
common to them  might have changed.

Anyone else encounter this issue?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Recent change in destructor behavior?

[Tom McDermott]

My OOT module prints some statistics upon closing of the flowgraph from GRC.
This is implemented with printf(stderr) in the destructor for my module.

GRC --> IMPL constructed by Make --> constructs one of my objects.

This worked well through all versions of gnuradio until about last week.
Now the printf() never shows in the GRC console after a rebuild of
3.7.9.git,
the version that introduced per-flowgraph QSS support (which appeared
broken as of last weekend).

printf(stderr) prior to the start of flowgraph shutown still works fine.
It's just
the one in the destructor that seems no longer to print.

Is there a recent change that would explain this, or is printf() in a
destructor
bad practice?


-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] flags / xml to supress Add throttle warning ?

[Tom McDermott]

Thanks.   throttle it will be ...  (works fine).

-- Tom, N5EG



On Mon, Aug 24, 2015 at 8:59 PM, Marcus D. Leech  wrote:

> On 08/24/2015 11:26 PM, Tom McDermott wrote:
>
> I've built an OOT for some physical SDR hardware.
> However, when compiling a flowgraph in gnruradio-companion
> it prints a warning message about no audio or rf sink, so please
> insert a throttle.
>
> Since my module actually paces the samples in hardware, I don't
> want a throttle.  How can I supress the warning message?
>
> Looking through some GRC blocks, I've found two tags:
>
> 1
>
> and another is
>
> throttle
>
> Reading the documentation that discusses XML tags in the block,
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Creating-the-XML-Block-Definition
> it doesn't mention these tags, or what they do. Is one of these the
> correct way to suppress the flowgraph compile warning?
>
> -- Tom, N5EG
>
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> I think the newer way is to use throttle
>
> But for backwards compat, you can use 1
>
> It's an indicator to GRC that this block provides a flow-regulated data
> stream.
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] flags / xml to supress Add throttle warning ?

[Tom McDermott]

I've built an OOT for some physical SDR hardware.
However, when compiling a flowgraph in gnruradio-companion
it prints a warning message about no audio or rf sink, so please
insert a throttle.

Since my module actually paces the samples in hardware, I don't
want a throttle.  How can I supress the warning message?

Looking through some GRC blocks, I've found two tags:

1

and another is

throttle

Reading the documentation that discusses XML tags in the block,
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Creating-the-XML-Block-Definition
it doesn't mention these tags, or what they do. Is one of these the
correct way to suppress the flowgraph compile warning?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dx Patrol Setup

[Tom McDermott]

Some applications (e.g. DVB) automatically acquire the RTL at
boot, preventing Gnuradio from opening it.

sudo rmmod dvb_usb_rtl28xxu rtl2832

at the command line, each each boot, or

blacklist the device by creating a somefilename.conf file in /etc/modprobe.d
(may depend on Linux distribution) containing:

  blacklist dvb_usb_rtl28xxu
  blacklist rtl2832
  blacklist rtl2830

-- Tom, N5EG



On Sat, Jun 27, 2015 at 4:12 PM, Marco  wrote:

> Hello.
>
> I have been buying today a DX Patrol SDR board. Works on Android,
> however I'm getting some troubles with GRC.
>
> #rtl_eeprom
> Found 1 device(s):
>   0:  Generic RTL2832U OEM
>
> Using device 0: Generic RTL2832U OEM
> Found Rafael Micro R820T tuner
>
> Current configuration:
> __
> Vendor ID:  0x0bda
> Product ID: 0x2838
> Manufacturer:   Realtek
> Product:RTL2838UHIDIR
> Serial number:  0001
> Serial number enabled:  yes
> IR endpoint enabled:yes
> Remote wakeup enabled:  no
>
>
> GRC console:
>
> Using Volk machine: sse4_2_64_orc
> gr-osmosdr v0.1.4-31-gb3fdf5b8 (0.1.5git) gnuradio 3.7.5
> built-in source types: file fcd rtl rtl_tcp rfspace
> Using device #0 Realtek RTL2838UHIDIR SN: 0001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> Exact sample rate is: 200,052982 Hz
> [R82XX] PLL not locked!
> INFO: Audio sink arch: alsa
> len(audio_taps) = 2409
>
> A Terratec board with an Elonic s E400 tuner is working without any
> major problem at the test frequency (98.6 M).
>
> May I ask for help?
>
> Tnx
>
>
> Marco
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE Access (free) article on 60 GHz T/R converter for USRP.

[Tom McDermott]

An article has been published in IEEE Access (free, open access IEEE
publication) on a 60 GHz front-end for USRP
N2000/N210. There's a video on the abstract page, and a link to the pdf of
the article. the video demonstrates
2x2 MIMO using linear polarization:

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7072470

The authors state they have released the hardware T/R and controlling
software as open source.  However I've not
been able to yet locate that file:

open_source_60GHz.tar.gz

which is said to be located in a supplemental file released with the
article.

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] HermesNB with Pybombs

[Tom McDermott]

Hi Greg - there is no Pybombs recipe for gr-hpsdr. I do not have Pybombs
installed, so can't test a recipe.

My development system pushes to github, so it's always up to date and the
most accurate mirror. I endeavor to keep
TAPR SVN accurate, but it is manually copied from github...

I recommend getting gr-hpsdr from github which has the latest, and doing
the source build.

https://github.com/Tom-McDermott/gr-hpsdr

-- Tom, N5EG


On Mon, May 4, 2015 at 6:58 PM, Gregory W. Ratcliff  wrote:

> Tom,
>
> Heard your talk on this work.   Went digging around  in the new Pybombs
> list but didn't notice anything that looked HPSDR-like.
>
> Before I go to TAPR subversion could you give us a pointer to the latest
> version for the
> Everyone wants to brag about their progress before Dayton weekend.
>
>
> Greg
> nz8r
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Tom McDermott]

Thanks, Tom.

It works.

After checking out maint, I can checkout master then,
git submodule init volk
and now all 3 branches (next, master, maint) checkout correctly.

My issue was being unfamiliar with git submodules.

I'll wait for 3.7.7 before further testing - so many new cool features to
play with!

-- Tom, N5EG


On Sun, Apr 5, 2015 at 10:06 AM, Tom Rondeau  wrote:

> On Sun, Apr 5, 2015 at 11:51 AM, Tom McDermott  wrote:
>
>> When I clone from the gnuradio repository:
>>
>> *git clone* --recursive http://git.*gnuradio*.org/git/*gnuradio*.git
>>
>> The clone succeeds. It is on the master branch.  I can checkout next, and
>> switch back and forth
>> between next and master. However when I attempt to checkout maint, git
>> says the checkout is aborted
>> because the untracked working tree (everything in volk) would be
>> overwritten by the maint checkout.
>>
>> $ git checkout maint
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>> volk/CMakeLists.txt
>> volk/apps/CMakeLists.txt
>>  many line of volk/ contents ...
>>
>> Aborting
>>
>> Any advice on how to get to the maint version?
>>
>> -- Tom, N5EG
>>
>
> You'll need to deinitialize the volk submodule first to make it a clean
> checkout:
>
> git submodule deinit volk
> git checkout maint
>
> Probably best not to worry too much about this. For feature branches,
> you'll do this and then rebase off master to prevent this happening again.
> For maint, if you need it, best to keep a separate directory just for that
> branch.
>
> This is temporary. The planned release of 3.7.7 is next Monday. When that
> happens, master becomes maint, so the current maint issue will go away.
>
> Tom
>
>
>
>
>> On Sat, Apr 4, 2015 at 9:28 AM, madengr  wrote:
>>
>>> Actually now I see it would probably be:
>>>
>>> git pull --recurse-submodules=on
>>> git submodule update
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gnuradio.4.n7.nabble.com/Empty-volk-directory-when-I-git-gnuradio-tp53073p53155.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Tom McDermott]

When I clone from the gnuradio repository:

*git clone* --recursive http://git.*gnuradio*.org/git/*gnuradio*.git

The clone succeeds. It is on the master branch.  I can checkout next, and
switch back and forth
between next and master. However when I attempt to checkout maint, git says
the checkout is aborted
because the untracked working tree (everything in volk) would be
overwritten by the maint checkout.

$ git checkout maint
error: The following untracked working tree files would be overwritten by
checkout:
volk/CMakeLists.txt
volk/apps/CMakeLists.txt
 many line of volk/ contents ...

Aborting

Any advice on how to get to the maint version?

-- Tom, N5EG




On Sat, Apr 4, 2015 at 9:28 AM, madengr  wrote:

> Actually now I see it would probably be:
>
> git pull --recurse-submodules=on
> git submodule update
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Empty-volk-directory-when-I-git-gnuradio-tp53073p53155.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor with pybombs

[Tom McDermott]

My particular video card OpenCL drivers moved where they were installed
between different
versions of Ubuntu. I tracked it down with:

~$ locate libOpenCL.so

  producing...
/usr/lib/i386-linux-gnu/libOpenCL.so.1
/usr/lib/i386-linux-gnu/libOpenCL.so.1.0
/usr/lib/i386-linux-gnu/libOpenCL.so.1.0.0
/usr/lib/x86_64-linux-gnu/libOpenCL.so
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0
/usr/lib/x86_64-linux-gnu/libOpenCL.so.1.0.0

So when building gr-fosphor:

cmake ../ -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libOpenCL.so


-- Tom, N5EG



On Thu, Mar 19, 2015 at 8:51 AM, ben Gee  wrote:

> Sylvain,
> Firstly, there is only one install of pybombs on this machine, so
> definitely no separate install conflicts
>
> Second, unfortunately, in an effort to start over, i uninstalled
> gr-fosphor and attemted to reinstall it. I'm now getting this opencl error
> now. not sure if this was something i overlooked last time, but i thought
> the build was ok.
> the resources on the internet regarding opencl are somewhat hazy (or at
> least they are to me) and it seems that there are many different options
> for drivers. Can you shed some light on building these with pybombs as a
> dependency for gr-fosphor? Should they be installed system-wide or do they
> have to be installed in the pybombs environment?
>
> thanks,
> -b
>
> On Thu, Mar 19, 2015 at 3:22 AM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> On Wed, Mar 18, 2015 at 11:47 PM, ben Gee  wrote:
>> > i should also add that the output of "./pyboms" list shows that
>> gr-fosphor
>> > IS installed, output below:
>>
>> Interesting ...
>>
>> Are you sure you haven't two install of pybombs with different
>> prefixes that would mix things up ?
>>
>> If not, I think pybombs keeps a build log somewhere for the various
>> installed package, try to find it and pastebin it somewhere.
>>
>> Cheers,
>>
>>Sylvain
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FATAL: No supported device found

[Tom McDermott]

Hi Bananpi,

On some Linux distributions the RTL dongle USB can be grabbed by other
applications
at boot time, leaving it not available when you use gnuradio. If that is
your issue it may
be resolved by blacklisting the RTL device.

Modify or create a file:   etc/modprobe.d/rtlsdr.conf

and add:

blacklist dvbusbrt128xxu
blacklist e4000
blacklist rtl2832

Then reboot.

-- Tom, N5EG




On Wed, Jan 14, 2015 at 7:38 AM, Marcus D. Leech  wrote:

>  On 01/14/2015 07:54 AM, Andreas Ladanyi wrote:
>
>   Hi,
>
> Bananapi / LUbuntu
>
>
> After building GNURadio with the build-script and compiling / installing
> with success i can start gnuradio-companion or any gnuradio based py
> application but i get the following error messages.
>
> ===
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-52-gd9e7a42d
>
>
> Gtk-Message: Failed to load module "canberra-gtk-module" -> I know the reason
> of this error. This is easy to fix.
>
> gr-osmosdr v0.1.4-9-g48045b59 (0.1.5git) gnuradio 3.7.6
> built-in source types: file fcd rtl_tcp uhd rfspace
>
> FATAL: No supported devices found to pick from.
>
> Trying to fill up 1 missing channel(s) with null source(s).
> This is being done to prevent the application from crashing
> due to gnuradio bug #528.
>
> Source has no sample rates (wrong device arguments?).
> 
>
> It seems that the USB RTL 2832U stick is not found by gnuradio.
>
>
> I could see the device with dmesg and the rtl_test / rtl-test -t is 
> successfull.
>
>
> Any ideas ?
>
> Andreas
>
> ___
> Discuss-gnuradio mailing list
> address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  YOu don't have the rtl support compiled-in to gr-osmosdr--perhaps because
> you were missing librtlsdr
>
> Hi Marcus,
>
> ok, so the problem is that the build-script didnt compile gr-osmosdr with
> rtl support because the librtlsdr wasnt installed from the build-script
> before compiling gr-osmosdr ?
>
> What do i have to do now ? Should i uninstall gr-osmosdr and then compile
> and install gr-osmsosdr again ?
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  Which build script did you use?  build-gnuradio?   It definitely *does*
> build-and-install librtlsdr prior to build gr-osmosdr, but if that fails
> for some reason,
>   gr-osmosdr will get built.
>
> If you re-run it with "-v" it will give you more verbose output.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor. builds OK, throws runtime error

[Tom McDermott]

Thank you Sylvain.   Apologies for misspelling your name.



-- Tom, N5EG





On Wed, Aug 27, 2014 at 4:24 AM, Tom McDermott  wrote:

> Thank you, Manaut.   That indeed was my problem, it runs fine making that
> change.
>
> gr-fosphor is such an incredibly useful tool, it's painful to do without.
>
>
> -- Tom, N5EG
>
>
>
>
> On Tue, Aug 26, 2014 at 10:54 PM, Sylvain Munaut <246...@gmail.com> wrote:
>
>> > cmake ../
>> -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1
>>
>>
>> That's not correct.
>>
>> libnvidia-opencl.so.1 is the backend driver. You need to link against
>> the ICD loader which should be named libOpenCL.so
>>
>>
>> Cheers,
>>
>> Sylvain
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-fosphor. builds OK, throws runtime error

[Tom McDermott]

Thank you, Manaut.   That indeed was my problem, it runs fine making that
change.

gr-fosphor is such an incredibly useful tool, it's painful to do without.


-- Tom, N5EG




On Tue, Aug 26, 2014 at 10:54 PM, Sylvain Munaut <246...@gmail.com> wrote:

> > cmake ../
> -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1
>
>
> That's not correct.
>
> libnvidia-opencl.so.1 is the backend driver. You need to link against
> the ICD loader which should be named libOpenCL.so
>
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-fosphor. builds OK, throws runtime error

[Tom McDermott]

Ubuntu 14.04.
Have updated to gnuradio 3.7.5git-194-g76a271ac, seems to run fine.

I rebuilt / reinstalled gr-fosphor. No problems with the build. The
location of Nvidia's OpenCL library
changed from Ubuntu 13.10 to 14.04.  The cmake command was:

cmake ../ -DOPENCL_LIBRARY=/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1

cmake and make complete successfully.


The QT fosphor block shows up in Gnuradio Companion OK.  When trying to
run, I get the following error:

  from gnuradio import fosphor
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/fosphor/__init__.py", line
45, in 
from fosphor_swig import *
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/fosphor/fosphor_swig.py",
line 28, in 
_fosphor_swig = swig_import_helper()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/fosphor/fosphor_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_fosphor_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-fosphor-3.7.0git.so.0.0.0:
undefined symbol: clBuildProgram

The version of gr-fosphor (which git tells me is the latest) is:
Revision: 9aea19a
Author: Sylvain Munaut
Date: 2014-07-24 22:34:07
fosphor: Allow operation without CL/GL sharing extension


Any advice?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: gnuradio companion core dump

[Tom McDermott]

()



On Mon, Aug 4, 2014 at 2:01 AM, Martin Braun  wrote:

> These can be a bit annoying. You can inspect the core dump
> (http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging)
> to see where this happens. Chances are you rebuilt GNU Radio and this is
> some OOT module that is acting up.
>
> M
>
> On 08/04/2014 12:14 AM, Tom McDermott wrote:
> > I had this problem a couple weeks ago.  After deleting the build
> > subdirectory and rebuilding it went away until today
> > when it came back.  I deleted the build directory and
> > re-cmake/make/install/ldconfig, but the problem will not clear.
> >
> >
> > gnuradio-companion
> > linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef
> >
> > terminate called after throwing an instance of 'std::runtime_error'
> >   what():  rpcmanager: Aggregator not in use, and a rpc booter is
> > already registered
> >
> > Aborted (core dumped)
> >
> >
> > Ubuntu 14.04
> > Gnuradio master  41d0844
> >
> > -- Tom, N5EG
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio companion core dump

[Tom McDermott]

I had this problem a couple weeks ago.  After deleting the build
subdirectory and rebuilding it went away until today
when it came back.  I deleted the build directory and
re-cmake/make/install/ldconfig, but the problem will not clear.


gnuradio-companion
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef

terminate called after throwing an instance of 'std::runtime_error'
  what():  rpcmanager: Aggregator not in use, and a rpc booter is already
registered

Aborted (core dumped)


Ubuntu 14.04
Gnuradio master  41d0844

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.5git core dumps

[Tom McDermott]

Hi Tom,   Thanks!

Deleting the gnuradio/build directory, then rebuilding fixed the issue.

-- Tom, N5EG




On Sat, Jul 12, 2014 at 1:36 PM, Tom Rondeau  wrote:

> On Sat, Jul 12, 2014 at 4:15 PM, Tom McDermott  wrote:
>
>> Hi Tom,
>>
>> The commit that caused the issue was 2bb2b31.  I did a cmake, make, make
>> install after checking out that commit.
>>
>> I will go back, clean out the build folder, checkout 2bb2b31 and try
>> again.
>>
>> -- tom, N5EG
>>
>
> Ok, thanks. It's possibly due to the change in commit b4bbda76 that
> adjusted how one of the classes in ControlPort was defined. That should
> just take clearing things out and rebuilding to fix. As I said, it's
> working fine for me now even though I saw a similar problem.
>
> Tom
>
>
>
>
>> On Sat, Jul 12, 2014 at 1:03 PM, Tom Rondeau  wrote:
>>
>>> On Sat, Jul 12, 2014 at 3:10 PM, Tom McDermott 
>>> wrote:
>>>
>>>> I went back to build b5006c1 , rebuilt, and gnuradio-companion is
>>>> running again...
>>>>
>>>> ~gnuradio$ git checkout b5006c1
>>>>
>>>> System is Ubuntu 13.10, Ice3.5
>>>>
>>>> -- Tom, N5EG
>>>>
>>>
>>> Did you try rebuilding before doing this? What was the original commit
>>> that was giving your trouble so we could see what's changed since b5006c1
>>> that could be causing this. Frankly, that shouldn't have anything to do
>>> with anything.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>>> On Sat, Jul 12, 2014 at 11:13 AM, Tom Rondeau  wrote:
>>>>
>>>>> On Sat, Jul 12, 2014 at 2:00 PM, Tom McDermott 
>>>>> wrote:
>>>>>
>>>>>> Built 3.7.5git, and updated UHD to latest. Builds fine. Gnuradio from
>>>>>> the command line runs fine.
>>>>>> When trying to run gnuradio-companion it core dumps:
>>>>>>
>>>>>>
>>>>>> ~/gnuradio$ gnuradio-companion
>>>>>> linux; GNU C++ version 4.8.1; Boost_105300;
>>>>>> UHD_003.007.001-84-gd99ce4ef
>>>>>>
>>>>>> terminate called after throwing an instance of 'std::runtime_error'
>>>>>>   what():  rpcmanager: Aggregator not in use, and a rpc booter is
>>>>>> already registered
>>>>>>
>>>>>> Aborted (core dumped)
>>>>>>
>>>>>>
>>>>>> Any advice?
>>>>>>
>>>>>> -- Tom, N5EG
>>>>>>
>>>>>
>>>>> Well, shoot. I was really hoping that was just me and something weird
>>>>> I had done to my system. I had a similar issue. I just removed my 
>>>>> installed
>>>>> version of GR, deleted all my build files, and rebuilt. If it's still
>>>>> causing you issue, you can try turning off ControlPort with
>>>>> -DENABLE_GR_CTRLPORT=False in the cmake command.
>>>>>
>>>>> I'm not sure what it is because this only happened on one of my
>>>>> machines. Potentially some weird interaction with Ice during the rebuild.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.5git core dumps

[Tom McDermott]

Hi Tom,

The commit that caused the issue was 2bb2b31.  I did a cmake, make, make
install after checking out that commit.

I will go back, clean out the build folder, checkout 2bb2b31 and try again.

-- tom, N5EG




On Sat, Jul 12, 2014 at 1:03 PM, Tom Rondeau  wrote:

> On Sat, Jul 12, 2014 at 3:10 PM, Tom McDermott  wrote:
>
>> I went back to build b5006c1 , rebuilt, and gnuradio-companion is running
>> again...
>>
>> ~gnuradio$ git checkout b5006c1
>>
>> System is Ubuntu 13.10, Ice3.5
>>
>> -- Tom, N5EG
>>
>
> Did you try rebuilding before doing this? What was the original commit
> that was giving your trouble so we could see what's changed since b5006c1
> that could be causing this. Frankly, that shouldn't have anything to do
> with anything.
>
> Tom
>
>
>
>
>> On Sat, Jul 12, 2014 at 11:13 AM, Tom Rondeau  wrote:
>>
>>> On Sat, Jul 12, 2014 at 2:00 PM, Tom McDermott 
>>> wrote:
>>>
>>>> Built 3.7.5git, and updated UHD to latest. Builds fine. Gnuradio from
>>>> the command line runs fine.
>>>> When trying to run gnuradio-companion it core dumps:
>>>>
>>>>
>>>> ~/gnuradio$ gnuradio-companion
>>>> linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef
>>>>
>>>> terminate called after throwing an instance of 'std::runtime_error'
>>>>   what():  rpcmanager: Aggregator not in use, and a rpc booter is
>>>> already registered
>>>>
>>>> Aborted (core dumped)
>>>>
>>>>
>>>> Any advice?
>>>>
>>>> -- Tom, N5EG
>>>>
>>>
>>> Well, shoot. I was really hoping that was just me and something weird I
>>> had done to my system. I had a similar issue. I just removed my installed
>>> version of GR, deleted all my build files, and rebuilt. If it's still
>>> causing you issue, you can try turning off ControlPort with
>>> -DENABLE_GR_CTRLPORT=False in the cmake command.
>>>
>>> I'm not sure what it is because this only happened on one of my
>>> machines. Potentially some weird interaction with Ice during the rebuild.
>>>
>>> Tom
>>>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.5git core dumps

[Tom McDermott]

I went back to build b5006c1 , rebuilt, and gnuradio-companion is running
again...

~gnuradio$ git checkout b5006c1

System is Ubuntu 13.10, Ice3.5

-- Tom, N5EG


On Sat, Jul 12, 2014 at 11:13 AM, Tom Rondeau  wrote:

> On Sat, Jul 12, 2014 at 2:00 PM, Tom McDermott  wrote:
>
>> Built 3.7.5git, and updated UHD to latest. Builds fine. Gnuradio from the
>> command line runs fine.
>> When trying to run gnuradio-companion it core dumps:
>>
>>
>> ~/gnuradio$ gnuradio-companion
>> linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef
>>
>> terminate called after throwing an instance of 'std::runtime_error'
>>   what():  rpcmanager: Aggregator not in use, and a rpc booter is already
>> registered
>>
>> Aborted (core dumped)
>>
>>
>> Any advice?
>>
>> -- Tom, N5EG
>>
>
> Well, shoot. I was really hoping that was just me and something weird I
> had done to my system. I had a similar issue. I just removed my installed
> version of GR, deleted all my build files, and rebuilt. If it's still
> causing you issue, you can try turning off ControlPort with
> -DENABLE_GR_CTRLPORT=False in the cmake command.
>
> I'm not sure what it is because this only happened on one of my machines.
> Potentially some weird interaction with Ice during the rebuild.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 3.7.5git core dumps

[Tom McDermott]

Built 3.7.5git, and updated UHD to latest. Builds fine. Gnuradio from the
command line runs fine.
When trying to run gnuradio-companion it core dumps:


~/gnuradio$ gnuradio-companion
linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.007.001-84-gd99ce4ef

terminate called after throwing an instance of 'std::runtime_error'
  what():  rpcmanager: Aggregator not in use, and a rpc booter is already
registered

Aborted (core dumped)


Any advice?

-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Removing GNU Radio Throughly

[Tom McDermott]

Hi Jon - I made a bash script to do a more or less complete removal, based
on a something Jonathan posted several years ago. It's a bit pre-3.7
centric, but seems to get the job done (even with 3.7).

svn.tapr.org/repos_sdr_hpsdr/trunk/N5EG/GRC3.6/Gnuradio_remove

-- Tom, N5EG




On Tue, Jun 24, 2014 at 3:48 PM, Jonathan Fox <31...@cardinalmail.cua.edu>
wrote:

> I forgot a crucial bit of information, make uninstall wasn't working
> right, I kept getting
>
> Cmake Error at cmake_uninstall.cmake:20 (ELSEIF):
> had incorrect arguments: IS_SYMLINK "$ENV{DESTDIR}${file}" (Unknown
> arguments specified).
>
> So I just went into /usr/local/ and started purging.
>
>
> On Tue, Jun 24, 2014 at 6:42 PM, Jonathan Fox <31...@cardinalmail.cua.edu>
> wrote:
>
>> Just recently I decided to update my old build of GNU Radio (3.6 release
>> from Dec '13) to the newest one. Due to overly conservative and arbitrary
>> network policies, my CentOS machines are forbidden to interact with the
>> internet, so that means no build_gnuradio or PyBombs. I think I didn't
>> throughly remove my old install because I had an issue with gr.remez.
>>
>> I ran:
>>
>> sudo rm -rf /usr/local/include/gnuradio/
>> sudo rm -f /usr/local/lib*/libgnuradio*/
>>
>> and somehow old files stuck around. So I have gone through my whole
>> /usr/local/ directory and removed anything related to GNU Radio. Is there
>> any other places I should be aware of? I'm asking because I have done this
>> twice already, the 2nd reinstall wasn't working right, for example: blks2
>> module wasn't found on the ofdm benchmark scripts and I was still having
>> problems with that gr.remez, I know it has a new name now but I figured the
>> new install would of taken care of that unless I have old files lingering.
>> For the record this is my error:
>>
>> $ ./benchmark_rx.py -a addr="10.2.8.104" -v -f 146.0M -m qpsk
>> --discontinuous
>> Traceback (most recent call last):
>>   File "./benchmark_rx.py", line 23, in 
>> from gnuradio import gr, blks2
>>   File
>> "/usr/local/lib64/python2.6/site-packages/gnuradio/blks2/__init__.py", line
>> 37, in 
>> exec "from gnuradio.blks2impl.%s import *" % (f,)
>>   File "", line 1, in 
>>   File
>> "/usr/local/lib64/python2.6/site-packages/gnuradio/blks2impl/pfb_interpolator.py",
>> line 23, in 
>> from gnuradio import gr, optfir
>>   File "/usr/local/lib64/python2.6/site-packages/gnuradio/optfir.py",
>> line 33, in 
>> remez = gr.remez
>> AttributeError: 'module' object has no attribute 'remez'
>>
>> So I think the old build may be conflicting with the new build.
>>
>> To sum up my question again, is there any other directory outside of the
>> usr/local/ where old build files could be?
>>
>> Thank you so much,
>>
>> Jon
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] signal level

[Tom McDermott]

Hi Ali - some sinks care about the amplitude, and others do not.

For example, the instruments built into gnuradio (Scope, Frequency display,
etc.) can examine a signal of almost any amplitude within floating-point
range because you can adjust the display scale factor.

However other sinks, such as a physical transmitter (USRP, HPSDR, etc.) are
constrained in the amplitude that they can accept. Normally this must be
less than one, and hitting or exceeding 1.00 (even just on the peak)  can
cause problems. Also a physical transmitter might have only 12 or 16 bits
fixed point dynamic range, so there may be a minimum signal amplitude as
well.

-- Tom, N5EG




On Wed, Jun 4, 2014 at 7:33 PM, jason sam  wrote:

> Hi,
> In GRC is it necessary that we give a signal to any sink having an
> amplitude greater than 1?
> Regards,
> Ali
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error trying to load FFT filter taps

[Tom McDermott]

Thanks, Tom   that solved the problem.

numpy.fromfile('filename', numpy.complex64).tolist()

Should the gnuradio wiki (GRC) text be updated?

Apologies for the triple posting, first two attempts were using
yahoo.commail account, got
bit by the yahoo DMARC problem and dumped from the list. Changed to gmail
to avoid the problem.

-- Tom, N5EG




On Sun, Apr 20, 2014 at 8:44 AM, Tom Rondeau  wrote:

> On Sat, Apr 19, 2014 at 1:27 PM, Tom McDermott  wrote:
>
>> Am getting the following error when trying to run a GRC flowgraph that
>> loads FFT filter taps from an external file. The type filter parameter is
>> set to complex->complex (complex taps).
>> The flow graph has imported numpy.  The taps are loaded using:
>>
>> numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072',
>> numpy.complex64)
>>
>> as the taps parameter.  What does the error below mean?
>>
>> GRC: v3.7.4git-101-g76970d54
>> Ubuntu 13.10
>> top_block.py is attached.
>>
>> -- Tom, N5EG
>>
>>
>> Traceback (most recent call last):
>>   File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 173, in
>> 
>> tb = top_block()
>>   File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 115, in
>> __init__
>> self.fft_filter_xxx_0 = filter.fft_filter_ccc(1,
>> (numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072',
>> numpy.complex64)), 1)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
>> line 1329, in make
>> return _filter_swig.fft_filter_ccc_make(*args, **kwargs)
>> TypeError: in method 'fft_filter_ccc_make', argument 2 of type
>> 'std::vector< gr_complex,std::allocator< gr_complex > > const &'
>>
>
>
> Tom,
>
> This is a conflict between the numpy array data type and swig. Call the
> .tolist() function on the array passed back from numpy and it should work.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error trying to load FFT filter taps

[Tom McDermott]

Am getting the following error when trying to run a GRC flowgraph that
loads FFT filter taps from an external file. The type filter parameter is
set to complex->complex (complex taps).
The flow graph has imported numpy.  The taps are loaded using:

numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072',
numpy.complex64)

as the taps parameter.  What does the error below mean?

GRC: v3.7.4git-101-g76970d54
Ubuntu 13.10
top_block.py is attached.

-- Tom, N5EG


Traceback (most recent call last):
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 173, in

tb = top_block()
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 115, in
__init__
self.fft_filter_xxx_0 = filter.fft_filter_ccc(1,
(numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072',
numpy.complex64)), 1)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
line 1329, in make
return _filter_swig.fft_filter_ccc_make(*args, **kwargs)
TypeError: in method 'fft_filter_ccc_make', argument 2 of type
'std::vector< gr_complex,std::allocator< gr_complex > > const &'
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Sat Apr 19 09:34:24 2014
##

execfile("/home/tom/.grc_gnuradio/ChirpSource.py")
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import hpsdr
import numpy
import sip
import sys

class top_block(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "Top Block")
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
try:
 self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
 pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())


##
# Variables
##
self.samp_rate = samp_rate = 48000
self.TxDrive = TxDrive = 0
self.Frequency = Frequency = 3525000

##
# Blocks
##
self._TxDrive_tool_bar = Qt.QToolBar(self)
self._TxDrive_tool_bar.addWidget(Qt.QLabel("TxDrive"+": "))
self._TxDrive_line_edit = Qt.QLineEdit(str(self.TxDrive))
self._TxDrive_tool_bar.addWidget(self._TxDrive_line_edit)
self._TxDrive_line_edit.returnPressed.connect(
	lambda: self.set_TxDrive(int(self._TxDrive_line_edit.text().toAscii(
self.top_layout.addWidget(self._TxDrive_tool_bar)
self._Frequency_tool_bar = Qt.QToolBar(self)
self._Frequency_tool_bar.addWidget(Qt.QLabel("Frequency"+": "))
self._Frequency_line_edit = Qt.QLineEdit(str(self.Frequency))
self._Frequency_tool_bar.addWidget(self._Frequency_line_edit)
self._Frequency_line_edit.returnPressed.connect(
	lambda: self.set_Frequency(int(self._Frequency_line_edit.text().toAscii(
self.top_layout.addWidget(self._Frequency_tool_bar)
self.qtgui_time_sink_x_0 = qtgui.time_sink_c(
	131072, #size
	samp_rate, #samp_rate
	"QT GUI Plot", #name
	1 #number of inputs
)
self.qtgui_time_sink_x_0.set_update_time(0.10)
self.qtgui_time_sink_x_0.set_y_axis(-1, 1)
self.qtgui_time_sink_x_0.enable_tags(-1, True)
self.qtgui_time_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, qtgui.TRIG_SLOPE_POS, 0.0, 0, 0, "")
self.qtgui_time_sink_x_0.enable_autoscale(False)

labels = ["", "", "", "", "",
  "", "", "", "", ""]
widths = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
  "magenta", "yellow", "dark red", "dark green", "blue"]
styles = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
markers = [-1, -1, -1, -1, -1,
   -1, -1, -1, -1, -1]
alphas = [1.0, 1.0, 1.0, 1.0, 1.0

[Discuss-gnuradio] Error trying to load taps into FFT filter

[Tom McDermott]

Am getting the following error when trying to run a GRC flowgraph that 
loads FFT filter taps from an external file. The type filter parameter 
is set to complex->complex (complex taps).

The flow graph has imported numpy.  The taps are loaded using:

numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072', 
numpy.complex64)

as the taps parameter.  What does the error below mean?

GRC: v3.7.4git-101-g76970d54
Ubuntu 13.10
top_block.py is attached.


-- Tom, N5EG



Traceback (most recent call last):
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 173, in 
    tb = top_block()
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 115, in __init__
   
 self.fft_filter_xxx_0 = filter.fft_filter_ccc(1, 
(numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072',
 numpy.complex64)), 1)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py", 
line 1329, in make
    return _filter_swig.fft_filter_ccc_make(*args, **kwargs)
TypeError:
 in method 'fft_filter_ccc_make', argument 2 of type 'std::vector< 
gr_complex,std::allocator< gr_complex > > const &'#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Sat Apr 19 09:34:24 2014
##

execfile("/home/tom/.grc_gnuradio/ChirpSource.py")
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import hpsdr
import numpy
import sip
import sys

class top_block(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "Top Block")
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
try:
 self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
 pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())


##
# Variables
##
self.samp_rate = samp_rate = 48000
self.TxDrive = TxDrive = 0
self.Frequency = Frequency = 3525000

##
# Blocks
##
self._TxDrive_tool_bar = Qt.QToolBar(self)
self._TxDrive_tool_bar.addWidget(Qt.QLabel("TxDrive"+": "))
self._TxDrive_line_edit = Qt.QLineEdit(str(self.TxDrive))
self._TxDrive_tool_bar.addWidget(self._TxDrive_line_edit)
self._TxDrive_line_edit.returnPressed.connect(
	lambda: self.set_TxDrive(int(self._TxDrive_line_edit.text().toAscii(
self.top_layout.addWidget(self._TxDrive_tool_bar)
self._Frequency_tool_bar = Qt.QToolBar(self)
self._Frequency_tool_bar.addWidget(Qt.QLabel("Frequency"+": "))
self._Frequency_line_edit = Qt.QLineEdit(str(self.Frequency))
self._Frequency_tool_bar.addWidget(self._Frequency_line_edit)
self._Frequency_line_edit.returnPressed.connect(
	lambda: self.set_Frequency(int(self._Frequency_line_edit.text().toAscii(
self.top_layout.addWidget(self._Frequency_tool_bar)
self.qtgui_time_sink_x_0 = qtgui.time_sink_c(
	131072, #size
	samp_rate, #samp_rate
	"QT GUI Plot", #name
	1 #number of inputs
)
self.qtgui_time_sink_x_0.set_update_time(0.10)
self.qtgui_time_sink_x_0.set_y_axis(-1, 1)
self.qtgui_time_sink_x_0.enable_tags(-1, True)
self.qtgui_time_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, qtgui.TRIG_SLOPE_POS, 0.0, 0, 0, "")
self.qtgui_time_sink_x_0.enable_autoscale(False)

labels = ["", "", "", "", "",
  "", "", "", "", ""]
widths = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
  "magenta", "yellow", "dark red", "dark green", "blue"]
styles = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
markers = [-1, -1, -1, -1, -1,
   -1, -1, -1, -1, -1]
alphas = [1.0, 1.0, 1.

[Discuss-gnuradio] Error trying to load taps into FFT filter

[Tom McDermott]

Am getting the following error when trying to run a GRC flowgraph that loads 
FFT filter taps from an external file. The type filter parameter is set to 
complex->complex (complex taps).

The flow graph has imported numpy.  The taps are loaded using:

numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072', 
numpy.complex64)

as the taps parameter.  What does the error below mean?

GRC: v3.7.4git-101-g76970d54
Ubuntu 13.10
top_block.py is attached.


-- Tom, N5EG



Traceback (most recent call last):
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 173, in 
    tb = top_block()
  File "/home/tom/Desktop/EchoScreencaps/top_block.py", line 115, in __init__
    self.fft_filter_xxx_0 = filter.fft_filter_ccc(1, 
(numpy.fromfile('/home/tom/Desktop/EchoScreencaps/chirp-down-20-20-131072', 
numpy.complex64)), 1)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py", 
line 1329, in make
    return _filter_swig.fft_filter_ccc_make(*args, **kwargs)
TypeError: in method 'fft_filter_ccc_make', argument 2 of type 'std::vector< 
gr_complex,std::allocator< gr_complex > > const &'#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Sat Apr 19 09:34:24 2014
##

execfile("/home/tom/.grc_gnuradio/ChirpSource.py")
from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import filter
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import hpsdr
import numpy
import sip
import sys

class top_block(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "Top Block")
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
try:
 self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
 pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())


##
# Variables
##
self.samp_rate = samp_rate = 48000
self.TxDrive = TxDrive = 0
self.Frequency = Frequency = 3525000

##
# Blocks
##
self._TxDrive_tool_bar = Qt.QToolBar(self)
self._TxDrive_tool_bar.addWidget(Qt.QLabel("TxDrive"+": "))
self._TxDrive_line_edit = Qt.QLineEdit(str(self.TxDrive))
self._TxDrive_tool_bar.addWidget(self._TxDrive_line_edit)
self._TxDrive_line_edit.returnPressed.connect(
	lambda: self.set_TxDrive(int(self._TxDrive_line_edit.text().toAscii(
self.top_layout.addWidget(self._TxDrive_tool_bar)
self._Frequency_tool_bar = Qt.QToolBar(self)
self._Frequency_tool_bar.addWidget(Qt.QLabel("Frequency"+": "))
self._Frequency_line_edit = Qt.QLineEdit(str(self.Frequency))
self._Frequency_tool_bar.addWidget(self._Frequency_line_edit)
self._Frequency_line_edit.returnPressed.connect(
	lambda: self.set_Frequency(int(self._Frequency_line_edit.text().toAscii(
self.top_layout.addWidget(self._Frequency_tool_bar)
self.qtgui_time_sink_x_0 = qtgui.time_sink_c(
	131072, #size
	samp_rate, #samp_rate
	"QT GUI Plot", #name
	1 #number of inputs
)
self.qtgui_time_sink_x_0.set_update_time(0.10)
self.qtgui_time_sink_x_0.set_y_axis(-1, 1)
self.qtgui_time_sink_x_0.enable_tags(-1, True)
self.qtgui_time_sink_x_0.set_trigger_mode(qtgui.TRIG_MODE_FREE, qtgui.TRIG_SLOPE_POS, 0.0, 0, 0, "")
self.qtgui_time_sink_x_0.enable_autoscale(False)

labels = ["", "", "", "", "",
  "", "", "", "", ""]
widths = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
colors = ["blue", "red", "green", "black", "cyan",
  "magenta", "yellow", "dark red", "dark green", "blue"]
styles = [1, 1, 1, 1, 1,
  1, 1, 1, 1, 1]
markers = [-1, -1, -1, -1, -1,
   -1, -1, -1, -1, -1]
alphas = [1.0, 1.0, 1.

Re: [Discuss-gnuradio] installing via PyBombs

[Tom McDermott]

Hi John.
 
In a command window, type
 
gnuradio-companion
 
That will launch grc.  While it's open, you will have an icon on the left-hand 
icon bar.
Right click the grc icon, and lock it to the launch bar, then you'll have an 
icon in the future.
 
-- Tom, N5EG
 



From: John Meloche 
To: discuss-gnuradio@gnu.org 
Sent: Saturday, April 5, 2014 9:53 PM
Subject: [Discuss-gnuradio] installing via PyBombs



Hello...  new user here.  I need to know what do next.  There is no GRC icon 
after the install.  Any help would be great.  Thanks.


I ran the following on a very fresh install of Ubuntu LTS. 

sudo apt-get install git 

git clone git://github.com/pybombs/pybombs 

cd pybombs
./pybombs install gnuradio
sudo ldconfig 


There were no errors reported along the way and took about 1 hour.  I selected 
all of the defaults during the pybombs install.
Terminal window displayed the following upon completion:

Best unaligned arch: u_sse3
RUN_VOLK_TESTS: volk_32f_s32f_multiply_32f(
204602,1)
u_sse completed in 470ms
u_avx completed in 480ms
generic completed in 1110ms
a_sse completed in 470ms
a_avx completed in 500ms
a_generic completed in 1120ms
Best aligned arch: u_sse
Best unaligned arch: u_sse
Creating "/home//.volk"...
Writing "/home//.volk/volk_config"...

@-TECRA-R950:~/pybombs$ sudo ldconfig
[sudo] password for : 
@-TECRA-R950:~/pybombs$ 
Now what?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT GUI Chooser not working

[Tom McDermott]

GRC v3.7.2.1-195-g19d111e2   //  ubuntu 13.10

Using QT GUI range works fine, changing it to QT GUI chooser (Type = Integer)
seems to fail (regardless of number of options), with the following error 
message:


linux; GNU C++ version 4.8.1; Boost_105300; UHD_003.006.000-0-g7788c692


Traceback (most recent call last):
  File "/home/tom/Desktop/top_block.py", line 185, in 
    tb = top_block()
  File "/home/tom/Desktop/top_block.py", line 78, in __init__
    self._RxFreq_callback(self.RxFreq)
  File "/home/tom/Desktop/top_block.py", line 77, in 
    self._RxFreq_callback = lambda i: 
Qt.QMetaObject.invokeMethod(self._RxFreq_button_group, "updateButtonChecked", 
Qt.Q_ARG("int", self._RxFreq_options.index(i)))
ValueError: tuple.index(x): x not in tuple


A bug?  More information needed?

-- Tom, N5EG


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble with SSB demod of real signal

[Tom McDermott]

Hi Lou - the diagram you sent isn't going to perform a single-signal conversion.
Taking just the real part of the received signal (and throwing away the 
imaginary part) 
gets rid of information that distinguishes negative frequency components from
positive frequency components. After that point there is no possibility to 
separate out
the LSB components from the USB components.
 
You will need a bit more complicated design, I've used the following 
configuration for 
implementing a phasing type receiver. There are other ways as well, the Weaver 
method,
and a filter method (using complex taps to a filter).
 
http://www.tapr.org/~n5eg/index_files/DCC_2013_Gnuradio_Presentation%20-%20Rev%205.pdf
 
Look at about slide 14.
 
-- Tom, N5EG
 
 


 From: Louis Brown 
To: GNURadio List Discussion  
Sent: Sunday, February 16, 2014 9:10 AM
Subject: [Discuss-gnuradio] Trouble with SSB demod of real signal
  


Hi,

I'm exploring the LF spectrum (< 500 kHz) using a USRP N210+LFRX+active loop 
antenna, and GR 3.7.  I'm pulling my hair out trying to down convert the USB as 
I can't get the LSB rejected.  My GRC flow graph is here:

https://dl.dropboxusercontent.com/u/49570443/test.grc.png

It is based on figure 5 of below; quadrature, direct down conversion with 
Hilbert transform.

http://www.arrl.org/files/file/Technology/tis/info/pdf/98qex003.pdf


I'm taking the real output (i.e. the DAC hooked to the LFRX channel 1) of the 
N210 at 25 Msps with 0 Hz DDS, then low-pass filtering at 550 kHz and 
decimating to 1.25 Msps. This seems to provide better rejection of the AM band 
than using the DDS tuning internal to the N210.
I then use the translating FIR filter to tune a 2 kHz passband, decimated to 5 
ksps.

Problem comes when I try to do the LSB rejection with the Hilbert.  I think I'm 
using it correctly; I have tried swapping the Re and Im outputs of the Hilbert 
with no luck.  Maybe there is something conceptually I am missing since I am 
starting with a real signal.  I have done SSB demod with complex USRP signal 
with no problems.

Any ideas of what I am doing wrong?  This should be basic stuff but I'm not 
getting something.

Thanks,
Lou

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Resolved: gr-perf-monitorx graphics

[Tom McDermott]

Got the graphics working on gr-perf-monitorx. Here's a list of packages, and 
the installation 

sequence needed to get it running on Ubuntu 13.10:


sudo apt-get install  3 packages:
  pip   (the python package installer)
  graphviz
  libgraphviz-dev

Then

pip install 2 packages:
  networkx
  pygraphviz


-- Tom, N5EG
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Resolved CtrlPort build problem

[Tom McDermott]

Have resolved my CtrlPort build problem on Ubuntu.


ICE 3.4 will not build under GCC 4.7 or 4.8.  I installed ICE 3.5 for Ubuntu 
13.10 using the following script, claimed to work for Raring or later [1].  ice 
installed OK, ice-dev did not. Apparently ice-dev not needed, so consider 
eliminating it from the script below.


$ sudo su
# wget http://www.zeroc.com/download/Ice/3.5/ubuntu/ice3.5-raring.list -O- > 
/etc/apt/sources.list.d/ice3.5-raring.list
# wget http://www.zeroc.com/download/RPM-GPG-KEY-zeroc-release -O- | apt-key 
add -
# apt-get update
# apt-get install ice ice-dev

When running Control Port monitor I get a screen with the running performance 
values for all the blocks, but no graphics of any kind. Is this normal?  Is 
there a way to dump the performance text values to a file?


-- Tom, N5EG


[1] 
http://crysol.github.io/recipe/2013-09-19/ice35-deb-packages-from-zeroc/#.UvchUvjiB2W___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio