Re: Using volk_profile for all users on shared server

[Richard Bell]

What is a good way to test whether this is working or not?

On Thu, Jun 22, 2023 at 5:58 PM Marcus D. Leech 
wrote:

> On 22/06/2023 20:50, Richard Bell wrote:
>
> Hello,
>
> I am managing a server that is connected to several USRP N320s and USRP
> X300s, that many users access. The server is running Ubuntu 22.04 with GNU
> Radio 3.10.6.0 and UHD 4.4.0.0, installed from source.
>
> I would like to know if there is a way to run "volk_profile" once, for all
> users, instead of every user needing to run this individually. Is this
> possible?
>
> Thank you,
>
> Rich
>
> /etc/volk/volk_configfrom a very very cursory inspection of the code...
>
>

Using volk_profile for all users on shared server

[Richard Bell]

Hello,

I am managing a server that is connected to several USRP N320s and USRP
X300s, that many users access. The server is running Ubuntu 22.04 with GNU
Radio 3.10.6.0 and UHD 4.4.0.0, installed from source.

I would like to know if there is a way to run "volk_profile" once, for all
users, instead of every user needing to run this individually. Is this
possible?

Thank you,

Rich

Monitor O's and U's from Python

[Richard Bell]

Hello,

I have a python flowgraph that transmits data from one radio to another for
a research project. Sometimes during one of these tx/rx events, U's or O's
will occur, making the data invalid. I would like to monitor the USRP for
these events from within Python so I can request a retransmit when they
occur.

How do I monitor for O's and U's from within Python?

Thank you,

Richard

Does a block exist that does...

[Richard Bell]

Hi all,

I'm looking for a block that is like the vector sink, however, it does not
store samples in an unbounded manor until it is reset. It's a vector sink
that stores a fixed item length worth of samples that allows python to get
them when it wants. The block should consume samples every time its called
by the scheduler whether the block is accessed by python or not.

Does this functionality already exist?

Thanks,
Rich

Capture Finite Samples

[Richard Bell]

Hello everyone,

I'm trying to capture a user specified number of samples from 3 USRP
X300's. To do this I found the finite_acquisition_v function. The problem
is it behaves very irregularly, so much so that I can't figure out the
right way to use it.

It seems that I have to call it once with a big number as a prerequisite.
It always returns an empty type this first call.

After that first call I have to call it with a sample number request larger
than ~1000 to get a none empty tuple. However, the number of samples is
less than 1000, for some reason it is 728

If I call it again a third time, I am getting an empty tuple again.

I'm wondering if someone can explain the proper way to use this for me. In
theory it does exactly what I need to do in one simple function call.

Example code:

junk = uhd_usrp_source_0.finite_acquisition_v(1000) # first call
returns nothing
data1 = uhd_usrp_source_0.finite_acquisition_v(1000) # returns 728
samples
data2 = uhd_usrp_source_0.finite_acquisition_v(1000) # returns nothing

Thanks,

Rich

Stopping and Starting Flowgraphs in Python

[Richard Bell]

Hello,

I'm trying to transmit and receive small chunks of data in between data
processing steps. I can only get the first chunk of data across, after
that, calling tx.start() and rx.start() does not seems to work. The
flowgraphs I'm starting have head() blocks in them that are responsible for
calling tx.stop() and rx.stop(). So the series of call would look something
like this:

# send first chunk, this goes fine
rx.start()
time.sleep(0.1)
tx.start()
tx.wait()
rx.wait()

time.sleep(1)

# send the second chunk, this doesn't work
x.start()
time.sleep(0.1)
tx.start()
tx.wait()
rx.wait()

When the head blocks call tx.stop() and rx.stop() internally, does that
make the flowgraphs unrecoverable for the next tx/rx.start()? If this is
the case, how would we implement what I'm describing?

Re: [Discuss-gnuradio] Pybombs broken?

[Richard Bell]

I should have added that when I try and mimic the way that worked for
gnuradio37 that you gave above, replacing it with the gnuradio38 recipe, I
get the following error:

rbell@rbell:~$ pybombs install gnuradio38
[INFO] Prefix Python version is: 2.7.15
[INFO] PyBOMBS Version 2.3.4a0
[INFO] Phase 1: Creating install tree and installing binary packages:
Install tree:
|
\- gnuradio38
[INFO] Phase 1 complete: All binary dependencies installed.
[INFO] Phase 2: Recursively installing source packages to prefix:
[INFO] Installing package: gnuradio38
fatal: No such remote or remote group: gnuradio38
[ERROR] Unexpected error while fetching git+
https://github.com/gnuradio/gnuradio.git.
[ERROR] Command '['git', 'remote', 'update', 'gnuradio38']' returned
non-zero exit status 1
[ERROR] Problem occurred while building package gnuradio38:
Unable to fetch recipe gnuradio38
[ERROR] Error installing package gnuradio38. Aborting.

On Thu, Oct 17, 2019 at 11:26 AM Richard Bell 
wrote:

> Michael,
>
> I can confirm this worked for me without any issues. Now if I want to
> install the latest version of gnuradio next to this one in a new prefix, do
> you know what set of commands would work?
>
> On Wed, Oct 16, 2019 at 11:45 AM Michael Kacher  wrote:
>
>> Hi Richard,
>> The following steps have been successful in building v3.7.13.5 in my
>> 18.04 docker. Give this a shot.
>>
>> -Mike
>>
>> $ pip install pybombs
>> $ pybombs auto-config
>> $ pybombs recipes add-defaults
>> $ pybombs config --package gnuradio gitrev v3.7.13.5
>> $ pybombs config --package uhd gitrev v3.14.1.0
>> $ pybombs prefix init -a {MyAlias} {MyPrefixPath}
>> $ pybombs config --package uhd forcebuild true
>> $ pybombs install gnuradio37
>>
>> On Wed, Oct 16, 2019 at 2:22 PM Chris Kuethe 
>> wrote:
>>
>>> On the upside, this is fantastic opportunity to figure out a
>>> framework/process for the 3.8-3.9 upgrade.
>>>
>>> On Wed, Oct 16, 2019, 11:18 Martin Braun  wrote:
>>>
>>>> Hey Richard,
>>>>
>>>> PyBOMBS is having a hard time dealing with 3.7 vs. 3.8. Use the PyBOMBS
>>>> master branch for any hope of it working.
>>>>
>>>> -- M
>>>>
>>>> On Tue, Oct 15, 2019 at 5:00 PM Richard Bell 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm using pybombs to install gnuradio 3.7.13.5 onto ubuntu 18.04.
>>>>> Pybombs seems to be unable to install dependencies anymore. Each time I 
>>>>> run
>>>>>
>>>>> pybombs prefix init ~/Documents/gnuradio/gr37 -a gr37 -R
>>>>> gnuradio-default
>>>>>
>>>>> it goes for a while until it finds software that is missing and errors
>>>>> out. I then manually install the software and rerun the above command. 
>>>>> I've
>>>>> had to do this for several dependencies now, including:
>>>>>
>>>>> mako, cppunit, pyqt4, cheetah, thrift, numpy and more.
>>>>>
>>>>> Did something change recently that broke pybombs? About a year ago I
>>>>> was using it without much problem, it installed everything for me.
>>>>>
>>>>> v/r,
>>>>>
>>>>> 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
>>>>
>>> ___
>>> 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] Pybombs broken?

[Richard Bell]

Michael,

I can confirm this worked for me without any issues. Now if I want to
install the latest version of gnuradio next to this one in a new prefix, do
you know what set of commands would work?

On Wed, Oct 16, 2019 at 11:45 AM Michael Kacher  wrote:

> Hi Richard,
> The following steps have been successful in building v3.7.13.5 in my 18.04
> docker. Give this a shot.
>
> -Mike
>
> $ pip install pybombs
> $ pybombs auto-config
> $ pybombs recipes add-defaults
> $ pybombs config --package gnuradio gitrev v3.7.13.5
> $ pybombs config --package uhd gitrev v3.14.1.0
> $ pybombs prefix init -a {MyAlias} {MyPrefixPath}
> $ pybombs config --package uhd forcebuild true
> $ pybombs install gnuradio37
>
> On Wed, Oct 16, 2019 at 2:22 PM Chris Kuethe 
> wrote:
>
>> On the upside, this is fantastic opportunity to figure out a
>> framework/process for the 3.8-3.9 upgrade.
>>
>> On Wed, Oct 16, 2019, 11:18 Martin Braun  wrote:
>>
>>> Hey Richard,
>>>
>>> PyBOMBS is having a hard time dealing with 3.7 vs. 3.8. Use the PyBOMBS
>>> master branch for any hope of it working.
>>>
>>> -- M
>>>
>>> On Tue, Oct 15, 2019 at 5:00 PM Richard Bell 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm using pybombs to install gnuradio 3.7.13.5 onto ubuntu 18.04.
>>>> Pybombs seems to be unable to install dependencies anymore. Each time I run
>>>>
>>>> pybombs prefix init ~/Documents/gnuradio/gr37 -a gr37 -R
>>>> gnuradio-default
>>>>
>>>> it goes for a while until it finds software that is missing and errors
>>>> out. I then manually install the software and rerun the above command. I've
>>>> had to do this for several dependencies now, including:
>>>>
>>>> mako, cppunit, pyqt4, cheetah, thrift, numpy and more.
>>>>
>>>> Did something change recently that broke pybombs? About a year ago I
>>>> was using it without much problem, it installed everything for me.
>>>>
>>>> v/r,
>>>>
>>>> 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
>>>
>> ___
>> 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] Anaconda Python and GR

[Richard Bell]

I'm having trouble with a gnuradio install. It built successfully, but I
can't import gnuradio in python. I believe it is because I'm using anaconda
python.

My group has a linux setup script we run to configure software on fresh
ubuntu installs. I ran this script and now when I type 'which python' I get:

/opt/anaconda3/bin/python

instead of the standard

/usr/bin/python

Is there a way I can overcome this by modifying the setup_env.sh script, or
does it require a special gnuradio compile? Do you think this is even the
problem? I'm not sure how to debug from here.

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

[Discuss-gnuradio] Pybombs broken?

[Richard Bell]

Hello,

I'm using pybombs to install gnuradio 3.7.13.5 onto ubuntu 18.04. Pybombs
seems to be unable to install dependencies anymore. Each time I run

pybombs prefix init ~/Documents/gnuradio/gr37 -a gr37 -R gnuradio-default

it goes for a while until it finds software that is missing and errors out.
I then manually install the software and rerun the above command. I've had
to do this for several dependencies now, including:

mako, cppunit, pyqt4, cheetah, thrift, numpy and more.

Did something change recently that broke pybombs? About a year ago I was
using it without much problem, it installed everything for me.

v/r,

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

[Discuss-gnuradio] Multiple Installs using Pybombs

[Richard Bell]

Hello list,

I'm trying to get gnuradio 3.7 and gnuradio 3.8 installed side by side on
my ubuntu18.04 virtual box. I think I'm missing a command because I'm
having trouble with this.

I start by installing the 3.7 version as:
pybombs config --package gnuradio gitrev v3.7.13.5
pybombs prefix init /home/rbell/Documents/gnuradio/gr37 -a gr37 -R
gnuradio-default

(note: pybombs fails at installing all required packages, I have to install
cppunit manually and then it makes it through)

Then I try installing the 3.8 version as:
pybombs config --package gnuradio gitrev v3.8.0.0
  pybombs prefix init /home/rbell/Documents/gnuradio/gr38 -a gr38 -R
gnuradio-default

Pybombs has some trouble installing required dependencies again at this
point, the configuration fails. I see from the terminal output swift is
missing, so I try installing it using

pybombs install apache-thrift

but I noticed that this package was installed to my gr37 prefix directory
instead of the gr38 one. How do I fix this?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs or PyGTK problem?

[Richard Bell]

Ok you're probably right, it's something at the Cmake level that's broken.
Thanks for the feedback.

On Mon, Sep 18, 2017 at 5:21 PM, Cinaed Simson <cinaed.sim...@gmail.com>
wrote:

> Okay, but just to be clear, I don't have python-gtk installed - only
> python-gtk2-dev.
>
> The dev version basically gives you the include files - which may be
> needed if you're building from source.
>
> Try
>
>   apt-get remove python-gtk
>   apt-get install python-gtk2-dev
>
> And then see if you can re-install python-gtk after you have rebuilt
> gnuradio.
>
> Then blow away the build directory - or move it and create a new build
> directory.
>
> In short, if cmake gets wedged you'll most likely never unwedge it - it
> typically has to be reconfigured - and the easy way to do that is blow
> away or move the build directory and start over.
>
> I don't know how to use pybombs, but if all else fails,  I would rename
> the current gnuradio to save it and re-install scratch.
>
> -- Cinaed
>
>
> On 09/18/2017 11:22 AM, Richard Bell wrote:
> > Yeah I've done that multiple times trying to debug it. gtk2 vs gtk2-dev
> > didn't make any difference when it came to gtk being found.
> >
> > On Sat, Sep 16, 2017 at 1:31 PM, Cinaed Simson <cinaed.sim...@gmail.com
> > <mailto:cinaed.sim...@gmail.com>> wrote:
> >
> > On 09/15/2017 09:07 AM, Richard Bell wrote:
> > > Hello all,
> > >
> > > I'm having a ridiculously annoying problem with either PyBOMBS or
> PyGTK
> > > right now. It prevents me from getting new prefixes of GNU Radio
> installed.
> > >
> > > I'm using Ubuntu 16.04 on VBox and I have a working version of GNU
> Radio
> > > already installed via PyBOMBS. I wanted to install a new prefix so
> I ran:
> > >
> > > pybombs -vv prefix init grcon/ -a grcon -R gnuradio-default
> > >
> > > I cannot get passed the installer thinking PyGTK is not installed,
> even
> > > though I have a version of GNU Radio working on this machine. I
> can't
> > > tell if PyGTK2 is supposed to cover the PyGTK dependecy either.
> From
> > > what I've been reading online I think it should, but I don't know
> for sure.
> > >
> > >
> > > Inline image 1
> > >
> > >
> > > Inline image 2
> > >
> > > I've tried installing pygtk using pip, but I get this error
> > >
> > >
> > > Inline image 2
> > >
> > > This is why I can't tell where the problem lies, with PyBOMBS or
> with
> > > PyGTK? How could I have a working install of GNU Radio without
> PyGTK?
> > > Any help is appreciated.
> >
> > Try
> >
> >   apt-get install python-gtk2-dev
> >
> > -- Cinaed
> >
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > <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] Pybombs or PyGTK problem?

[Richard Bell]

Yeah I've done that multiple times trying to debug it. gtk2 vs gtk2-dev
didn't make any difference when it came to gtk being found.

On Sat, Sep 16, 2017 at 1:31 PM, Cinaed Simson <cinaed.sim...@gmail.com>
wrote:

> On 09/15/2017 09:07 AM, Richard Bell wrote:
> > Hello all,
> >
> > I'm having a ridiculously annoying problem with either PyBOMBS or PyGTK
> > right now. It prevents me from getting new prefixes of GNU Radio
> installed.
> >
> > I'm using Ubuntu 16.04 on VBox and I have a working version of GNU Radio
> > already installed via PyBOMBS. I wanted to install a new prefix so I ran:
> >
> > pybombs -vv prefix init grcon/ -a grcon -R gnuradio-default
> >
> > I cannot get passed the installer thinking PyGTK is not installed, even
> > though I have a version of GNU Radio working on this machine. I can't
> > tell if PyGTK2 is supposed to cover the PyGTK dependecy either. From
> > what I've been reading online I think it should, but I don't know for
> sure.
> >
> >
> > Inline image 1
> >
> >
> > Inline image 2
> >
> > I've tried installing pygtk using pip, but I get this error
> >
> >
> > Inline image 2
> >
> > This is why I can't tell where the problem lies, with PyBOMBS or with
> > PyGTK? How could I have a working install of GNU Radio without PyGTK?
> > Any help is appreciated.
>
> Try
>
>   apt-get install python-gtk2-dev
>
> -- Cinaed
>
> >
> >
> > ___
> > 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] Autogenerate Code Function

[Richard Bell]

Hi all,

I am in a situation where I have a grc flowgraph set to 'NoGUI' mode with
no GUI blocks. I use this to auto-generate python code that is then called
by other python code.

One of the machines I'm working on does support GUIs, everything is through
the terminal, so I can't open grc files. I would like to know how I
programmatically call the 'Generate Code' button via the terminal or via a
python script so I can auto-generate the python code from the NoGUI grc
file. How would I do this?

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

[Discuss-gnuradio] ieee80211 Packet Header Question

[Richard Bell]

Hello,

I'm looking at the ieee 802-11 OOT from cgran to try and duplicate the
custom packet header creation done there. I'm wondering how the
signal_field "block" (it's not a block, it's just a class I think) was
made. Is it a 'noblock', or is it something else?  I'm not sure because
there are impl.cc and impl.h files, which do not get created by default
when a 'noblock' is made.

Thanks for any help,
Rich
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs Install Issue

[Richard Bell]

Thanks Marcus. I confused gtk with gtk2. I can't import gtk through python
so I must not have it. I'll look into it more.

Rich

On Fri, Mar 10, 2017 at 1:51 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Cinaed, Hi Rich,
>
> I think we do support gnuradio-runtime with Python 2.5; back in the GNU
> Radio 3.3 days it was the only viable Python there was; you still can do
> some things with it (Redhat 6, if I remember correctly, still ships with
> Python 2.5), but most of the Python things in GR need 2.7, I think.
>
> Anyway, I'd assume you're probably breaking a lot of things if you're
> installing Python 2.5 on a modern Linux; however, I don't really see
> Python 2.5 happening in Rich's output.
>
> On my machine (Fedora), there's no pygtk2 python module, only pygtk. The
> check that I'd do here is in fact a different one:
> What does
>
> import gtk
> print gtk.pygtk_version
>
> say? That's what the build infrastructure checks.
>
> Cheers,
>
> Marcus
>
>
> On 03/10/2017 10:33 AM, Cinaed Simson wrote:
> > You're running Ubuntu 16 but you're using python 2.5?
> >
> > I didn't even think gnuradio was supported under python 2.5 - I thought
> > it was just versions 2.6 and 2.7.
> >
> > pygtk is probably installed under python2.7.
> >
> > Start an instance of python2.7 and the type
> >
> >   import pygtk2
> >
> > and see if it works.
> >
> > -- Cinaed
> >
> >
> >
> > On 03/09/2017 11:52 AM, Richard Bell wrote:
> >> Hello all,
> >>
> >> I'm attempting to use Pybombs to install gnuradio onto a Ubuntu 16.04
> >> virtualbox image I was given by someone else. The problem is that pygtk2
> >> is installed as verified by apt-get, but Pybombs cannot find it, as
> >> given by the below output. The image did not have any form of GNU Radio
> >> installed prior, it only had Jupyter and packages related to TensorFlow
> >> installed. How should I fix this problem?
> >>
> >> -- Configuring gr-blocks support...
> >> --   Dependency Boost_FOUND = 1
> >> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> >> --   Enabling gr-blocks support.
> >> --   Override with -DENABLE_GR_BLOCKS=ON/OFF
> >> --
> >> -- Python checking for python >= 2.5
> >> -- Python checking for python >= 2.5 - found
> >> --
> >> -- Python checking for Cheetah >= 2.0.0
> >> -- Python checking for Cheetah >= 2.0.0 - found
> >> --
> >> -- Python checking for lxml >= 1.3.6
> >> -- Python checking for lxml >= 1.3.6 - found
> >> --
> >> -- Python checking for pygtk >= 2.10.0
> >> -- Python checking for pygtk >= 2.10.0 - not found
> >> --
> >> -- Python checking for numpy
> >> -- Python checking for numpy - found
> >> --
> >> -- Configuring gnuradio-companion support...
> >> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> >> --   Dependency ENABLE_PYTHON = ON
> >> --   Dependency PYTHON_MIN_VER_FOUND = TRUE
> >> --   Dependency CHEETAH_FOUND = TRUE
> >> --   Dependency LXML_FOUND = TRUE
> >> --   Dependency PYGTK_FOUND = FALSE
> >> --   Dependency NUMPY_FOUND = TRUE
> >> CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
> >>   user force-enabled gnuradio-companion but configuration checked failed
> >> Call Stack (most recent call first):
> >>   grc/CMakeLists.txt:45 (GR_REGISTER_COMPONENT)
> >>
> >> -- Configuring incomplete, errors occurred!
> >> See also
> >> "/home/guest/Documents/prefix/src/gnuradio/build/CMakeFiles/
> CMakeOutput.log".
> >> See also
> >> "/home/guest/Documents/prefix/src/gnuradio/build/CMakeFiles/
> CMakeError.log".
> >> PyBOMBS.Packager.source - ERROR - Configuration failed after running at
> >> least twice.
> >> PyBOMBS.Packager.source - ERROR - Problem occurred while building
> >> package gnuradio:
> >> Configuration failed
> >> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> >> Aborting.
> >> guest@guest-VirtualBox:~$
> >>
> >>
> >> ___
> >> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Pybombs Install Issue

[Richard Bell]

Hello all,

I'm attempting to use Pybombs to install gnuradio onto a Ubuntu 16.04
virtualbox image I was given by someone else. The problem is that pygtk2 is
installed as verified by apt-get, but Pybombs cannot find it, as given by
the below output. The image did not have any form of GNU Radio installed
prior, it only had Jupyter and packages related to TensorFlow installed.
How should I fix this problem?

