Re: [Discuss-gnuradio] Renaming PyBOMBS

[Tim Newman]

I agree with Tim, the tool is not gnuradio specific, and I personally dont
think it needs to be locked to gnuradio and have a "gr" in the name
anywhere and uniquely searchable is a must.  I'm a big fan of the original
name. Otherwise:

PySIS - Pybombs Software Installer System.

On Wed, Dec 23, 2015 at 1:43 PM, Richard Bell 
wrote:

> 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 
> 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 
>> 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 
>>> 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 
 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  > 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 Rad

Re: [Discuss-gnuradio] How to start with stream tags

[Tim Newman]

Try:

http://gnuradio.org/doc/doxygen-3.7/page_stream_tags.html

or

http://gnuradio.org/redmine/attachments/download/252/06-rondeau-stream_tags.pdf

or even

http://bit.ly/1kWXdCl



On Tue, Apr 22, 2014 at 6:29 AM, Hoang Ngo Khac wrote:

> Dear List,
>
> I want to make time synchronization for implementation of two-way relaying
> network. Each node contain both RX chain and TX chain but they should not
> run simultaneously (half-duplex mode). Therefore, the TX chain is on when
> it is needed to transmit, and off when the transmission is over. I found
> that *stream tags* is the key solution to perform that.
>
> My question is, how should I start to learn about* stream tags*, where
> can I find tutorial of *stream tags*?
>
> Thank you so much.
>
> Best Regards,
> Hoang
>
> --
> Ngo Khac Hoang
> Faculty of Electronics and Telecommunications -
> University of Engineering and Technology (UET) - Vietnam National
> University, Hanoi (VNU)
> Vice-president of Student Association of UET
> Alternative email:  hoangnk...@vnu.edu.vn
> Mobilephone:  +84.163.682.7874
>
> ___
> 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] Solution for SegFault with Lock / Unlock in 3.7 C++

[Tim Newman]

I was thinking the older version of boost had a bug in the boost thread
stuff that was causing this, but boost 1.53 should be fine.


On Fri, Mar 28, 2014 at 1:09 PM, Luke Berndt  wrote:

> I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it
> under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade
> because I think it is not compatible with GR 3.7?
>
> Would it be worth it to try build from source for Boost 1.48 or 1.55?
>
>
> On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman  wrote:
>
>> What version of boost are you using?
>>
>> Tim
>>
>>
>> On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt  wrote:
>>
>>> I was wondering if there has been any progress or work arounds for Bug
>>> 598 in 3.7?
>>>
>>> http://gnuradio.org/redmine/issues/598
>>>
>>> The issue is the GnuRadio will segfault if there are too many Lock /
>>> Unlocks.
>>> I am having it happen after 6 - 10 lock/unlocks.
>>>
>>> My program is a C++ program that records trunked radio calls and I need
>>> to be able to dynamically connect / disconnect recording flowgraphs as new
>>> calls are started. The program works fine under 3.6.
>>>
>>> I was wondering if there are any work arounds I should try. I have tried
>>> using tb->stop,  tb->wait, tb->start, but it still crashes. Is there some
>>> other way to dynmically connect & disconnect blocks that doesn't require
>>> lock / unlock?
>>>
>>> Is there an ETA when this would be fixed? Anything I can help on? I am
>>> going to have to go back to 3.6 if I can't figure out a solution.
>>>
>>> Thanks!
>>>
>>>  - Luke
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Solution for SegFault with Lock / Unlock in 3.7 C++

[Tim Newman]

What version of boost are you using?

Tim


On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt  wrote:

> I was wondering if there has been any progress or work arounds for Bug 598
> in 3.7?
>
> http://gnuradio.org/redmine/issues/598
>
> The issue is the GnuRadio will segfault if there are too many Lock /
> Unlocks.
> I am having it happen after 6 - 10 lock/unlocks.
>
> My program is a C++ program that records trunked radio calls and I need to
> be able to dynamically connect / disconnect recording flowgraphs as new
> calls are started. The program works fine under 3.6.
>
> I was wondering if there are any work arounds I should try. I have tried
> using tb->stop,  tb->wait, tb->start, but it still crashes. Is there some
> other way to dynmically connect & disconnect blocks that doesn't require
> lock / unlock?
>
> Is there an ETA when this would be fixed? Anything I can help on? I am
> going to have to go back to 3.6 if I can't figure out a solution.
>
> Thanks!
>
>  - Luke
>
>
>
>
> ___
> 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] Control Port, Perf Mon for GRC - errors

[Tim Newman]

Are you installing Ice after you build gnuradio?  If so, then gnuradio
won't enable the controlport modules during the gnuradio build because it
doesnt detect Ice.

Tim


On Fri, Feb 7, 2014 at 11:10 PM, Tom McDermott wrote:

>
> Having some issues with Control Port and Perf Mon in GRC.
>
> 1. Built Latest Gnuradio 3.7.2 from git.
> enabled performance counters in the cmake command line
> cmake ../ -DENABLE_PERFORMANCE_COUNTERS=On
> then successful make, install, ldconfig, and gnuradio runs fine.
>
> 2. Edited the  gnuradio-runtime-conf file to enable PerfCounters and
>   ControlPort, Edges.
>
> 3. Installed zeroc-ice (ver 3.4).
>
> If I add both a ControlPort Complex Probe and a CtrlPort Monitor, get the
> following error:
>
> Traceback (most recent call last):
>   File "home/tom//mod_phasing_test.py", line 17, in 
> from gnuradio.ctrlport.monitor import *
> ImportError: No module named ctrlport.monitor
>
> If I delete the CtrlPort Monitor, leaving only the probe, I get the
> following error:
> Traceback (most recent call last):
>   File "/home/tom/mod_phasing_test.py", line 231, in 
> tb = mod_phasing_test()
>   File "/home/tom/mod_phasing_test.py", line 144, in __init__
> self.blocks_ctrlport_probe_c_0 =
> blocks.ctrlport_probe_c("constellation", "Constellation Points")
> AttributeError: 'module' object has no attribute 'ctrlport_probe_c'
>
> Are there other configuration steps needed? Does zeroc-ice need to be
> configured in some manner?
>
> -- Tom, N5EG
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception

[Tim Newman]

I've seen ICE do this before, but usually its because my flowgraph dies,
via segfault or something.  When the flowgraph dies, the ice endpoints
aren't available anymore so the controlport monitor timesout when
attempting to query them.  Are you sure your flowgraph isn't crapping out
for some reason or another?

Tim


On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean
wrote:

>  >
>
> *>From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Nowlan, Sean
> *>Sent:* Monday, November 11, 2013 4:10 PM
> *>To:* discuss-gnuradio@gnu.org
> *>Subject:* [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
>
> >
>
> >I’m using ControlPort to monitor transmissions through a USRP. I have a
> flowgraph responsible for generating burst traffic and streaming to a
> uhd_sink. Then I have a uhd_source tuned to the same frequency as the
> uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
> have ControlPort support compiled-in and enabled from a config file. I’m
> able to connect to a remotely running flowgraph using gr-ctrlport-monitor
> and plot the PSD of the “samples” vector pulled from the probe2 block every
> 100 milliseconds. The problem is that after (what seems to be) a
> nondeterministic time, the ICE port stops responding and
> gr-ctrlport-monitor reports an error:
>
> >
>
> >ctrlport-monitor: radio.get threw exception (exception
> ::Ice::ConnectTimeoutException
>
> >{
>
> >}).
>
> >
>
> >When I close and restart, gr-ctrlport-monitor times out and segfaults:
>
> >
>
> >2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
> Traceback (most recent call last):
>
> >  File "/usr/lib/pymodules/python2.7/Ice.py", line 984, in main
>
> >status = self.doMain(args, initData)
>
> >  File "/usr/lib/pymodules/python2.7/Ice.py", line 1031, in doMain
>
> >return self.run(args)
>
> >  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
> line 97, in run
>
> >radio = self.getRadio(host, port)
>
> >  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
> line 36, in getRadio
>
> >radio = GNURadio.ControlPortPrx.checkedCast(base)
>
> >  File "/usr/local/lib/python2.7/dist-packages/gnuradio_ice.py", line
> 1257, in checkedCast
>
> >return
> _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
> '::GNURadio::ControlPort', facetOrCtx, _ctx)
>
> >ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
>
> >{
>
> >}
>
> >
>
> >Segmentation fault (core dumped)
>
> >
>
> >So there are two issues to note here:
>
> >-Something in the ICE instance is breaking on the GNU Radio
> flowgraph side. The port is still open; it just times out. Trying to
> instantiate gr-ctrlport-monitor to an incorrect port just says “connection
> refused,” as expected.
>
> >-gr-ctrlport-monitor is not robust to connection-related errors
> like timeouts or refused connections.
>
> >
>
> >Is there any advice of what I can turn on or enable in GNU Radio or my
> flowgraph to debug the first problem? I can live with the second problem as
> long as I can make sure ICE doesn’t break on me.
>
> >
>
> >Thanks,
>
> >Sean
>
>
>
> Sorry for getting antsy about this, but I’m really not sure how to go
> about debugging ICE server stuff. It seems like it’s buried pretty deeply
> in gnuradio-runtime. Where’s the best place to start looking to find out
> why the ICE server stops responding?
>
>
>
> Sean
>
> ___
> 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] Sampling with multiple USRP N210s with one host computer

[Tim Newman]

There are lots of different ways.  One example would be to simply connect
them all to a switch, along with your host.  Assuming the aggregate
bandwidth doesn't exceed what the host's network card or switch can handle
you'll be fine.  You could also, as you mentioned, have a single host with
8 network interfaces, this is completely possible.

Tim



On Thu, Oct 31, 2013 at 4:54 PM, rmsrms1987  wrote:

> Hi Everyone,
>
> I recently discovered that Ettus offer a way of synchronizing up the eight
> USRPs with the following clock distribution system:
>
> https://www.ettus.com/product/details/OctoClock-G
> 
>
> Out of curiosity, how would one be able to connect and sample with eight
> separate USRPs with one host computer.  Would you need eight separate
> ethernet ports?  That seems like more than what a typical motherboard would
> be able to handle.
>
> Or can the USRPs all be connected to a server, which can be individually
> accessed through the host computer?
>
> Understanding how to do this will be extremely beneficial in order to
> gather
> some ideas for a project.
>
> Thank you very much in advance,
> Rob
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Sampling-with-multiple-USRP-N210s-with-one-host-computer-tp44502.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio recipe in pybombs requires mcpp

[Tim Newman]

Yeah, I think your right, mcpp isn't needed in the gnuradio pybombs recipe.

Tim


On Thu, Aug 8, 2013 at 9:05 AM, Alexandru Csete  wrote:

> On Thu, Aug 8, 2013 at 2:16 PM, Tom Rondeau  wrote:
> > On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete 
> wrote:
> >> Greetings,
> >>
> >> I just noticed that executing "./pybombs install gnuradio" on a system
> >> that already has all the necessary dependencies starts by installing a
> >> package called mcpp. Searching the web I found out that it is a C/C++
> >> preprocessor from 2008...
> >>
> >> Since gnuradio builds just fine with the standard preprocessor in gcc,
> >> I hope we can get rid of it get rid of this dependency.
> >>
> >> Alex
> >
> > It's an ICE dependency... the rest of GNU Radio doesn't use it. It's
> > just needed to build ICE.
>
> Tom,
>
> Thanks for the info. If it is is an ICE build dependency then we can
> remove it from the gnuradio recipe, yes?
> Or is it also necessary for parsing and converting the gnuradio.ice files?
>
> Alex
>
> ___
> 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] Help Pybombs