-- Configuring gr-blocks support...
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Enabling gr-blocks support.
--   Override with -DENABLE_GR_BLOCKS=ON/OFF
-- 
-- Python checking for python >= 2.5
-- Python checking for python >= 2.5 - found
-- 
-- Python checking for Cheetah >= 2.0.0
-- Python checking for Cheetah >= 2.0.0 - found
-- 
-- Python checking for lxml >= 1.3.6
-- Python checking for lxml >= 1.3.6 - found
-- 
-- Python checking for pygtk >= 2.10.0
-- Python checking for pygtk >= 2.10.0 - not found
-- 
-- Python checking for numpy
-- Python checking for numpy - found
-- 
-- Configuring gnuradio-companion support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency PYTHON_MIN_VER_FOUND = TRUE
--   Dependency CHEETAH_FOUND = TRUE
--   Dependency LXML_FOUND = TRUE
--   Dependency PYGTK_FOUND = FALSE
--   Dependency NUMPY_FOUND = TRUE
CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
  user force-enabled gnuradio-companion but configuration checked failed
Call Stack (most recent call first):
  grc/CMakeLists.txt:45 (GR_REGISTER_COMPONENT)

-- Configuring incomplete, errors occurred!
See also
"/home/guest/Documents/prefix/src/gnuradio/build/CMakeFiles/CMakeOutput.log".
See also
"/home/guest/Documents/prefix/src/gnuradio/build/CMakeFiles/CMakeError.log".
PyBOMBS.Packager.source - ERROR - Configuration failed after running at
least twice.
PyBOMBS.Packager.source - ERROR - Problem occurred while building package
gnuradio:
Configuration failed
PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
Aborting.
guest@guest-VirtualBox:~$
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calculating additive noise power for known signal

[Richard Bell]

Great answer. I wish I could upvote it! There should be a GNU Radio Stack
Exchange type thing.

Rich

On Tue, Aug 23, 2016 at 3:07 PM, Andy Walls 
wrote:

> On Tue, 2016-08-23 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Message: 7
> > Date: Mon, 22 Aug 2016 18:14:29 -0700 (MST)
> > From: Paul Creaser 
> >
> > I've just started studying methods used to detect and then filter
> out/remove
> > cyclic noise from known signals.
> >
> > I have a signal of 256 samples which repeats itself. I take this signal,
> > attenuate it and add noise at a specific band (frequency band), for
> example
> > 50 Hz Sine Wave. In the simplest case this is none varying. However in
> the
> > future it will vary slowly over time.
>
> I'm not quite sure what you mean by "cyclic noise", but the example you
> give is 50 Hz (or 60 Hz) hum, so a narrowband interference.
>
>
> > What I would like to do is find the power level of the additive cyclic
> noise
> > (, which should be the difference between the two signals) and where in
> the
> > frequency spectrum this noise exists. Using this information, I would
> hope
> > to use weighting to recover the original signal.
>
> If the noise is always out of the channel of your signal of interest,
> then a bandpass filter will do the job and your done.
>
> If the noise is in the channel of your signal of interest, then it
> sounds like what you really want in the end is an adaptive equalizer or
> filter.
>
> If you're not afraid of a lot of work:
> Just dive into implementing a Least Mean Squares (LMS) adaptive
> filter.
>
> You can either make it Data-Aided (DA), adapting the filter when it
> detects and operates on a known preamble; or Decision Directed (DD),
> adapting the filter every time it makes a decision about what a data bit
> should be.
>
> I prefer using a Data-Aided LMS adaptive filter, as I often work with
> signals that have known preambles.
>
> Such a system would look something like:
>
> received samples source -> channel filter -> automatic gain control ->
> correlator to detect and mark the preamble -> LMS DA adaptive filter
> -> ...
>
> Translating that to example GNURadio blocks:
>
> USRP Source -> Freq Xlating FIR Filter -> Feed Forward AGC ->
> Correlation Estimator -> (Your custom LMS DA filter block) -> ...
>
>
> > *Steps*
> >
> > 1 I take the original and modified signal and rescale the modified
> signal to
> > match the original.
> >
> > At the moment I use a very naive approach which is to take the absolute
> sum
> > of the 256 samples for both signals and from this calculate a simple
> scale
> > factor. I think this should be OK where I have narrow band noise, but it
> may
> > fail badly in other cases where the noise levels are high.
> >
> > 2 Next I take the FFT of the two signals (256 samples).
> >
> > 3 Calculate the noise
> >
> > Using the difference between the FFTs, I then calculate the noise power.
> >
> > *Two questions?*
> >
> > 1 The rescaling method is very basic, using absolute accumulated sums.
> Does
> > GNU radio have any blocks, which could perform this auto-scaling more
> > effectively?
>
> GNURadio has several AGC blocks.  They all have their quirks.  Pick one
> an try to make it work.
>
>
> > 2 Using the basic difference between the FFT's, such as the absolute
> > magnitude difference, should provide a starting point for calculating the
> > noise power. Again is this naive?
>
> Noise power and noise density have specific meanings which I don't think
> match what you're thinking about here.  AFAICT, you want to know the
> power of an in-channel narrowband interference (so that you can
> ultimately filter it out).
>
> Looking at FFT's will give you a feel for the situation, but it's kind
> of a blunt instrument, if you plan of filtering by direct FFT bin
> scaling or excision.
>
> It really sounds like what you want is an adaptive equalizer (aka
> adaptive filter).
>
> There's lots of existing literature on equalizers.
> This lecture is still a little too advanced for most folks, but it has
> the basic concepts covered clearer than most others I could find on
> Google:
> http://www.eecg.toronto.edu/~johns/nobots/courses/ece1392/
> equalization2.pdf
>
>
> Section 14.6 of this book describes the LMS algorithm:
> https://www.amazon.com/Mathematical-Methods-Algorithms-Signal-Processing/
> dp/0201361868
>
> And here is a PDF copy I spotted on the internet (click at your own
> risk):
> https://www.u-cursos.cl/usuario/834c0e46b93fd72fd8408c492af56f
> 8d/mi_blog/r/4%29_Todd_Moon_Mathematical_Methods_and_
> Algorithms_for_Signal_Processing.pdf
>
> -Andy
>
>
>
> ___
> 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] Input Selector

[Richard Bell]

Hello,

I need to let the user select which input stream to transmit by pushing a
button on the GUI. By default, the transmitter transmits random data until
the user clicks the button, at which point a file is transmitted.

It is important that the entire file be transmitted, from the beginning.
This means that the file data stream can't be dropped to the floor until
the user clicks the button, it must apply back pressure from the selector
block to the file source block until the user presses the button.

The selector block uses a null sink for each stream that isn't connected to
the output, so I loose the ability to send the file from the beginning. In
addition, the selector is causing the flowgraph to close with return code
-11 and no other message.

Does someone have an idea of how I could do this using GRC?

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

Re: [Discuss-gnuradio] Pending feature freeze for GNU Radio Release v3.7.10

[Richard Bell]

Excellent news. Does this branch include Toms fix for tags through rate
change blocks?

On Wed, Jun 22, 2016 at 10:14 AM, West, Nathan 
wrote:

> Hi all,
>
> I want to give a heads up that we're actively planning the v3.7.10 release
> of GNU Radio for a couple of weeks from now. We'll go in to a feature
> freeze within a few days. If you have work you want in the release please
> wrap it up and submit PRs or at least let us know about it.
>
> Related, the big merge coming in is a new "packet3" branch that's
> available from the gnuradio.org git remote as well as the Github mirror.
> This branch has a pretty hefty overhaul of packetized modem work from Tom.
> If you have vested interests in that please review and test that branch.
>
> That's all for now. Cheers,
> Nathan
>
> ___
> 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] GRCon 16 Latex Files

[Richard Bell]

The website that should have the Latex template files for paper submission
is broken,
http://gnuradio.org/grcon-2016/papers/

If this cannot be quickly fixed, would someone send out the template files
to the mailing list please?

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

Re: [Discuss-gnuradio] Retune Request Time

[Richard Bell]

I think I have a misunderstanding about the DSP tune, because it's not
behaving the way I expect it to. Let me describe my experiment. Suppose I
want to hop between two frequencies, 900e6 and 901e6, using a sample rate
of 500e3 and a usrp as a sink (transmitter).

1) If I use set_center_freq(900e6) and set_center_freq(901e6) in a loop to
hop between the two frequencies, it works just as you would expect. I
verified this by using a second USRP as a spectrum analyzer.

2) Now, If I use the following to make the same hop, I see a strong static
tone coming out at 900e6, and a small baby tone popping up and down at
901e6. The baby tones are about 40 dB down from the static tone. There are
also even smaller image tones popping up and down at the hop rate around
901e6.

tr = uhd.tune_request(900e6, 1e6)
successful_hop = tb.usrp.set_center_freq(tr)

and then on the next iteration

tr = uhd.tune_request(900e6, 0)
successful_hop = tb.usrp.set_center_freq(tr)

I'm expecting to see the exact same behavior as I did when using
set_center_freq in the first approach above, but I'm not. Am I
understanding the dsp_tune incorrectly?

Rich


On Tue, Jun 14, 2016 at 1:20 PM, Marcus D. Leech <mle...@ripnet.com> wrote:

> On 06/14/2016 03:13 PM, Richard Bell wrote:
>
> Martin,
>
> If I create a USRP object
>
> self.usrp = uhd.usrp_sink(device_addr=options.args,
> stream_args=uhd.stream_args('fc32'))
>
> and initialize the USRP center frequency to 900e6
>
> self.usrp.set_center_freq(900e6)
>
> and then do
>
> tr = uhd.tune_request(901e6, 1e3)
>
> followed by
>
> uhd.usrp_sink.get_center_freq()
>
> it returns the original center freq of 900e6. My question is what is the
> tune_request doing?
>
> Rich
>
> uhd.tune_request() is just a constructor for a tune_request_t object, it
> doesn't actually touch the hardware at all.  So, you take that tr, and
>   hand it to a uhd.usrp_sink.set_center_freq(tr).
>
>
>
>
> On Mon, Jun 13, 2016 at 4:47 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I can call the C++ functions from Python? Why is there a separate python
>> API, I'm confused.
>>
>> Lets say I set an initial center frequency of 900 MHz to start the script
>> off. You're saying that if the next frequency I want to hop to is within
>> the ADC sampling rate, which in my case for the N210 is 100 MHz, I should
>> manually tell the USRP to set the DSP_FREQ and leave the RF_FREQ alone for
>> the fastest hop, and that the USRP automatic settings are not smart enough
>> to figure this out?
>>
>> If the above is true, it seems I should do something like this:
>> 1) Ask the USRP what the current RF_FREQ is
>> 2) Find the difference between RF_FREQ and the new center freq
>> 3) If the difference is greater then 100 MHz, change the RF Freq,
>> otherwise change the DSP freq
>>
>> Is this correct?
>>
>> On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun <martin.br...@ettus.com>
>> wrote:
>>
>>> Richard,
>>>
>>> "use DSP tuning when possible" is not a valid policy.
>>>
>>> In Python:
>>>
>>> from gnuradio import uhd
>>>
>>> rf_freq = 900e6
>>> dsp_freq = 1e3
>>> TR = uhd.tune_request(rf_freq, dsp_freq)
>>> # Oh look it worked:
>>> print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
>>>
>>>
>>> So, in a nutshell, rf_freq and dsp_freq are used depending on the
>>> respective policies, but there's no 'figure out smart tunes based on
>>> state' policy.
>>>
>>> -- M
>>>
>>>
>>> On 06/13/2016 03:49 PM, Richard Bell wrote:
>>> > Derek,
>>> >
>>> > that manual is the C++ API. How would I format the tune policy
>>> > information in python? It's not clear to me looking at the C++ API and
>>> > the Python API for the set_center_freq python function. Could you give
>>> > an example of how you would call
>>> >
>>> > C++: http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>>> > Python:
>>> >
>>> http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink
>>> >
>>> > set_center_freq(center_freq, )
>>> >
>>> > What goes in place of the careted argument?
>>> >
>>> > Rich
>>> >
>>> > On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel <derek.ko...@ettus.com
>>> > <mailto:derek.ko...@ettus.com>> wrote:
>>> >
>>> > Hi Rich,
>>> >
>>> > You can create and pass a tune_r

Re: [Discuss-gnuradio] Retune Request Time

[Richard Bell]

Martin and Derek,

Thank you. That is much more clear to me now.

Rich

On Tue, Jun 14, 2016 at 1:19 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> On 06/13/2016 04:47 PM, Richard Bell wrote:
> > I can call the C++ functions from Python? Why is there a separate python
> > API, I'm confused.
>
> It's the same API, SWIG exposes that to Python.
>
> > Lets say I set an initial center frequency of 900 MHz to start the
> > script off. You're saying that if the next frequency I want to hop to is
> > within the ADC sampling rate, which in my case for the N210 is 100 MHz,
> > I should manually tell the USRP to set the DSP_FREQ and leave the
> > RF_FREQ alone for the fastest hop, and that the USRP automatic settings
> > are not smart enough to figure this out?
>
> What I'm saying is, there are no automatic settings other than fixing
> the limited accuracy of the RF frequency using the DSP.
> The tune logic is mostly stateless (with the exception of the
> calibrations on the AD9361-based devices).
>
> > If the above is true, it seems I should do something like this:
> > 1) Ask the USRP what the current RF_FREQ is
> > 2) Find the difference between RF_FREQ and the new center freq
> > 3) If the difference is greater then 100 MHz, change the RF Freq,
> > otherwise change the DSP freq
> >
> > Is this correct?
>
> Yup.
>
> M
>
> >
> > On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > Richard,
> >
> > "use DSP tuning when possible" is not a valid policy.
> >
> > In Python:
> >
> > from gnuradio import uhd
> >
> > rf_freq = 900e6
> > dsp_freq = 1e3
> > TR = uhd.tune_request(rf_freq, dsp_freq)
> > # Oh look it worked:
> > print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
> >
> >
> > So, in a nutshell, rf_freq and dsp_freq are used depending on the
> > respective policies, but there's no 'figure out smart tunes based on
> > state' policy.
> >
> > -- M
> >
> >
> > On 06/13/2016 03:49 PM, Richard Bell wrote:
> > > Derek,
> > >
> > > that manual is the C++ API. How would I format the tune policy
> > > information in python? It's not clear to me looking at the C++ API
> and
> > > the Python API for the set_center_freq python function. Could you
> give
> > > an example of how you would call
> > >
> > > C++:
> http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
> > > Python:
> > >
> http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink
> > >
> > > set_center_freq(center_freq, )
> > >
> > > What goes in place of the careted argument?
> > >
> > > Rich
> > >
> > > On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel <
> derek.ko...@ettus.com <mailto:derek.ko...@ettus.com>
> > > <mailto:derek.ko...@ettus.com <mailto:derek.ko...@ettus.com>>>
> wrote:
> > >
> > > Hi Rich,
> > >
> > > You can create and pass a tune_request_t into the set
> frequency call
> > > of a USRP object. This gives you control of how it tunes. By
> default
> > > it does not optimize for speed to my knowledge.
> > >
> http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
> > >
> > > Depending on what USRP you are using there are self calibration
> > > thresholds which will cause a retune to incur a delay when
> tuning
> > > outside of a certain range. On the B200 for instance this
> range is
> > > 100MHz.
> > >
> > > Regards,
> > > Derek
> > >
> > > On Mon, Jun 13, 2016 at 3:05 PM, Richard Bell
> > > <richard.be...@gmail.com <mailto:richard.be...@gmail.com>
> > <mailto:richard.be...@gmail.com <mailto:richard.be...@gmail.com>>>
> > wrote:
> > >
> > > I am using set_center_freq(center_freq) in my python
> script to
> > > retune my USRP to various center frequencies. Does this
> command
> > > use the smartest retune technique to get to the new
> frequency?
> > >
> > > For example, if I want to retune from 900.000

Re: [Discuss-gnuradio] Retune Request Time

[Richard Bell]

Martin,

If I create a USRP object

self.usrp = uhd.usrp_sink(device_addr=options.args,
stream_args=uhd.stream_args('fc32'))

and initialize the USRP center frequency to 900e6

self.usrp.set_center_freq(900e6)

and then do

tr = uhd.tune_request(901e6, 1e3)

followed by

uhd.usrp_sink.get_center_freq()

it returns the original center freq of 900e6. My question is what is the
tune_request doing?

Rich

On Mon, Jun 13, 2016 at 4:47 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> I can call the C++ functions from Python? Why is there a separate python
> API, I'm confused.
>
> Lets say I set an initial center frequency of 900 MHz to start the script
> off. You're saying that if the next frequency I want to hop to is within
> the ADC sampling rate, which in my case for the N210 is 100 MHz, I should
> manually tell the USRP to set the DSP_FREQ and leave the RF_FREQ alone for
> the fastest hop, and that the USRP automatic settings are not smart enough
> to figure this out?
>
> If the above is true, it seems I should do something like this:
> 1) Ask the USRP what the current RF_FREQ is
> 2) Find the difference between RF_FREQ and the new center freq
> 3) If the difference is greater then 100 MHz, change the RF Freq,
> otherwise change the DSP freq
>
> Is this correct?
>
> On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun <martin.br...@ettus.com>
> wrote:
>
>> Richard,
>>
>> "use DSP tuning when possible" is not a valid policy.
>>
>> In Python:
>>
>> from gnuradio import uhd
>>
>> rf_freq = 900e6
>> dsp_freq = 1e3
>> TR = uhd.tune_request(rf_freq, dsp_freq)
>> # Oh look it worked:
>> print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
>>
>>
>> So, in a nutshell, rf_freq and dsp_freq are used depending on the
>> respective policies, but there's no 'figure out smart tunes based on
>> state' policy.
>>
>> -- M
>>
>>
>> On 06/13/2016 03:49 PM, Richard Bell wrote:
>> > Derek,
>> >
>> > that manual is the C++ API. How would I format the tune policy
>> > information in python? It's not clear to me looking at the C++ API and
>> > the Python API for the set_center_freq python function. Could you give
>> > an example of how you would call
>> >
>> > C++: http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>> > Python:
>> >
>> http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink
>> >
>> > set_center_freq(center_freq, )
>> >
>> > What goes in place of the careted argument?
>> >
>> > Rich
>> >
>> > On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel <derek.ko...@ettus.com
>> > <mailto:derek.ko...@ettus.com>> wrote:
>> >
>> > Hi Rich,
>> >
>> > You can create and pass a tune_request_t into the set frequency call
>> > of a USRP object. This gives you control of how it tunes. By default
>> > it does not optimize for speed to my knowledge.
>> > http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>> >
>> > Depending on what USRP you are using there are self calibration
>> > thresholds which will cause a retune to incur a delay when tuning
>> > outside of a certain range. On the B200 for instance this range is
>> > 100MHz.
>> >
>> > Regards,
>> > Derek
>> >
>> > On Mon, Jun 13, 2016 at 3:05 PM, Richard Bell
>> > <richard.be...@gmail.com <mailto:richard.be...@gmail.com>> wrote:
>> >
>> > I am using set_center_freq(center_freq) in my python script to
>> > retune my USRP to various center frequencies. Does this command
>> > use the smartest retune technique to get to the new frequency?
>> >
>> > For example, if I want to retune from 900.000 MHz to 900.001 MHz
>> > ( a 1 kHz change), will it use DSP tuning instead of RF tuning
>> > for speed? Is there a way to control this through python?
>> >
>> > In my testing, it seems the retune time is constant whether I
>> > make a 1 GHz hop, a 3 MHz hop or a 1 kHz hop, which makes me
>> > think I'm overlooking something.
>> >
>> > Thanks,
>> > Rich
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org <mailto: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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Retune Request Time

[Richard Bell]

I can call the C++ functions from Python? Why is there a separate python
API, I'm confused.

Lets say I set an initial center frequency of 900 MHz to start the script
off. You're saying that if the next frequency I want to hop to is within
the ADC sampling rate, which in my case for the N210 is 100 MHz, I should
manually tell the USRP to set the DSP_FREQ and leave the RF_FREQ alone for
the fastest hop, and that the USRP automatic settings are not smart enough
to figure this out?

If the above is true, it seems I should do something like this:
1) Ask the USRP what the current RF_FREQ is
2) Find the difference between RF_FREQ and the new center freq
3) If the difference is greater then 100 MHz, change the RF Freq, otherwise
change the DSP freq

Is this correct?

On Mon, Jun 13, 2016 at 4:03 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> Richard,
>
> "use DSP tuning when possible" is not a valid policy.
>
> In Python:
>
> from gnuradio import uhd
>
> rf_freq = 900e6
> dsp_freq = 1e3
> TR = uhd.tune_request(rf_freq, dsp_freq)
> # Oh look it worked:
> print TR.rf_freq_policy == uhd.tune_request.POLICY_MANUAL
>
>
> So, in a nutshell, rf_freq and dsp_freq are used depending on the
> respective policies, but there's no 'figure out smart tunes based on
> state' policy.
>
> -- M
>
>
> On 06/13/2016 03:49 PM, Richard Bell wrote:
> > Derek,
> >
> > that manual is the C++ API. How would I format the tune policy
> > information in python? It's not clear to me looking at the C++ API and
> > the Python API for the set_center_freq python function. Could you give
> > an example of how you would call
> >
> > C++: http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
> > Python:
> >
> http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink
> >
> > set_center_freq(center_freq, )
> >
> > What goes in place of the careted argument?
> >
> > Rich
> >
> > On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel <derek.ko...@ettus.com
> > <mailto:derek.ko...@ettus.com>> wrote:
> >
> > Hi Rich,
> >
> > You can create and pass a tune_request_t into the set frequency call
> > of a USRP object. This gives you control of how it tunes. By default
> > it does not optimize for speed to my knowledge.
> > http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
> >
> > Depending on what USRP you are using there are self calibration
> > thresholds which will cause a retune to incur a delay when tuning
> > outside of a certain range. On the B200 for instance this range is
> > 100MHz.
> >
> > Regards,
> > Derek
> >
> > On Mon, Jun 13, 2016 at 3:05 PM, Richard Bell
> > <richard.be...@gmail.com <mailto:richard.be...@gmail.com>> wrote:
> >
> > I am using set_center_freq(center_freq) in my python script to
> > retune my USRP to various center frequencies. Does this command
> > use the smartest retune technique to get to the new frequency?
> >
> > For example, if I want to retune from 900.000 MHz to 900.001 MHz
> > ( a 1 kHz change), will it use DSP tuning instead of RF tuning
> > for speed? Is there a way to control this through python?
> >
> > In my testing, it seems the retune time is constant whether I
> > make a 1 GHz hop, a 3 MHz hop or a 1 kHz hop, which makes me
> > think I'm overlooking something.
> >
> > Thanks,
> > Rich
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto: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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Retune Request Time

[Richard Bell]

Derek,

that manual is the C++ API. How would I format the tune policy information
in python? It's not clear to me looking at the C++ API and the Python API
for the set_center_freq python function. Could you give an example of how
you would call

C++: http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
Python:
http://www.gnuradio.org/doc/sphinx/uhd_blocks.html#gnuradio.uhd.usrp_sink

set_center_freq(center_freq, )

What goes in place of the careted argument?

Rich

On Mon, Jun 13, 2016 at 3:31 PM, Derek Kozel <derek.ko...@ettus.com> wrote:

> Hi Rich,
>
> You can create and pass a tune_request_t into the set frequency call of a
> USRP object. This gives you control of how it tunes. By default it does not
> optimize for speed to my knowledge.
> http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
>
> Depending on what USRP you are using there are self calibration thresholds
> which will cause a retune to incur a delay when tuning outside of a certain
> range. On the B200 for instance this range is 100MHz.
>
> Regards,
> Derek
>
> On Mon, Jun 13, 2016 at 3:05 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I am using set_center_freq(center_freq) in my python script to retune my
>> USRP to various center frequencies. Does this command use the smartest
>> retune technique to get to the new frequency?
>>
>> For example, if I want to retune from 900.000 MHz to 900.001 MHz ( a 1
>> kHz change), will it use DSP tuning instead of RF tuning for speed? Is
>> there a way to control this through python?
>>
>> In my testing, it seems the retune time is constant whether I make a 1
>> GHz hop, a 3 MHz hop or a 1 kHz hop, which makes me think I'm overlooking
>> something.
>>
>> 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

[Discuss-gnuradio] Retune Request Time

[Richard Bell]

I am using set_center_freq(center_freq) in my python script to retune my
USRP to various center frequencies. Does this command use the smartest
retune technique to get to the new frequency?

For example, if I want to retune from 900.000 MHz to 900.001 MHz ( a 1 kHz
change), will it use DSP tuning instead of RF tuning for speed? Is there a
way to control this through python?

In my testing, it seems the retune time is constant whether I make a 1 GHz
hop, a 3 MHz hop or a 1 kHz hop, which makes me think I'm overlooking
something.

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

[Discuss-gnuradio] Cause of thread[thread-per-block[89]: std::bad_alloc

[Richard Bell]

Hi all,

I've written a packet alignment block whose purpose is to detect packet
drops and insert garbage items into the stream to keep the known data
stream aligned with the received data stream. I'm testing this with no
hardware in the loop at the moment, full simulation.

After a while of working properly, grc fails and returns:
thread[thread-per-block[89]: ]: std::bad_alloc

I'm not sure what in the packet_align block is causing this. Can it be
caused by me allowing the input buffer to fillup while I'm producing
garbage data and not consuming anything? It was my understanding that in
pure simulation, this would simply backup all the buffers before this block
until the source block simply sits doing nothing until room is available.
Is this correct?

I'm being careful not to dump to the output buffer anything more than
noutput_items worth. It was also my understanding that in pure simulations,
it would be output buffers overflowing that caused this type of error, is
that right?

I'm not sure where to focus my debug efforts on this problem.

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

Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7

[Richard Bell]

Hi Martin,

Yes I did source the setup_env.sh file. I can call gnuradio-companion from
command line and the base install works fine. It's only when compiling OOT
modules that I have issues.

 I have not tried compiling without sudo, I will give it a shot.

Rich

On Mon, Jun 6, 2016 at 10:18 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> Richard,
>
> did you call your setup_env.sh before doing the compile? Also, you can
> run cmake with -Wno-dev to remove some more annoying warnings.
>
> On 06/04/2016 04:40 PM, Richard Bell wrote:
> > Sure no problem. Here is the output when I try to build a brand new or
> > pre-existing OOT module, notice the cmake warnings:
> >
> > rbell@rbell
> :~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
> > cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
> > -- The CXX compiler identification is GNU 5.3.1
> > [...]
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to:
> >
> /home/rbell/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build
>
> Looks like this worked fine.
>
> > rbell@rbell
> :~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
> > sudo make install
>
> You really don't want to 'sudo make' anything unless you really need to.
> Here, you don't, as far as I can tell.
>
> Martin
>
> > Scanning dependencies of target gnuradio-add_tagged_stream_once
> > [  4%] Building CXX object
> >
> lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/add_tagged_stream_once_impl.cc.o
> > [  8%] Linking CXX shared library libgnuradio-add_tagged_stream_once.so
> > /usr/bin/ld: cannot find -lgnuradio-runtime
> > /usr/bin/ld: cannot find -lgnuradio-pmt
> > collect2: error: ld returned 1 exit status
> > lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/build.make:98: recipe
> > for target 'lib/libgnuradio-add_tagged_stream_once.so' failed
> > make[2]: *** [lib/libgnuradio-add_tagged_stream_once.so] Error 1
> > CMakeFiles/Makefile2:137: recipe for target
> > 'lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all' failed
> > make[1]: *** [lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all]
> > Error 2
> > Makefile:138: recipe for target 'all' failed
> > make: *** [all] Error 2
> >
> > On Sat, Jun 4, 2016 at 9:14 AM, Marcus Müller <marcus.muel...@ettus.com
> > <mailto:marcus.muel...@ettus.com>> wrote:
> >
> > Hi Rich,
> >
> > currently unable to access my Ubuntu VMs; could you copy the
> > build log of your OOT? Also, I might be a bit paranoid, but could
> > you verify by "which gr_modtool" that you're really running the
> > modtool you want?
> >
> > Best regards,
> > Marcus
> >
> >
> > On 04.06.2016 17:51, Richard Bell wrote:
> >> Since I didn't get much feedback when I brought this up a few
> >> weeks ago, I want to bring it up again to make sure you all see
> >> it.  After using the default pybombs command to build a clean
> >> install on Ubuntu 16.04, everything worked fine except that I
> >> can't get gr_modtool working. No OOT Modules I make, old or brand
> >> new, will make it through compile. There are cmake issues I've
> >> never seen before.
> >>
> >> Can someone confirm they have used gr_modtool on Ubuntu 16.04
> >> successfully after installing via the pybombs default route.
> >>
> >> Sent from my iPad
> >>
> >> On Jun 3, 2016, at 7:42 PM, Eric Statzer
> >> <<mailto:eric.stat...@gmail.com>eric.stat...@gmail.com
> >> <mailto:eric.stat...@gmail.com>> wrote:
> >>
> >>>
> >>>
> >>> On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller
> >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>
> wrote:
> >>>
> >>>> Everyone should get a kick out of this: I had fixed this
> >>>> once before [1] but it was actually YOU, Marcus, that broke
> >>>> it again! [2]
> >>> I wish that was true! First of all, we need to find a better
> >>> way to fix that then to build libtool on practically all
> >>> platforms from source.
> >>> You really don't need libtool > 2.4.6 to build thrift. Works
> >>> perfectly on my Fedora 22 with libtool 2.4.2 .
> >>> The problem is not the libtool version, 

Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7

[Richard Bell]

erty() called with non-existent target

"/home/rbell/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/python/qa_add_tagged_stream_once.py".
Call Stack (most recent call first):
  python/CMakeLists.txt:44 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to:
/home/rbell/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build


rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
sudo make install
Scanning dependencies of target gnuradio-add_tagged_stream_once
[  4%] Building CXX object
lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/add_tagged_stream_once_impl.cc.o
[  8%] Linking CXX shared library libgnuradio-add_tagged_stream_once.so
/usr/bin/ld: cannot find -lgnuradio-runtime
/usr/bin/ld: cannot find -lgnuradio-pmt
collect2: error: ld returned 1 exit status
lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/build.make:98: recipe
for target 'lib/libgnuradio-add_tagged_stream_once.so' failed
make[2]: *** [lib/libgnuradio-add_tagged_stream_once.so] Error 1
CMakeFiles/Makefile2:137: recipe for target
'lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all] Error
2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

On Sat, Jun 4, 2016 at 9:14 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Rich,
>
> currently unable to access my Ubuntu VMs; could you copy the build
> log of your OOT? Also, I might be a bit paranoid, but could you verify by
> "which gr_modtool" that you're really running the modtool you want?
>
> Best regards,
> Marcus
>
>
> On 04.06.2016 17:51, Richard Bell wrote:
>
> Since I didn't get much feedback when I brought this up a few weeks ago, I
> want to bring it up again to make sure you all see it.  After using the
> default pybombs command to build a clean install on Ubuntu 16.04,
> everything worked fine except that I can't get gr_modtool working. No OOT
> Modules I make, old or brand new, will make it through compile. There are
> cmake issues I've never seen before.
>
> Can someone confirm they have used gr_modtool on Ubuntu 16.04 successfully
> after installing via the pybombs default route.
>
> Sent from my iPad
>
> On Jun 3, 2016, at 7:42 PM, Eric Statzer <eric.stat...@gmail.com> wrote:
>
> <eric.stat...@gmail.com>
>
>
>
> On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Everyone should get a kick out of this: I had fixed this once before [1]
>> but it was actually YOU, Marcus, that broke it again! [2]
>>
>> I wish that was true! First of all, we need to find a better way to fix
>> that then to build libtool on practically all platforms from source.
>> You really don't need libtool > 2.4.6 to build thrift. Works perfectly on
>> my Fedora 22 with libtool 2.4.2 .
>> The problem is not the libtool version, by the way. autoconf/aclocal just
>> can't, for some reasons I really can't figure out, find the "default"
>> system-wide M4 files containing the PKG_CHECK_MODULES macro under specific
>> circumstances. It seems that installing libtool into the same prefix one is
>> going to use later on fixes the problem (as the M4s end up in a location
>> that aclocal ends up looking in). Have a test: if you edit the bootstrap.sh
>> of thrift, and modify the
>>
>> aclocal -I ./aclocal
>>
>> line to
>>
>> aclocal -I $(env -i aclocal --print-ac-dir) -I ./aclocal
>>
>> the M4 syntax error disappears, at least for me. Of course, thrift
>> wouldn't successfully build with those modifications, either, but that's
>> really a long rabbit hole to go into :) Hence my curiosity!
>>
>>
> Alright, its all coming back to me now, I think you've got me straightened
> out again, Marcus.  I was definitely wrong on the pkg-config/libtool
> versions before, thanks for taking my hasty accusations so well!  This is
> the exact same sort of issue that I was running in to when running
> autoreconf for libosmo-dsp and I realized that having ANY version of
> pkg-config installed from source under the PYBOMBS_PREFIX would make these
> sort of errors go away, too.  I'm on-board with leaving the pkg-config and
> libtool versions alone and fixing the real underlying problems.
>
> So, the thrift recipe was switched to using git for the source fetch
> around this time [3] due to a possible thrift bug.  Question: now that
> thrift 0.9.3 is available in tarball form, might we want to switch back to
> using the release tarball?  The benefit of the tarball is that it already

Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7

[Richard Bell]

Since I didn't get much feedback when I brought this up a few weeks ago, I want 
to bring it up again to make sure you all see it.  After using the default 
pybombs command to build a clean install on Ubuntu 16.04, everything worked 
fine except that I can't get gr_modtool working. No OOT Modules I make, old or 
brand new, will make it through compile. There are cmake issues I've never seen 
before.

Can someone confirm they have used gr_modtool on Ubuntu 16.04 successfully 
after installing via the pybombs default route. 

Sent from my iPad

> On Jun 3, 2016, at 7:42 PM, Eric Statzer  wrote:
> 
> 
> 
>> On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller  
>> wrote:
>>> Everyone should get a kick out of this: I had fixed this once before [1] 
>>> but it was actually YOU, Marcus, that broke it again! [2]
>> 
>> I wish that was true! First of all, we need to find a better way to fix that 
>> then to build libtool on practically all platforms from source. 
>> You really don't need libtool > 2.4.6 to build thrift. Works perfectly on my 
>> Fedora 22 with libtool 2.4.2 .
>> The problem is not the libtool version, by the way. autoconf/aclocal just 
>> can't, for some reasons I really can't figure out, find the "default" 
>> system-wide M4 files containing the PKG_CHECK_MODULES macro under specific 
>> circumstances. It seems that installing libtool into the same prefix one is 
>> going to use later on fixes the problem (as the M4s end up in a location 
>> that aclocal ends up looking in). Have a test: if you edit the bootstrap.sh 
>> of thrift, and modify the
>> 
>> aclocal -I ./aclocal 
>> 
>> line to 
>> 
>> aclocal -I $(env -i aclocal --print-ac-dir) -I ./aclocal 
>> 
>> the M4 syntax error disappears, at least for me. Of course, thrift wouldn't 
>> successfully build with those modifications, either, but that's really a 
>> long rabbit hole to go into :) Hence my curiosity!
> 
> Alright, its all coming back to me now, I think you've got me straightened 
> out again, Marcus.  I was definitely wrong on the pkg-config/libtool versions 
> before, thanks for taking my hasty accusations so well!  This is the exact 
> same sort of issue that I was running in to when running autoreconf for 
> libosmo-dsp and I realized that having ANY version of pkg-config installed 
> from source under the PYBOMBS_PREFIX would make these sort of errors go away, 
> too.  I'm on-board with leaving the pkg-config and libtool versions alone and 
> fixing the real underlying problems. 
>  
> So, the thrift recipe was switched to using git for the source fetch around 
> this time [3] due to a possible thrift bug.  Question: now that thrift 0.9.3 
> is available in tarball form, might we want to switch back to using the 
> release tarball?  The benefit of the tarball is that it already includes all 
> of the required m4 macro files, and that makes ./configure run MUCH more 
> smoothly.  In fact, this branch [4], which just switches to the tarball 
> release of thrift 0.9.3, builds cleanly for me on CentOS 7.  Give it a shot!
> 
> -Eric
> 
> [3] 
> https://github.com/gnuradio/gnuradio/commit/621c086b94e1f9b70f24034bf6fb6f7e15e5fa7c
> [4] https://github.com/estatz/gr-recipes/tree/thrift_tarball
> ___
> 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] OOT Module Issue

[Richard Bell]

Hi,

This is on Ubuntu 14.04 with GNU Radio 3.7.10

I have a module that I use just for altering existing GNU Radio blocks.
Currently, it has the header/payload demux block and the
packet_header_parser block in it, which I copied and pasted from the
built-in block files. The HPD block was working fine yesterday, but today
when I added the packet_header_parser block, it appears to have broken not
only itself, but the hpd block as well.

The issue is that I'm getting

AttributeError: 'module' object has no attribute 'packet_headerparser_b_ins'

when I have either of these blocks included in a flowgraph. I did not
forget to 'sudo ldconfig'.

Here is the output of ldd

bell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-ins_blocks/build/lib$
ldd libgnuradio-ins_blocks.so
linux-vdso.so.1 =>  (0x7fff000ea000)
libboost_system.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x7fa5de816000)
libgnuradio-runtime-3.7.10git.so.0.0.0 =>
/usr/local/lib/libgnuradio-runtime-3.7.10git.so.0.0.0 (0x7fa5de53a000)
libgnuradio-pmt-3.7.10git.so.0.0.0 =>
/usr/local/lib/libgnuradio-pmt-3.7.10git.so.0.0.0 (0x7fa5de2ef000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7fa5ddfeb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa5ddce4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7fa5ddace000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa5dd709000)
libvolk.so.1.2.2 => /usr/local/lib/libvolk.so.1.2.2 (0x7fa5dd2a)
libboost_filesystem.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x7fa5dd08a000)
libboost_thread.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x7fa5dce74000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fa5dcc55000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7fa5dca15000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fa5dc80d000)
/lib64/ld-linux-x86-64.so.2 (0x7fa5dec64000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7fa5dc5f2000)

When I run the top level python flowgraph under gdb, I get no useful
feedback, it only tells me the attributeError line that I already knew.

What is something that causes all blocks in a module to produce this sort
of error?

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

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Thanks Ron. I think this is narrowing down the issue. When I ran that
command, I did not get any entries containing libgnuradio back. When I run
the same command on a working Ubuntu 14.04 install, I get many of those
entries.

I added the file you mentioned with the path to the base install gnuradio
libraries and they then show up in the output list. The question is, why
was base install gnuradio working at all without knowing the location to
those libraries?

Second question, why do I have to do this at all, shouldn't Pybombs have
handled this for me?

Lastly, even after adding this gnuradio.conf file, I am still unable to
compile OOT. The process returns the same cmake warnings and make error as
it did before. No change at all.

On Thu, May 26, 2016 at 11:46 AM, Ron Economos <w...@comcast.net> wrote:

> You probably don't have a path to the GNU Radio libraries for the linker.
> Try this command:
>
> sudo ldconfig -v | grep gnuradio
>
> The way I like to resolve this is to add a file to /etc/ld.so.conf.d
> called gnuradio.conf with the path to the libraries. On my setup, it
> contains:
>
> /opt/gnuradio-3.7.10git/lib
>
> Ron
>
>
> On 05/26/2016 11:05 AM, Richard Bell wrote:
>
> Yeah I've blown away build a few times now. I tried this to a few
> different OOT modules as well. They all produce the same output I've
> posted. Weird how GNU Radio istelf had no cmake issues but child OOT
> modules do.
>
> On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn <bhilb...@gnuradio.org>
> wrote:
>
>> Pretty strange. Stupid question: I assume you have tried blowing away the
>> build directory and giving it another go? Wondering if this is the CMake
>> cache mucking you up.
>>
>> This might be worth a try?
>> https://github.com/dmlc/mxnet/issues/1131
>>
>> Cheers,
>> Ben
>>
>> On Thu, May 26, 2016 at 12:47 PM, Richard Bell <
>> <richard.be...@gmail.com>richard.be...@gmail.com> wrote:
>>
>>> Then it spit out this error message:
>>>
>>>  CMake Error at
>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>>  (CMAKE_PARSE_ARGUMENTS):
>>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>>  Call Stack (most recent call first):
>>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>>> (find_package_handle_standard_args)
>>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>>CMakeLists.txt:106 (find_package)
>>>
>>> I don't know what to make of this, do you?
>>>
>>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell <richard.be...@gmail.com>
>>> wrote:
>>>
>>>> It seems to be looking into the grprefix directory, this is what I get
>>>> from ccmake:
>>>>
>>>>  CMAKE_BUILD_TYPE
>>>> *
>>>>  CMAKE_INSTALL_PREFIX
>>>> */usr/local
>>>>  ENABLE_DOXYGEN
>>>> *ON
>>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>>> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>>> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>>>>  Gnuradio_DIR
>>>> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>>>>  LIB_SUFFIX
>>>> *
>>>>  QA_PYTHON_EXECUTABLE
>>>> */usr/bin/python2
>>>>  SHELL  */bin/sh
>>>>
>>>> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn < <bhilb...@gnuradio.org>
>>>> bhilb...@gnuradio.org> wrote:
>>>>
>>>>> Hi Richard -
>>>>>
>>>>> Can you try peeking into the CMAKE madness to see what paths it
>>>>> selected for those two gnuradio libraries? I've found the curses-based
>>>>> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
>>>>> ccmake
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <
>>>>> <richard.be...@gmail.com>richard.be...@gmail.com> wrote:
>>>>>
>>>>>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>>>>>> 16.04 install and I wonder if I'm having compatibility issues. I'm 
>>>>>> getting
>>>>>> what looks like cmake issues that cause make to error out. I made sure to
>>>>>> feed the prefix location into cmake. There are warnings that I'm not used
>>>>>> to seeing in the cmake outpu

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

I tried making a fresh OOT module and I get the same problem. So it seems
to be connected to gr_modtool.

On Thu, May 26, 2016 at 11:05 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Yeah I've blown away build a few times now. I tried this to a few
> different OOT modules as well. They all produce the same output I've
> posted. Weird how GNU Radio istelf had no cmake issues but child OOT
> modules do.
>
> On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn <bhilb...@gnuradio.org>
> wrote:
>
>> Pretty strange. Stupid question: I assume you have tried blowing away the
>> build directory and giving it another go? Wondering if this is the CMake
>> cache mucking you up.
>>
>> This might be worth a try?
>> https://github.com/dmlc/mxnet/issues/1131
>>
>> Cheers,
>> Ben
>>
>> On Thu, May 26, 2016 at 12:47 PM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> Then it spit out this error message:
>>>
>>>  CMake Error at
>>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>>  (CMAKE_PARSE_ARGUMENTS):
>>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>>  Call Stack (most recent call first):
>>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>>> (find_package_handle_standard_args)
>>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>>CMakeLists.txt:106 (find_package)
>>>
>>> I don't know what to make of this, do you?
>>>
>>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell <richard.be...@gmail.com>
>>> wrote:
>>>
>>>> It seems to be looking into the grprefix directory, this is what I get
>>>> from ccmake:
>>>>
>>>>  CMAKE_BUILD_TYPE
>>>> *
>>>>  CMAKE_INSTALL_PREFIX
>>>> */usr/local
>>>>  ENABLE_DOXYGEN
>>>> *ON
>>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>>> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>>> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>>>>  Gnuradio_DIR
>>>> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>>>>  LIB_SUFFIX
>>>> *
>>>>  QA_PYTHON_EXECUTABLE
>>>> */usr/bin/python2
>>>>  SHELL  */bin/sh
>>>>
>>>> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn <bhilb...@gnuradio.org>
>>>> wrote:
>>>>
>>>>> Hi Richard -
>>>>>
>>>>> Can you try peeking into the CMAKE madness to see what paths it
>>>>> selected for those two gnuradio libraries? I've found the curses-based
>>>>> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
>>>>> ccmake
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <richard.be...@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>>>>>> 16.04 install and I wonder if I'm having compatibility issues. I'm 
>>>>>> getting
>>>>>> what looks like cmake issues that cause make to error out. I made sure to
>>>>>> feed the prefix location into cmake. There are warnings that I'm not used
>>>>>> to seeing in the cmake output. make says it can't find a few required
>>>>>> libraries that cmake reported it found. Here is the full cmake and make
>>>>>> output:
>>>>>>
>>>>>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>>>>>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>>>>>> -- The CXX compiler identification is GNU 5.3.1
>>>>>> -- The C compiler identification is GNU 5.3.1
>>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>>> -- Detecting CXX compiler ABI info
>>>>>> -- Detecting CXX compiler ABI info - done
>>>>>> -- Detecting CXX compile features
>>>>>> -- Detecting CXX compile features - done
>>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>>> -- Detecting C compiler ABI info
>>

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Yeah I've blown away build a few times now. I tried this to a few different
OOT modules as well. They all produce the same output I've posted. Weird
how GNU Radio istelf had no cmake issues but child OOT modules do.