[Tim Newman]

When you run pybombs for the first time, it should ask you what prefix you
want it to install into.  For example, i think it defaults to /usr/local/.
 This then passes that prefix directory to the configurare parameter
"--prefix" for autotools based projects or the cmake parameter
"-DCMAKE_INSTALL_PREFIX" for cmake based projects, and the projects install
into that prefix.  Pybombs is simply running the "configure/make/make
install" for the project you want to install and all it's dependencies.
 There's no magic about where it installs things.

Tim


On Fri, Aug 2, 2013 at 9:37 AM, tom sutherland wrote:

> I have in stalled pybombs. I looked at all the projects in the recipe
> directory and have run "./pybombs install gr-ham" and a few others but
> can't figure out what it is installing and WHERE did it put it. I thought
> it was installing some examples but I can't find anything.
> Thanks...Tom
>
> ___
> 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] Gnuradio3.7 make error

[tim . newman]

Its finding 1.40 headers somewhere on your system.

Tim
Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Harry Zhang 
Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Tue, 30 Jul 
2013 19:23:47 
To: Nathan West
Cc: 
Subject: Re: [Discuss-gnuradio] Gnuradio3.7 make error

Dear Nathan,
 Thank you for your reply.
 I have changed the boost to 1.48 but the error remains. According 
to the error information, it seems to require libboost1.40,which puzzles me.

2013/7/30 12:12, Nathan West wrote:
> On Mon, Jul 29, 2013 at 11:55 PM, Gong Zhang  wrote:
>> Dear Nathan,
>>  I have tried the method in the URL but it does not work. The error
>> remains.
>>
>>   2013/7/30 10:58, Nathan West wrote:
>>> On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang  wrote:
 Hi,
   I'm using Ubuntu 12.04 and libboost1.46. I got the following errors
 when
 I make the project.

>>> libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04
>>> should have libboost1.48 available in the repos. Here's some more
>>> info:
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html
>>>
> What do you mean you tried the method in the URL? The cmake flag? The
> point of sending that link is the version of boost you have is known
> to cause problems with GNU Radio and unless you have a very good
> reason for using it you should use another version. If you're having
> trouble installing GNU Radio for the first time you might give pybombs
> a shot. It's pretty easy to get an installation going for the first
> time, especially if you're having a problem with dependencies like
> boost.
>
> Here's info on pybombs: http://gnuradio.org/redmine/projects/pybombs/wiki
>
> 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

Re: [Discuss-gnuradio] pybombs building 3.6.5.1 - swapping and out of virtual memory

[Tim Newman]

By default pybombs runs make with the "-j4" option, allowing it to compile
things in parallel.  This typically helps the compile go quicker.  I
certainly wouldnt expect the gnuradio compile to have issues like this, but
you could edit the gnuradio recipe to force it not to use the "-j4" option
by adding:

make {
make
}

This basically overwrites the template pybombs uses for the make
stage, which uses the "-j4" by default. It will result in a longer
compile time, and again I wouldnt expect a machine with 4GB of RAM to
have any problems, even with that option, but its something to try.

Tim




On Mon, Jul 29, 2013 at 12:40 PM, M Dammer  wrote:

> Not sure if this is a Pybombs or Gnuradio build issue: When building
> version 3.6.5.1 via pybombs the system starts swapping after about 70%
> of the build have completed and even sometimes bails out with "out of
> virtual memory". I can complete the build by restarting pybombs install
> - sometimes several times.
> I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM.
> I notice that "top" shows several cc1plus processes running in parallel
> each consuming over 1Gb of memory.
>
>
>
> ___
> 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 Build Failure

[tim . newman]

If you go into the pybombs/src/gnuradio/build directory and run "make -j4" 
you'll replicate exactly what pybombs is doing and maybe get a hint of what's 
up. Plus you can check if just "make" works.

Tim
Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Dan CaJacob 
Date: Fri, 26 Jul 2013 16:40:39 
To: Tim Newman
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] PYBOMBS Build Failure

I am trying to get you the full output.  Apparently tee-ing the output to a
file results in a truncated file for some reason.  Do you know if there is
a logging feature in pybombs?  I haven't seen one yet.  In any event, the
portion I posted was the full extent of the error-related output.
 Everything above had proceeded correctly.  I sort of wonder if this is the
-j4 make option getting in the way.  It seems that pybombs is setting that
by default, if I am not mistaken.

I realize the build error is with building gnuradio, but pybombs handles
all the dependencies and manages the build process, which is why I am
referencing it.

Very Respectfully,

Dan CaJacob


On Thu, Jul 25, 2013 at 1:07 PM, Tim Newman  wrote:

> It appears that your error is not with pybombs but with building gnuradio.
>  Can you post a bit more of the compile log?
>
> Tim
>
>
>  On Thu, Jul 25, 2013 at 12:36 PM, Dan CaJacob wrote:
>
>>  Hi,
>>
>> I've been trying out pybombs for building the latest gnuradio.  I had a
>> successful build at home last week, but I am having repeated failures in a
>> test environment VM (virtualbox, ubuntu 12.04 x64).
>>
>> I am running the build like this: sudo ./pybombs install gnuradio
>>
>> Here's the relevant part of the make output:
>>
>> [ 68%] Built target gnuradio-blocks
>> Linking CXX shared module _vocoder_swig.so
>> [ 68%] Built target _vocoder_swig
>> make: *** [all] Error 2
>> bash return val = 2
>> Traceback (most recent call last):
>>   File "./pybombs", line 91, in 
>> install(p,True);
>>   File "/home/spacequest/pybombs/mod_pybombs/pybombs_ops.py", line 49, in
>> install
>> global_recipes[pkg].install();
>>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 512, in
>> install
>> st = self.install_src();
>>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 582, in
>> install_src
>> self.install_order[step][1]();
>>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 612, in make
>> assert(st == 0);
>> AssertionError
>>
>> ___
>> 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 Build Failure

[Tim Newman]

It appears that your error is not with pybombs but with building gnuradio.
 Can you post a bit more of the compile log?

Tim


On Thu, Jul 25, 2013 at 12:36 PM, Dan CaJacob  wrote:

> Hi,
>
> I've been trying out pybombs for building the latest gnuradio.  I had a
> successful build at home last week, but I am having repeated failures in a
> test environment VM (virtualbox, ubuntu 12.04 x64).
>
> I am running the build like this: sudo ./pybombs install gnuradio
>
> Here's the relevant part of the make output:
>
> [ 68%] Built target gnuradio-blocks
> Linking CXX shared module _vocoder_swig.so
> [ 68%] Built target _vocoder_swig
> make: *** [all] Error 2
> bash return val = 2
> Traceback (most recent call last):
>   File "./pybombs", line 91, in 
> install(p,True);
>   File "/home/spacequest/pybombs/mod_pybombs/pybombs_ops.py", line 49, in
> install
> global_recipes[pkg].install();
>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 512, in
> install
> st = self.install_src();
>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 582, in
> install_src
> self.install_order[step][1]();
>   File "/home/spacequest/pybombs/mod_pybombs/recipe.py", line 612, in make
> assert(st == 0);
> AssertionError
>
> ___
> 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] Gnuradio 3.6.x recipe for pybombs ?

[Tim Newman]

On 07/20/2013 12:38 PM, M Dammer wrote:
> thanks for the suggestion. I already solved the problem here, by putting
> this configure section in the recipe:
> configure {
> git checkout tags/v3.6.5.1
> cmake .. -DCMAKE_BUILD_TYPE=$cmakebuildtype
> -DCMAKE_INSTALL_PREFIX=$prefix $config_opt
> }
>
>
> On 20/07/13 17:04, Nathan West wrote:
>> On Sat, Jul 20, 2013 at 10:26 AM, M Dammer  wrote:
>>> This does not work. I am getting a "branch not found, building HEAD
>>> instead" like error and then it builds 3.7. It looks as the gitbranch
>>> part of the recipe really only works with branches while the version
>>> numbers are tags. Does pybombs has a similar command than gitbranch to
>>> define a tag in a recipe ?
>>>
>>> On 19/07/13 20:00, Tom Rondeau wrote:
 On Fri, Jul 19, 2013 at 12:31 PM, M Dammer  wrote:
> Has anyone a recipe for installing the 3.6-branch via pybombs ? I need a
> 3.6 parallel installation on my system, because many old projects are
> not working "out of the box" in 3.7.x. Even many of the projects
> referenced by recipes that currently come with pybombs do not compile.
> tnx, Mark
 Mark,

 You can edit the recipe file to change the branch you want to check
 out. In pybombs/recipes/gnuradio.lwr look for the 'gitbranch' line.
 Change this from 'master' to the tag of the version you want, such as
 'v3.6.5.1' for the latest in the 3.6 version.

 Tom
>> Leave the branch as whatever you want (master, maint...) but add a
>> line for gitrev:
>> gitrev: tags/v3.6.5.1
>>
>> Of course this could be whatever rev you want.
>>
>> Nathan
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Nathan's correct, the proper way would be by using the "gitrev:" line,
you should be table to specify either a tag or a specific git revision.

Tim

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

Re: [Discuss-gnuradio] Recent Commit Issue

[Tim Newman]

I think this is a sort of different beast.  You could check for gslcblas
and even pass -lgslcblas as a compile flag, in fact that is what is going
on.  The problem is GSL needs BLAS but does not call it directly from the
object file, and the --as-needed doesnt check for symbols recursively, so
doesnt link it, even if you specifically pass -lgslcblas as a parameter.  I
suppose one option is to directly link the gr-wavelet library to CBLAS,
 which honestly I thought was already happening.

Tim


On Wed, Jun 26, 2013 at 2:55 PM, Michael Dickens  wrote:

> Regarding commit c0b3ce38db0eaaca05fe2f45827fcf6c9184b72b "wavelet: fix
> for -lgslcblas getting stripped out of the link flags due to
> -Wl,--as-needed default on newer gcc toolchains, results in missing blas
> symbols at runtime", as well as other assumptions being made about GCC:
>
> 
>
> Just because the compiler is GCC does not mean it will accept the flag
> being passed to it, nor that it is guaranteed to provide specific
> functionality if >= a specific version.  Maybe this works on Linux, but it
> does not on Mac OS X using either Apple's or MacPorts' GCC (4.2, 4.6, 4.7).
>  So, the above "-Wl,--no-as-needed" does not work, nor does the "xgetbv"
> instruction, because all versions of GCC use Apple's assembler (which does
> not support these features).
>
> Clang as provided by Xcode or MacPorts does -not- use Apple's assembler,
> which means it should be multi-OS compatible for flags and instructions --
> but:
>
> The best way to check for a feature (compiler flag, or specific
> instruction) is to actually test for it, just like we do for most other
> compiler flags, headers, and many functions (both OS-provided and other
> dependencies).
>
> 
>
> Thanks for listening.  I'm patching the MacPorts install of GNU Radio to
> remove this commit until a better solution is found. - MLD
>
>
> ___
> 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] Run time FIFO error