On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Pretty strange. Stupid question: I assume you have tried blowing away the
> build directory and giving it another go? Wondering if this is the CMake
> cache mucking you up.
>
> This might be worth a try?
> https://github.com/dmlc/mxnet/issues/1131
>
> Cheers,
> Ben
>
> On Thu, May 26, 2016 at 12:47 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Then it spit out this error message:
>>
>>  CMake Error at
>> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
>>  (CMAKE_PARSE_ARGUMENTS):
>>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>>  Call Stack (most recent call first):
>>/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
>> (find_package_handle_standard_args)
>>cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
>>CMakeLists.txt:106 (find_package)
>>
>> I don't know what to make of this, do you?
>>
>> On Thu, May 26, 2016 at 9:45 AM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> It seems to be looking into the grprefix directory, this is what I get
>>> from ccmake:
>>>
>>>  CMAKE_BUILD_TYPE
>>> *
>>>  CMAKE_INSTALL_PREFIX
>>> */usr/local
>>>  ENABLE_DOXYGEN
>>> *ON
>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>  GNURADIO_RUNTIME_LIBRARIES_gnu
>>> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>>>  Gnuradio_DIR
>>> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>>>  LIB_SUFFIX
>>> *
>>>  QA_PYTHON_EXECUTABLE
>>> */usr/bin/python2
>>>  SHELL  */bin/sh
>>>
>>> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn <bhilb...@gnuradio.org>
>>> wrote:
>>>
>>>> Hi Richard -
>>>>
>>>> Can you try peeking into the CMAKE madness to see what paths it
>>>> selected for those two gnuradio libraries? I've found the curses-based
>>>> CMAKE UI to be pretty helpful in seeing what the build parameters are: $
>>>> ccmake
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <richard.be...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>>>>> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
>>>>> what looks like cmake issues that cause make to error out. I made sure to
>>>>> feed the prefix location into cmake. There are warnings that I'm not used
>>>>> to seeing in the cmake output. make says it can't find a few required
>>>>> libraries that cmake reported it found. Here is the full cmake and make
>>>>> output:
>>>>>
>>>>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>>>>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>>>>> -- The CXX compiler identification is GNU 5.3.1
>>>>> -- The C compiler identification is GNU 5.3.1
>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>> -- Detecting CXX compiler ABI info
>>>>> -- Detecting CXX compiler ABI info - done
>>>>> -- Detecting CXX compile features
>>>>> -- Detecting CXX compile features - done
>>>>> -- Check for working C compiler: /usr/bin/cc
>>>>> -- Check for working C compiler: /usr/bin/cc -- works
>>>>> -- Detecting C compiler ABI info
>>>>> -- Detecting C compiler ABI info - done
>>>>> -- Detecting C compile features
>>>>> -- Detecting C compile features - done
>>>>> -- Build type not specified: defaulting to release.
>>>>> -- Boost version: 1.58.0
>>>>> -- Found the following Boost libraries:
>>>>> --   filesystem
>>>>> --   system
>>>>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>>>>> -- Checking for module 'cppunit'
>>>>> --   Found cppunit,

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

Then it spit out this error message:

 CMake Error at
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
 (CMAKE_PARSE_ARGUMENTS):
   Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
 Call Stack (most recent call first):
   /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
(find_package_handle_standard_args)
   cmake/Modules/FindCppUnit.cmake:12 (INCLUDE)
   CMakeLists.txt:106 (find_package)

I don't know what to make of this, do you?

On Thu, May 26, 2016 at 9:45 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> It seems to be looking into the grprefix directory, this is what I get
> from ccmake:
>
>  CMAKE_BUILD_TYPE
> *
>  CMAKE_INSTALL_PREFIX
> */usr/local
>  ENABLE_DOXYGEN
> *ON
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>  GNURADIO_RUNTIME_LIBRARIES_gnu
> */home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
>  Gnuradio_DIR
> */home/rbell/Documents/grprefix/lib/cmake/gnuradio
>  LIB_SUFFIX
> *
>  QA_PYTHON_EXECUTABLE
> */usr/bin/python2
>  SHELL  */bin/sh
>
> On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn <bhilb...@gnuradio.org>
> wrote:
>
>> Hi Richard -
>>
>> Can you try peeking into the CMAKE madness to see what paths it selected
>> for those two gnuradio libraries? I've found the curses-based CMAKE UI to
>> be pretty helpful in seeing what the build parameters are: $ ccmake
>>
>> Cheers,
>> Ben
>>
>> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>>> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
>>> what looks like cmake issues that cause make to error out. I made sure to
>>> feed the prefix location into cmake. There are warnings that I'm not used
>>> to seeing in the cmake output. make says it can't find a few required
>>> libraries that cmake reported it found. Here is the full cmake and make
>>> output:
>>>
>>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>>> -- The CXX compiler identification is GNU 5.3.1
>>> -- The C compiler identification is GNU 5.3.1
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Build type not specified: defaulting to release.
>>> -- Boost version: 1.58.0
>>> -- Found the following Boost libraries:
>>> --   filesystem
>>> --   system
>>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>>> -- Checking for module 'cppunit'
>>> --   Found cppunit, version 1.13.2
>>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>>> Checking for GNU Radio Module: RUNTIME
>>> -- Checking for module 'gnuradio-runtime'
>>> --   Found gnuradio-runtime, version 3.7.10git
>>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>>  *
>>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>> -- Found GNURADIO_RUNTIME:
>>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>>
>>> GNURADIO_RUNTIME_FOUND = TRUE
>>> CMake Warning (dev) at
>>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>>> (get_target_property):
>>>   Policy CMP0026 is not set: Disallow use of the LOCATION target
>>> property.
>>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>>> cmake_policy
>>>   command to set the policy and suppress this warning.
>>>
>>>   The LOCATION property should not be read from target
>>>   "test-add_tagged_stream_once".  Use the target name directly with
>>>   add_custom_command, o

Re: [Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

It seems to be looking into the grprefix directory, this is what I get from
ccmake:

 CMAKE_BUILD_TYPE
*
 CMAKE_INSTALL_PREFIX
*/usr/local
 ENABLE_DOXYGEN
*ON
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
 GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so
 Gnuradio_DIR
*/home/rbell/Documents/grprefix/lib/cmake/gnuradio
 LIB_SUFFIX
*
 QA_PYTHON_EXECUTABLE
*/usr/bin/python2
 SHELL  */bin/sh

On Thu, May 26, 2016 at 7:54 AM, Ben Hilburn <bhilb...@gnuradio.org> wrote:

> Hi Richard -
>
> Can you try peeking into the CMAKE madness to see what paths it selected
> for those two gnuradio libraries? I've found the curses-based CMAKE UI to
> be pretty helpful in seeing what the build parameters are: $ ccmake
>
> Cheers,
> Ben
>
> On Wed, May 25, 2016 at 4:19 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I'm trying to compile one of my custom OOT modules on this new Ubuntu
>> 16.04 install and I wonder if I'm having compatibility issues. I'm getting
>> what looks like cmake issues that cause make to error out. I made sure to
>> feed the prefix location into cmake. There are warnings that I'm not used
>> to seeing in the cmake output. make says it can't find a few required
>> libraries that cmake reported it found. Here is the full cmake and make
>> output:
>>
>> rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>> cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>> -- The CXX compiler identification is GNU 5.3.1
>> -- The C compiler identification is GNU 5.3.1
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.58.0
>> -- Found the following Boost libraries:
>> --   filesystem
>> --   system
>> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>> -- Checking for module 'cppunit'
>> --   Found cppunit, version 1.13.2
>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
>> Checking for GNU Radio Module: RUNTIME
>> -- Checking for module 'gnuradio-runtime'
>> --   Found gnuradio-runtime, version 3.7.10git
>>  * INCLUDES=/home/rbell/Documents/grprefix/include
>>  *
>> LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>> -- Found GNURADIO_RUNTIME:
>> /home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
>>
>> GNURADIO_RUNTIME_FOUND = TRUE
>> CMake Warning (dev) at
>> /home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>> cmake_policy
>>   command to set the policy and suppress this warning.
>>
>>   The LOCATION property should not be read from target
>>   "test-add_tagged_stream_once".  Use the target name directly with
>>   add_custom_command, or use the generator expression $, as
>>   appropriate.
>>
>> Call Stack (most recent call first):
>>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> --
>> -- Checking for module SWIG
>> -- Found SWIG version 2.0.12.
>> -- Found SWIG: /usr/bin/swig2.0
>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
>> suitable version "2.7.11+", minimum required is "2")
>> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.11",
>> minimum required is "2")
>> -- Looking for sys/types.h
>> -- Looking for sys/types.h - found
>> -- Looking for stdint.h
>> -- Looking for stdint.h - found
>> -- Looking for stddef.h
>> -- Looking for stddef.h - found
>> -- Check size of size_t
>> -

[Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

I'm trying to compile one of my custom OOT modules on this new Ubuntu 16.04
install and I wonder if I'm having compatibility issues. I'm getting what
looks like cmake issues that cause make to error out. I made sure to feed
the prefix location into cmake. There are warnings that I'm not used to
seeing in the cmake output. make says it can't find a few required
libraries that cmake reported it found. Here is the full cmake and make
output:

rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
-- The CXX compiler identification is GNU 5.3.1
-- The C compiler identification is GNU 5.3.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'cppunit'
--   Found cppunit, version 1.13.2
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
Checking for GNU Radio Module: RUNTIME
-- Checking for module 'gnuradio-runtime'
--   Found gnuradio-runtime, version 3.7.10git
 * INCLUDES=/home/rbell/Documents/grprefix/include
 *
LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
-- Found GNURADIO_RUNTIME:
/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so

GNURADIO_RUNTIME_FOUND = TRUE
CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target
  "test-add_tagged_stream_once".  Use the target name directly with
  add_custom_command, or use the generator expression $, as
  appropriate.

Call Stack (most recent call first):
  lib/CMakeLists.txt:79 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- 
-- Checking for module SWIG
-- Found SWIG version 2.0.12.
-- Found SWIG: /usr/bin/swig2.0
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
suitable version "2.7.11+", minimum required is "2")
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.11",
minimum required is "2")
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of size_t
-- Check size of size_t - done
-- Check size of unsigned int
-- Check size of unsigned int - done
-- Check size of unsigned long
-- Check size of unsigned long - done
-- Check size of unsigned long long
-- Check size of unsigned long long - done
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target
  "gnuradio-add_tagged_stream_once".  Use the target name directly with
  add_custom_command, or use the generator expression $, as
  appropriate.

Call Stack (most recent call first):
  python/CMakeLists.txt:44 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0045 is not set: Error on non-existent target in
  get_target_property.  Run "cmake --help-policy CMP0045" for policy
details.
  Use the cmake_policy command to set the policy and suppress this warning.

  get_target_property() called with non-existent target "/usr/bin/python2".
Call Stack (most recent call first):
  python/CMakeLists.txt:44 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0045 is not set: Error on non-existent target 

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Richard Bell]

I just installed GR using Pybombs on a fresh Ubuntu 16.04 (16.04 not 14.04)
with no problems.

Rich

On Tue, May 24, 2016 at 5:30 PM, Ben Hilburn  wrote:

> Hi all -
>
> Some great discussion here.
>
> We have talked about adding a "dry-run" option to PyBOMBS a couple of
> times in the past. It sounds like a number of folks think it would be
> useful, here, too.
>
> With regard to using PyBOMBS on 'antiquated' OSes - one of the original
> purposes of PyBOMBS, actually, was to make it easier to maintain GNU Radio
> installations on these old OSes. I believe at its inception PyBOMBS needed
> to support RHEL4, actually.
>
> How long we should support otherwise obsolete OSes is a conversation worth
> having. There are enough users that need to build on legacy systems that I
> think it's an important function to consider.
>
> Cheers,
> Ben
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Richard Bell]

I have GNU Radio installed via source on my computer, but I'd like to try
the Pybombs method to see if it works. Before I do, I want to make sure I
won't screw up my current install, whether its through conflicts or
confusion over multiple installs or something else. Here a few questions I
have:

1) If there are two installs, is it a matter of whichever one had a "sudo
make install" run last as to which version is actually being used?
2) Are there any gotchas I should know about when two different GNU Radios
are installed on one machine?

On Sun, May 22, 2016 at 3:07 PM, Marcus Müller 
wrote:

> Hi Sylvain,
>
> what platform are you on? (basically, libalsa should be installed via
> package whenever possible, which is the case on debian, ubuntu, fedora
> and centos, I thought)
> Also: I kind of like the "don't install, just list" idea. However,
> Pybombs would never encourage you to build stuff as root – super user
> privileges are acquired as necessary through sudo.
>
> Cheers,
> Marcus
>
> On 22.05.2016 23:32, Sylvain Munaut wrote:
> > Hi,
> >
> >> My prime test case is the following pybombs command:
> >>
> >> $ pybombs prefix init ~/path/to/prefix -R gnuradio-default
> >>
> >> (Note you will need the most current PyBOMBS and gr-recipes to run
> this).
> > I just gave this a shot, but I aborted pretty quickly.
> >
> > It started building alsa from sources ...
> >
> > Ideally I'd like to only build from source the SDR related packages
> > that don't have any decent version available as package and not every
> > package.
> > Also since I run pybombs as user and not root (no way I'm building all
> > of this as the root user ...), I don't expect pybomb to install the
> > packages, but I would expect it to list them to me so I can install
> > them myself then restart pybombs.
> >
> > Anyway, just my 2 ct ...
> >
> >
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python OOT Block Selectable Types

[Richard Bell]

Martin,

I like the first idea. Would it be possible to create a new variable in the
xml file that is assigned numpy.float32 when the user selects the float
option, or is assigned numpy.complex64 when the user selects the complex
option? Another words, I don't want the user to have to select the port
type AND have to type in the python type of the port, that should be clear
from the port type drop down selection. I'm just not sure how to work this
in the xml file, or if its even possible.

Rich

On Thu, May 12, 2016 at 11:11 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> You can either make this a block argument (i.e., you ask the user to
> pass in numpy.float32 or whatever), or, to keep consistent with the C++
> way of doing things, you can make a block argument called 'sizeof' and
> then create a dict that maps sizes to numpy. values, and use that
> to set in_sig.
>
> M
>
> On 05/11/2016 02:04 PM, Richard Bell wrote:
> > I've created a python based OOT block and I want to give the user the
> > ability to select the input/output type. I know how to do this for C++
> > based blocks, but I'm stuck on what to do with the python blocks
> > signature, as it doesn't ask for the item_size like the C++ blocks do. I
> > have to give it something explicit like
> >
> > in_sig = [numpy.float32]
> >
> > How do I write the generic sig that depends on what the user selected in
> > GRC?
> >
> > Note: The algorithm in the body of this block doesn't change depending
> > on type selected. It's a simple block.
> >
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Code Reuse Question

[Richard Bell]

If we wanted that behavior, could we do something similar to what gating
blocks do (like the power squelch), where we pass X number of items through
and after that only consume items without ever producing anything. Is there
an efficiency problem with this technique?

On Thu, May 12, 2016 at 6:14 AM, Marcus Müller 
wrote:

> Yep, having had a walk over this: if we didn't want to have this
> behaviour, we'd need to have some buffer_writer specific done_policy or so,
> where we tell the block it should shut down based on whether all or just
> any one of its buffer readers signaled WORK_DONE.
> We don't have that, so this is the only way to shut down a graph tree from
> a non-source block.
>
>
> On 12.05.2016 14:58, Tom Rondeau wrote:
>
> On Thu, May 12, 2016 at 5:13 AM, Marcus Müller 
> wrote:
>
>> Yeah, I've been actually scratching my head on whether that is
>> intentional or not – if we don't have that behaviour, there's no chance
>> that a leaf in a non-path tree-shaped flow graph can stop the flow
>> graph, is there?
>
>
>
> Definitely intentional and the way it's worked since the beginning.
>
> Tom
>
>
>
>
>> On 12.05.2016 12:23, Sylvain Munaut wrote:
>> > Hi,
>> >
>> >
>> >> I thought so, too, at first, but then tested:
>> >>
>> >> Null src +-> Head --> Null sink0
>> >>  \--> Null sink1
>> >>
>> >>
>> >> stops.
>> >>
>> >> I think this is the "am done" message bubbling up from head to src,
>> then
>> >> src knowing it should be done, then the info "there's no input coming
>> >> anymore" bubbling down to sink1. Thoughts?
>> > I'd classify that as a bug.
>> >
>> > I don't think that's the intended behavior. (but I tested too and
>> > that's indeed what happens, even with non-null sink/source)
>> >
>> > 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Python OOT Block Selectable Types

[Richard Bell]

I've created a python based OOT block and I want to give the user the
ability to select the input/output type. I know how to do this for C++
based blocks, but I'm stuck on what to do with the python blocks signature,
as it doesn't ask for the item_size like the C++ blocks do. I have to give
it something explicit like

in_sig = [numpy.float32]

How do I write the generic sig that depends on what the user selected in
GRC?

Note: The algorithm in the body of this block doesn't change depending on
type selected. It's a simple block.

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

Re: [Discuss-gnuradio] Code Reuse Question

[Richard Bell]

I don't want the flowgraph to stop. I just want to store a set number but
leave the flowgraph running.

On Wed, May 11, 2016 at 1:13 PM, Dan CaJacob <dan.caja...@gmail.com> wrote:

> You can use a head block inline (already in core).
>
> On Wed, May 11, 2016 at 4:09 PM Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Hello,
>>
>> I want to add an additional parameter to the existing file sink block
>> that lets the user tell it how many items to save to file. This amounts to
>> adding a few lines to the existing file sink work function.
>>
>> What's the smartest way to do this? What I would do currently is create a
>> new block, copy and paste the existing file sink code to my new block and
>> add the few lines of code to change it. Is there a smarter way?
>>
>> Rich
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool consolidation question

[Richard Bell]

OK thanks Marcus.

Rich

On Wed, May 11, 2016 at 12:40 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Rich,
> there's no such functionality directly integrated in gr_modtool. However,
> there's not that many places you'll have to work when manually merging
> things.
> To be safe, you could just re-add all the blocks you want to add to your
> consolidated module with "gr_modtool add", and then just overwrite the
> resulting blockname.h, blockname_impl.cc and blockname_impl.h with your
> originals, before replacing all occurences of your "original" module names
> with the consolidated module's name via some search & replace tool ("sed -i
> 's/original/consolidated/g' filenames" does wonders :) )
>
> Cheers,
> Marcus
>
> On 11.05.2016 19:42, Richard Bell wrote:
>
> Hi all,
>
> Before I fully understood how gr_modtool worked, I would make a new module
> for each new block I made. I would like to consolidate these disparate
> modules into one overarching module now. I have approx 10 modules some with
> more then one block that I'd like to make one module.
>
> Is there an easy way to do this or do I have to create each existing block
> via modtool in the new module?
>
> Rich
>
>
> ___
> 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

[Discuss-gnuradio] Code Reuse Question

[Richard Bell]

Hello,

I want to add an additional parameter to the existing file sink block that
lets the user tell it how many items to save to file. This amounts to
adding a few lines to the existing file sink work function.

What's the smartest way to do this? What I would do currently is create a
new block, copy and paste the existing file sink code to my new block and
add the few lines of code to change it. Is there a smarter way?

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

Re: [Discuss-gnuradio] disabling UHD OOOOO... messages

[Richard Bell]

Are you sure you want to ignore them instead of fixing the cause of them?
Can you lower your sample rate? They are telling you you're losing data,
depending on what you're doing. O means overflow so something is being lost
do to a lack of buffer space.

The typical cause of this is your computer is not processing your receiver
chain fast enough to keep up with the samples being generated by the B200,
so the samples are just lost. If you reduce the sample rate of the B200, it
could fix it. If you can't reduce the sample rate, you would have to better
optimize your receiver or not try and do so much with it so the computer
can keep up with the B200.

Rich

On Wed, May 11, 2016 at 9:12 AM, Engin Karabulut  wrote:

>
> I'm using Gnuradio with Ettus B200 device. My application runs fine but
> UHD driver prints O... messages randomly. I guess some overflow
> or something else happens inside UHD driver,but I want to ignore these
> long UHD messages. How can I disable O messages.
>
> regards.
>
>
> ___
> 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] gr_modtool consolidation question

[Richard Bell]

Hi all,

Before I fully understood how gr_modtool worked, I would make a new module
for each new block I made. I would like to consolidate these disparate
modules into one overarching module now. I have approx 10 modules some with
more then one block that I'd like to make one module.