[Tim Newman]

It's hard to tell in the pcap file where it gets lost.  I'm not using a
dissector for the UHD packets so I can't see whats in the data field, thus
I can't match up commands coming/going.  I have confirmed that this issue
does not exist when I'm using 003.004.X firmware and fpga load.

Tim


On Fri, Jun 21, 2013 at 1:18 PM, Josh Blum  wrote:

>
>
> On 06/21/2013 09:41 AM, Tim Newman wrote:
> > Yes, bringing this back up. Back to the original topic.  When I get this
> > FIFO ctrl error, the host is sending back an icmp port unreachable msg to
> > the usrp, I grab this using wireshark.
> >
>
> Well if the app shutdown from the error. That could be the host's
> response to a stray packet coming from the USRP after the socket was
> closed. For example a UDP packet w/ a GPSDO NMEA message. So this ICMP
> error may not be indicative of anything.
>
> > All I'm doing is running "uhd_usrp_probe".  I've tried with and without
> > adding the --args addr= parameter, same thing using both.
> >
> > I've debugged a bit, and increased the ACK_TIMEOUT in
> > usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just
> sits
> > at:
> >
> > Creating the usrp device with: ...
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > 
> >
> > Then spits out
> > RuntimeError: RuntimeError: fifo ctrl timed out looking for acks
> >
> > Again, there is a switch in between the USRP and the host.
> >
>
> Yup, definitely a lost packet. Its gone and more time isnt going to
> help. Question is, where is the packet lost? We have a control packet
> from host to switch, then switch to USRP. Then a response packet from
> USRP to switch, then switch to host.
>
> -josh
>
> > Tim
> >
> >
> > On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan
> > wrote:
> >
> >> I think 512 is the max value for N on N200/N210 hence 195kSps is minimum
> >> sample rate.
> >>
> >>
> >> Karan Talasila  wrote:
> >>
> >> @sean can you please tell me how you got minimum sampling rate for usrp
> >> N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N
> where
> >> N is an integer. So N can be any integer even greater than 512 right. In
> >> that way, what is the minimum that the USRP accepts. what is maximum N
> that
> >> can be used.
> >>
> >>
> >> On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan <
> sean.now...@gtri.gatech.edu>wrote:
> >>
> >>> On 06/12/2013 08:49 PM, Marcus D. Leech wrote:
> >>>
> >>>> On 06/12/2013 08:29 PM, Sean Nowlan wrote:
> >>>>
> >>>>>
> >>>>> The minimum "reasonable" sample rate I've used is 2e5 (100e6/2e5 =
> >>>>> 500). I think 100e6/512 = 195312.5 is the smallest supported rate.
> >>>>>
> >>>>>  Yup, sorry, you're right.  I tend to pick values that are valid for
> >>>> both 64Msps and 100Msps master clock rates, since I write apps that
> need to
> >>>> be reasonably
> >>>>   agnostic with respect to hardware.
> >>>>
> >>>>
> >>>>  Ah, makes sense.
> >>>
> >>>
> >>>>
> >>>>
> >>>
> >>> __**_
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> >>>
> >>
> >>
> >>
> >> --
> >> Regards
> >> Karan Talasila
> >>
> >> ___
> >> 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 error

[Tim Newman]

In the recipe itself, you should be able to put:

var config_opt = 

Tim



On Tue, Jun 25, 2013 at 8:12 AM, Blake Morgan  wrote:

> On 06/25/2013 05:10 AM, Philip Balister wrote:
>
>> On 06/24/2013 09:19 PM, Blake Morgan wrote:
>>
>>> I decided to try out pybombs on one of my Beaglebones, and attempted to
>>> install gnuradio. Below is the error message I received, if this helps.
>>>
>>>  This is the key issue"
>>
>
> Heh, I suspected as much.
>
>
>>  make[2]: *** Waiting for unfinished jobs
>>> c++: internal compiler error: Killed (program cc1plus)
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>>
>>>  This is a sign the OOM killer killed one of he compiler processes. This
>> is a known issue with building gnuradio. You will typically see it on
>> low memory machines (embedded stuff), but you can see it on intensive
>> x86 build machines also :)
>>
>> Basically, building gnuradio on anything other than a beefy x86 is
>> silly. I've heard of builds on ARM succeeding, but build times are up to
>> like 12 hours. Learn to cross compile.
>>
> Yes, I have successfully cross compiled gnuradio for the beaglebone in the
> past, and it is happily running on one in my lab as I write. The point was
> to see what would happen using the pybombs tool. I think pybombs is a cool
> tool, and I liked how it worked on an x86 machine over the weekend, so I
> thought I'd try a different architecture. Does the pybombs tool accept
> cross compile options? It isn't obvious that it does from looking at
> config.defaults.
>
> Regards,
>
> Blake
>
>>
>> Philip
>>
>>
>>
>
>
> __**_
> 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] Run time FIFO error

[Tim Newman]

Yes, bringing this back up. Back to the original topic.  When I get this
FIFO ctrl error, the host is sending back an icmp port unreachable msg to
the usrp, I grab this using wireshark.

All I'm doing is running "uhd_usrp_probe".  I've tried with and without
adding the --args addr= parameter, same thing using both.

I've debugged a bit, and increased the ACK_TIMEOUT in
usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just sits
at:

Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes


Then spits out
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks

Again, there is a switch in between the USRP and the host.

Tim


On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan
wrote:

> I think 512 is the max value for N on N200/N210 hence 195kSps is minimum
> sample rate.
>
>
> Karan Talasila  wrote:
>
> @sean can you please tell me how you got minimum sampling rate for usrp
> N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N where
> N is an integer. So N can be any integer even greater than 512 right. In
> that way, what is the minimum that the USRP accepts. what is maximum N that
> can be used.
>
>
> On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan 
> wrote:
>
>> On 06/12/2013 08:49 PM, Marcus D. Leech wrote:
>>
>>> On 06/12/2013 08:29 PM, Sean Nowlan wrote:
>>>

 The minimum "reasonable" sample rate I've used is 2e5 (100e6/2e5 =
 500). I think 100e6/512 = 195312.5 is the smallest supported rate.

  Yup, sorry, you're right.  I tend to pick values that are valid for
>>> both 64Msps and 100Msps master clock rates, since I write apps that need to
>>> be reasonably
>>>   agnostic with respect to hardware.
>>>
>>>
>>>  Ah, makes sense.
>>
>>
>>>
>>>
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards
> Karan Talasila
>
> ___
> 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] Run time FIFO error

[tim . newman]

I'm also getting that error about 50% of the time when running through a 
switch.  I checked the pcap output and when it fails, the host sends an icmp 
port unreachable msg to the usrp.

Tim
Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Josh Blum 
Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Wed, 12 Jun 
2013 19:01:49 
To: 
Reply-To: j...@joshknows.com
Subject: Re: [Discuss-gnuradio] Run time FIFO error



On 06/12/2013 06:54 PM, Marcus D. Leech wrote:
> On 06/12/2013 06:52 PM, Jay Prakash wrote:
>> USRP N210
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> This error is usually caused by the network connection dropping packets.
> 
> Are you directly connected to your PC? What kind of network card do you
> have?
> 

Jay mentioned in a previous email ubluntu 11.10, which is quite old by
now (13.04 is out). Perhaps there could be a network driver issue that
was resolved in a newer release.

-josh

> 
> 
> 
> 
> ___
> 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] Master build failure for ARM when building cross

[Tim Newman]

I had problems similar to this using swig < 2.0.  Swig 2.0.4 helped.


On Mon, Apr 22, 2013 at 7:08 PM, Almohanad Fayez
wrote:

> Philip, this is problem of no help but I ran into this issue when I was
> still using ubuntu 10.04, I found a reference where Marcus was having the
> same problem but on ubuntu 12.04
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00178.html
>
> where I applied the recommended changes and added some other mods
> recommended by Josh but I couldn't fix it I ended up upgrading from 10.04
> to 12.04 and everything worked.
>
> My suspicion, and again I'm probably the wrong person to comment on this,
> is that it was a swig/python version issue 10.04 was running Python 2.6 I
> don't remember what swig version and 12.04 is running Python 2.7 and swig
> 2.0.4.  I would recommend experimenting with alternative swig versions and
> see if the problem goes away.
>
> al fayez
>
>
> On Thu, Apr 18, 2013 at 9:38 PM, Philip Balister wrote:
>
>> Any ideas? I haven't looked at it hard yet.
>>
>> Philip
>>
>> eglibc/sysroots/ettus-e200/usr/include-fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized -o
>> CMakeFiles/test-gr-blocks.dir/qa_gr_block.cc.o -c
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/gr-blocks/lib/qa_gr_block.cc
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7083:22:
>> error: redefinition of 'struct swig::traits'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6345:22:
>> error: previous definition of 'struct swig::traits'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7087:23:
>> error: redefinition of 'struct swig::traits_asval'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6349:23:
>> error: previous definition of 'struct swig::traits_asval'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:7093:23:
>> error: redefinition of 'struct swig::traits_from'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/gnuradio/3.6.4.1-r0/git/build/gr-blocks/swig/blocks_swig0PYTHON_wrap.cxx:6355:23:
>> error: previous definition of 'struct swig::traits_from'
>>
>> /home/balister/src/oe-core/build/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueab:
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Almohanad (Al) Fayez
>
> ___
> 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] Check for gr-ctrlport

[tim . newman]

I can confirm I had the same problem. Adding -DENABLE_GR_CTRLPORT=TRUE helped, 
but it should be enabled without it also, according to the cmake log.

Tim

Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Alexandru Csete 
Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Sat, 30 Mar 
2013 23:37:39 
To: Tom Rondeau
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Check for gr-ctrlport

On Sat, Mar 30, 2013 at 2:42 PM, Tom Rondeau  wrote:
> On Fri, Mar 29, 2013 at 8:12 PM, Alexandru Csete  wrote:
>> Is there a recommended or preferred way an application should check
>> for the availability of control port? I can see some #ifdef
>> GR_CTRLPORT in the gnuradio headers but that is only defined while
>> compiling gnuradio. If there is a safe check I could perform at cmake
>> time I would prefer that.
>> Thanks in advance.
>>
>> Alex
>
> Hi Alex,
>
> Good question. This is what the config.h file is for. It's installed
> into $prefix/include/gnuradio/config.h. If ControlPort is defined and
> built for the project, it will be defined in this file as "#define
> GR_CTRLPORT". If you include that header file, you can test #ifdef
> GR_CTRLPORT in your own work.

Hi Tom,

Thanks for the reply. This will work for me, but it seems some cmake
magic is missing from the build procedure because GR_CTRLPORT is not
defined in the config.h that I have. Here are the contents:

#ifndef GNURADIO_CONFIG_H
#define GNURADIO_CONFIG_H
#ifndef TRY_SHM_VMCIRCBUF
#define TRY_SHM_VMCIRCBUF
#endif
#ifndef GR_PERFORMANCE_COUNTERS
/* #undef GR_PERFORMANCE_COUNTERS */
#endif
#ifndef GR_CTRLPORT
/* #undef GR_CTRLPORT */
#endif
#ifndef ENABLE_GR_LOG
#define ENABLE_GR_LOG
#endif
#ifndef HAVE_LOG4CPP
#define HAVE_LOG4CPP
#endif