Is there an easy way to do this or do I have to create each existing block
via modtool in the new module?

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

Re: [Discuss-gnuradio] How do I use formatter in QT GUI Label?

[Richard Bell]

All,

I'm still not sure what's going on with this. Is it a problem with my
installation or a bug in the code related to the formatter? Has anyone
tested using the formatter field recently?

v/r,
Rich

On Mon, May 9, 2016 at 1:05 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> Dan and Marcus (from another thread related to this),
>
> I'm trying to do what you say, but I get an error when using
> *"{0:.3e}".format* in the formatter field. The default value (0) is now
> formatted properly but it won't ever update and in terminal I get the
> following error
>
> Exception in thread Thread-8:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
> self.run()
>   File "/usr/lib/python2.7/threading.py", line 763, in run
> self.__target(*self.__args, **self.__kwargs)
>   File
> "/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
> line 1704, in _ber_probe
> self.set_ber(val)
>   File
> "/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
> line 2043, in set_ber
>
> self.set_variable_qtgui_label_0(self._variable_qtgui_label_0_formatter(self.ber))
>   File
> "/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
> line 2106, in set_variable_qtgui_label_0
> Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label,
> "setText", Qt.Q_ARG("QString",
> eng_notation.num_to_str(self.variable_qtgui_label_0)))
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/eng_notation.py",
> line 41, in num_to_str
> m = abs(n)
> TypeError: bad operand type for abs(): 'str'
>
> I also get this error whenever I double click the QT GUI Label in question:
>
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Param.py",
> line 72, in _update_gui
> Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(),
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Utils.py",
> line 121, in __call__
> return str(template(namespaces=kwargs))
>   File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005,
> in __str__
> rc = getattr(self, mainMethName)()
>   File
> "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py", line
> 130, in respond
>   File
> "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py", line
> 87, in truncate
> IndexError: tuple index out of range
>
> Am I doing something wrong?
>
> Rich
>
>
>
>
> On Fri, May 6, 2016 at 5:54 PM, Dan CaJacob <dan.caja...@gmail.com> wrote:
>
>> I am not sure about this, but you may try the standard python
>> formatters.  See https://docs.python.org/2/library/string.html
>>
>> On Fri, May 6, 2016 at 5:13 PM Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> I am displaying a number using QT GUI Label in GRC like this
>>>
>>> 20.6u
>>>
>>> when I want it to display like this
>>>
>>> 20.6e-6 or 20.6x10-6, something along these lines.
>>>
>>> What do I put in the formatter section to make this happen?
>>>
>>> Rich
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I use formatter in QT GUI Label?

[Richard Bell]

Dan and Marcus (from another thread related to this),

I'm trying to do what you say, but I get an error when using
*"{0:.3e}".format* in the formatter field. The default value (0) is now
formatted properly but it won't ever update and in terminal I get the
following error

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 1704, in _ber_probe
self.set_ber(val)
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 2043, in set_ber

self.set_variable_qtgui_label_0(self._variable_qtgui_label_0_formatter(self.ber))
  File
"/home/rbell/Documents/pcodes/radio_devel/production/Stream/pcodes_bpsk_stream_FEC_complexDecoder_loopback.py",
line 2106, in set_variable_qtgui_label_0
Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label,
"setText", Qt.Q_ARG("QString",
eng_notation.num_to_str(self.variable_qtgui_label_0)))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/eng_notation.py",
line 41, in num_to_str
m = abs(n)
TypeError: bad operand type for abs(): 'str'

I also get this error whenever I double click the QT GUI Label in question:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Param.py",
line 72, in _update_gui
Utils.parse_template(TIP_MARKUP_TMPL, param=self.param).strip(),
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Utils.py",
line 121, in __call__
return str(template(namespaces=kwargs))
  File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005,
in __str__
rc = getattr(self, mainMethName)()
  File "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py",
line 130, in respond
  File "cheetah_DynamicallyCompiledCheetahTemplate_1462212927_77_69202.py",
line 87, in truncate
IndexError: tuple index out of range

Am I doing something wrong?

Rich




On Fri, May 6, 2016 at 5:54 PM, Dan CaJacob <dan.caja...@gmail.com> wrote:

> I am not sure about this, but you may try the standard python formatters.
> See https://docs.python.org/2/library/string.html
>
> On Fri, May 6, 2016 at 5:13 PM Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I am displaying a number using QT GUI Label in GRC like this
>>
>> 20.6u
>>
>> when I want it to display like this
>>
>> 20.6e-6 or 20.6x10-6, something along these lines.
>>
>> What do I put in the formatter section to make this happen?
>>
>> Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How do I use formatter in QT GUI Label?

[Richard Bell]

I am displaying a number using QT GUI Label in GRC like this

20.6u

when I want it to display like this

20.6e-6 or 20.6x10-6, something along these lines.

What do I put in the formatter section to make this happen?

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

Re: [Discuss-gnuradio] Introducing the New GNU Radio Website

[Richard Bell]

I like the new style, it feels fresh and modern.

I've noticed that depending on the link you click, you may end up on a page
in the old style. For example, clicking the development link does this.
Will the entire website eventually get the makeover?

Rich

On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn  wrote:

> Hi all -
>
> I am happy to share that primary development on the user-facing GNU Radio
> website has been wrapped up! You can check out the new site in action at
> gnuradio.org.
>
> There is still a lot of content work to do as we migrate away from Redmine
> (you may notice that many of the links on the website take you to
> Redmine-hosted content, at the moment), but initial development on the site
> infrastructure itself has wrapped up. There are some items we would still
> like to get to eventually (like integrating the site Events Calendar
>  with the Org GCal
> ),
> so if you have any ideas for further improvement, feel free to send them my
> way. Also, if you are into web development and would like to get involved,
> please let me know!
>
> Going forward, community & project News  and
> Events  will be posted on the website (in
> addition to the mailing list, as usual), and developers will be sharing
> articles in the Blog  area of the site. If you
> have an idea for content that you would like to share with the broader
> community on the site, just get in touch. And, of course, if you spot any
> issues, please send me a note.
>
> A special thanks to Marcus Mueller, who did a ton of work on most of the
> images that appear on the site, and to Johnathan Corgan, who manages our
> server infrastructure in addition to everything else he is doing for the
> project.
>
> Cheers,
> Ben
>
> ___
> 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] sweep generator

[Richard Bell]

Do you specifically not want to use uhd_siggen_gui when you say you want to
use companion?

If you were not aware of uhd_siggen_gui, type that into a command line and
test it out. It can generate a sweeping tone if that's all you need.

Rich

On Thu, Apr 28, 2016 at 3:16 PM, Dan McKenna  wrote:

> Hi There,
>
> I am using a B210 to record band widths from 1 to 20 MHZ, center
> frequencies from 400Mhz to 2 Ghz.
> To test my post detection software I would like to use a Tx channel to
> make a sweep generator as a real time test source
> at sweep rates of around 50 Mhz/second over 1 to 20 mhz range with a
> center frequency of 400 Mhz to 2Ghz.
>
> To be clear I wish to use companion to generate a frequency sweep at a
> rate, defined by start/stop frequency and sweep time
> or frequency, range, rate. for example Freq 400 Mhz, range 2 mhz, rate
> 50Mhz/second.
>
> Is this possible with the standard gnu radio companion block set?
>
> Thanks
>
> Dan
>
>
> ___
> 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] gr-osmosdr python question

[Richard Bell]

I'm new to using gr-osmosdr and I'm trying to implement the equivalent set
of USRP function calls for a HackRF

set_center_freq(target_freq)
get_sensor("lo_locked")

which amounts to measuring how long it takes to command a frequency change
and lock at the new frequency.

The set_center_freq function happens to be the same, but I don't know where
to find documentation or example code that shows the get_sensor equivalent,
or if it's even needed. Would someone direct me to an API manual for
gr-osmosdr, or source code that defines these things?

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

Re: [Discuss-gnuradio] [USRP-users] UHD Updating Question

[Richard Bell]

OK thanks Martin. I'll give it a try.

Rich

On Tue, Apr 12, 2016 at 3:27 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> It's my experience that ccache errs on the right side, i.e. it rather
> recompiles if unsure. I've never had any caching issues with ccache.
> Note that the cache quickly fills up, if I can spare the space I will up
> the cache size from the default 1 GB. Right now it's at 8 GB but I doubt
> that'll ever fill up.
>
> M
>
> On 04/12/2016 03:09 PM, Richard Bell wrote:
> > Johnathan,
> >
> > Regarding ccache, do you need to worry about cleaning ccache because of
> > weird compilation errors at all, or does it always just work? I haven't
> > used a tool like this before but I'm considering it since you recommend
> it.
> >
> > Rich
> >
> > On Tue, Apr 12, 2016 at 2:59 PM, Richard Bell <richard.be...@gmail.com
> > <mailto:richard.be...@gmail.com>> wrote:
> >
> > Now that you mention it, I don't think I've ever tried recompiling
> > GNU Radio without pulling from gnuradios github first. If I don't
> > pull gnuradios latest souce, maybe it would be a fast upgrade for
> > uhd only.
> >
> > My process for rebuilding gnuradio is to go to where my build
> > directory is (without destroying it), and running sudo make install.
> > This is what usually takes about an hour.
> >
> > Rich
> >
> > On Tue, Apr 12, 2016 at 12:26 PM, Johnathan Corgan
> > <jcor...@gnuradio.org <mailto:jcor...@gnuradio.org>> wrote:
> >
> > On Tue, Apr 12, 2016 at 12:13 PM, Marcus Müller
> > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>
> wrote:
> >
> >
> > GR compile time is an interesting issue.
> >
> >
> > I can't recommend enough using the ccache utility if you are
> > going to be compiling GNU Radio more than once.
> >
> > -Johnathan
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto: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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] UHD Updating Question

[Richard Bell]

Johnathan,

Regarding ccache, do you need to worry about cleaning ccache because of
weird compilation errors at all, or does it always just work? I haven't
used a tool like this before but I'm considering it since you recommend it.

Rich

On Tue, Apr 12, 2016 at 2:59 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> Now that you mention it, I don't think I've ever tried recompiling GNU
> Radio without pulling from gnuradios github first. If I don't pull
> gnuradios latest souce, maybe it would be a fast upgrade for uhd only.
>
> My process for rebuilding gnuradio is to go to where my build directory is
> (without destroying it), and running sudo make install. This is what
> usually takes about an hour.
>
> Rich
>
> On Tue, Apr 12, 2016 at 12:26 PM, Johnathan Corgan <jcor...@gnuradio.org>
> wrote:
>
>> On Tue, Apr 12, 2016 at 12:13 PM, Marcus Müller <marcus.muel...@ettus.com
>> > wrote:
>>
>>
>>> GR compile time is an interesting issue.
>>>
>>
>> I can't recommend enough using the ccache utility if you are going to be
>> compiling GNU Radio more than once.
>>
>> -Johnathan
>>
>> ___
>> 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] [USRP-users] UHD Updating Question

[Richard Bell]

Now that you mention it, I don't think I've ever tried recompiling GNU
Radio without pulling from gnuradios github first. If I don't pull
gnuradios latest souce, maybe it would be a fast upgrade for uhd only.

My process for rebuilding gnuradio is to go to where my build directory is
(without destroying it), and running sudo make install. This is what
usually takes about an hour.

Rich

On Tue, Apr 12, 2016 at 12:26 PM, Johnathan Corgan 
wrote:

> On Tue, Apr 12, 2016 at 12:13 PM, Marcus Müller 
> wrote:
>
>
>> GR compile time is an interesting issue.
>>
>
> I can't recommend enough using the ccache utility if you are going to be
> compiling GNU Radio more than once.
>
> -Johnathan
>
> ___
> 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] Compiling Documentation with an OOT

[Richard Bell]

I've asked this question a few times now on the mailing list, and each time
I hope a different answer comes through. Each time though it's the answer
Ron gave, which never works for me. I can't figure it out. So I've always
resorted to the xml tags to get documentation into GRC, but for the reasons
Tom just mentioned, would rather not do that. Hoping someday I figure this
out.

Rich

On Wed, Mar 30, 2016 at 7:50 AM, Tom Rondeau <t...@trondeau.com> wrote:

>
>
> On Mon, Mar 28, 2016 at 9:25 PM, Tom McDermott <tom.n...@gmail.com> wrote:
>
>> 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
>>
>
>
> I would recommend against using the  tags in the GRC XML files.
> You're just duplicating text, so if anything is ever updated, you now need
> to remember to update it in two places.
>
> As Ron Economos showed in his response, exporting from his public .h files
> works fine.
>
> This might be a question for Sebastian, who I think has gone through a
> couple of iterations of grabbing those docs strings into GRC.
>
> Tom
>
>
>
>
>> On Mon, Mar 28, 2016 at 5:30 PM, Richard Bell <richard.be...@gmail.com>
>> 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] Compiling Documentation with an OOT

[Richard Bell]

Hey Ron,

That's where I added my documentation, just like you have it there, but I
can't get it to propagate through. Do I need to compile it differently for
that to happen? Is there a gnuradio setting that needs to be set for
documentation to make its way through?

Rich

On Mon, Mar 28, 2016 at 5:52 PM, Ron Economos <w...@comcast.net> wrote:

> You put the documentation into the .h file(s) in the
> gr-/include/ directory. Here's an example.
>
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/include/gnuradio/dtv/dvbt2_framemapper_cc.h
>
> Ron
>
>
> On 03/28/2016 05: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

[Discuss-gnuradio] Compiling Documentation with an OOT

[Richard Bell]

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

Re: [Discuss-gnuradio] Scrambler - Descrambler

[Richard Bell]

I've always used a "skip head" block after the descrambler to remove these
erroneous items that come out. "skip head" will drop whatever number of
items on the floor you tell it to and there after pass everything.

Rich

On Tue, Mar 22, 2016 at 10:24 AM, devin kelly  wrote:

> Hi Sean,
>
> Thanks for taking the time.  You're definitely right about setting the
> parameters for the scrambler/descrambler, it seems like I can get my
> descrambled signal to look pretty close to my original signal or I can
> totally screw it up by changing the parameters.  What I don't know is
> whether I can get the output of my descrambler to match the input of my
> scrambler.
>
> With mask = 0x61 and seed = 0x7f I get (the first message is the input to
> my scrambler and the second is the output):
>
> length = 6
>
> * MESSAGE DEBUG PRINT PDU VERBOSE *
> ()
> pdu_length = 14
> contents =
> : d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
> ***
> * MESSAGE DEBUG PRINT PDU VERBOSE *
> ()
> pdu_length = 14
> contents =
> : 00 68 91 f3 6a 10 fc 74 9c 50 27 0c c6 23
> ***
>
>
> length = 7
>
> * MESSAGE DEBUG PRINT PDU VERBOSE *
> ()
> pdu_length = 14
> contents =
> : d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
> ***
> * MESSAGE DEBUG PRINT PDU VERBOSE *
> ()
> pdu_length = 14
> contents =
> : 06 d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47
> ***
>
> Neither of these messages are what I expect but length = 7 is pretty
> close.  Does anyone know if it's possible to configure the scrambler and
> de-scrambler so the message I get out of my descrambler is exactly the same
> message I put into my scrambler?
>
> Thanks,
> Devin
>
> On Tue, Mar 22, 2016 at 11:45 AM, Sean Nowlan  wrote:
>
>> Devin,
>>
>> I haven't used the multiplicative scrambler/descrambler, although I've
>> used the additive scrambler. Both blocks use the same underlying LFSR
>> implementation. I noticed that there is some sensitivity in how the LFSR
>> parameters are specified. Judging by the parameters in your flowgraph,
>> you're using the polynomial: 0x61 --> 0b111 --> x^6 + x^5 + 1, which is
>> listed as an example in
>> gnuradio/gr-digital/include/gnuradio/digital/lfsr.h. This suggests a
>> degree=6 polynomial. However, according to [1] there is an implied 1 at the
>> highest order bit, so this is in fact a degree=7 polynomial: x^7 +  x^6 +
>> x^5 + 1. Also in [1] it mentions that "length" is not the shift register
>> length but the length of the bit shift when a new bit enters the shift
>> register. Hence, length should be length=(degree - 1).
>>
>> I would modify your scrambler/descrambler parameters to be the following:
>>
>> Mask: 0x61 (degree=7)
>> Seed: 0x7f
>> Length: 6
>>
>> Perhaps the junk you're seeing can be explained by the LFSR configuration.
>>
>> Note that I figured this out by trying to get a compatible LFSR
>> implementation for the CCITT polynomial x^9 + x^5 + 1, which has an LFSR
>> specification:
>>
>> Mask: 0x21 (degree=9)
>> Seed: 0x1ff
>> Length: 8
>>
>> [1] https://www.mail-archive.com/patch-gnuradio@gnu.org/msg00180.html
>> [2] http://cache.nxp.com/files/rf_if/doc/app_note/AN5070.pdf
>>
>>
>> On Mon, Mar 21, 2016 at 2:40 PM, devin kelly  wrote:
>>
>>> Hello,
>>>
>>> I'm a little confused on how to use the scrambler and descrambler, it
>>> looks like the descrambler always preprends a byte to my stream.  When I
>>> run this flowgraph I get this from the message ports (the first message is
>>> the original message, the second message is from the descrambler):
>>>
>>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>>> ()
>>> pdu_length = 10
>>> contents =
>>> : d0 22 e7 d5 20 f8 e9 38 a1 4e
>>> ***
>>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>>> ()
>>> pdu_length = 10
>>> contents =
>>> : 06 d0 22 e7 d5 20 f8 e9 38 a1
>>> ***
>>>
>>>
>>> I'm not totally sure what do about this, I've tried adding a delay block
>>> but that screws up my packet_len tags.
>>>
>>> Here's the original work function:
>>>
>>> {
>>> const unsigned char *in = (const unsigned char*)input_items[0];
>>> unsigned char *out = (unsigned char*)output_items[0];
>>>
>>> for(int i = 0; i < noutput_items; i++) {
>>> out[i] = d_lfsr.next_bit_descramble(in[i]);
>>> }
>>>
>>> return noutput_items;
>>> }
>>>
>>> I've also tried this work function (my approach here is to ignore the
>>> first byte out of the descrambler and then put junk into the last byte
>>> which would then be ignored on the next call to work() and yes I realize
>>> this isn't a general solution)
>>>
>>> {
>>> const unsigned char *in = (const unsigned char*)input_items[0];
>>> unsigned char *out = (unsigned char*)output_items[0];
>>>
>>>   unsigned char junk;
>>>   for(int i = 0; i < noutput_items + 8; i++) {
>>>   if (i < 8) {
>>> junk 

Re: [Discuss-gnuradio] Pybombs Prefix and Modtool

[Richard Bell]

Oh, this is news to me. I'll look into that.

Thanks,
Rich

On Tue, Mar 8, 2016 at 10:54 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> Yeah I think that should be fine. You could also use PyBOMBS to build
> your own OOT :)
>
> M
>
> On 03/08/2016 10:44 AM, Richard Bell wrote:
> > The OOT is not installed by Pybombs, because its my own custom OOT that
> > I made after using Pybombs. With this understanding Martin, would you
> > agree I need to do what Ron said to make custom OOTs work?
> >
> > Rich
> >
> > On Tue, Mar 8, 2016 at 10:18 AM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > If you're using PyBOMBS to install both GNU Radio and the OOT into
> the
> > same prefix, this is already happening. Also, once you've sourced
> > setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes?
> I'm
> >     not sure I fully understand your setup.
> >
> > Cheers,
> > Martin
> >
> > On 03/07/2016 10:32 PM, Richard Bell wrote:
> > > Thanks Ron, I will test it later tomorrow.
> > >
> > > Rich
> > >
> > > On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos <w...@comcast.net
> <mailto:w...@comcast.net>
> > > <mailto:w...@comcast.net <mailto:w...@comcast.net>>> wrote:
> > >
> > > When you build your OOT module, you have to use the same
> prefix as
> > > your GNU Radio install. This is done in the cmake stage with
> > > -DCMAKE_INSTALL_PREFIX. For example.
> > >
> > > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> > >
> > > Ron
> > >
> > >
> > > On 03/07/2016 02:21 PM, Richard Bell wrote:
> > >> Hi,
> > >>
> > >> I think I've narrowed down what I and some colleagues of mine
> > have
> > >> been experiencing enough to explain it and hopefully get a
> > solution.
> > >>
> > >> When I installed gr using the new pybombs, I specified a
> custom
> > >> prefix location (on several computers). It seems that later
> on,
> > >> when I create an OOT module using modtool, GRC does not
> interact
> > >> properly with these OOT modules, for some reason unknown to me
> > >> that I'm assuming is related to this prefix. The only
> > workaround I
> > >> know to get OOT modules to show up in GRC now is to add each
> OOT
> > >> module directory path to the GRC_BLOCKS_PATH env variable.
> This
> > >> causes XML parser errors to be reported everytime I open GRC,
> and
> > >> slows it down.
> > >>
> > >> So my question is this:
> > >>
> > >> With the old pybombs, I always used the default prefix and
> > >> thereafter modtool always worked. After sudo make install and
> > sudo
> > >> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
> > >> custom prefix, is there an additional step I am supposed to
> take
> > >> when making OOT blocks?
> > >>
> > >> Summary: Installed GR using new Pybombs in custom prefix.
> > >> Installing OOT module custom blocks does not work without
> editing
> > >> GRC_BLOCKS_PATH variable for each OOT path.
> > >>
> > >> Thanks,
> > >> Rich
> > >>
> > >>
> > >> ___
> > >> Discuss-gnuradio mailing list
> > >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>>
> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto: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] Pybombs Prefix and Modtool

[Richard Bell]

The OOT is not installed by Pybombs, because its my own custom OOT that I
made after using Pybombs. With this understanding Martin, would you agree I
need to do what Ron said to make custom OOTs work?

Rich

On Tue, Mar 8, 2016 at 10:18 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> If you're using PyBOMBS to install both GNU Radio and the OOT into the
> same prefix, this is already happening. Also, once you've sourced
> setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes? I'm
> not sure I fully understand your setup.
>
> Cheers,
> Martin
>
> On 03/07/2016 10:32 PM, Richard Bell wrote:
> > Thanks Ron, I will test it later tomorrow.
> >
> > Rich
> >
> > On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos <w...@comcast.net
> > <mailto:w...@comcast.net>> wrote:
> >
> > When you build your OOT module, you have to use the same prefix as
> > your GNU Radio install. This is done in the cmake stage with
> > -DCMAKE_INSTALL_PREFIX. For example.
> >
> > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> >
> > Ron
> >
> >
> > On 03/07/2016 02:21 PM, Richard Bell wrote:
> >> Hi,
> >>
> >> I think I've narrowed down what I and some colleagues of mine have
> >> been experiencing enough to explain it and hopefully get a solution.
> >>
> >> When I installed gr using the new pybombs, I specified a custom
> >> prefix location (on several computers). It seems that later on,
> >> when I create an OOT module using modtool, GRC does not interact
> >> properly with these OOT modules, for some reason unknown to me
> >> that I'm assuming is related to this prefix. The only workaround I
> >> know to get OOT modules to show up in GRC now is to add each OOT
> >> module directory path to the GRC_BLOCKS_PATH env variable. This
> >> causes XML parser errors to be reported everytime I open GRC, and
> >> slows it down.
> >>
> >> So my question is this:
> >>
> >> With the old pybombs, I always used the default prefix and
> >> thereafter modtool always worked. After sudo make install and sudo
> >> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
> >> custom prefix, is there an additional step I am supposed to take
> >> when making OOT blocks?
> >>
> >> Summary: Installed GR using new Pybombs in custom prefix.
> >> Installing OOT module custom blocks does not work without editing
> >> GRC_BLOCKS_PATH variable for each OOT path.
> >>
> >> Thanks,
> >> Rich
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto: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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs Prefix and Modtool

[Richard Bell]

Thanks Ron, I will test it later tomorrow.

Rich

On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos <w...@comcast.net> wrote:

> When you build your OOT module, you have to use the same prefix as your
> GNU Radio install. This is done in the cmake stage with
> -DCMAKE_INSTALL_PREFIX. For example.
>
> cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
>
> Ron
>
>
> On 03/07/2016 02:21 PM, Richard Bell wrote:
>
> Hi,
>
> I think I've narrowed down what I and some colleagues of mine have been
> experiencing enough to explain it and hopefully get a solution.
>
> When I installed gr using the new pybombs, I specified a custom prefix
> location (on several computers). It seems that later on, when I create an
> OOT module using modtool, GRC does not interact properly with these OOT
> modules, for some reason unknown to me that I'm assuming is related to this
> prefix. The only workaround I know to get OOT modules to show up in GRC now
> is to add each OOT module directory path to the GRC_BLOCKS_PATH env
> variable. This causes XML parser errors to be reported everytime I open
> GRC, and slows it down.
>
> So my question is this:
>
> With the old pybombs, I always used the default prefix and thereafter
> modtool always worked. After sudo make install and sudo ldconfig, my OOT
> blocks showed up in GRC. Since now I chose a custom prefix, is there an
> additional step I am supposed to take when making OOT blocks?
>
> Summary: Installed GR using new Pybombs in custom prefix. Installing OOT
> module custom blocks does not work without editing GRC_BLOCKS_PATH variable
> for each OOT path.
>
> Thanks,
> Rich
>
>
> ___
> 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

[Discuss-gnuradio] Pybombs Prefix and Modtool

[Richard Bell]

Hi,

I think I've narrowed down what I and some colleagues of mine have been
experiencing enough to explain it and hopefully get a solution.

When I installed gr using the new pybombs, I specified a custom prefix
location (on several computers). It seems that later on, when I create an
OOT module using modtool, GRC does not interact properly with these OOT
modules, for some reason unknown to me that I'm assuming is related to this
prefix. The only workaround I know to get OOT modules to show up in GRC now
is to add each OOT module directory path to the GRC_BLOCKS_PATH env
variable. This causes XML parser errors to be reported everytime I open
GRC, and slows it down.

So my question is this:

With the old pybombs, I always used the default prefix and thereafter
modtool always worked. After sudo make install and sudo ldconfig, my OOT
blocks showed up in GRC. Since now I chose a custom prefix, is there an
additional step I am supposed to take when making OOT blocks?

Summary: Installed GR using new Pybombs in custom prefix. Installing OOT
module custom blocks does not work without editing GRC_BLOCKS_PATH variable
for each OOT path.

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

Re: [Discuss-gnuradio] Frequency Lock Times

[Richard Bell]

Ooops.

Rich

On Thu, Mar 3, 2016 at 8:35 PM, Marcus D. Leech <mle...@ripnet.com> wrote:

> On 03/03/2016 11:30 PM, Ian Buckley wrote:
>
> er 0.8mS is 1250Hz.
>
> We were told there'd be no arithmetic
>
>
>
>
> On Thu, Mar 3, 2016 at 6:30 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I see thanks. My BW is several hundred MHz wide, so no all DSP tuning for
>> me.
>>
>> Rich
>>
>> On Thu, Mar 3, 2016 at 5:57 PM, Derek Kozel <derek.ko...@ettus.com>
>> wrote:
>>
>>> Also if your frequency hopping is within the analog bandwidth of the
>>> radio you may be able to use DSP tuning, which has almost instantaneous
>>> reactions.
>>>
>>>
>>> On Thu, Mar 3, 2016 at 5:39 PM, Marcus D. Leech <mle...@ripnet.com>
>>> wrote:
>>>
>>>> On 03/03/2016 08:35 PM, Richard Bell wrote:
>>>>
>>>>> I was reading in a separate thread that soon to be released UHD code
>>>>> will allow lock times on the order of 0.8 ms. Does this mean the fastest 
>>>>> we
>>>>> should expect to get a frequency hopping radio to work is at a hop rate of
>>>>> 1/0.008 = 125 Hz?
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>> With that particular radio, yes.
>>>>
>>>> That was for the B2xx series and E3xx series, which are based on the
>>>> AD9361/AD9364 chips, which were never really designed for
>>>>   fast frequency-hopping applications.
>>>>
>>>> The other RF cards, like WBX, SBX, CBX have faster PLL synthesizers, so
>>>> faster hopping is possible, although there are host-to-radio
>>>>   transaction times to consider as well.
>>>>
>>>>
>>>>
>>>> ___
>>>> 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 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] Frequency Lock Times

[Richard Bell]

I see thanks. My BW is several hundred MHz wide, so no all DSP tuning for
me.

Rich

On Thu, Mar 3, 2016 at 5:57 PM, Derek Kozel <derek.ko...@ettus.com> wrote:

> Also if your frequency hopping is within the analog bandwidth of the radio
> you may be able to use DSP tuning, which has almost instantaneous reactions.
>
>
> On Thu, Mar 3, 2016 at 5:39 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
>
>> On 03/03/2016 08:35 PM, Richard Bell wrote:
>>
>>> I was reading in a separate thread that soon to be released UHD code
>>> will allow lock times on the order of 0.8 ms. Does this mean the fastest we
>>> should expect to get a frequency hopping radio to work is at a hop rate of
>>> 1/0.008 = 125 Hz?
>>>
>>> Thanks,
>>> Rich
>>>
>>> With that particular radio, yes.
>>
>> That was for the B2xx series and E3xx series, which are based on the
>> AD9361/AD9364 chips, which were never really designed for
>>   fast frequency-hopping applications.
>>
>> The other RF cards, like WBX, SBX, CBX have faster PLL synthesizers, so
>> faster hopping is possible, although there are host-to-radio
>>   transaction times to consider as well.
>>
>>
>>
>> ___
>> 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] Frequency Lock Times

[Richard Bell]

I was reading in a separate thread that soon to be released UHD code will
allow lock times on the order of 0.8 ms. Does this mean the fastest we
should expect to get a frequency hopping radio to work is at a hop rate of
1/0.008 = 125 Hz?

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

Re: [Discuss-gnuradio] Custom Blocks not being found

[Richard Bell]

When I start grc from terminal, it lists
/usr/local/share/gnurado/grc/blocks as one of the block paths,
~/.grc_gnuradio being the other. This leads me to believe it knows to look
there. The gnuradio config.conf file also lists this as the global blocks
path.

I'm not at the laptop giving me issues right now, but since the issue does
not appear to be obvious to you, I'll double check everything once more to
make sure I'm not wasting your time.

Rich


On Thu, Feb 25, 2016 at 1:09 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> Are you sure GRC is looking for the files in
> /usr/local/share/gnurado/grc/blocks, and not elsewhere (e.g.
> /usr/share/gnurado/grc/blocks) ?
>
> M
>
>
> On 02/25/2016 01:03 PM, Richard Bell wrote:
> > Oh yes that's what I was trying to explain. This is an OOT module, with
> > a properly configured .xml file that I gave a category. This xml file
> > was installed to the gnuradio blocks tree directory as described in my
> > first email. I checked and it is there
> > (/usr/local/share/gnurado/grc/blocks). However, I do not see the
> > category or the block in the grc library list. The OOT is only
> > recognized when I use the export GRC_BLOCKS_PATH variable to point to my
> > OOT folder. This causes other xml related errors to occur everytime I
> > start grc, but I ignore them becaues it's the only way I can use the OOT
> > blocks at the moment.
> >
> > Rich
> >
> > On Thu, Feb 25, 2016 at 12:41 PM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > The block tree is the data structure that holds the blocks and what
> GRC
> > uses to sort them on the right-hand panel. Is this an OOT? Then you
> > typically put them into the block tree by having a  tag in
> > your XML.
> > The other option is a block tree file, which is what the in-tree
> > components use. You can use the block tree files in OOTs, too.
> >
> > Then make sure you run gnuradio-companion in a terminal. It'll print
> out
> > warning if it can't find stuff.
> >
> > M
> >
> >
> >
> > On 02/25/2016 12:37 PM, Richard Bell wrote:
> > > I think I'm misunderstanding you. I thought you were just asking
> me if I
> > > could find the blocks in the grc library, either manually or using
> > > Ctrl-F. That I cannot do.
> > >
> > > If they are not there, I don't know how to manually place them in
> the
> > > block tree, as it seems your saying I should do. How do I add them
> to
> > > the block tree as you say?
> > >
> > > Thanks,
> > > Rich
> > >
> >     > On Thu, Feb 25, 2016 at 12:31 PM, Martin Braun <
> martin.br...@ettus.com <mailto:martin.br...@ettus.com>
> > > <mailto:martin.br...@ettus.com <mailto:martin.br...@ettus.com>>>
> wrote:
> > >
> > > So if you put them in the block tree, do they show up?
> > >
> > > M
> > >
> > > On 02/25/2016 12:19 PM, Richard Bell wrote:
> > > > No they are not in the block tree.
> > > >
> > > > Rich
> > > >
> > > > On Thu, Feb 25, 2016 at 11:44 AM, Martin Braun <
> martin.br...@ettus.com <mailto:martin.br...@ettus.com>
> > <mailto:martin.br...@ettus.com <mailto:martin.br...@ettus.com>>
> > > > <mailto:martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com> <mailto:martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>>>>
> > > wrote:
> > > >
> > > > Are the blocks in the block tree? Can you see them by
> doing
> > > Ctrl-F +
> > > > search?
> > > >
> > > > M
> > > >
> > > > On 02/25/2016 11:40 AM, Richard Bell wrote:
> > > > > I've noticed lately that I can't just compile and
> > install custom
> > > > blocks
> > > > > and have them show up in grc. I've had to add a
> > GRC_BLOCKS_PATH
> > > > > environment variable that points to the location of my
> > > custom blocks
> > > > > folder to make them discoverable.
> > > > >
> > > > > Isn't the sudo make install process supposed to copy
&g

Re: [Discuss-gnuradio] Custom Blocks not being found

[Richard Bell]

Oh yes that's what I was trying to explain. This is an OOT module, with a
properly configured .xml file that I gave a category. This xml file was
installed to the gnuradio blocks tree directory as described in my first
email. I checked and it is there (/usr/local/share/gnurado/grc/blocks).
However, I do not see the category or the block in the grc library list.
The OOT is only recognized when I use the export GRC_BLOCKS_PATH variable
to point to my OOT folder. This causes other xml related errors to occur
everytime I start grc, but I ignore them becaues it's the only way I can
use the OOT blocks at the moment.

Rich

On Thu, Feb 25, 2016 at 12:41 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> The block tree is the data structure that holds the blocks and what GRC
> uses to sort them on the right-hand panel. Is this an OOT? Then you
> typically put them into the block tree by having a  tag in
> your XML.
> The other option is a block tree file, which is what the in-tree
> components use. You can use the block tree files in OOTs, too.
>
> Then make sure you run gnuradio-companion in a terminal. It'll print out
> warning if it can't find stuff.
>
> M
>
>
>
> On 02/25/2016 12:37 PM, Richard Bell wrote:
> > I think I'm misunderstanding you. I thought you were just asking me if I
> > could find the blocks in the grc library, either manually or using
> > Ctrl-F. That I cannot do.
> >
> > If they are not there, I don't know how to manually place them in the
> > block tree, as it seems your saying I should do. How do I add them to
> > the block tree as you say?
> >
> > Thanks,
> > Rich
> >
> > On Thu, Feb 25, 2016 at 12:31 PM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > So if you put them in the block tree, do they show up?
> >
> > M
> >
> > On 02/25/2016 12:19 PM, Richard Bell wrote:
> > > No they are not in the block tree.
> > >
> > > Rich
> > >
> > > On Thu, Feb 25, 2016 at 11:44 AM, Martin Braun <
> martin.br...@ettus.com <mailto:martin.br...@ettus.com>
> > > <mailto:martin.br...@ettus.com <mailto:martin.br...@ettus.com>>>
> > wrote:
> > >
> > > Are the blocks in the block tree? Can you see them by doing
> > Ctrl-F +
> > > search?
> > >
> > > M
> > >
> > > On 02/25/2016 11:40 AM, Richard Bell wrote:
> > > > I've noticed lately that I can't just compile and install
> custom
> > > blocks
> > > > and have them show up in grc. I've had to add a
> GRC_BLOCKS_PATH
> > > > environment variable that points to the location of my
> > custom blocks
> > > > folder to make them discoverable.
> > > >
> > > > Isn't the sudo make install process supposed to copy the
> > required
> > > files
> > > > to known places that gnuradio can find them so I don't have
> > to worry
> > > > about this? For example, I do see the custom blocks .xmls in
> the
> > > > /usr/local/share/gnurado/grc/blocks directory after
> installing.
> > > >
> > > > To make sure I'm not being silly and forgetting something,
> > here is my
> > > > process:
> > > >
> > > > 1) Create a new block in a random directory with gr_modtool
> > and get
> > > > ready to compile and install
> > > >
> > > > 2) Create a build directory and do the following from within
> > build:
> > > >
> > > > cmake ..
> > > > sudo make install
> > > > sudo ldconfig
> > > >
> > > > 3) Re-open grc and see your new blocks in the library
> > > >
> > > > Is this a bug or am I overlooking something? Could it be
> > related to
> > > > using the new pybombs?
> > > >
> > > > Rich
> > > >
> > > >
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>>
> > >

Re: [Discuss-gnuradio] Custom Blocks not being found

[Richard Bell]

I think I'm misunderstanding you. I thought you were just asking me if I
could find the blocks in the grc library, either manually or using Ctrl-F.
That I cannot do.

If they are not there, I don't know how to manually place them in the block
tree, as it seems your saying I should do. How do I add them to the block
tree as you say?

Thanks,
Rich

On Thu, Feb 25, 2016 at 12:31 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> So if you put them in the block tree, do they show up?
>
> M
>
> On 02/25/2016 12:19 PM, Richard Bell wrote:
> > No they are not in the block tree.
> >
> > Rich
> >
> > On Thu, Feb 25, 2016 at 11:44 AM, Martin Braun <martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> >
> > Are the blocks in the block tree? Can you see them by doing Ctrl-F +
> > search?
> >
> > M
> >
> > On 02/25/2016 11:40 AM, Richard Bell wrote:
> > > I've noticed lately that I can't just compile and install custom
> > blocks
> > > and have them show up in grc. I've had to add a GRC_BLOCKS_PATH
> > > environment variable that points to the location of my custom
> blocks
> > > folder to make them discoverable.
> > >
> > > Isn't the sudo make install process supposed to copy the required
> > files
> > > to known places that gnuradio can find them so I don't have to
> worry
> > > about this? For example, I do see the custom blocks .xmls in the
> > > /usr/local/share/gnurado/grc/blocks directory after installing.
> > >
> > > To make sure I'm not being silly and forgetting something, here is
> my
> > > process:
> > >
> > > 1) Create a new block in a random directory with gr_modtool and get
> > > ready to compile and install
> > >
> > > 2) Create a build directory and do the following from within build:
> > >
> > > cmake ..
> > > sudo make install
> > > sudo ldconfig
> > >
> > > 3) Re-open grc and see your new blocks in the library
> > >
> > > Is this a bug or am I overlooking something? Could it be related to
> > > using the new pybombs?
> > >
> > > Rich
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto: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] Custom Blocks not being found

[Richard Bell]

No they are not in the block tree.

Rich

On Thu, Feb 25, 2016 at 11:44 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> Are the blocks in the block tree? Can you see them by doing Ctrl-F +
> search?
>
> M
>
> On 02/25/2016 11:40 AM, Richard Bell wrote:
> > I've noticed lately that I can't just compile and install custom blocks
> > and have them show up in grc. I've had to add a GRC_BLOCKS_PATH
> > environment variable that points to the location of my custom blocks
> > folder to make them discoverable.
> >
> > Isn't the sudo make install process supposed to copy the required files
> > to known places that gnuradio can find them so I don't have to worry
> > about this? For example, I do see the custom blocks .xmls in the
> > /usr/local/share/gnurado/grc/blocks directory after installing.
> >
> > To make sure I'm not being silly and forgetting something, here is my
> > process:
> >
> > 1) Create a new block in a random directory with gr_modtool and get
> > ready to compile and install
> >
> > 2) Create a build directory and do the following from within build:
> >
> > cmake ..
> > sudo make install
> > sudo ldconfig
> >
> > 3) Re-open grc and see your new blocks in the library
> >
> > Is this a bug or am I overlooking something? Could it be related to
> > using the new pybombs?
> >
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Custom Blocks not being found

[Richard Bell]

I've noticed lately that I can't just compile and install custom blocks and
have them show up in grc. I've had to add a GRC_BLOCKS_PATH environment
variable that points to the location of my custom blocks folder to make
them discoverable.

Isn't the sudo make install process supposed to copy the required files to
known places that gnuradio can find them so I don't have to worry about
this? For example, I do see the custom blocks .xmls in the
/usr/local/share/gnurado/grc/blocks directory after installing.

To make sure I'm not being silly and forgetting something, here is my
process:

1) Create a new block in a random directory with gr_modtool and get ready
to compile and install

2) Create a build directory and do the following from within build:

cmake ..
sudo make install
sudo ldconfig

3) Re-open grc and see your new blocks in the library

Is this a bug or am I overlooking something? Could it be related to using
the new pybombs?

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

Re: [Discuss-gnuradio] Async Message to File

[Richard Bell]

Sorry, still not working. Values seem to be either 0 or gigantic. I think
it's because the single 64 bit value is being written as 8 consecutive
bytes as you said, and I'm not handling that anywhere once I read the file
into octave. I'll try and figure it out next time I'm working on this.

Thanks,
Rich

On Thu, Feb 18, 2016 at 3:12 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Argh, sorry, to_float returns a float64, which of course means that
> Python's file.write is a bit confused by this request, and it's getting
> late :/ concentration used to be better.
>
> So, add
> import struct
> where the other imports are.
>
> Then,
> self._file.write(struct.pack("d", pmt.to_float(msg) ) )
> should
> 1. get the 64 bit float from the pmt message,
> 2. pack that into a string object according to the format "d" (which
> simply says, take a single double and give it to me as raw 8 bytes)
> 3. writes that to the file.
>
> Best regards,
> Marcus
>
>
> On 19.02.2016 00:05, Richard Bell wrote:
>
> Sorry Marcus, I'm not familiar with pmts and message passing things to
> handle these errors on my own. When I change
> "self._file.write(pmt.serialize_str(msg))" to
> "self._file.write(pmt.to_float(msg))", I get the following error in grc
> terminal
>
> handler caught exception: expected a character buffer object
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
> line 73, in eval
> try: self._callback(arg)
>   File "/usr/local/lib/python2.7/dist-packages/msgtools/msg_file_sink.py",
> line 41, in _msg_handler
> self._file.write(pmt.to_float(msg))
> TypeError: expected a character buffer object
> thread[thread-per-block[101]: ]: caught
> unrecognized exception
>
> Thanks for the help.
>
> Rich
>
> On Thu, Feb 18, 2016 at 2:55 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Ah, sorry, no, the block just takes the raw serialized pmt and writes it
>> to a file [1]:
>>
>> self._file.write(pmt.serialize_str(msg))
>>
>> You could use python with pmt module to unserialize, but:
>>
>> if you just replace "serialize_str" with "to_float", this should give you
>> what you expect. Notice this is really just experimental; copy the block to
>> your own code. I'll probably rewrite as something in C++ to make it useful
>> on platforms without python, too.
>>
>> Cheers,
>> Marcus
>>
>> [1]
>> https://github.com/marcusmueller/gr-msgtools/blob/master/python/msg_file_sink.py#L41
>>
>>
>> On 18.02.2016 23:13, Richard Bell wrote:
>>
>> I just tested it. I expect to see log scale values of SNR coming out of
>> the estimator block. When I look at this directly using a function_probe
>> and qt_gui_label in grc, I see proper estimates. When I load the file
>> produced by the msg_file_snk into octave, I see incorrect values ranging
>> from e-40 to e+40. I assumed the msg_file_snk stored values as float, so I
>> used the read_float_binary.m script on the file to plot. Are we having a
>> type conversion issue here?
>>
>> Rich
>>
>> On Thu, Feb 18, 2016 at 1:33 PM, Marcus Müller <
>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote:
>>
>>> Sorry, I forgot to git push; could you git pull?
>>>
>>> On 02/18/2016 10:27 PM, Richard Bell wrote:
>>>
>>> There is only one block in your git, Variable To Message, and no built
>>> in Message File Sink in GR. I'm using gr 3.7.10. How did you see this being
>>> used?
>>>
>>> Rich
>>>
>>> On Thu, Feb 18, 2016 at 1:12 PM, Richard Bell <
>>> <richard.be...@gmail.com>richard.be...@gmail.com> wrote:
>>>
>>>> Excellent thanks.
>>>>
>>>> Rich
>>>>
>>>> On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller <
>>>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote:
>>>>
>>>>> Sorry, took a while longer, juggling multiple mails:
>>>>> <https://github.com/marcusmueller/gr-msgtools>
>>>>> https://github.com/marcusmueller/gr-msgtools
>>>>>
>>>>> use the msg_file_sink :)
>>>>>
>>>>>
>>>>> On 02/18/2016 09:35 PM, Marcus Müller wrote:
>>>>>
>>>>> From the top of my head, there's nothing that does that... yet.
>>>>> Let's see if I can hack together something in python that does that.
>>>&g