#endif /* GNURADIO_CONFIG_H */


The cmake step says gr-ctrlport is enabled.

Alex

___
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] uhd_find_devices issue

[tim . newman]

In your screenshot, it looks like your eth0 ip address was lost.

Tim
Sent on the Sprint® Now Network from my BlackBerry®

-Original Message-
From: Karan Talasila 
Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Fri, 28 Dec 
2012 17:20:56 
To: 
Subject: [Discuss-gnuradio] uhd_find_devices issue

___
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] ZeroC ICE Choice for ControlPort

[Tim Newman]

Which version of Ice does the controlport branch currently depend on?
I only ask because I think only Ubuntu 12.04 and 11.10 have Ice 3.4.2,
whereas older Ubuntu versions come with the Ice 3.3.x versions and
there are significant API changes between the two, so the "apt-get
install" may only be supported on 12.04 and 11.10.

Tim

On Mon, Nov 19, 2012 at 10:25 AM, Tom Rondeau  wrote:
> On Mon, Nov 19, 2012 at 10:05 AM, Philip Balister  wrote:
>> On 11/18/2012 06:38 PM, devin kelly wrote:
>>>
>>> I just read about the release of
>>>
>>> ControlPort,
>>>
>>> (which I'm excited about) just wondering why use ZeroC ICE?
>>>
>>> Thanks for any explanation
>>
>>
>> This is a start:
>>
>> http://www.zeroc.com/iceVsCorba.html
>>
>> Philip
>
> Devin,
>
> Yes, the comparisons between ICE and CORBA are definitely one reason.
> We wanted the benefits of CORBA without all of its drawbacks, and ICE
> is the logical choice. Also, it's easy to install and pretty easy to
> learn how to use. It's available in most systems, like being able to
> 'apt-get install zeroc-ice' in Ubuntu and Debian.
>
> Now, we could ask why we want something as complex as this for
> ControlPort? ICE is pretty good at supporting other languages
> (specifically for our needs both C++ and Python). We want it to be
> robust, which takes a lot of thought and overhead. ICE has already
> done that for us. One of the subtle but useful things that ICE does is
> pass exceptions over the connection. So if one side throws an
> exception (like say the running application crashes or is terminated),
> the other side can gracefully shut down, free up resources, and exit.
>
> It also provides mechanisms for authentication and encryption. We're
> still working out details of how to make use of this, but it should be
> pretty clear that this is something we want. For instance, we actually
> have privilege levels for each variable that's exported. The intent is
> that when connecting, the authentication mechanism would use your
> credentials to determine what your privilege level is and only allow
> you access to those parameters (for example, maybe you can 'get' all
> the variables but you need special permission to be able to 'set'
> them). Again, as these things are already designed into ICE, we don't
> have to worry about how it's done; just how to use it.
>
> But finally, I'll say this. If you look at the code, you'll see that a
> lot of it is abstracted away from ICE. We've  tried to make it so that
> we could replace it with other solutions if people want to or
> something better comes along. You'll see some comments for XMLRPC and
> Erlang in the code. We could also potentially use CORBA here, too, if
> someone is crazy for CORBA. The main problem with this last bit is
> that we haven't architected any other layers besides ICE, so it's
> possible that a lot of our decisions are fundamentally rooted in ICE's
> way of doing things. It's probably not unworkable, but I bring this up
> because  it's likely that 'just' dropping in a new middleware might
> not be 'just' that easy. Still, the intent is there.
>
> Tom
>
> ___
> 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] "GNU Radio is crap" and GSoc

[Tim Newman]

I believe the gr event scheduler, presented at the last gr conference, is
for just that kind of thing.

Tim
On Feb 17, 2012 7:39 PM, "Andrew Davis"  wrote:

> Yes, I could feed the blocks work functions directly, but this is
> tricky sometimes. I'm working on a simple program that needs to route
> data from different sources to changing functions and blocks and then
> to multiple sinks. The current scheduler is just to static in flow for
> this task ( I believe, tell me if i'm wrong ).
>
> On Fri, Feb 17, 2012 at 7:17 PM, Almohanad Fayez  wrote:
> > I also agree that a big issue with gnuradio is that it tries to take over
> > all the computing resources in an application but in my opinion that
> this is
> > not an inherent issue with the gnuradio scheduler not wanting to play
> with
> > other applications.  Some people complain that gnuradio doesn't provide
> an
> > API with functions that can be called to a process data in their external
> > applications, I haven't tried this per se, but isn't that the purpose
> behind
> > gnuradio supports running c++-only apps?  But people need to be careful
> what
> > they ask for, if they get only an API to call basic gnuradio
> functionality
> > to process data they want to be processed the overall performance might
> not
> > be acceptable because they are ultimately giving up the
> > scheduler.  Processing is done in gnuradio the way they are, at least in
> my
> > opinion, to address the issue of running a Synchronous Dataflow (SDF)
> graphs
> > which is exactly what you want for signal processing, and an integral
> part
> > of running SDF graphs is running a suitable scheduler.
> >
> > What gnuradio lacks is coherent links to the scheduler in my experience
> it
> > is fairly difficult to step through the code with gdb to figure out what
> the
> > scheduler is doing, if users are able to have some control over the
> > scheduler or replace it entirely for custom applications where gnuradio
> > needs to work in cohesion with other apps then gnuradio can run as part
> of a
> > larger system versus being the only system running.  While this might be
> > outside the scope of a GSoC project but it's a necessity for gnuradio to
> > progress beyond its current state.
> > Almohanad (Al) Fayez
> >
> >
> > -Original Message-
> > From: Andrew Davis 
> > To: Jens Elsner ; discuss-gnuradio
> > 
> > Sent: Thu, Feb 16, 2012 9:03 am
> > Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
> >
> >>I don't agree. We'll hopefully settle the matter some day. :-)
> >
> > Me too, DREAM is an amazing SDR program that could benefit from
> > GNURadio and show off GNURadio as-well. But this idea has been batted
> > around before and never really develops, possibly due to the way
> > GNURadio is currently setup. When I get some free time i'll continue
> > getting some of the python examples ported to C++, so that potential
> > developers who prefer C over python can see how things can be done
> > from C world. I think this will get people who find GNURadio to start
> > porting other C based programs to the GNURadio framework.
> >
> > On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner  wrote:
> >> Andrew,
> >>
> >> Am 15.02.2012 19:41, schrieb Andrew Davis:
> >>
> >>> Well some major GNUradio program would drive up sales of USRP's :)
> >>>
> >>> Back on topic, IMHO Gnuradio's problem with large apps stems from it
> >>> trying to be the source to sink and everything in between of a radio.
> >>
> >>
> >>> Lets take DREAM for example, they do transfer functions and digital
> >>> AGC and the likes that GNUradio by design should not do.
> >>
> >>
> >> If you could elaborate on this point - why should GNU Radio not
> implement
> >> channel equalization (I assume that's what you mean?) or digital AGC?
> >>
> >>
> >>> If you want
> >>> to re-write DREAM with GNUradio you will end up writing about +200
> >>> blocks, not much fun.
> >>
> >>
> >> Since I suggested this particular project, I obviously cannot agree. :-)
> >>
> >> Pulling the code base into GNU Radio might be a nice addition to
> >> the available receivers and it can be useful for all amateur radio
> >> operators world wide.
> >>
> >> Plus DRM is broadcasting so we don't need to worry about timing issues,
> >> a real drawback of GNU Radio (and high level SDR in general).
> >>
> >> How fine the signal processing chain needs to be chopped up is a
> >> matter of taste and performance, I believe.
> >>
> >>
> >>> What people want is simple input to there
> >>> program and a simple output API, not there entire program. They don't
> >>> what to figure out how to write a GNURadio block or know anything
> >>> about the complexities of GNURadio. They want to say "get me a signal
> >>> at 100MHz, filter and interpolate to 1ksp with these cutoff
> >>> frequencies then send me the data and let me do the rest", no need to
> >>> know anything about GNURadio, what other API makes you learn as much
> >>> about it?
> >>
> >>
> >> I am not sure I und

Re: [Discuss-gnuradio] USRP2 firmware + cross compiled GNU Radio question

[Tim Newman]

alfa...@aol.com wrote:
Hi, I've been working on cross compiling the latest stable GNU Radio 
release, 3.2.1, onto the TI Davinci DM6446 board using OpenEmbedded as 
my build environment and Angstrom as my Linux Distro.  I've managed to 
cross compile and download gnuradio onto the board, though I'm going 
with a console only Linux image so I don't have any of the gnuradio 
python GUI stuff.  Anyways, I am using a USRP2 and the board I'm using 
doesn't have has 100T ethernet and not 1000T, so I'm using a 
1000/100/10T DLink switch to do the translation. 

First, maybe it was a mistype but the latest version of gnuradio is 
3.2.2 not 3.2.1.  Next, if you just want to test transmit, use 
usrp2_siggen.py.


The USRP2 won't work unless you are using a GigE network card on the host. 

Matt has put together a new ethernet MAC here: 
http://gnuradio.org/trac/wiki/NewEthMAC


I don't think this supports 10/100, maybe I'm wrong, but it may be worth 
trying.


Tim

--
---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041



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

Re: [Discuss-gnuradio] ztex USB-FPGA board

[Tim Newman]

Luke Kenneth Casson Leighton wrote:

http://shop.ztex.de/product_info.php?cPath=21&products_id=28

dear gnuradio developers,

i was searching on opencores.org to see if there was a SoC that
incorporates an FPGA(-like) device with an open core, and i
accidentally encountered the above USB-FPGA board.  it has a Cypress
CY7C68013A/14A 480mb/s USB-2 Microcontroller and a Xilinx Spartan-3
XC3S400 FPGA.  it is also accompanied by a developer board:

  http://www.ztex.de/usb-fpga-1/exp-1.1.e.html

the price for the USB-FPGA is an incredibly-low $EUR 70, and the
developer board is only $20.

so my primary question is: is this USB-FPGA board (apart from the
issue of connecting to A-D / D-A boards) suitable for use to do an
802.11b transceiver?  is it fast enough?

many thanks,

l.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
  
This is a fairly loaded question, as it completely depends on WHERE you 
implement certain portions of the 802.11b waveform.  The primary 
bottleneck is the USB bus, and you can't get 20 MHz of bandwidth over 
that bus.  BBN and whoever else worked on the current GNU radio 802.11b 
waveform solved this by moving the despreading to the FPGA.  This is 
just one example.  In the end, it completely depends on where you 
implement the latency and bandwidth sensitive components of the waveform. 


Tim


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

Re: [Discuss-gnuradio] GnuRadio on PCI-104 (i.e., Fedora on USB Flash Drive)

[Tim Newman]

William:
How do I handle the various drivers that are needed for the PCI-104 machine? 
From my experience with embedded boards, typically the OS drivers are 
provided either with the board or at least on the web page for the 
manufacturer.  Looks like yours have the audio/ethernet/video all 
provided here from the lippert site:


http://www.lippert-at.com/index.php?id=395&L=http%3A%2F%2Fwww.vacacionalhouse.com%2Fen%2Fimg%2Fvohe%2Fseyon%2F


Can I create a boot thumbdrive on one machine and use it to boot a very 
different machine?

  

Depends on how different I guess, but typically yes.

Tim Newman


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