Re: [Discuss-gnuradio] Async Message to File

[Richard Bell]

Sorry Marcus, I'm not familiar with pmts and message passing things to
handle these errors on my own. When I change
"self._file.write(pmt.serialize_str(msg))" to
"self._file.write(pmt.to_float(msg))", I get the following error in grc
terminal

handler caught exception: expected a character buffer object
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py",
line 73, in eval
try: self._callback(arg)
  File "/usr/local/lib/python2.7/dist-packages/msgtools/msg_file_sink.py",
line 41, in _msg_handler
self._file.write(pmt.to_float(msg))
TypeError: expected a character buffer object
thread[thread-per-block[101]: ]: caught
unrecognized exception

Thanks for the help.

Rich

On Thu, Feb 18, 2016 at 2:55 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Ah, sorry, no, the block just takes the raw serialized pmt and writes it
> to a file [1]:
>
> self._file.write(pmt.serialize_str(msg))
>
> You could use python with pmt module to unserialize, but:
>
> if you just replace "serialize_str" with "to_float", this should give you
> what you expect. Notice this is really just experimental; copy the block to
> your own code. I'll probably rewrite as something in C++ to make it useful
> on platforms without python, too.
>
> Cheers,
> Marcus
>
> [1]
> https://github.com/marcusmueller/gr-msgtools/blob/master/python/msg_file_sink.py#L41
>
>
> On 18.02.2016 23:13, Richard Bell wrote:
>
> I just tested it. I expect to see log scale values of SNR coming out of
> the estimator block. When I look at this directly using a function_probe
> and qt_gui_label in grc, I see proper estimates. When I load the file
> produced by the msg_file_snk into octave, I see incorrect values ranging
> from e-40 to e+40. I assumed the msg_file_snk stored values as float, so I
> used the read_float_binary.m script on the file to plot. Are we having a
> type conversion issue here?
>
> Rich
>
> On Thu, Feb 18, 2016 at 1:33 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Sorry, I forgot to git push; could you git pull?
>>
>> On 02/18/2016 10:27 PM, Richard Bell wrote:
>>
>> There is only one block in your git, Variable To Message, and no built in
>> Message File Sink in GR. I'm using gr 3.7.10. How did you see this being
>> used?
>>
>> Rich
>>
>> On Thu, Feb 18, 2016 at 1:12 PM, Richard Bell < <richard.be...@gmail.com>
>> richard.be...@gmail.com> wrote:
>>
>>> Excellent thanks.
>>>
>>> Rich
>>>
>>> On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller <
>>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote:
>>>
>>>> Sorry, took a while longer, juggling multiple mails:
>>>> https://github.com/marcusmueller/gr-msgtools
>>>>
>>>> use the msg_file_sink :)
>>>>
>>>>
>>>> On 02/18/2016 09:35 PM, Marcus Müller wrote:
>>>>
>>>> From the top of my head, there's nothing that does that... yet.
>>>> Let's see if I can hack together something in python that does that.
>>>> Gimme a second.
>>>>
>>>> On 02/18/2016 09:22 PM, Richard Bell wrote:
>>>>
>>>> I want to store the output SNR measurement messages of the MPSK SNR
>>>> Estimator Probe to a file, but I'm not sure how to transform async messages
>>>> to a stream to get them into a file. Would someone please recommend a
>>>> method of doing this in GRC.
>>>>
>>>> Rich
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Async Message to File

[Richard Bell]

I just tested it. I expect to see log scale values of SNR coming out of the
estimator block. When I look at this directly using a function_probe and
qt_gui_label in grc, I see proper estimates. When I load the file produced
by the msg_file_snk into octave, I see incorrect values ranging from e-40
to e+40. I assumed the msg_file_snk stored values as float, so I used the
read_float_binary.m script on the file to plot. Are we having a type
conversion issue here?

Rich

On Thu, Feb 18, 2016 at 1:33 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Sorry, I forgot to git push; could you git pull?
>
> On 02/18/2016 10:27 PM, Richard Bell wrote:
>
> There is only one block in your git, Variable To Message, and no built in
> Message File Sink in GR. I'm using gr 3.7.10. How did you see this being
> used?
>
> Rich
>
> On Thu, Feb 18, 2016 at 1:12 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Excellent thanks.
>>
>> Rich
>>
>> On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller <
>> <marcus.muel...@ettus.com>marcus.muel...@ettus.com> wrote:
>>
>>> Sorry, took a while longer, juggling multiple mails:
>>> https://github.com/marcusmueller/gr-msgtools
>>>
>>> use the msg_file_sink :)
>>>
>>>
>>> On 02/18/2016 09:35 PM, Marcus Müller wrote:
>>>
>>> From the top of my head, there's nothing that does that... yet.
>>> Let's see if I can hack together something in python that does that.
>>> Gimme a second.
>>>
>>> On 02/18/2016 09:22 PM, Richard Bell wrote:
>>>
>>> I want to store the output SNR measurement messages of the MPSK SNR
>>> Estimator Probe to a file, but I'm not sure how to transform async messages
>>> to a stream to get them into a file. Would someone please recommend a
>>> method of doing this in GRC.
>>>
>>> Rich
>>>
>>>
>>> ___
>>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Async Message to File

[Richard Bell]

There is only one block in your git, Variable To Message, and no built in
Message File Sink in GR. I'm using gr 3.7.10. How did you see this being
used?

Rich

On Thu, Feb 18, 2016 at 1:12 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> Excellent thanks.
>
> Rich
>
> On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Sorry, took a while longer, juggling multiple mails:
>> https://github.com/marcusmueller/gr-msgtools
>>
>> use the msg_file_sink :)
>>
>>
>> On 02/18/2016 09:35 PM, Marcus Müller wrote:
>>
>> From the top of my head, there's nothing that does that... yet.
>> Let's see if I can hack together something in python that does that.
>> Gimme a second.
>>
>> On 02/18/2016 09:22 PM, Richard Bell wrote:
>>
>> I want to store the output SNR measurement messages of the MPSK SNR
>> Estimator Probe to a file, but I'm not sure how to transform async messages
>> to a stream to get them into a file. Would someone please recommend a
>> method of doing this in GRC.
>>
>> Rich
>>
>>
>> ___
>> 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] Async Message to File

[Richard Bell]

Excellent thanks.

Rich

On Thu, Feb 18, 2016 at 1:09 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Sorry, took a while longer, juggling multiple mails:
> https://github.com/marcusmueller/gr-msgtools
>
> use the msg_file_sink :)
>
>
> On 02/18/2016 09:35 PM, Marcus Müller wrote:
>
> From the top of my head, there's nothing that does that... yet.
> Let's see if I can hack together something in python that does that. Gimme
> a second.
>
> On 02/18/2016 09:22 PM, Richard Bell wrote:
>
> I want to store the output SNR measurement messages of the MPSK SNR
> Estimator Probe to a file, but I'm not sure how to transform async messages
> to a stream to get them into a file. Would someone please recommend a
> method of doing this in GRC.
>
> Rich
>
>
> ___
> 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

[Discuss-gnuradio] Async Message to File

[Richard Bell]

I want to store the output SNR measurement messages of the MPSK SNR
Estimator Probe to a file, but I'm not sure how to transform async messages
to a stream to get them into a file. Would someone please recommend a
method of doing this in GRC.

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

Re: [Discuss-gnuradio] non-diff QPSK symbol sync, improper alignemnt/errors using real msg

[Richard Bell]

What are you doing to handle the phase ambiguity that diff encoding is
intended to fix?

Rich

On Wed, Feb 17, 2016 at 2:35 PM, Landsman, Arik 
wrote:

> Hello Folks,
>
> I am debugging a flowgraph of QPSK without diff encoding. The aim here is
> to tx messages between two N210's, as a starting point for a heterogeneous
> networking project. long story short, I am seeing an issue
> sending/receiving a real message within the same flow graph (just direct
> connection to the Rx portion)
>
> Please read on..
>
> The Tx msg is:
> "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 4B 4B 4B 4B 20 20 48 65 6C 6C 6F 20 57 6F 72 6C 64 20 20 4B
> 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00"
>
> where,
>   "4B" is a rotating vector to allow costas to lock (not used here while
> in debug)
>   "20 20 48 65 6C 6C 6F 20 57 6F 72 6C 64 20 20" = "  Hello World  "
>   "00" is just padding (I tried a psudo-random sequence instead, 4096 bits
> long on either side of msg, similar results)
>
> the rx msg is (consistently across runs):
> "C0 03 3C 3C 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 48 4B 4B 4B 13 10 48 98 DA D8 D8 13 A8 DB 3B D9
> 98 10 10 48 4B 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
>
> Added 4bit delay to align the samples before the file sink. Note that "4B"
> is ok, but the 0x20 expected right after is typically passed as 0x10. rest
> of the msg is scrambled, consistently.
>
> My signal chain is as follow:
> file source -- const mod (see const object below) -- throttle (320k) --
> Polyphase CS (or Clock Rec MM, same result) -- const soft decoder (using
> same const object) -- binary slicer / bit packing / file sink
>
> const rect object:
>   sym map: digital.psk_4()[1] // evals to [0,1,2,3]
>   points: digital.psk_4()[0] // evals to [(-1-1j), (1-1j), (-1+1j),
> (1+1j)]
>   [..]
>   Soft Decision LUT: 'auto'
>
> Polyphase Clock
>   sps: 8
>   taps: firdes.root_raised_cosine(32, 32, 1.0, 0.5, int(5*sps*32))
>   *rest is at default, LB = 2*3.14/100
>
> excess bw = 0.5
>
> when on repeat, the binary out of the soft decoder looks crisp, easy for
> binary slicer to decide.
>
> not sure what RRC taps are used in the Const Mod block - maybe the RRC in
> the PPCS doesn't match. Seems close enough though, same as in similar
> examples that use the Const Mod block. again, decoded binary looks clean.
>
> Few questions...
>
> had anyone seen this before, i.e. dropped bits or incorrectly decoded
> symbols W/O using Costas?
> any thoughts on new debug directions? the two active blocks are the
> Constel Mod and the PPCS (or MM, same result)
> Did anyone in general try non diff-encoded QPSK transmission using a real
> message? Seems like diff encoding was laways ON while QA'ing the psk
> blocks. I haven't seen an example online as of yet (although plenty of good
> material that uses psudo-random)
>
> Thank you in advance!
>
> Arik Landsman
>
>
> ___
> 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] Building GNU-Radio for Windows

[Richard Bell]

Hi Rowan,

Getting GNU Radio working on Windows is not elementary, as there is very
little support for this. I have tried it myself in the past with no
success. It is certainly possible, as people do it, but these people get it
working with very little support beyond their own knowledge.

The easiest way to use GNU Radio on a Windows machine, is to use the GNU
Radio Live Images to boot from either a DVD or Thumb drive (i.e. bypass
Windows), which gives you Linux and a full GNU Radio install with very
little work on your end and doesn't disrupt your Windows install.

If you really need GNU Radio in a Windows environment, you'll have to hope
someone more knowledgeable responds, but it is certainly not elementary.

Rich

On Mon, Feb 15, 2016 at 11:22 AM, Rowan Sylvester-Bradley <
ro...@sylvesterbradley.org> wrote:

> I'm sorry, this is no doubt a very elementary question. I am completely
> new to GNU Radio, and know little about Unix or many of the tools involved.
> I have tried to follow the instructions on the page
> http://gnuradio.org/redmine/projects/gnuradio/wiki/MingwInstallMain.
> While installing Boost, when I try to execute the command ./bootstrap.sh
> --with-toolset=mingw I get the errors:
>
>
>
> ###
>
> ### Using 'mingw' toolset.
>
> ###
>
> rm -rf bootstrap
>
> mkdir bootstrap
>
> gcc -DNT -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c
> hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c
> make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c
> rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c
> filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c
> modules/set.c modules/path.c modules/regex.c modules/property-set.c
> modules/sequence.c modules/order.c execnt.c filent.c
>
> jam.c: In function `main':
>
> jam.c:403: error: `environ' undeclared (first use in this function)
>
> jam.c:403: error: (Each undeclared identifier is reported only once
>
> jam.c:403: error: for each function it appears in.)
>
> pathunix.c:276:19: tchar.h: No such file or directory
>
> pathunix.c: In function `ShortPathToLongPath':
>
> pathunix.c:287: error: `_MAX_PATH' undeclared (first use in this function)
>
> pathunix.c:287: error: (Each undeclared identifier is reported only once
>
> pathunix.c:287: error: for each function it appears in.)
>
> pathunix.c: In function `short_path_to_long_path':
>
> pathunix.c:387: error: `_MAX_PATH' undeclared (first use in this function)
>
> filent.c: In function `file_dirscan':
>
> filent.c:84: error: storage size of 'finfo' isn't known
>
> filent.c:166: error: `_A_SUBDIR' undeclared (first use in this function)
>
> filent.c:166: error: (Each undeclared identifier is reported only once
>
> filent.c:166: error: for each function it appears in.)
>
>
>
> Can someone tell me why I am getting all these "undeclared" errors, or
> what to do to fix them, or what to do next to find out what’s wrong?
>
>
>
> Thanks - Rowan
>
>
>
> ___
> 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] Remote Control Question, Control Ports?

[Richard Bell]

Hey all,

 I just started writing a python script that will control two radios via
Ethernet to conduct various tests. Each radio has its own computer and the
receiver is considered the master (it will make all the control decisions).

There will be two python scripts handshaking with each other, to do things
like this:

1) Assume both computers are on and listening to a socket, I don't want to
worry about setting this part up programmatically.

2) I start the receiver script manually

3) The receiver radio starts listening and  sends a command to the
transmitter computer to start transmitting

4) The transmitter computer receives the message to start sending, and
starts sending. While sending data, it is listening for a command to stop.

5) The receiver reaches some DONE condition, stops itself and sends a
command to the transmitter to stop and reconfigure for the next test.

6) The process starts over again

It occurred to me that control ports might be what I want to use to do this
stuff, instead of going a pure python route. Would someone recommend a
course of action that stays as close to GNU Radio as possible. The more
contained the better. I'd like to use tools that are intended for this type
of thing if they already exist in GNU Radio.

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

[Discuss-gnuradio] Pybombs Question

[Richard Bell]

What is the new way of setting up environment variables, I'm not able to
find information on that.

The old way was to run './pybombs env' and source this auto-generated file
from .bashrc file.

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

Re: [Discuss-gnuradio] Pybombs Question

[Richard Bell]

Ah, didn't notice it there.

Thanks,
Rich

On Wed, Feb 10, 2016 at 1:27 PM, Seth Hitefield <sd...@vt.edu> wrote:

> The environment variable file (setup_env) is automatically generated when
> you create a new prefix. You simply need to source it as before in .bashrc
>
> -- Seth
>
>
> On 02/10/2016 04:23 PM, Richard Bell wrote:
>
> What is the new way of setting up environment variables, I'm not able to
> find information on that.
>
> The old way was to run './pybombs env' and source this auto-generated file
> from .bashrc file.
>
> Rich
>
>
> ___
> 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

[Discuss-gnuradio] Awesome New Stuff in GR3.7.10!

[Richard Bell]

Hey developers,

I just wanted to give you guys some positive feedback on two new things
that I've immediately noticed and benefited from since upgrading to
gr3.7.10 from gr3.7.8.

1) Bypass block (aka comment through in other tools). I've wished for this
for a while. Love it!

2) Unconnected GUI blocks don't cause GRC errors. Love this too!

Thanks again.

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

[Discuss-gnuradio] Digital TV with USRP and GNU Radio

[Richard Bell]

Does anyone know of a good tutorial that shows how to receive and display
TV on Ubuntu using a USRP and GNU Radio? I'm interested.

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

Re: [Discuss-gnuradio] Digital TV with USRP and GNU Radio

[Richard Bell]

Got it. Thanks Tom.

Rich

On Wed, Jan 6, 2016 at 8:26 AM, Tom Rondeau <t...@trondeau.com> wrote:

> On Wed, Jan 6, 2016 at 11:09 AM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Does anyone know of a good tutorial that shows how to receive and display
>> TV on Ubuntu using a USRP and GNU Radio? I'm interested.
>>
>> Rich
>>
>
>
> Rich,
>
> I'm not sure anyone's written it up, but there are examples in
> gr-dtv/examples. I just looked, and we've neglected to add the files to the
> CMakeLists.txt file to install these properly. Regardless, if you have the
> source code, look at uhd_atsc_capture.grc and file_atsc_rx.grc. If you have
> a powerful enough machine, you can also try uhd_rx_atsc.grc directly.
>
> I think it'd be great if someone wrote a tutorial showing to how use these.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS -- You Can Vote Now!

[Richard Bell]

Hey Martin,

Is there anyway for us to see results in real time before the official
closure and announcement?

Rich

On Tue, Dec 29, 2015 at 10:30 AM, Martin Braun 
wrote:

> Hi everyone,
>
> new names for PyBOMBS are up for vote now at:
>
> http://goo.gl/forms/nUfCOZWCY2
>
> This includes most names that were suggested on the list, and some that
> were suggested in #gnuradio (the latter had a higher ratio of
> questionable suggestions...). However, I subtracted all the names that
> were already package names in pip, which is quite a lot, and
> unfortunately included 'grab'.
>
> Also, I'm deliberately leaving out expansions of acronyms. You can make
> them mean whatever you like.
>
> So, please vote!
>
> Cheers,
> Martin
>
> Disclaimer: I'll reserve the right to overrule the outcome if there's a
> really good reason.
>
> ___
> 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] Renaming PyBOMBS

[Richard Bell]

I'd like to throw in another point from an entry level perspective. Those
people who might need pybombs most, are those who need names that tell them
what it's for the most. Even if it is incorrect to call pybombs an
installer, it would really help the entry level folks (which I would claim
without support is the largest population of the community at any given
time) understand what it's for and how they should use it. I think we all
have the experience of learning new tools and running into tool names,
which even though the description is spot on for what its for, at the time
carried zero value for the new guy using it (thinking mostly about Xilinx
tool names here).

With that said, I think it would be good for the community to use the word
installer in the tool that makes gnuradio and uhd really easy to install,
and is what the vast majority of people I'm guessing would use it for.

On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> On 23.12.2015 09:28, Stefan Wunsch wrote:
> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and
> > you can think of the associated sentences ;)
>
> 'grab' is also a very common english verb, so I think people would be
> able to distinguish. It also sounds like 'crab' if you like :)
>
> M
>
> >
> > On 12/22/2015 09:31 PM, Richard Bell wrote:
> >> GRAB = Gnu RAdio Basic installer
> >>
> >> Then we can say things like "Go GRAB it" when referring to a needed
> module
> >>
> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <martin.br...@ettus.com>
> >> wrote:
> >>
> >>> There's been some demand to rename PyBOMBS, and now that we're
> >>> re-releasing it, this is a good time to think about it. Complaints
> about
> >>> the name include:
> >>>
> >>> - It may or may not be true that people have been detained by TSA for
> >>> working on PyBOMBS at the airport[1]
> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
> >>> rather than a GNU Radio-related tool
> >>> - People can't agree on a capitalization
> >>> - No one can remember what the acronym stands for
> >>>
> >>> Sure, this is not a critical thing, but now's a good chance to bring it
> >>> up and also, this is not a joke :)
> >>>
> >>> Here's how we're going to do this:
> >>>
> >>> - Please suggest new names in this thread.
> >>> - I will choose from those names based on 'can I live with this name',
> >>> 100% subjectively.
> >>> - New names will be put up for a vote. This will include an option to
> >>> keep the old name.
> >>> - Finally, the result of the vote will be used as a strong suggestion
> on
> >>> what the new name will be.
> >>>
> >>> There already have been some suggestions:
> >>>
> >>> - gromit -- the GNU Radio out-of-tree module installation tool
> >>> - the groot
> >>> - grpm -- the GNU Radio package manager
> >>>
> >>>
> >>> OK guys, bring up the ideas!
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>> [1] It's not.
> >>>
> >>> ___
> >>> 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 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] Renaming PyBOMBS

[Richard Bell]

Yeah I should have clarified that. I tried the full package manager route
of install about 2 years ago for gnuradio and uhd. It didn't work. I
installed uhd through apt-get and gnuradio through apt-get with no success.

I'm just bringing that up so we don't assume that is an easy possibility
for someone to do. As far as I know from my stab at it two years ago, it's
not viable. Someone should try that route now to see if it is before we
assume anything.

On Wed, Dec 23, 2015 at 10:38 AM, Tim O'Shea <tim.oshea...@gmail.com> wrote:

> Ubuntu packages uhd
> Assuming other oses do too
> I'm sure there are up to date ppas somewhere too
>
>
> On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Is there a way for a new user to get uhd installed from the package
>> manager though? A lot of people want to dive right into gnu radio with
>> hardware, doing simple things like spectrum analysis. I'm not aware of a
>> way of getting the uhd + gnuradio setup running that's easier then pybombs.
>> I very well could be wrong here.
>>
>> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com>
>> wrote:
>>
>>> Most new users should be installing gnu radio binaries via their os
>>> package manager repos or ppa.   Pybombs should be used for 1. Helping get
>>> up to date oot modules set up and deployed ( like pip ) and 2. Helping
>>> developers set up their development environment.
>>> So I'm not sure installer is the right idea to impart on new users at all
>>>
>>>
>>> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com>
>>> wrote:
>>>
>>>> I'd like to throw in another point from an entry level perspective.
>>>> Those people who might need pybombs most, are those who need names that
>>>> tell them what it's for the most. Even if it is incorrect to call pybombs
>>>> an installer, it would really help the entry level folks (which I would
>>>> claim without support is the largest population of the community at any
>>>> given time) understand what it's for and how they should use it. I think we
>>>> all have the experience of learning new tools and running into tool names,
>>>> which even though the description is spot on for what its for, at the time
>>>> carried zero value for the new guy using it (thinking mostly about Xilinx
>>>> tool names here).
>>>>
>>>> With that said, I think it would be good for the community to use the
>>>> word installer in the tool that makes gnuradio and uhd really easy to
>>>> install, and is what the vast majority of people I'm guessing would use it
>>>> for.
>>>>
>>>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com>
>>>> wrote:
>>>>
>>>>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well
>>>>> and
>>>>> > you can think of the associated sentences ;)
>>>>>
>>>>> 'grab' is also a very common english verb, so I think people would be
>>>>> able to distinguish. It also sounds like 'crab' if you like :)
>>>>>
>>>>> M
>>>>>
>>>>> >
>>>>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>>>>> >> GRAB = Gnu RAdio Basic installer
>>>>> >>
>>>>> >> Then we can say things like "Go GRAB it" when referring to a needed
>>>>> module
>>>>> >>
>>>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>>>>> martin.br...@ettus.com>
>>>>> >> wrote:
>>>>> >>
>>>>> >>> There's been some demand to rename PyBOMBS, and now that we're
>>>>> >>> re-releasing it, this is a good time to think about it. Complaints
>>>>> about
>>>>> >>> the name include:
>>>>> >>>
>>>>> >>> - It may or may not be true that people have been detained by TSA
>>>>> for
>>>>> >>> working on PyBOMBS at the airport[1]
>>>>> >>> - The name suggests a Python-related packages (like Pylint,
>>>>> PyPI...)
>>>>> >>> rather than a GNU Radio-related tool
>>>>> >>> - People can't agree on a capitalization
>>>>> >>> - No one can remember

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Richard Bell]

Is there a way for a new user to get uhd installed from the package manager
though? A lot of people want to dive right into gnu radio with hardware,
doing simple things like spectrum analysis. I'm not aware of a way of
getting the uhd + gnuradio setup running that's easier then pybombs. I very
well could be wrong here.

On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com> wrote:

> Most new users should be installing gnu radio binaries via their os
> package manager repos or ppa.   Pybombs should be used for 1. Helping get
> up to date oot modules set up and deployed ( like pip ) and 2. Helping
> developers set up their development environment.
> So I'm not sure installer is the right idea to impart on new users at all
>
>
> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I'd like to throw in another point from an entry level perspective. Those
>> people who might need pybombs most, are those who need names that tell them
>> what it's for the most. Even if it is incorrect to call pybombs an
>> installer, it would really help the entry level folks (which I would claim
>> without support is the largest population of the community at any given
>> time) understand what it's for and how they should use it. I think we all
>> have the experience of learning new tools and running into tool names,
>> which even though the description is spot on for what its for, at the time
>> carried zero value for the new guy using it (thinking mostly about Xilinx
>> tool names here).
>>
>> With that said, I think it would be good for the community to use the
>> word installer in the tool that makes gnuradio and uhd really easy to
>> install, and is what the vast majority of people I'm guessing would use it
>> for.
>>
>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com>
>> wrote:
>>
>>> On 23.12.2015 09:28, Stefan Wunsch wrote:
>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well
>>> and
>>> > you can think of the associated sentences ;)
>>>
>>> 'grab' is also a very common english verb, so I think people would be
>>> able to distinguish. It also sounds like 'crab' if you like :)
>>>
>>> M
>>>
>>> >
>>> > On 12/22/2015 09:31 PM, Richard Bell wrote:
>>> >> GRAB = Gnu RAdio Basic installer
>>> >>
>>> >> Then we can say things like "Go GRAB it" when referring to a needed
>>> module
>>> >>
>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun <
>>> martin.br...@ettus.com>
>>> >> wrote:
>>> >>
>>> >>> There's been some demand to rename PyBOMBS, and now that we're
>>> >>> re-releasing it, this is a good time to think about it. Complaints
>>> about
>>> >>> the name include:
>>> >>>
>>> >>> - It may or may not be true that people have been detained by TSA for
>>> >>> working on PyBOMBS at the airport[1]
>>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...)
>>> >>> rather than a GNU Radio-related tool
>>> >>> - People can't agree on a capitalization
>>> >>> - No one can remember what the acronym stands for
>>> >>>
>>> >>> Sure, this is not a critical thing, but now's a good chance to bring
>>> it
>>> >>> up and also, this is not a joke :)
>>> >>>
>>> >>> Here's how we're going to do this:
>>> >>>
>>> >>> - Please suggest new names in this thread.
>>> >>> - I will choose from those names based on 'can I live with this
>>> name',
>>> >>> 100% subjectively.
>>> >>> - New names will be put up for a vote. This will include an option to
>>> >>> keep the old name.
>>> >>> - Finally, the result of the vote will be used as a strong
>>> suggestion on
>>> >>> what the new name will be.
>>> >>>
>>> >>> There already have been some suggestions:
>>> >>>
>>> >>> - gromit -- the GNU Radio out-of-tree module installation tool
>>> >>> - the groot
>>> >>> - grpm -- the GNU Radio package manager
>>> >>>
>>> >>>
>>> >>> OK guys, bring up the ideas!
>>> >>>
>>> >>> Cheers,
>>> &

Re: [Discuss-gnuradio] Saving work on Gnu radio live usb stick

[Richard Bell]

You have to create the USB Stick with persistence checked off in the Live
Creator tool. Then when you boot with that stick, you'll see another drive
mounted that you can save things to and they will persist.

Rich

On Wed, Dec 23, 2015 at 11:55 AM, Yahia Tachwali 
wrote:

> Hello everyone,
>
> Is there away to save work and installed packages on usb stick when
> booting from gnu radio live?
>
> ___
> 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] Limits of freq_hopping.py

[Richard Bell]

I'm using Ubuntu 14.04 LTS, GNU Radio 3.7.9rc1, UHD 3.9.1 with two USRP
N210s with WBX daughtercards.

I'm trying to determine what the fastest hopping rate is with the given
setup above. Using the provided gr-uhd/examples/python frequency hopping
script, it seems that 100 ms (10 Hz) is the fastest. What I haven't been
able to figure out yet, is if this is due to a limitation imposed by that
script, or if this is the fastest way (or right around the fastest way)
that any script could hope to approach.

What I did to arive at this 100 ms limit is the following:
1) The first N210 is used as a transmitter and I use the following command
to initiate hopping
./freq_hopping.py -a "addr=10.0.8.5" --antenna TX/RX --verbose --freq
915e6 --gain 20 --rate 5e6 --num-bursts 1 --freq-delta 0.1e6
--samp-per-burst 10 --hop-time 50

2) The second N210 is a spectrum analyzer using the following command and
the waterfall tab
uhd_fft -f 915M -s 0.5M -A TX/RX

3) I stop the waterfall plot, so it stops scrolling, and measure the
smallest length of time at one frequency I can achieve given any batch of
settings in step 1. The settings I linked in step one should have set a hop
time of 50 ms, but this measurements shows 100 ms.

I'm going to try writing my own custom script, but would like to know if
others have pushed this before and found ~100 ms (10 Hz) as the limit for
frequency hopping intervals using the N210+WBX combo.

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

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Richard Bell]

GRAB = Gnu RAdio Basic installer

Then we can say things like "Go GRAB it" when referring to a needed module

On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun 
wrote:

> There's been some demand to rename PyBOMBS, and now that we're
> re-releasing it, this is a good time to think about it. Complaints about
> the name include:
>
> - It may or may not be true that people have been detained by TSA for
> working on PyBOMBS at the airport[1]
> - The name suggests a Python-related packages (like Pylint, PyPI...)
> rather than a GNU Radio-related tool
> - People can't agree on a capitalization
> - No one can remember what the acronym stands for
>
> Sure, this is not a critical thing, but now's a good chance to bring it
> up and also, this is not a joke :)
>
> Here's how we're going to do this:
>
> - Please suggest new names in this thread.
> - I will choose from those names based on 'can I live with this name',
> 100% subjectively.
> - New names will be put up for a vote. This will include an option to
> keep the old name.
> - Finally, the result of the vote will be used as a strong suggestion on
> what the new name will be.
>
> There already have been some suggestions:
>
> - gromit -- the GNU Radio out-of-tree module installation tool
> - the groot
> - grpm -- the GNU Radio package manager
>
>
> OK guys, bring up the ideas!
>
> Cheers,
> Martin
>
> [1] It's not.
>
> ___
> 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] setup_env.sh equivalent when installing form source

[Richard Bell]

Got it. Thanks.

Rich

On Mon, Dec 21, 2015 at 4:19 PM, Chris Kuethe <chris.kue...@gmail.com>
wrote:

> Basic unix familiarity is required.
>
> If your shell can't find a program, check that it's in your PATH.
> If a program fails to start, make sure the linker can find any necessary
> libraries and maybe add them with LD_LIBRARY_PATH
> If python can't find a module, check that it's in PYTHONPATH, and any
> necessary libraries can be linked.
>
>
> On Mon, Dec 21, 2015 at 4:10 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I would like to know if there is a way of creating the setup_env.sh file
>> that pybombs creates for you automatically, when you are installing from
>> source without pybombs at all. Currently, I cheat by copy and pasting the
>> pybombs generated file from another computer that used pybombs. What is
>> someone who does not have pybombs supposed to do to setup paths? Are they
>> supposed to just know how, go to a website I haven't found that explains
>> it, or something else?
>>
>> Thanks,
>> Rich
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] setup_env.sh equivalent when installing form source

[Richard Bell]

Hi all,

I would like to know if there is a way of creating the setup_env.sh file
that pybombs creates for you automatically, when you are installing from
source without pybombs at all. Currently, I cheat by copy and pasting the
pybombs generated file from another computer that used pybombs. What is
someone who does not have pybombs supposed to do to setup paths? Are they
supposed to just know how, go to a website I haven't found that explains
it, or something else?

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

[Discuss-gnuradio] Bug with set_taps in pfb_clock_sync

[Richard Bell]

I think I've come across a bug with the pfb_clock_sync blocks set_taps
implementation. If I change a parameter in python that causes a change to
the filter tap variable being fed to the pfb_clock_sync block, which then
requires pfb_clock_sync.set_taps() to be called, the program will error out
with the following:










*Traceback (most recent call last):  File
"radio_devel/scripts/pcodes_multi_sim.py", line 484, in main()
File "radio_devel/scripts/pcodes_multi_sim.py", line 205, in main
tb.set_rolloff(rolloff)   # same problem with pfb_filter  File
"/home/rbell/Documents/pcodes/radio_devel/scripts/pcodes_bpsk_stream_FEC_loopback_costas_nogui.py",
line 184, in set_rolloff
self.digital_pfb_clock_sync_xxx_0.set_taps((firdes.root_raised_cosine(self.nfilts_pfb,
self.nfilts_pfb*self.samp_symb, 1, self.rolloff,
self.nfilts_pfb*11*self.samp_symb+1)))  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/digital/digital_swig.py",
line 25452, in set_tapsreturn
_digital_swig.pfb_clock_sync_ccf_sptr_set_taps(self, *args,
**kwargs)TypeError: Required argument 'ourtaps' (pos 3) not found*

Two examples of variables that cause this change are samp_per_symb or
shaping filter rolloff factor. I only set these variables while the
simulation is not running, i.e. before I call tb.start(). I don't know why
setting the rolloff should break the pfb_clock_sync.

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

Re: [Discuss-gnuradio] Python Script Stalls

[Richard Bell]

Glad you cleared that up, but unfortunately this isn't the fix to my
problem. The flowgraph for some iterations (seemingly random) still stalls
so that I have to hit 'Ctrl-C' to get it to move on.

To be more clear on the "random" stall, here is what happens. I have 10
different simulation iterations I want to run on the base radio. The
parameter I change is the injected noise standard deviation between each
iteration. Sometimes, the script will make it through all 10 runs with no
issue. If I run the script again, the 2nd and 8th iteration might stall.
Now I run it again, and only the 4th stalls. I run it again and I get no
stalls. I run it again and the 5th and 6th stall. It's behavior like this
that I'm seeing.

In between each for loop iteration, I'm doing this in Python:
for n in xrange(0, 10):
tb = top_block()
tb.start()
tb.wait()
tb.stop()
tb.wait()
tb = None

I'm guessing at this point I'm on my own. If anyone knows of a good bit of
info I should have when making these multi-run simulations in python,
please let me know.

Apprecaited,
Rich

On Wed, Nov 11, 2015 at 1:35 PM, Johnathan Corgan <johnat...@corganlabs.com>
wrote:

> On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> John, did you mean this four step process, otherwise stop before wait
>> doesn't let anything happen:
>>
>> tb.start()
>> tb.wait()
>> tb.stop()
>> tb.wait()
>>
>> Like that? If so, why don't the auto-generated top_blocks have to do that?
>>
>
> ​To clarify what is happening under the hood here, let me go through what
> these calls actually do.
>
> tb.start() creates and runs a thread for each block in the flowgraph, and
> immediately returns to the foreground thread execution. One uses this form
> when one wants to continue to do other things in the application while the
> flowgraph is running in the background.  This is typically used with GUI
> applications that have their own event loop thread.
>
> At the end of the application, one must call tb.stop(), which issues a
> cancel to each thread, and then tb.wait(), which joins each thread and
> ensures everything is cleaned up before continuing.
>
> ​Now, flowgraphs can either exit on their own, such when a finite data
> source is used, or a head() block is in place, or they run indefinitely.
> In either case, if the flowgraph is started with tb.start(), it must
> eventually be followed with tb.stop() and tb.wait().
>
> The alternative, which is more common in non-GUI scripts, is to use
> tb.run().  This will internally call start(), and then block either until
> the flowgraph to exits on its own, or a SIGINT (ctrl-c) arrives.  It then
> calls tb.stop() and tb.wait() internally, then returns.
>
> Thus, the simpler tb.run() semantics let you create a flowgraph, let it
> run till exit, or break out of it with SIGINT.  When tb.run() returns,
> there is nothing else the user needs to do.  Hence, many command-line
> examples you see in GNU Radio use tb.run().  If they use the tb.start()
> method, which again, returns immediately to the foreground, they usually
> have a raw input call or something else that blocks until the user does
> something, then they call tb.stop() and tb.wait().
>
> It sounds like what you are trying to do, if I understood correctly, is
> run a finite-length flowgraph over and over again.  For that, tb.run()
> should suffice.  If the flowgraph is not guaranteed to exit on its own,
> then you'll need to do tb.start(), block while you figure out whether
> conditions are proper for terminating the flowgraph, then do tb.stop() and
> tb.wait().
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python Script Stalls

[Richard Bell]

I thought I'd add this bit of information. After stopping a number of
simulations by pressing 'Ctrl-Z' in the middle of the sim, I will get the
following buffer error:

gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::vmcircbuf_sysv_shm: shmget (2): No space left on device
gr::buffer::allocate_buffer: failed to allocate buffer of size 64 KB
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

I found a post that Martin Muller made explaining how to overcome this
(execute: sudo sysctl kernel.shmmni=32000),  but I'm more interested in
whether this could be related to the stalling I'm seeing.

Rich


On Thu, Nov 12, 2015 at 9:27 AM, Richard Bell <richard.be...@gmail.com>
wrote:

> Glad you cleared that up, but unfortunately this isn't the fix to my
> problem. The flowgraph for some iterations (seemingly random) still stalls
> so that I have to hit 'Ctrl-C' to get it to move on.
>
> To be more clear on the "random" stall, here is what happens. I have 10
> different simulation iterations I want to run on the base radio. The
> parameter I change is the injected noise standard deviation between each
> iteration. Sometimes, the script will make it through all 10 runs with no
> issue. If I run the script again, the 2nd and 8th iteration might stall.
> Now I run it again, and only the 4th stalls. I run it again and I get no
> stalls. I run it again and the 5th and 6th stall. It's behavior like this
> that I'm seeing.
>
> In between each for loop iteration, I'm doing this in Python:
> for n in xrange(0, 10):
> tb = top_block()
> tb.start()
> tb.wait()
> tb.stop()
> tb.wait()
> tb = None
>
> I'm guessing at this point I'm on my own. If anyone knows of a good bit of
> info I should have when making these multi-run simulations in python,
> please let me know.
>
> Apprecaited,
> Rich
>
> On Wed, Nov 11, 2015 at 1:35 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On Wed, Nov 11, 2015 at 10:59 AM, Richard Bell <richard.be...@gmail.com>
>> wrote:
>>
>>> John, did you mean this four step process, otherwise stop before wait
>>> doesn't let anything happen:
>>>
>>> tb.start()
>>> tb.wait()
>>> tb.stop()
>>> tb.wait()
>>>
>>> Like that? If so, why don't the auto-generated top_blocks have to do
>>> that?
>>>
>>
>> ​To clarify what is happening under the hood here, let me go through what
>> these calls actually do.
>>
>> tb.start() creates and runs a thread for each block in the flowgraph, and
>> immediately returns to the foreground thread execution. One uses this form
>> when one wants to continue to do other things in the application while the
>> flowgraph is running in the background.  This is typically used with GUI
>> applications that have their own event loop thread.
>>
>> At the end of the application, one must call tb.stop(), which issues a
>> cancel to each thread, and then tb.wait(), which joins each thread and
>> ensures everything is cleaned up before continuing.
>>
>> ​Now, flowgraphs can either exit on their own, such when a finite data
>> source is used, or a head() block is in place, or they run indefinitely.
>> In either case, if the flowgraph is started with tb.start(), it must
>> eventually be followed with tb.stop() and tb.wait().
>>
>> The alternative, which is more common in non-GUI scripts, is to use
>> tb.run().  This will internally call start(), and then block either until
>> the flowgraph to exits on its own, or a SIGINT (ctrl-c) arrives.  It then
>> calls tb.stop() and tb.wait() internally, then returns.
>>
>> Thus, the simpler tb.run() semantics let you create a flowgraph, let it
>> run till exit, or break out of it with SIGINT.  When tb.run() returns,
>> there is nothing else the user needs to do.  Hence, many command-line
>> examples you see in GNU Radio use tb.run().  If they use the tb.start()
>> method, which again, returns immediately to the foreground, they usually
>> have a raw input call or something else that blocks until the user does
>> something, then they call tb.stop() and tb.wait().
>>
>> It sounds like what you are trying to do, if I understood correctly, is
>> run a finite-length flowgraph over and over again.  For that, tb.ru

Re: [Discuss-gnuradio] Python Script Stalls

[Richard Bell]

John, did you mean this four step process, otherwise stop before wait
doesn't let anything happen:

tb.start()
tb.wait()
tb.stop()
tb.wait()

Like that? If so, why don't the auto-generated top_blocks have to do that?

Rich

On Tue, Nov 10, 2015 at 7:24 PM, Johnathan Corgan <johnat...@corganlabs.com>
wrote:

> tb.stop(), then tb.wait()
>
> On Tue, Nov 10, 2015 at 6:39 PM, Richard Bell <richard.be...@gmail.com>
> wrote:
>
>> I've written a python script that instantiates a top_block.py file (no
>> GUI), sets the parameters, runs until 100 block errors are detected, stops
>> the simulation and starts the process over with a new instantiation, etc..
>>
>> The problem I have is that I randomly (as far as I can tell) have a
>> problem where the gnuradio simulation stalls out during one of these
>> simulations. Everything its supposed to be printing to terminal stops. I
>> can still hit 'Ctrl-C' to get it to move on to the next simulation, and it
>> will continue on working after that. But I can't figure out why it stalls
>> such that all I can do to get it to move onto the next simulation iteration
>> is hit 'Ctrl-C'.
>>
>> For an example of what I mean by stall, I added a message debug block to
>> my sim just to see if that also stopped outputting to terminal when the
>> stall happened, and sure enough, it too was effected.
>>
>> I can't recreate this issue when I just the radio from GRC. It always
>> runs fine.
>>
>> Has anyone experienced something like this when using python? What I do
>> in python is pretty simple:
>>
>> for nn in xrange(0,nsims):
>> tb = top_block()
>> time.sleep(1)
>>
>> --set a bunch of radio paramters--
>>
>> tb.start()
>> tb.wait()
>> tb.stop()
>>
>> --collect results and push to file--
>>
>> tb = None
>>
>> I could really use some debug help
>>
>> Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio