Job Opportunities at Planet Labs!

[Eric Blossom]

Hi Folks,

I've got some great opportunities I'd like to let you know about:

The first is a Senior Satellite Communication Engineer (SDR).
Our current constellation of satellites (200+) and ground stations communicate
in the S and X bands, running at 64kb/s, 500kb/s, and 1.5+Gb/s (not a typo).
And no surprise, we're working on new radios too.
https://boards.greenhouse.io/planetlabs/jobs/4234415

We're also looking for a Senior RF Systems Engineer
https://boards.greenhouse.io/planetlabs/jobs/4233885

And a Senior Flight Software Engineer.  If you have experience with
embedded systems, Linux, and microcontrollers, and like the idea of writing
software that runs in orbit, this one could be for you:
https://boards.greenhouse.io/planetlabs/jobs/4224485

(These jobs are based in the San Francisco Bay Area.)

For those of you not familiar with Planet, we design, build, and operate the
largest constellation of imaging satellites in history. We are both a
space company
and a data company all rolled into one.

Eric

[Discuss-gnuradio] setup_env.sh on 3.8-maint for python3

[Eric Blossom via Discuss-gnuradio]

Hi Folks!

I'm building gnuradio using pybombs on Ubuntu 18.04 (x86_64)

My intention is to have it use python3.

When I do this:

sudo pip3 install PyBOMBS
pybombs auto-config
pybombs recipes add-defaults
pybombs prefix init ~/gr/default -a default -R gnuradio-default

It builds, and generates python3 code, however setup_env.sh references 2.6
and 2.7.

Am I missing something?

The config seems reasonable:

default$ pybombs config
PyBOMBS.ConfigManager - INFO - Prefix Python version is: 3.6.8
PyBOMBS - INFO - PyBOMBS Version 2.3.3
PyBOMBS.config - INFO - Using config file:
/home/eric/.pybombs/config.yml
python_ver: 3.6.8
  - Python version for this prefix
default_prefix: default
  - Default Prefix
git-cache: /home/eric/.pybombs/gitcache
  - Path to git reference repository (git cache)
makewidth: 4
  - Concurrent make threads [1,2,4,8...]
elevate_pre_args: ['sudo', '-H']
  - For commands that need elevated privileges, prepend this
packagers: apt,pymod,pip,pkgconfig,cmd
  - Priority of non-source package managers
keep_builddir:
  - When rebuilding, default to keeping the build directory
builddocs: ON
  - Build doxygen while compiling packages? options are: ON, OFF
cmakebuildtype: RelWithDebInfo
  - CMAKE_BUILD_TYPE args to pass to cmake projects, options are:
Debug, Release, RelWithDebInfo, MinSizeRel

I've worked around it by editing setup_env.sh.  Is there a better fix?
Where would it go?

Thanks for all of your efforts!  Super happy to see 3.8.0.0 released!

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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Eric Blossom]

Congratulations to all of you on this new phase of GNU Radio!

Tom, thanks for all you've done serving as the project lead since I stepped
down some 5 years ago.  I'm happy to hear about your new adventure as a
DARPA PM!

Johnathan and Ben, thanks for all that you've already done for GNU Radio,
and thank you for stepping into these expanded roles!

I looking forward to seeing what the next 5 years brings for GNU Radio!

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

[Discuss-gnuradio] [OT] Greetings from Eric and a small favor...

[Eric Blossom]

Hey Everyone!

It's Eric here.  Sorry for being a stranger around here.  [For those
of you who arrived since I've been away, I founded GNU Radio, wrote
most of the original code base, worked with Matt to bring the original
USRP and USRP2 into existence, and served as maintainer of GNU Radio
for the first 9 years...]


Anyhow, I've been lurking here for the last few weeks, and I'm really
happy to see all the progress that's being made on GNU Radio, the new
contributors and the "old hands" at work, and all of the cool things
you are doing with it.


I've been kicking around some product and service ideas, basically
looking to see where I should pour my life energy.  In a break from my
usual "Build It and They Will Come" approach, I thought I'd ask you
for input before I get too far down the road.

I'd really appreciate your help on this.
Please help me out by taking this quick survey:

  http://comsec.com/gnuradio-quick-survey

It won't take more than 5 minutes, and it'll help point me in the
direction of creating something that might be useful to you.

I'm looking for that magical intersection of creating real value for
you, and being interesting to me :)

Thanks for your time,
Eric

P.S. Here's that link again:

  http://comsec.com/gnuradio-quick-survey

P.P.S  If you've got any questions about any of this, please contact
me off-list at e...@comsec.com.  Thanks.

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

Re: [Discuss-gnuradio] TPB scheduler fills block buffers

[Eric Blossom]

On Tue, Dec 07, 2010 at 11:36:19AM +0100, Anton Blad wrote:
> On Mon, 29 Nov 2010 09:30:11 -0800, Eric Blossom  wrote:
> > On Mon, Nov 29, 2010 at 08:42:14AM +0100, antonb wrote:
> >> Hi,
> >> 
> >> I am writing an application for which I want to keep the latency to a
> >> minimum, and this involves trying to keep the buffers between the
> blocks
> >> as
> >> empty as possible. Basically, I have a source block with an element
> size
> >> of
> >> 512 bytes that accepts data through a public member function. If there
> is
> >> no data to transmit it will produce one empty packet to keep the USRP
> >> busy.
> >> The scheduler keeps asking for 64 items and I give it one. This goes on
> >> until its write buffer is full. The processing latency (from the source
> >> block to the USRP) of the first items is a few ms, but this grows to
> well
> >> over a second due to the large amounts of buffered data.
> >> 
> >> Looking at the behavior of the single threaded scheduler, it seems it
> is
> >> trying to keep the latency low by only requesting data from source
> blocks
> >> when the other blocks fail to produce anything. However, the thread per
> >> block scheduler does not seem to care about whether a block is a source
> >> block or not. Is there any way I can configure it to do this? Is there
> >> any
> >> other approach for solving this problem?
> >> 
> >> Thankful for any help,
> >> Anton Blad
> > 
> > Hi Anton,
> > 
> > There's been some discussion about this over the past few months.
> > Probably the easiest way to fix this problem is to limit the usable
> > size of the buffers in the processing chain.  This is a relatively
> > small change, that would allow an application developer to control the
> > worst case amount of buffering that is used in the graph.  By default,
> > we allocate buffers on the order of 32KiB, then double that size so
> > that we can double buffer under the TPB scheduler. (Optimizing for
> > throughput.)
> > 
> > The current implementation requires that the physical size of the
> > buffers be a multiple of the page size.  The fix I'm proposing leaves
> > that constraint in place (it's hard to remove for a variety of
> > reasons), but allows the specification of a limit on the total number
> > of samples allowed in the buffer.  Thus, if want low latency, you
> > could specify a limit of 512 bytes (or less for that matter), and the
> > total buffering would be drastically reduced from what's currently
> > used.
> > 
> > I won't have time to look at this until after the new year, but if
> > you're interested in looking at it, the primary place to look is
> > gnuradio-core/src/lib/runtime/gr_buffer.{h,cc}.  Basically you'd want
> > to limit the amount of space that it reports is available for writing
> > to min(, )
> > 
> > Eric
> 
> Hi Eric,
> 
> Thanks for your reply. There are two obvious drawbacks with the simple
> fix: the latency will still be higher than necessary, and processing large
> chunks will not be possible. I have the following alternative suggestion:
> 
> * Create a new policy governing class (gr_tpb_policy_governor?) with the
> purpose of keeping track of which blocks are making progress. The class
> contains a condition variable that source blocks wait on in case the
> scheduling policy disallows adding more samples to the flowgraph.
> 
> * Create an instance of gr_tpb_policy_governor in the gr_scheduler_tpb
> constructor and tell it the number of blocks in the flattened flowgraph.
> 
> * Add a reference to the gr_tpb_policy_governor instance in the
> gr_tpb_detail blocks. Update the states of the blocks in
> gr_tpb_detail::set_{input,output}_changed and in
> gr_tpb_thread_body::gr_tpb_thread_body depending on
> gr_block_executor::state.
> 
> The policies I can think of being useful are:
> 
> * flooding: the current policy, for performance
> 
> * active_blocks: block sources if more than a minimum number of blocks are
> processing concurrently, in order to reduce latency. Could be set to 1 to
> give the behavior of the single threaded scheduler.
> 
> * num_samples: block sources if more than a minimum number of samples are
> processed currently, in order to reduce latency while still ensuring
> acceptable performance.
> 
> I guess that the main drawback of this proposal is that the
> gr_tpb_policy_governor will contain a very heavily used mutex.
> 
> Comments? If I do these changes, will the GNU Radio team be interested in
> a patch?

If it can be done cleanly and simply in a way that doesn't reduce the
performance too much (say 3%) for those who are using "flooding", then
I think we'd consider it.  The measure of performance should be total
CPU time (== user + sys).

I do have some questions about how you'd tune the "active_blocks" and
"num_samples" cases...

Eric

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

Re: [Discuss-gnuradio] Broken gr_fir_fff ?

[Eric Blossom]

On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote:
> 
> Sorry if I can't provide any more debug info, I'm new and ignorant, but I
> updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now
> I'm getting two programs with duplicate failure in gr_fir_fff.  They just
> dump back to the shell after 2 seconds with no debug info.

It's unlikely that there's a problem in gr_fir_fff.

What version of GNU Radio are you using?
What OS, distribution and version?
What hardware are you running it on?
How much memory does the machine have?
Is there anything interesting in /var/log/messages?

If there are 100's of blocks in this graph, you may want to reduce the
default stack size allocated for each thread.  (Even if not used, the
virtual address space is reserved.)


# Output from an x86_64 machine running Fedora 13

$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 63888
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 50
stack size  (kbytes, -s) 10240
cpu time   (seconds, -t) unlimited
max user processes  (-u) 1024
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited


The default stack size is 10240k. You can probably reduce this to
4094k (or maybe 2048k) without a problem using:

   $ ulimit -Ss 4096

Using -S sets the "soft limit", which means you can set it back up
without being root:

  $ ulimit -Ss 10240

Eric

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

Re: [Discuss-gnuradio] usrp_fft.py question and benchmark related question

[Eric Blossom]

On Wed, Dec 01, 2010 at 04:57:11PM -0600, John Andrews wrote:
> Hi,
> Can we change the DDC value to 0 in usrp_fft.py? Why is this not 0 as one
> would expect to input the center frequency same as the baseband frequency;
> i.e. if I know that my signal is on a carrier at 2.4G then I would use
> usrp_fft.py to display the spectrum by having the center frequency as 2.4G
> instead of typing in 2.404G (as DDC is -4M).

It's non-zero to move the RF DC offset problem away from zero (and in
most cases out of the range that anybody cares about).  See earlier
message today...

> In benchmark_tx/rx programs do I have to account for this DDC=-4.0M? If one
> USRP is transmitting at 2.4G ( ./benchmark_tx.py -f 2400M ) then should I
> have the receiving USRP receiving at 2.404G ( ./benchmark_rx.py -f 2404M )?

No you don't.  If you do -f 2400M then the complex baseband signal is
equivalent to the RF signal that's centered at 2400M.

Eric

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

Re: [Discuss-gnuradio] Tesla C2000 series and CUDA and Gnu Radio

[Eric Blossom]

On Wed, Dec 01, 2010 at 01:40:03AM -0500, Marcus D. Leech wrote:
> 
> On a related note, has anyone looked at enabling the multi-threaded FFTW
> stuff?  The cross-over
>   points there (between FFTW in a single-thread and FFTW in
> multiple-threads) seem to be lower-down
>   on the FFT-size curve.

Marcus, 

I haven't tried it, but I'd guess that the crossover point is >= 16K points.

If you try it, let us know what you find.

Eric

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

Re: [Discuss-gnuradio] help -- how to implement transmitting periodic on/off tones

[Eric Blossom]

On Mon, Nov 29, 2010 at 12:42:38AM -0800, Steve Mcmahon wrote:
> Hello:

> I have a USRP2 board and a WBX daughterboard. I am trying to
> implement a scheme where a single-tone sine wave (at frequencies
> between 1 kHz and 10 kHz) is transmitted
> intermittently. Specifically, time is divided into intervals,
> defined by the user on the command line, typically of values such as
> 200 ms or 500 ms or 1s. When invoked, the flow graph (the Python
> script) would transmit nothing (all zeros) during the first time
> interval, then transmit the tone during the second time interval,
> then transmit nothing (all zeros) during the third and fourth and
> fifth time intervals, then transmit the tone during the sixth time
> interval, then transmit nothing (all zeros) during the seventh time
> interval, and then stop and end.

> How in the world could I implement this? I feel like it'd be hard to
> do, but maybe it's actually easy. Would I need to use a timer in
> Python to set what gets transmitted at the start of each interval
> duration? Any help would be very much appreciated, as I am still
> somewhat new to GNU Radio and Python. Thanks for your help,
> everyone.

Think of the on/off part as a control stream consisting of 1's and
0's.  Generate the control stream, and multiple the control stream by
the carrier stream.

Don't try to start and stop the graph or anything like that from
python. 

You can probably generate the control stream with a
gr.vector_source_f([], True) followed by a dumb
interpolator that will just replicate values.

  my_pattern = [1, 1, 0, 0, 1, 0, ... ]
  interp_factor = 1000   # scale the pattern up in time to match signal

  ctrl_pattern = gr.vector_source_f(my_pattern, True)
  ctrl_interp = gr.interp_fir_filter_fff(interp_factor, interp_factor*[1.0])
  
  signal = 

  mult = gr.multiple_ff()

  sink = 


  tb.connect(ctrl_pattern, ctrl_interp, (mult, 0))
  tb.connect(signal, (mult, 1))
  tb.connect(mult, sink)



Eric

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

Re: [Discuss-gnuradio] TPB scheduler fills block buffers

[Eric Blossom]

On Mon, Nov 29, 2010 at 08:42:14AM +0100, antonb wrote:
> Hi,
> 
> I am writing an application for which I want to keep the latency to a
> minimum, and this involves trying to keep the buffers between the blocks as
> empty as possible. Basically, I have a source block with an element size of
> 512 bytes that accepts data through a public member function. If there is
> no data to transmit it will produce one empty packet to keep the USRP busy.
> The scheduler keeps asking for 64 items and I give it one. This goes on
> until its write buffer is full. The processing latency (from the source
> block to the USRP) of the first items is a few ms, but this grows to well
> over a second due to the large amounts of buffered data.
> 
> Looking at the behavior of the single threaded scheduler, it seems it is
> trying to keep the latency low by only requesting data from source blocks
> when the other blocks fail to produce anything. However, the thread per
> block scheduler does not seem to care about whether a block is a source
> block or not. Is there any way I can configure it to do this? Is there any
> other approach for solving this problem?
> 
> Thankful for any help,
> Anton Blad

Hi Anton,

There's been some discussion about this over the past few months.
Probably the easiest way to fix this problem is to limit the usable
size of the buffers in the processing chain.  This is a relatively
small change, that would allow an application developer to control the
worst case amount of buffering that is used in the graph.  By default,
we allocate buffers on the order of 32KiB, then double that size so
that we can double buffer under the TPB scheduler. (Optimizing for
throughput.)

The current implementation requires that the physical size of the
buffers be a multiple of the page size.  The fix I'm proposing leaves
that constraint in place (it's hard to remove for a variety of
reasons), but allows the specification of a limit on the total number
of samples allowed in the buffer.  Thus, if want low latency, you
could specify a limit of 512 bytes (or less for that matter), and the
total buffering would be drastically reduced from what's currently
used.

I won't have time to look at this until after the new year, but if
you're interested in looking at it, the primary place to look is
gnuradio-core/src/lib/runtime/gr_buffer.{h,cc}.  Basically you'd want
to limit the amount of space that it reports is available for writing
to min(, )

Eric

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

Re: [Discuss-gnuradio] Not getting Makefile after bootstrap configure?

[Eric Blossom]

On Sat, Nov 27, 2010 at 11:16:24PM -0600, Brett L. Trotter wrote:
> On an up to date fedora 13 x86_64
> 
> I just did this:
>   624  git clone http://gnuradio.org/git/gnuradio.git
>   625  cd gnuradio
>   626  git branch --track next origin/next
>   627  git checkout next
>   628  ./bootstrap
>   629  ./configure --enable-docs --enable-grc --enable-gnuradio-examples
> --enable-gr-utils --enable-gr-sounder --enable-gr-qtgui
> --enable-gr-wxgui --enable-gr-video-sdl --enable-gr-trellis
> --enable-gr-radio-astronomy --enable-gr-pager
> --enable-gr-noaa--enable-gr-gsm-fr-vocoder --enable-gr-gpio
> --enable-gr-cvsd-vocoder --enable-gr-atsc --enable-gr-audio-jack
> --enable-gr-audio-alsa --enable-gr-usrp2 --enable-gr-usrp --enable-usrp2
> --enable-usrp --enable-gnuradio-core --enable-gruel --enable-python
> --enable-gr-uhd UHD_LIBS=/opt/uhd/lib UHD_INCLUDEDIR=/opt/uhd/include
> --no-create --no-recursion
>   630  make
> 
> and I get success from configure:
> *
> The following GNU Radio components have been successfully configured:
> 
> config
> gruel
> gnuradio-core
> usrp
> usrp2
> gr-usrp
> gr-usrp2
> gr-msdd6000
> gr-audio-alsa
> gr-audio-jack
> gr-audio-oss
> gr-atsc
> gr-cvsd-vocoder
> gr-gpio
> gr-gsm-fr-vocoder
> gr-noaa
> gr-pager
> gr-radar-mono
> gr-radio-astronomy
> gr-trellis
> gr-video-sdl
> gr-wxgui
> gr-qtgui
> gr-sounder
> gr-utils
> gnuradio-examples
> grc
> gr-uhd
> docs
> 
> You my now run the make command to build these components.
> 
> *
> The following components were skipped either because you asked not
> to build them or they didn't pass configuration checks:
> 
> gcell
> gr-gcell
> gr-audio-osx
> gr-audio-portaudio
> gr-audio-windows
> gr-comedi
> 
> These components will not be built.
> 
> 
> but I get no Makefile generated.
> [r...@localhost gnuradio]# ls -la Makefile*
> -rw-r--r-- 1 root root  1455 Nov 27 22:47 Makefile.am
> -rw-r--r-- 1 root root  4024 Nov 27 22:47 Makefile.common
> -rw-r--r-- 1 root root  1358 Nov 27 22:47 Makefile.common.spu
> -rw-r--r-- 1 root root  2734 Nov 27 22:47 Makefile.gen.gen
> -rw-r--r-- 1 root root 43538 Nov 27 22:48 Makefile.in
> -rw-r--r-- 1 root root  2833 Nov 27 22:47 Makefile.par.gen
> -rw-r--r-- 1 root root  3913 Nov 27 22:47 Makefile.swig
> -rw-r--r-- 1 root root  9605 Nov 27 22:47 Makefile.swig.gen.t
> 
> Have i missed something?

Any particular reason you're passing the --no-create --no-recursion flags?

Eric

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

Re: [Discuss-gnuradio] call set_output_multiple() on the fly

[Eric Blossom]

On Fri, Nov 26, 2010 at 11:55:50AM +1100, Kyle Zhou wrote:
> On 26/11/2010 11:28 AM, Eric Blossom wrote:
> >There is no guarantee that set_output_multiple will work if you change
> >it on the fly.
> >
> >It is possible that you could specify a value for set_output_multiple
> >that would require reallocation of the impacted buffers.  We do not do
> >that.
> >
> >Eric
> >
> 
> Thanks Eric.
> How about set_relative_rate()? can I call it on the fly?

Small changes are OK.  Large changes have the same problem as
set_output_multiple. 

> Another question: is it thread safe to modify the module's member
> variables from outside the work()?

In general no, unless you do something to make it safe yourself.

Eric

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

Re: [Discuss-gnuradio] call set_output_multiple() on the fly

[Eric Blossom]

On Thu, Nov 25, 2010 at 11:11:27PM +1100, Kyle Zhou wrote:
> I am writing a module that might need dynamic change to the block length.
> So I want to call set_output_multiple(blk_len) when the flow graph is running.
> Firstly, is this allowed?
> Secondly, what are the effects? 
> If I have a "noutput_items%blk_len==0" checking in work(), will it fail 
> during the transition?
> Thanks
> Kyle

There is no guarantee that set_output_multiple will work if you change
it on the fly.

It is possible that you could specify a value for set_output_multiple
that would require reallocation of the impacted buffers.  We do not do
that. 

Eric

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

Re: [Discuss-gnuradio] Carrier frequency mismatching?

[Eric Blossom]

On Fri, Nov 19, 2010 at 09:19:04PM +0900, Songsong Gee wrote:
> I understan what you told me...
> Then... however, why they have same sign?
> One is for up conversion, and the other is for down conversion
> they might have opposite signs.
> one is MINUS 4 MHz, and the other is PLUS 4 MHz
> 
> and one another...
> They meet in frequency by DXC,
> but, in my opinion, they are basically different in baseband frequency...
> I really really cannot understand this magic :(

Try drawing a picture...

Eric


> 2010/11/19 Eric Blossom 
> 
> > On Fri, Nov 19, 2010 at 05:17:53PM +0900, Songsong Gee wrote:
> > > I use USRP sink and source and set frequency with 2.6 GHz
> > > When I run a flow graph, I see like below:
> > > ==
> > > A: Flex 2400 Tx MIMO B
> > > r.baseband_frequency = 260400.0
> > > r.dxc_frequency = -400.0
> > > r.residual_frequency = 0.0
> > > r.inverted = False
> > >
> > > A: Flex 2400 Rx MIMO B
> > > r.baseband_frequency = 259600.0
> > > r.dxc_frequency = -400.0
> > > r.residual_frequency = 0.0
> > > r.inverted = False
> > > ===
> > > Both of baseband frequency are near 2.6 G, but they do not match up
> > > Can it be problmeatic for communicating each other?
> >
> > The actual frequencies on the air will be 2.6 G +/- oscillator tolerance.
> >
> > In the Tx case, the LO is set 4MHz higher than the target, and the
> > DUC is used to adjust the baseband -4MHz.
> >
> > In the Rx case the LO is set 4MHz lower than the target, and the DDC
> > is used to move the digitized IF signal 4MHz lower prior to decimating.
> >
> > This is easy to confirm with a siggen and a spectrum analyzer.
> >
> > Eric

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

Re: [Discuss-gnuradio] Carrier frequency mismatching?

[Eric Blossom]

On Fri, Nov 19, 2010 at 05:17:53PM +0900, Songsong Gee wrote:
> I use USRP sink and source and set frequency with 2.6 GHz
> When I run a flow graph, I see like below:
> ==
> A: Flex 2400 Tx MIMO B
> r.baseband_frequency = 260400.0
> r.dxc_frequency = -400.0
> r.residual_frequency = 0.0
> r.inverted = False
> 
> A: Flex 2400 Rx MIMO B
> r.baseband_frequency = 259600.0
> r.dxc_frequency = -400.0
> r.residual_frequency = 0.0
> r.inverted = False
> ===
> Both of baseband frequency are near 2.6 G, but they do not match up
> Can it be problmeatic for communicating each other?

The actual frequencies on the air will be 2.6 G +/- oscillator tolerance.

In the Tx case, the LO is set 4MHz higher than the target, and the
DUC is used to adjust the baseband -4MHz.

In the Rx case the LO is set 4MHz lower than the target, and the DDC
is used to move the digitized IF signal 4MHz lower prior to decimating.

This is easy to confirm with a siggen and a spectrum analyzer.

Eric

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

Re: [Discuss-gnuradio] Help - Custom block generating data @ 1:5115 input to output ratio causes flowgraph to hang -- how to prevent this

[Eric Blossom]

On Wed, Nov 17, 2010 at 09:14:47AM -0800, John Andrews wrote:
> Hi,
> I am posting this question again with better explanation as I got no help
> yet.
> 
> I have a custom C++ block that I use in the modified dbpsk.py modulation
> scheme. This block basically spreads each input data bit by 1023.
> 
> The flowgraph connect looks like this
> self.connect(self,self.bytes2chunks,self.symbol_mapper,self.diffenc,self.CUSTOM_BLOCK,self.chunks2symbols,self.rrc_filter,self)
> 
> The CUSTOM_BLOCK outputs 5115 bytes for every input byte read therefore, in
> the flowgraph the input rate at self.chunks2symbols is 5115 times to that of
> input at self.CUSTOM_BLOCK. This causes the flowgraph to slow down
> incredibly to such an extent that I have to force kill it. I am using
> benchmark_tx.py to pass data to the flowgraph.

Stating the obvious, you have just increased the workload by a factor
of 5115.  You seem surprised that it's taking 5000 times longer to run...



> I implemented the custom block in 2 different ways once by inheriting
> gr_block and the other by using gr_sync_interpolator but the result is still
> the same. What should I do to make it work smoothly?
> 
> Thanks
> 
> P.S - The work function is shown below when using gr_sync_interpolator.
> 
>  dsss_sync_spread_b::work(int noutput_items,gr_vector_const_void_star
> &input_items,gr_vector_void_star &output_items)
> {
>   const unsigned char *in = (const unsigned char *)input_items[0];
>   unsigned char *out = (unsigned char *)output_items[0];
>   int data_items=noutput_items/interpolation(); // interploation() returns
> (d_length_PN * d_n_pn which is equal to 1023 * 5)
>   int nout=0;
>   for(int i=0;i   if(in[i]&0x01){
>   for(int j=0;j   out[nout]=d_pn_array1[j%d_length_PN];   // the array d_pn_array1
> has datatype 'char' and is of size 1023. d_length_PN = 1023 and is
> initialised in the constructor and is never changed
>   nout++;
>   }

The modulo operator in the inner loop isn't helping matters.  div and
mod are not free.  Q: How may cycles does an integer divide take on
the Core 2 microarchitecture?

Have you used oprofile or some other tool to see where you're actually
spending your cycles?

With a bit of restructuring, you could turn the inner loop into a
memcpy.  Left as an exercise...

However, I strongly recommend using oprofile of some other tool to see
where you're spending your cycles before you change anything.


>   }
>   else{
>   for(int j=0;j   out[nout]=d_pn_array0[j%d_length_PN];  // the array d_pn_array2
> has datatype 'char' and is of size 1023. d_length_PN = 1023 and is
> initialised in the constructor and is never changed
>   nout++;
>   }
>   }
>   }
>   return noutput_items;
> }


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

Re: [Discuss-gnuradio] question about import a new block in gnuradio-3.3.0

[Eric Blossom]

On Wed, Nov 17, 2010 at 06:28:32PM +0800, intermilan wrote:
> 
> Hi Eric:
>thanks for your help. I figured the question out.

What was the problem and the fix?  It's nice to have it here on the
list so that others can find it with their favorite search engine.

Eric


> > Date: Tue, 16 Nov 2010 21:46:13 -0800
> > From: e...@comsec.com
> > To: tianxia...@hotmail.com
> > CC: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] question about import a new block in 
> > gnuradio-3.3.0
> > 
> > On Wed, Nov 17, 2010 at 10:48:11AM +0800, intermilan wrote:
> > > 
> > > hi all:
> > >  I use the command create-gnuradio-out-of-tree-project to bulid a new 
> > > block,and after that I use the following command:
> > >  ./bootstrap
> > >  ./configure
> > >  make
> > >  make check
> > >  sudo make install
> > >  Then I thought I had installed the new block.then I want to import 
> > > the new block in the python to make sure it is successfully 
> > > installed.Then I got this:
> > > 
> > > tianxia...@ubuntu:~/gnuradio-3.3.0/test_example$ python
> > > Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
> > > [GCC 4.4.3] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> import test_example
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File "/usr/local/lib/python2.6/dist-packages/test_example/__init__.py", 
> > > line 40, in 
> > > from test_example_swig import *
> > >   File 
> > > "/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py",
> > >  line 24, in 
> > > _test_example_swig = swig_import_helper()
> > >   File 
> > > "/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py",
> > >  line 20, in swig_import_helper
> > > _mod = imp.load_module('_test_example_swig', fp, pathname, 
> > > description)
> > > ImportError: libgnuradio-test_example.so.0: cannot open shared object 
> > > file: No such file or directory
> > > 
> > > My python is not very well,so I hope someone can help me figure it 
> > > out.
> > > Thank you in advance.   
> > 
> > Assuming you've got /usr/local/lib in /etc/ld.so.conf...
> > 
> >  $ sudo ldconfig
> > 
> > 
> > Or
> > 
> >  $ export LD_LIBRARY_PATH=/usr/local/lib
> > 
> > 
> > BTW, it's always helpful to tell us what OS and distribution you're using...
> > 
> > Eric

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

Re: [Discuss-gnuradio] question about import a new block in gnuradio-3.3.0

[Eric Blossom]

On Wed, Nov 17, 2010 at 10:48:11AM +0800, intermilan wrote:
> 
> hi all:
>  I use the command create-gnuradio-out-of-tree-project to bulid a new 
> block,and after that I use the following command:
>  ./bootstrap
>  ./configure
>  make
>  make check
>  sudo make install
>  Then I thought I had installed the new block.then I want to import the 
> new block in the python to make sure it is successfully installed.Then I got 
> this:
> 
> tianxia...@ubuntu:~/gnuradio-3.3.0/test_example$ python
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test_example
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.6/dist-packages/test_example/__init__.py", 
> line 40, in 
> from test_example_swig import *
>   File 
> "/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py", 
> line 24, in 
> _test_example_swig = swig_import_helper()
>   File 
> "/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py", 
> line 20, in swig_import_helper
> _mod = imp.load_module('_test_example_swig', fp, pathname, description)
> ImportError: libgnuradio-test_example.so.0: cannot open shared object file: 
> No such file or directory
> 
> My python is not very well,so I hope someone can help me figure it out.
> Thank you in advance.   

Assuming you've got /usr/local/lib in /etc/ld.so.conf...

 $ sudo ldconfig


Or

 $ export LD_LIBRARY_PATH=/usr/local/lib


BTW, it's always helpful to tell us what OS and distribution you're using...

Eric

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

Re: [Discuss-gnuradio] GNU Radio Unstable Behavior

[Eric Blossom]

On Tue, Nov 16, 2010 at 11:51:51AM -0500, g...@vt.edu wrote:
> I set up a two-node link using tunnel.py, two nodes continuously exchanged 
> data
> with each other. Quite often, GNU Radio stopped in one node because of the
> following error. Any hints to resolve this problem will be highly appreciated.
> 
> Andrew
> 
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
> self.run()
>   File "/home/titan/new_multi_chan/pkt.py", line 95, in run
> ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1()))
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py", line
> 183, in unmake_packet
> payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset)
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py", line
> 95, in dewhiten
> return whiten(s, o)# self inverse
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py", line
> 91, in whiten
> z = sa ^ random_mask_vec8[o:len(sa)+o]
> ValueError: shape mismatch: objects cannot be broadcast to a single shape
> 

I looks like you may be passing a zero-length string to unmake_packet,
and that whiten doesn't not properly deal with a zero length string.

Try not calling unmake_packet if msg.to_string() returns a zero length
string.

Eric

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

Re: [Discuss-gnuradio] Re: get fatal IO error 11 when running usrp2_fft.py (USRP2 + XCVR2450)

[Eric Blossom]

On Tue, Nov 16, 2010 at 12:27:07PM -0500, XIAN PAN wrote:
> Hi Marcus D. Leech,
> 
> Thanks for your response. I try the -d 40 on the command usrp2_fft.py. The
> problem is still here.

Is your system running out of memory?

Look at the output of

  $ dmesg

and look at /var/log/messages

  $ sudo tail -1000 /var/log/messages | less


Eric

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

Re: [Discuss-gnuradio] gnuradio-3.3.0 Build Error On Fedora 14 (x86_64)

[Eric Blossom]

On Sat, Nov 13, 2010 at 11:33:05PM -0800, Arya Santini wrote:
> Hi List,
> 
> I'm trying to build gnuradio-3.3.0 on Fedora 14 x86_64. I've installed
> all the prerequisites, and I run ./configure and it completes fine,
> reporting the modules going to be built. But when I run 'make', it
> runs for a while and then exits with the following error(s):

This particular problem is fixed in the git master.

Please use that until a new release is made.

http://gnuradio.org/redmine/wiki/gnuradio/Download

Eric

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

[Discuss-gnuradio] Re: TPB update

['Eric Blossom']

On Fri, Nov 12, 2010 at 10:05:28AM +1100, Balint Seeber wrote:
> Dear Eric,
> 
> I realised I was actually getting ahead of myself regarding scenario (1),
> because - of course - the sample rate means nothing in terms of timing if it
> is not a synchronous graph, and as I stated I didn't use Throttle. So the
> behaviour in (1) is expected. would you agree?

Yes.

> Still not sure about (3) though. Did the graph make it through okay?
> 
> Thanks very much once again,
> 
> Balint
> 


Using the single graph (the one you sent me):

Running case (1):

htop shows it burning 95% of one core and 25% of another.
Seems reasonable to me.  (On my 8-core Xeon)

I started oprofile, ran the flow graph for a while (> 10s), then
looked at the output of opreport:

  $ opreport --long-filenames  --symbols -t 0.5 >/tmp/report

It gives the report below, which isn't surprising.  That is, 57% of
the samples are in ccomplex_dotprod_sse (the innerloop of the
gr_fir_ccc_simd_filter, used by the resampler), and 16% are in
gr_sig_source_c::work (generating the complex sinusoid).

The cycles chargable to the resampler include ccomplex_dotprod_sse,
gr_fir_ccc_simd_filter, and gr_rational_resampler_base_ccc, which
comes out to ~69%.

(It's normalized to total samples counted)


CPU: Core 2, speed 3000.07 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask 
of 0x00 (Unhalted core cycles) count 10
samples  %app name symbol name
17535154 57.4244  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
ccomplex_dotprod_sse
4966060  16.2629  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_sig_source_c::work(int, std::vector 
>&, std::vector >&)
2909663   9.5286  /no-vmlinux  /no-vmlinux
2490431   8.1557  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_fir_ccc_simd::filter(std::complex const*)
1094391   3.5839  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_rational_resampler_base_ccc::general_work(int, std::vector >&, std::vector 
>&, std::vector >&)
2352070.7703  /lib64/libpthread-2.12.1.so pthread_mutex_lock



Running case (3):

htop shows it burning 95% of TWO cores and 25% of another.
Also seems reasonable to me.  One core for each of the two rational
resamplers, and 25% for the rest.

  $ opreport --long-filenames  --symbols -t 0.5 >/tmp/report3


CPU: Core 2, speed 3000.07 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask 
of 0x00 (Unhalted core cycles) count 10
samples  %app name symbol name
3931690  63.0917  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
ccomplex_dotprod_sse
6110599.8056  /no-vmlinux  /no-vmlinux
5578618.9520  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_fir_ccc_simd::filter(std::complex const*)
5502238.8294  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_sig_source_c::work(int, std::vector 
>&, std::vector >&)
2484203.9864  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_rational_resampler_base_ccc::general_work(int, std::vector >&, std::vector 
>&, std::vector >&)
55851 0.8962  /lib64/libpthread-2.12.1.so pthread_mutex_lock
31423 0.5042  /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 
gr_tpb_detail::notify_upstream(gr_block_detail*)


In this case, it's about 76% from the two rational resamplers, 9% for
the sig gen, and 1.5% scheduler overhead (pthread_mutex_lock and
notify_upstream).  In reality, the ticks in the kernel should be
charged towards overhead too.


Is there any chance that you had some kind of power control or
frequency scaling going on?  If it's a laptop, be sure that it's in
"performance mode" and not "I want the battery to last a long time
mode"


Remember that Amdahl's Law gives the maximum speedup within a given
graph.  https://secure.wikimedia.org/wikipedia/en/wiki/Amdahl%27s_law


In any case, I think that you'll find a combination of htop and
oprofile should help shed some light on where the cycles are being
burned.

Eric

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

Re: [Discuss-gnuradio] USRP2 printing of character "S" bothersome!!

[Eric Blossom]

On Thu, Nov 11, 2010 at 04:57:56PM -0500, Bishal Thapa wrote:
> Hello,
>   I am using USRP2 version of BBN code to look at AP beacons as seen by the
> USRP2 host. There is lots of "S" printing going on, which keeps me from
> reading AP beacon information from STDOUT (unless I save the output to a
> file, which I prefer not to). Is there anyway to enforce the printing of "S"
> character to go away. Here is my node's specification:
> 
> 
>- BBN Code Location:
>https://www.cgran.org/cgran/projects/bbn_80211/branches/usrp2_version
>- CPU: Intel(R) Core(TM) 2 CPU E8400 @ 3GHz
>- Memory: 4GB
>- Hard Disk: 1TB
> 
> My ubuntu version = 10.04
> GNuradio version = 3.3.0
> 
> 
> Thank you in advance for your help.

One of the joys of Free Software is you have the freedom to study how
the program works, and change it to make it do what you wish.  We
provide the source code to enable this freedom.

The "S" is written out on line 454 of usrp2_impl.cc

FWIW, it's written to stderr, not stdout, so you could just shunt
stderr into /dev/null:

  $ my-program 2>/dev/null

Eric

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

Re: [Discuss-gnuradio] config.guess and config.sub in git

[Eric Blossom]

On Thu, Nov 11, 2010 at 10:23:38AM -0800, Philip Balister wrote:
> I'm building gnuradio from a git checkout using OE to setup the
> toolchains etc. Part of the build process is similar to running
> bootstrap, but with special autotools. Afterwards, git status
> reports change in config.guess and config.sub. My understanding is
> these are generated files and should not be in the repository.
> 
> Can we delete these from git/next, or is there some reason they are there?
> 
> # modified:   config.guess
> # modified:   config.sub
> # modified:   usrp2/firmware/config.guess
> # modified:   usrp2/firmware/config.sub
> 
> Philip

Those files are not generated, but if they're not there, they are
copied from the local (potentially out of date) system.

What's in the repository are most likely more up-to-date than what's
on your local system.  You can check the date code at the top of each
file to check.

Mostly this matters when we build tarballs, since what's in the tree
is what goes into the tarball.  The reason we like the most
up-to-date, is that they support more system configurations.

You could make the problem "invisible" on your end by adding appropriate
entries to your own ~/.gitignore  :-)

Eric

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

Re: [Discuss-gnuradio] Cannot build USRP. ./configure reports sdcc is missing in spite of it being installed!

[Eric Blossom]

On Wed, Nov 10, 2010 at 07:13:17PM -0800, Arya Santini wrote:
> Hi List,
> 
> I'm trying to build GNU Radio from source, and when I run ./configure,
> I see USRP is not going to be built under the heading : "The following
> components were skipped either because you asked not to build them or
> they didn't pass configuration checks:"
> 
> gcell
> usrp
> gr-usrp
> gr-gcell
> gr-audio-jack
> gr-audio-osx
> gr-audio-portaudio
> gr-audio-windows
> gr-comedi
> gr-gpio
> gr-radar-mono
> gr-video-sdl
> gr-sounder
> gr-utils
> 
> This is the text from ./configure pertaining to USRP:
> 
> checking for sdcc... sdcc -mmcs51 --no-xinit-opt
> checking for asx8051... no
> USRP requires sdcc. sdcc not found. See http://sdcc.sf.net
> Unable to find firmware compiler SDCC.
> Not building component usrp.
> 
> Why? I've installed sdcc and double checked it. Still I cannot get
> USRP to build. I'm on Fedora 12. Please help.
> 
> Thanks,
> Arya.

Fedora installs it into /usr/libexec/sdcc.

Add /usr/libexec/sdcc to your path:

  $ PATH=$PATH:/usr/libexec/sdcc.

Eric

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

Re: [Discuss-gnuradio] Using Both Input Channels of a Sound Card

[Eric Blossom]

On Wed, Nov 10, 2010 at 11:51:26AM -0500, George S. Williams wrote:
> Hello,
> 
> Is it possible to take input from both the right and left input
> channels of a sound card?
> 
> And, can they both be processed in the same flowgraph?
> 
> I've spent some time with Google this morning and haven't found an answer.
> 
> Thanks in advance,
> George

Yes, just connect using (source, 0) and (source, 1).

Eric

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

Re: [Discuss-gnuradio] question on howto write a new block

[Eric Blossom]

On Tue, Nov 09, 2010 at 03:23:35PM +0100, Martin Braun wrote:
> On Tue, Nov 09, 2010 at 05:33:15PM +0800, intermilan wrote:
> > hi all:
> >  I am writing a new simple signal processing block following the 
> > tutorial
> > under the directory /gnuradio-3.2.2/gr-howto-write-a-block-3.2.2(there is no
> > gr-howto-write-a-block-3.2.2 at the beginning,and this one is I downloaded 
> > and
> > copied to this directory)and named 'howto_add_ff' block. I've created
> > howto_add_ff.h and howto_add_ff.cc file under /gnuradio-3.2.2/
> > gr-howto-write-a-block-3.2.2/src/lib.Then I modified howto.i and 
> > Makefile.am in
> > the same directory.
> >After that  I run the following command under the directory 
> > /gnuradio-3.2.2/
> > gr-howto-write-a-block-3.2.2:
> >./bootstrap
> >./configure 
> >make
> >   Then I got a error  said "thers is no rules for "all-am" to creat the
> > required target "howto_add_ff.h".STOP."( I translate the error into english
> > beacause I do no use engliah as the language of my Ununtu).
> >Can anyone tell me how to fix it?
> 
> You've probably not adapted the Makefiles properly.
> Have a look where howto_square_ff.* is referenced (it's a couple of
> places).
> I recommend using gr_modtool.py (you can get it from
> https://www.cgran.org/wiki/devtools), this automatically does all the
> edits for you.
> 
> Cheers,
> MB

I'd also suggest starting with 3.3.0 (or git master) instead of 3.2.2, and use 
the
 
  $ create-gnuradio-out-of-tree-project 

command to get you started.

Eric

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

Re: [Discuss-gnuradio] Pipelined processing with the Thread-Per-Block scheduler?

[Eric Blossom]

On Tue, Nov 09, 2010 at 04:34:42PM +1100, Balint Seeber wrote:
> Dear all,
> 
> I conducted a simple experiment (using GRC) to test the TPB scheduler's
> performance, and following a search here, I cannot find any definitive
> information that would explain the observed behaviour. I kindly request your
> thoughts on the matter:
> 
>  
> 
> Three flow graphs were created in separate GRC documents. No graph uses
> throttling. Tests were run on a dual-core Linux machine using a 3.3git
> release.
> 
>  
> 
> 1)  One graph: a high-rate signal source connected to a resampler, which
> is in turn connected to a null sink.
> 
> 2)  Two identical disconnected sub-graphs: each contains a high-rate
> signal source connected to a resampler, which is in turn connected to a null
> sink (i.e. as above, just twice).
> 
> 3)  One graph: one high-rate signal source whose output is connected to
> the input of two separate resamplers, each of which is connected to its own
> null sink.
> 
> 'High-rate' means a few Msps, and the resamplers output data at a similar
> rate (e.g. 8MHz, decim/interp=4:3).
> 
> Thanks to the TPB scheduler, (2) uses 100% CPU (max load on both cores) as
> the sub-graphs are disconnected.
> 
> However when running (1) and (3), only 50% utilisation is observed. I also
> placed 'Copy' and 'Kludge Copy' blocks before the resampler inputs in (3),
> but this did not increase performance (which makes sense given the assumed
> flow model below).
> 
> I am not aware of the intricacies of the asynchronous flow model used, or
> the TPB scheduler (I only skimmed the source), but I wonder why (1) and (3)
> do not use more than 50% CPU?

What kind of hardware are you running this on?  (Pls be specific.)
How may core does the kernel say you have? cat /proc/cpuinfo

If these are i5's or i7's (or anything else with "hyperthreading")
please remember that half of the cores shown by the kernel aren't
really cores, and that there are substantial resources shared between
them.

I've achieved near linear speed up, up to 24 cores, with certain flow
graphs so I'm pretty sure that the implementation is sound.

Feel free to send me the grc file off list and I'll take a look at it.

Eric

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

Re: [Discuss-gnuradio] Basic analog USRP2 transmitter

[Eric Blossom]

On Mon, Nov 08, 2010 at 03:18:53PM -0500, Marcus D. Leech wrote:
> On 11/08/2010 03:10 PM, Eric Blossom wrote:
> >
> > I'm guessing that the Fedora 14 package is OK too :-)
> >
> > Eric
> >
> >
> >   
> I'll let you know sometime near the end of this week.  My main 'pooter
> in the house has quit,
>   so I'm replacing the mobo and disk drive, and I plan to upgrade to F14
> at the same time.
> 
> Replacing a Pentium D dual-core with a Phenom II X3.

Thanks!
Eric

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

Re: [Discuss-gnuradio] Basic analog USRP2 transmitter

[Eric Blossom]

On Sun, Nov 07, 2010 at 10:06:13PM -0500, alexander levedahl wrote:
> I might have made an error here by assuming that since the latest version of
> grc doesn't come with the build for Fedora 13, it doesn't work with Fedora
> 13.  When I have used the add/remove software tool, it tells me that
> 0.70-6.fc12 is the most up to date version around, and I can't find
> instructions on the gnuradio website for a more recent version.

I can't speak about the Fedora packages, but when building from source
GNU Radio builds and runs fine under Fedora 13, both 32 and 64-bit.

Eric

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

Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0

[Eric Blossom]

On Sat, Nov 06, 2010 at 02:34:35PM -0700, Steve Mcmahon wrote:
> Hello:
> 
> Thanks for your reply, Tom Rondeau.

> I guess I'm not sure about what people are saying on this issue
> regarding my problem building GNU Radio 3.3.0 on openSUSE 11.3 using
> gcc 4.5 -- is it gcc-4.5's "fault" (a bug in gcc), or
> gnuradio-3.3.0's "fault" (a bug in gnuradio)?

> I don't think I'm understanding the source of my problem
> correctly. Is my issue that gcc 4.5 cannot properly compile Boost
> 1.42, and that I need to use newer version of Boost with gcc-4.5, or
> is it that gnuradio-3.3.0 uses a C++ construct not supported in
> gcc-4.5, or is it a bug in gcc-4.5, or what?

I don't know about any boost/gcc problem. However we did fix a bug in
GNU Radio on 2010-08-04 in changeset d2888160c3fca8da2 that was for 
gcc 4.5.0 compatibility.

The diff is attached.

Eric
diff --git a/usrp2/host/lib/usrp2.cc b/usrp2/host/lib/usrp2.cc
index f0ee564..0842482 100644
--- a/usrp2/host/lib/usrp2.cc
+++ b/usrp2/host/lib/usrp2.cc
@@ -38,9 +38,9 @@ namespace usrp2 {
   struct usrp_table_entry {
 // inteface + normalized mac addr ("eth0:01:23:45:67:89:ab")
 std::stringkey;
-boost::weak_ptr  value;
+boost::weak_ptr  value;
 
-usrp_table_entry(const std::string &_key, boost::weak_ptr 
_value)
+usrp_table_entry(const std::string &_key, boost::weak_ptr _value)
   : key(_key), value(_value) {}
   };
 
@@ -70,7 +70,7 @@ namespace usrp2 {
 // We don't have the USRP2 we're looking for
 
 // create a new one and stick it in the table.
-usrp2::sptr r(new usrp2::usrp2(ifc, pr, rx_bufsize));
+usrp2::sptr r(new usrp2(ifc, pr, rx_bufsize));
 usrp_table_entry t(key, r);
 s_table.push_back(t);
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP BasicRX read_io() from pins

[Eric Blossom]

On Sat, Nov 06, 2010 at 12:43:28PM -0400, Burak TUYSUZ wrote:
> Thanks Eric,
> 
> Is there a pps input application/example done with this on USRP1
> probably using a counter in python.

Not that I know of.

> I would like it to count the pulses coming from a source and according to
> that
> start collecting data.
> 
> I would appreciate if you could explain this a little bit.
> Thank you
> 
> On Sat, Nov 6, 2010 at 12:32 PM, Eric Blossom  wrote:
> 
> > On Sat, Nov 06, 2010 at 11:11:51AM -0400, Burak TUYSUZ wrote:
> > > Hi all,
> > > I want to read an input from BasicRX pins using read_io()
> > > I could not find a document how to do this in python.
> > > An example would be great thank you in advance.
> >
> >   pins = u.read_io(0)   # 0 -> side A; 1 -> side B
> >
> > Eric
> >

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

Re: [Discuss-gnuradio] USRP BasicRX read_io() from pins

[Eric Blossom]

On Sat, Nov 06, 2010 at 11:11:51AM -0400, Burak TUYSUZ wrote:
> Hi all,
> I want to read an input from BasicRX pins using read_io()
> I could not find a document how to do this in python.
> An example would be great thank you in advance.

  pins = u.read_io(0)   # 0 -> side A; 1 -> side B

Eric

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

Re: [Discuss-gnuradio] Linking Gnuradio with SWIG

[Eric Blossom]

On Fri, Nov 05, 2010 at 11:14:53AM -0700, sirjanselot wrote:
> 
> Hello,
> 
> I have two SWIG versions in my machine.  I am using Centos 5.5.  One is
> installed using repositories and the other is installed using source.  Since
> Centos doesn't update their repositories on a regular basis, I had to
> install a more advanced version of SWIG manually.
> 
> When I try the ./configure command, gnuradio sees the old one but not the
> new version.
> 
> How do I fix this?

It searches based on PATH.  Adjust PATH.

Eric

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

Re: [Discuss-gnuradio] CPU Utilization and USRP2

[Eric Blossom]

On Thu, Nov 04, 2010 at 03:07:42PM -0500, Marc Epard wrote:

> This reminds me of a question. What do you guys use for profiling
> native code on Linux? I have a lot more experience on Mac OS where
> we have Shark, Instruments and the like.

Marc,

I like to use oprofile.  It's packaged for Fedora and Ubuntu (and
probably the rest).  It gets the job done using the h/w performance
counters, and as such, the measurement doesn't perturb the "regular"
execution time, and there's no need to recompile with special options.

It would be a great tool to use on this UHD problem to get a better
idea of exactly where the cycles are getting burned.

http://oprofile.sourceforge.net/docs

On Fedora 13:

  $ rpm -qa | grep -i oprofile
  oprofile-0.9.6-6.fc13.x86_64
  oprofile-gui-0.9.6-6.fc13.x86_64

Eric


> On Nov 4, 2010, at 2:23 PM, Josh Blum wrote:
> 
> > Well, there is extra overhead. A "pirate" thread in the the receive path 
> > spins on the socket and inspects the contents. The packet may be an 
> > asynchronous message packet for flow control or destined for the user. Or 
> > it may be a data packet, in which case it is placed into a queue to be 
> > popped off by the device::recv() call. No extra memcopies, its just 
> > managing pointers.
> > 
> > Could this pirate thread be removed? If the async messages came in over a 
> > different UDP port, and the multi-device buffer alignment logic was 
> > re-written to be event driven (when recv() is called). Then yes. And I will 
> > probably implement this when I get the time.  :-)
> > 
> > So, my best guess is that you are mostly seeing the overhead of the thread 
> > inspecting the packets. Of course there is also additional overhead added 
> > by using UDP, parsing VRT packets, parsing inline message packets.
> > 
> > 
> > Thanks for testing it out BTW!
> > -Josh
> > 
> > On 11/04/2010 10:46 AM, David Campbell wrote:
> >> Hi All,
> >>I've noticed that the C++ interfaces provided in gnu-radio and UHD for 
> >> usrp2
> >> data streaming are CPU-intensive (UHD moreso than gnu-radio).  I am 
> >> wondering if
> >> there are easy ways to mitigate this or are there plans in the future to
> >> diminish these.  For UHD a decimate by 16 process chews up 75% of a CPU 
> >> just on
> >> the uhd::device::recv functiion (not much less even when I use
> >> RECV_MODE_FULL_BUFF and size the buffer to be 100x the size of a single
> >> packet).  For gnuradio's  the CPU utilization is more like 36% - still a 
> >> lot.
> >> 
> >>   I may try to recode some of the lower-level interfaces in UHD if there 
> >> is not
> >> an easy way to help improve CPU utilization.
> >> 
> >>   Thanks for your help,
> >> David

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

Re: [Discuss-gnuradio] gcc 4.5 and GNU Radio 3.3.0

[Eric Blossom]

On Thu, Nov 04, 2010 at 10:17:04AM -0700, Steve Mcmahon wrote:
> It took me a while to get some time to go back to my openSUSE 11.3 machine 
> and regenerate the error message. Sorry, I should have done this when I made 
> the initial post.
> 
> So I successfully installed the following from source under openSUSE 11.3:
> 
> Cheetah-2.4.2.1.tar.gz
> Markdown-2.0.3.tar.gz
> cppunit-1.12.1.tar.gz
> fftw-3.2.2.tar.gz
> gsl-1.14.tar.gz
> numpy-1.4.1.tar.gz
> sdcc-2.9.0-i386-unknown-linux2.5.tar.bz2
> swig-1.3.40.tar.gz
> 
> Then I do a "./configure" for GNU Radio 3.3.0, and it runs fine, and it 
> reports it's going to build everything that I need/that it should. 
> 
> However, when I do a "make", it runs for a while, but then I get these errors:

There's a much easier way to get where you're headed.

Use the "master" branch in git.  I'm pretty sure it has this problem fixed.

  http://www.gnuradio.org/redmine/wiki/gnuradio/Download

Eric

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

Re: [Discuss-gnuradio] Re: ATSC decoding - Now Working!

[Eric Blossom]

On Thu, Nov 04, 2010 at 12:30:51AM -0400, Achilleas Anastasopoulos wrote:
> Nick and others,
> 
> I have decoded a capture of ATSC that Nick provided (many thanks).
> Here are some numbers for double-checking:

> 3) the output of the field_sync_demux (pipe_5) is ~455MB which i don't
> know what it corresponds to
> since i do not know the  "atsc_soft_data_segment" data structure
> details (btw, where is it defined?)

It's in atsc_types.h

> At this point i don't know if i am getting what i am supposed to get.
> For one thing, the equalizer output (stream 0) does not look like a
> nice 8-PAM signal
> Also, i don't know how to view the mpeg stream; VLC does not like it...

I haven't tried in a long time, but I used to use xine to play the
mpeg transport stream.  It could be that VLC is just missing a plugin
for it.  I'm guessing that mplayer will play it too.

Eric

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

Re: [Discuss-gnuradio] howto module ... please help

[Eric Blossom]

On Mon, Nov 01, 2010 at 03:29:25PM -0700, Michael Civ wrote:
> Hello, I posted this a week ago and received no response. Any comments or 
> suggestions would be greatly appreciate.
> 
> I recently got python programs to successfully import the howto 
> module, but I cannot use the functions:
> 

Michael,

I just built gnuradio and howto from the git master (Fedora 13 on x86-64).
It doesn't SEGFAULT for me leading me to think that you have a hosed-
up GNU Radio installation on your system.  Is there any chance that
you've got more than one installation?  Perhaps one from a .deb or
.rpm and one from source?  If so, uninstall the packaged one.

Also, what you really want is something like the code below.
Otherwise the dst.data() is always empty, since the graph hasn't run
when you first print it out.

Eric

$ cd gnuradio
$ ./bootstrap && ./configure --disable-docs
$ (make -j12 && make check && make install) 2>&1 | tee make.log
$ cd gr-howto-write-a-block/
$ ./bootstrap 
$ ./configure
$ make && make check && make install



#!/usr/bin/env python

from gnuradio import gr
import howto

class my_top_block(gr.top_block):
  def __init__(self):
gr.top_block.__init__(self)

src_nums = (4, 5, 6)
src = gr.vector_source_f (src_nums)
sqr = howto.square_ff ()
dst = gr.vector_sink_f ()
self.dst = dst
self.connect (src, sqr)
self.connect (sqr, dst)
print "src: ", src
print "sqr: ", sqr
print "dst.data: ", dst.data()

if __name__ == '__main__':
tb = my_top_block()
tb.run()
print "dst.data: ", tb.dst.data()


$ /tmp/test.py
src:  
sqr:  
dst.data:  ()
dst.data:  (16.0, 25.0, 36.0)

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

Re: [Discuss-gnuradio] RF Gain and BB gain of XCVR2450

[Eric Blossom]

On Mon, Nov 01, 2010 at 05:36:35PM +0100, Jorge Miguel wrote:
> Hello,
> 
> I will rephrase former question.

Jorge, I don't know the answer to your question, but I do that the
answer is in the source code that is associated with the XCVR2450.

You haven't specified whether you're using the UHD or not and whether
or not you're on a USRP1 or USRP2, all of which may matter.

In any event, I'd look for files that contain "2450" in their name :-)

"find" and "grep" are powerful command line tools for this kind of
stuff, and would allow you to answer your own question quickly, or to
at least generate a more refined question, that indicated that you'd
"tried the obvious".

To increase your chances of getting assistance on this list (or any
list for that matter), please read and follow the suggestions here:

  http://www.gnuradio.org/redmine/wiki/gnuradio/ReportingErrors

Eric



> When using the XCVR2450, up to 92dB gain in rx mode is allowed.
> However this gain is shared between to places. Gain at RF and then gain at
> baseband (after the mixing)
> 
> It is very important (from the point of view of the Noise Figure) how gain
> is shared.
> There is a register B7 to B1 which control the gain to the MAX2829 chip
> placed inside the XCVR2450.
> The first 2 bits are critical since they define 3 states: High gain (11),
> Medium gain(10) and Low gain (0X)
> 
> I would like to know how the overal gain configunation setting (0-92 dB) is
> shared between theses two places and what the limits to be in high, medium
> and low gain state are.
> Where I can find it?
> 
> Many thanks,
> Jorge
> 
> 
> I would like to know how the gain setting (up to 92 dB in Rx mode) of the
> MAXIM2829 is sorted between the two amplifiers placed around the mixer.
> 
> I is clear in the data sheet what the total gain is depending on the gain
> settings but it is not clear where the gain is. Most of them can be before
> the mixer (RF gain), or after the mixing (BB gain)..Is it possible to
> find it out? I would like to model this receiver.
> 
> Many thanks,
> Jorge.

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

Re: [Discuss-gnuradio] Does anybody have sucessfully installed GNU Radio on Windows

[Eric Blossom]

On Fri, Oct 29, 2010 at 01:54:19PM -0700, Matt Dunstan wrote:
> Hi,
> 
>     OK, I really don't know what to do with that GNU Radio. I tried to 
> install 
> it many times with CygWin and MinGW but no success, this is why I have this 
> question: does anybody have sucessfully installed GNU Radio on Windows OS (on 
> the site of Ettus Research it's written: it works under Win 7, XP ...)? or 
> maybe 
> everybody is working under Linux and I shouldn't try to install GNU Radio on 
> Windows because I waste my time as I did in the last 3 month. One may ask why 
> Windows and not Linux: because this is the OS I'm used to and I found it very 
> easy to make any kind of software for my projects. Thank you very much for 
> any 
> answer. Maybe after 3 month finally I will be able to see a signal on my 
> screen, 
> that would be one of the biggest miracles in the world. If it will not start 
> than I will throw it away and find other hardware that is more Windows 
> friendly 
> (DLL drivers and others) and that will help me to make some real world 
> applications because I don't want to use it only to see some signals I want 
> to 
> get and send real data (data packages).
> 
> Best Regards,
> Matt Dunstan.

Hi Matt,

This is a follow up to Nick's answer.

GNU Radio, like most free software projects, is supported by volunteer
efforts.  It is the case that most active developers here tend to
favor the *nix platforms, for reasons quite similar to yours, plus a
lot having to do with freedom.  But that's a different conversation.

That said, we do try to avoid doing anything that would make GNU Radio
NOT work on any platform, including the variety of Microsoft OS's.  We
have users running under Linux (or course), but also OS/X and BSD too.
We also have active users running on x86, x86-64, PPC (32 and 64-bit)
and ARM, so the system as a whole has proven to be quite portable.

If you are interested in better support under Windows, then you, or
perhaps somebody you know, are probably in the best position to make
that happen.  We would be delighted to have good, solid support for
Windows, but that's going to take some effort from somebody.  There
are many experts on this list who are masters in multiple domains.  
At least some of them have deep knowledge of the guts of GNU Radio and
have substantial experience with portability concerns surrounding big,
complex s/w systems.  If you ask good questions, there's a pretty good
chance that these folks will step up to answer your questions.

If you're interested in helping with windows issues, we'd love to have
your assistance.  This is all about growing a bigger pile of high
quality free software.

Finally, we've found that the suggestions mentioned in the link below
have worked well at soliciting quality responses on this mailing list.

  http://gnuradio.org/redmine/wiki/1/ReportingErrors

Thanks for writing.  Sorry to hear about your pain.
We'd love to have better support on windows.  Perhaps you could help?

Eric

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

Re: [Discuss-gnuradio] understanding MUX registers

[Eric Blossom]

On Fri, Oct 29, 2010 at 10:22:27AM -0700, Sarah Boutwell wrote:
> Hi all.
> 
> I'm working on using GNU radio to receive and process GSM signals.  In
> looking at the usrp_rx_cfile.py program, it appears that the DDC's MUX value
> is set automatically by probing the USRP.  In our case it sets the MUX value
> to 0x1.  We think that means that the ADC1 input is wired to the signal I
> value on DDC0 and the ADC0 is wired to the signal Q value on DDC0.  Is this
> correct?
> 

Yes, it is.


> Thanks,
> 
> Sarah
> 
> LT Sarah Boutwell, USN
> NPS Student, Computer Science
> NIPR:    srbou...@nps.edu

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

Re: [Discuss-gnuradio] FM-Preemph block does nothing..

[Eric Blossom]

On Thu, Oct 28, 2010 at 06:13:12PM +0200, Jasper Kanbier wrote:
> The FM-Demphasis block seems to work, but FM Preemphasis does  nothing to
> the frequency response..looks broken to me..
> 

OK.  Please fix.

Eric

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

Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze

[Eric Blossom]

On Tue, Oct 26, 2010 at 11:50:34PM -0400, Arun Pillai wrote:
> I get exactly what you get.
> 
> $ file /opt/microblaze/bin/mb-gcc
> /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386,
> version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, not stripped
> 
> Arun

I think you're missing an i386 compatibility library.
Sorry, I'm not sure what it's called under Ubuntu.

Eric



> On 10/26/2010 11:45 PM, Eric Blossom wrote:
> >On Tue, Oct 26, 2010 at 10:48:23PM -0400, Arun Pillai wrote:
> >>Eric,
> >>
> >>The output of ldd is below:
> >>
> >>$ ldd /opt/microblaze/bin/mb-gcc
> >> not a dynamic executable
> >
> >
> >What does
> >
> >   $ file /opt/microblaze/bin/mb-gcc
> >
> >Give?
> >
> >I get:
> >
> >   $ file /opt/microblaze/bin/mb-gcc
> >   /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, 
> > version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 
> > 2.6.9, not stripped
> >
> >
> >
> >If that doesn't work, please try building the one from git.xilinx.com.
> >With luck, it might even build out of the box.  (Why Xilinx hasn't
> >gotten the microblaze stuff accepted into the gcc main line is beyond me...)
> >
> >Eric
> 

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

Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze

[Eric Blossom]

On Tue, Oct 26, 2010 at 10:48:23PM -0400, Arun Pillai wrote:
> Eric,
> 
> The output of ldd is below:
> 
> $ ldd /opt/microblaze/bin/mb-gcc
> not a dynamic executable


What does

  $ file /opt/microblaze/bin/mb-gcc

Give?

I get:

  $ file /opt/microblaze/bin/mb-gcc
  /opt/microblaze/bin/mb-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped



If that doesn't work, please try building the one from git.xilinx.com.
With luck, it might even build out of the box.  (Why Xilinx hasn't
gotten the microblaze stuff accepted into the gcc main line is beyond me...)

Eric

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

Re: [Discuss-gnuradio] Re: unable to compile firmware with microblaze

[Eric Blossom]

On Tue, Oct 26, 2010 at 10:04:10PM -0400, Arun Pillai wrote:
> I am also trying to build the microblaze compiler from scratch but I
> am unable to get the patch from svn.
> 
> $ svn export 
> http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch
> 
> svn: OPTIONS of 
> 'http://gnuradio.org/svn/gnuradio/trunk/dtools/microblaze/mb-gcc-4.1.1-gr-1.patch':
> 200 OK (http://gnuradio.org)
> 
> Where can I get this patch?
> 
> Arun

Arun,

The microblaze compiler has been quite an annoyance.

Although I haven't tried it yet, you may want to try the mb_gnu.git
project at http://git.xilinx.com

But see also below...


> On 10/26/2010 08:04 PM, Arun Pillai wrote:
> >I am running Ubuntu 10.10 2.6.35-22-generic with x86_64. I tried the
> >prebuilt binary as per instructions here:
> >http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ
> >
> >Specifically, I did the following:
> >
> >
> >$ wget http://gnuradio.org/tools/mb-gcc-4.1.1.gr2.i386.tar.gz
> >
> >Once you've downloaded the tarball,
> >
> >$ sudo bash
> ># cd /opt
> ># tar xzvf 
> >
> >Then add /opt/microblaze/bin to PATH ( export
> >PATH=$PATH:/opt/microblaze/bin )
> >==
> >
> >However, when I run configure.gnu in the firmware directory, I get the
> >following error in config.log:
> >
> >configure:3134: error: in `/home/rahul/vmimo/code/gnuradio/usrp2/firmware':
> >configure:3137: error: C compiler cannot create executables
> >
> >When I also explicitly run:
> >
> >mb-gcc with our without explicit path qualifier of /opt/microblaze/bin/,
> >I get the following error:
> >
> >$ /opt/microblaze/bin% ./mb-gcc
> >zsh: no such file or directory: ./mb-gcc
> >
> >This despite the file existing:
> >
> >$ /opt/microblaze/bin% ls -l mb-gcc
> >-rwxr-xr-x 1 500 500 192961 2008-10-13 19:47 mb-gcc*
> >
> >Any ideas?

If you run 

  $ ldd /opt/microblaze/bin/mb-gcc

Are all of the shared libraries found?

It's a 32-bit app.  Depending on your OS and machine, you may need to
install 32-bit versions of the required libraries.

Eric

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

Re: [Discuss-gnuradio] GR Block Input Item Size

[Eric Blossom]

On Mon, Oct 25, 2010 at 12:36:13PM -0700, Andrew Fong wrote:
> Hi,
> 
> I want to create a block that requires 1 input items and
> produces 1 output items on a single stream.  However, I'm
> getting the following message: sched:  is
> requesting more input data
>   than we can provide.
>   ninput_items_required = 1
>   max_possible_items_available = 8191
>   If this is a filter, consider reducing the number of taps.
> 
> How do I get the block to operate as I want?  I thought inheriting
> from gr_sync_block with 1:1 input/output rate would work, but it
> doesn't seems to be the case.
> 
> Andrew

If you require 10,000 input items at a time, you must
call set_output_multiple(1) in your constructor.

Eric

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

Re: [Discuss-gnuradio] remark on custom block + python behavior on Beagleboard

[Eric Blossom]

On Mon, Oct 25, 2010 at 11:38:00AM -0400, Almohanad Fayez wrote:

> Hi, sent an email a while back about what I thought was a scheduler
> issue with gnuradio on the beagleboard.  Basically I've been writing
> custom GNU Radio block for the OMAP's DSP and running them on the
> beagleboard.  On occassions when I'm running multiple blocks, GNU
> Radio would parse my flowgraph but then get lost and never starts
> the flowgraph.  I've always thought it was an issue with my code but
> it turned out to be a python issue and I'm not sure if it's specific
> to my platform or python in general.  python basically generates
> optimizied pre-interpred python files *.pyo and *.pyc. and as it
> happens, some of these files are not refreshed when I make changes
> to my python source file I managed to debug the issue where at the
> point where gnuradio calls the c++ file that handles the swig call
> handling "gnuradio_swig_py_runtime.cc".  This file is able to detect
> the python block so the "custom_blocks.cc" file generated by the
> howto-write-a-custom-block auto tools.  then there is a call placed
> to the constructor "gr_basic_block.cc" and that's where gnuradio
> gets lost into oblivion.

> I was able to finally fix this problem by writing a script that
> deletes all of the pyc and pyo files associated with my library and
> flowgraph.  my question is, is this a know python issue, an issue
> with the custom gnuradio block, or an issue with the platform?  I
> managed to recreate this problem using the custom block 3.2.1 and
> 3.2.2 templates and I was also able to recreate it by using the
> original how to square a number example.

> thanks.
> 
> al 

Is there any chance that sometime you run the code as root, and
sometimes as a non-root user?  If so, depending on the details of your
installation, you may have a situation where the non-root user cannot
remove the old and out of date *.pyo and *.pyc files.

I've never seen the problem you describe, thus I suspect that it
may have to do with permissions on the files and/or directories
involved.

Eric

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

Re: [Discuss-gnuradio] RAM consumption

[Eric Blossom]

On Sun, Oct 24, 2010 at 02:28:04PM -0700, David Knox wrote:
> 
> 
> Eric Blossom wrote:
> > 
> > 99% of the base code distributed with GNU Radio (runtime + blocks)
> > allocates NO MEMORY once the flow graph has started (see below for
> > exceptions).
> > 
> > DO NOT use a vector_sink for anything other than QA code that
> > produces a small amount of output.  The vector_sink will allocate an
> > unbounded amount of memory if you keep writing to it.
> > 
> > It is also possible to consume memory by sending an unbounded number
> > of messages into a message queue (gr.msg_queue) that doesn't have a
> > queue size limit and has a slow (or compute bound) reader.
> > 
> > If there's a GUI of any kind involved, or python code that's being
> > executed beyond initialization time, look there for problems.
> > 
> > Eric
> > 
> 
> Thanks for such a quick response.  I am modifying C++ code, rather than
> Python code.  There is no GUI (just an XTERM accessed via std::cout
> statements).  I am using std::queue data structures and the push and pop to
> these queues occurs in the same routine (see below).  

Is there only a single thread that manipulates the queue, or is one
for example inside of a GNU Radio block, and one is outside of the
block?

> I think that your vector sink comments refer to the Python construct, don't
> they?  What is the C++ equivalent of your 'DO NOT DO THIS'
> statement?

They map 1:1 from Python to C++:  

  gr.msg_queue -> gr_msg_queue
  gr.vector_sink_* -> gr_vector_sink_*

> Does this mean I have to access the queue in a critical section or using 
> explicit
> thread-safe methods?

As in any multithreaded programming, if there is more than one thread
involved, and you are accessing a shared data structure from more than
one thread, and somebody else isn't already handling the critical
section for you, you WILL have to implement a critical section.

STL containers are not inherently thread-safe.

> My output seems to be sequenced just fine and there
> are no duplicates or the like.

> My C++ implementation is:
> .
> if ( (int)queue.size() >= MAX) { queue.pop() } 
> queue.push(value)  
> .
> It is possible that the CPU is not able to keep up with the emptying task,
> but then I'd expect the queue size to be growing beyond MAX and it isn't...
> based on std::cout output anyway.  I suppose that this output could be also
> lagging further and further behind, but the output all appears to complete
> properly as each of my relatively rare test events occur (~1 second apart).
> 
> Is there something specific that I must do inside the C++ code to avoid
> GnuRadio run-time memory allocation issues?

No.

> I have not specifically added
> any new malloc/dalloc/calloc statements to the existing code myself.  Could
> declaring data structures (e.g. scalars, arrays, std::queue) inside or
> external to subroutines have this kind of side effect?

Of course they could.  If you're using some kind of container, you
need to know what it's worst case running time and memory usage is.

> Would I be better
> off implementing the queue using an array/circular buffer or std::vector of
> my own, rather than using the one from the std:: library?  

It all depends.

Have you written a new C++ block for GNU Radio?
If so, have you written any QA code for it?

If you've written a block, and you replace the guts of your work or
general_work method with:

  return noutput_items; // turn block into a NOP

does the memory increase stop?

If you haven't written a new block, how are you getting access to the
samples?  

> My overall objective is that I want to be able to capture and print off
> samples from the ADC on a specific trigger characteristic of the sample
> values (e.g. magnitude).  So, I need to remember (either print out to the
> XTERM or store to a file) small subsets of contiguous ADC samples that
> occurred just prior to my trigger condition.  Once they are printed, I want
> to 'forget' them entirely and start looking for my trigger again.  In my
> testing, this amounts to printing about 50 lines every second or so, but I
> am consuming RAM at a steady rate of about 3 MB/s.

Seems simple enough.  Instead of us trying to guess what you're actually
doing, can you post a link to the code including an example that
exercises it? 

> / David Knox

Eric

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

Re: [Discuss-gnuradio] RAM consumption

[Eric Blossom]

On Sun, Oct 24, 2010 at 09:19:25AM -0700, David Knox wrote:
> 
> I am running some Zigbee code from UCLA with some modifications of my own...
> When I run the (modified) code, RAM is slowly (but surely) consumed with
> high CPU usage.  After about half an hour, the CPU/RAM monitor shows 100%
> RAM usage and then operation stalls and CPU usage drops down once again to
> quiescent levels, with RAM remaining tied up until the program is ended
> (ctrl-C).  Until the stall, program operation appears to be correct.
> 
> I have reviewed the code by hand for memory leaks and also used some of the
> tools available for detecting memory leaks without any results.  Has anyone
> else had similar problems and, if so, how did they debug them?  Is this kind
> of inexorable creep of system memory usage symptomatic of anything else? 
> Within GnuRadio, is there any method for quickly determining how program
> memory (heap space) or data memory is being consumed?

99% of the base code distributed with GNU Radio (runtime + blocks)
allocates NO MEMORY once the flow graph has started (see below for
exceptions).

DO NOT use a vector_sink for anything other than QA code that
produces a small amount of output.  The vector_sink will allocate an
unbounded amount of memory if you keep writing to it.

It is also possible to consume memory by sending an unbounded number
of messages into a message queue (gr.msg_queue) that doesn't have a
queue size limit and has a slow (or compute bound) reader.

If there's a GUI of any kind involved, or python code that's being
executed beyond initialization time, look there for problems.

Eric

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

Re: [Discuss-gnuradio] Gnuradio Mode S project released

[Eric Blossom]

On Sat, Oct 23, 2010 at 06:52:34PM -0700, Nick Foster wrote:
> Hi all,
> 
> I finally got around to cleaning up my Mode S receiver enough for public
> release. The following is a short description of the software:

Cool stuff!

Thanks!
Eric

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

Re: [Discuss-gnuradio] help to compile gnuradio

[Eric Blossom]

On Sat, Oct 23, 2010 at 01:43:11PM -0700, Thomas Spuhler wrote:
> How can I get help to build/package Gnuradio. the USRP2 component doesn't 
> build anymore with newest gcc
> 
> http://pastebin.mandriva.com/21049
> 

I'm pretty sure this is fixed on master:

  http://gnuradio.org/redmine/wiki/gnuradio/Download

Eric

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

Re: [Discuss-gnuradio] Questions on multiple outputs and produce()

[Eric Blossom]

On Thu, Oct 21, 2010 at 05:06:26PM +0200, Martin Braun wrote:
> Hi list,

Hi Martin!

> Since the API for gr_blocks with multiple outputs was changed a bit with
> version 3.3.0, I have a couple of questions.
> 
> 1) The return value for general_work() is no longer relevant for the
> number of produced output items. 

It's still relevant, unless it has the value WORK_CALLED_PRODUCE

(I just noticed that the docs for general_work were not updated to
reflect this change.  Sorry about that.)

> Does this eliminate the need to produce all output values at the same rate?

Yes.  That was the reason for the change.

> 2) If I still want to (or have to) produce all output items at the same
> rate, wouldn't it be great to have a produce_all() member function,
> analogous to consume_all()? Is it just waiting to be patched in, or if
> not, what's the rationale for not including it?

To preserve the original behavior, non-negative values of the return
value are treated as they were before, in effect calling produce_all.

> 3) If it's possible to produce output at different rates, how does
> forecast() work? IIUC, forecast() returns the number of input items on
> every input stream to produce noutput_items output items. But for which
> output stream is this valid?
> On a similar note, what meaning does noutput_items in general_work() have?

None of the behavior (or implementation) of those routines has
changed.  Thus, for any given value of noutput_items, there is
guaranteed to be enough output buffer space on each output stream to
hold noutput_items.

Probably the easiest way to think about this, is that it allows you to
return fewer results on one or more output streams than the number
returned on the stream returning the maximum number of output streams.

Eric

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

Re: [Discuss-gnuradio] More on latency

[Eric Blossom]

On Thu, Oct 21, 2010 at 02:23:20AM -0400, Marcus D. Leech wrote:
> On 10/21/2010 02:10 AM, Eric Blossom wrote:
> > On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote:
> >   
> >> I had a flow-graph that earlier today had a latency of roughly 1 second
> >> or so.
> >>
> >> When I tested it this evening, after it had been running for several
> >> hours, the latency was
> >>   back up to *several tens of seconds*!!!.  Which means that external
> >> events at the source take
> >>   several tens of seconds to show up at the sinks -- two graphical, and
> >> one filesink.  WTF? !!
> >>
> >> The CPU load at the time was modest -- about 38%
> >> 
> > 38% of what?  How many cores?  What kind of machine?
> >   
> A dual-core machine, an Atom D-510
> > It's possible that there's a computation in a single block that
> > requires > 1 core to compute in realtime.
> >   
> Unlikely.  The most "computey" block is a 1024-bin FFT, and my sample
> rate is only 400Ksps.
>   There's also an FFT filter, but it typically has only about 40-45 taps.
> 
> 
> > Have you tried oprofile to see where the graph is spending its time?
> > Are you i/o bound?  What's the rate that you're writing to the file sink?
> >   
> I'm writing to the file sink at 1Ksps.
> 
> There's also an audio sink, I'm using the "plughw:0,0" device, and it's
> being pumped at
>   20Ksps, which generally divides my source rate exactly.  I tried
> turning off that sub-tree
>   the other night, but I didn't let it run very long.  Perhaps a
> residual clock-rate mis-match
>   is causing 'buffer creep', and after a few hours, that 'buffer creep'
> has grown to several-10s
>   of seconds?

Yes, that would cause it.  I've seen it with the FM receiver apps.

BTW, it would have been useful to tell us that there was an audio sink
in the graph when you first posted the observation.

Thanks,
Eric

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

Re: [Discuss-gnuradio] More on latency

[Eric Blossom]

On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote:
> I had a flow-graph that earlier today had a latency of roughly 1 second
> or so.
> 
> When I tested it this evening, after it had been running for several
> hours, the latency was
>   back up to *several tens of seconds*!!!.  Which means that external
> events at the source take
>   several tens of seconds to show up at the sinks -- two graphical, and
> one filesink.  WTF? !!
> 
> The CPU load at the time was modest -- about 38%

38% of what?  How many cores?  What kind of machine?

It's possible that there's a computation in a single block that
requires > 1 core to compute in realtime.

Have you tried oprofile to see where the graph is spending its time?
Are you i/o bound?  What's the rate that you're writing to the file sink?

I believe htop will show you all the threads of the process.  Are any
of them consuming on the order of 100% of a single core?

Eric

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

Re: [Discuss-gnuradio] Error when installing Boost

[Eric Blossom]

On Wed, Oct 20, 2010 at 04:47:47PM -0700, ish13 wrote:
> 
> I get an error with I use ./configure when I am installing boost.  The
> following commands are entered in the terminal when I am installing.

Why are you building boost?  It's packaged for pretty much every
reasonably modern distribution.

> cd boost_1_44_0
> BOOST_PREFIX=/opt/boost_1_44_0
> ./tools/jam/src/boehm_gc/configure --prefix=$BOOST_PREFIX
> --with-libraries=thread,date_time,program_options
> 
> confchecking if f77 PIC flag -fPIC works... yes
> checking if f77 static flag -static works... yes
> checking if f77 supports -c -o file.o... yes
> checking whether the f77 linker (/usr/bin/ld) supports shared libraries...
> yes
> checking dynamic linker characteristics... /usr/bin/f77: Illegal option:
> -print-search-dirs
> GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking sys/dg_sys_info.h usability... no
> checking sys/dg_sys_info.h presence... no
> checking for sys/dg_sys_info.h... no
> checking whether Solaris gcc optimization fix is necessary... no
> checking atomic_ops.h usability... no
> checking atomic_ops.h presence... no
> checking for atomic_ops.h... no
> configure: error: Missig libatomic_ops.
> 
> Can someone help?
> 
> Thanks
> Ismael

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

Re: [Discuss-gnuradio] Moon Bounce Experiment

[Eric Blossom]

On Wed, Oct 20, 2010 at 06:49:21PM -0600, Joseph Craig wrote:
> Hi Marcus,
> 
> Thanks for the quick reply...
> 
> 
> On Oct 20, 2010, at 5:51 PM, Marcus D. Leech wrote:
> 
> > On 10/20/2010 07:13 PM, Joseph Craig wrote:
> >> I have managed to install gnuradio and run usrp_fft.py with success!
> >> 
> >> Now for the questions...
> >> 
> >> 1)  I'm always seeing...  "Exception RuntimeError: 'maximum recursion 
> >> depth exceeded while calling a Python object' in  >> 'exception.AttributeError'> ignored ".  What does this mean, and how to 
> >> fix it?
> >> 
> > In what application are you seeing this error?
> 
> python

Which version of GNU Radio are you using?

  tarball?  If so, which one?
  git?  If so, which branch?

Eric

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

Re: [Discuss-gnuradio] shmat issue

[Eric Blossom]

On Wed, Oct 20, 2010 at 02:30:12PM -0400, Philip Balister wrote:
> On 10/20/2010 01:49 PM, Eric Blossom wrote:
> >On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote:
> >>On 10/19/2010 10:51 PM, Eric Blossom wrote:
> >>OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 *
> >>PAGE_SIZE. Need to puzzle through this a little more. This is the
> >>failing check in the kernel.
> >
> >OK.  What's PAGE_SIZE on arm?
> 
> PAGE_SIZE is still 4096, there is an additional restriction on the
> address passed to shmat().
> 
> >
> >I wonder how we can determine the actual value of SHMLBA at runtime?
> >We currently use the result of gr_pagesize() as the required alignment value.
> 
> It looks to me like the there are several shm sections created, with
> varying access rights. Then shmat is used to reserve a chunk of
> memory. Then the sections created first are attached to with
> addresses based on the result of the shmat used to get the address
> space.
> 
> The weird thing on arm, the shmat returns a page aligned section,
> but if you pass that address back to shmat it fails, because that
> address needs to be aligned to SHMLBA (found in
> arch/arm|x86/include/asm/shmparam.h.
> 
> What does it mean?
> 
> Well gnuradio falls back to a mmap approach to get the circular
> buffer. It is a bigger problem for kalibrate, which just fails.
> 
> I'm not sure who is to blame :) Is there another way to get reserve
> the memory on you process to use when you attach the shared memory
> segments?

Philip,

If you run "make check", it will probe for an implementation that
works.  Under *unix variants, there are three different
implementations that are tried: 

  gr_vmcircbuf_sysv_shm.cc
  gr_vmcircbuf_mmap_shm_open.cc
  gr_vmcircbuf_mmap_tmpfile.cc

Under windows, it uses

  gr_vmcircbuf_createfilemapping.cc


Since you're probably not going to get make check working in our
lifetimes, try this:

  $ echo -n  "gr_vmcircbuf_mmap_shm_open_factory"   > 
~/.gnuradio/prefs/gr_vmcircbuf_default_factory

Or this:

  $ echo -n  "gr_vmcircbuf_mmap_tmpfile_factory"   > 
~/.gnuradio/prefs/gr_vmcircbuf_default_factory


Even if they both work, they may have different runtime performance. YMMV...

Eric

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

Re: [Discuss-gnuradio] shmat issue

[Eric Blossom]

On Wed, Oct 20, 2010 at 01:02:15PM -0400, Philip Balister wrote:
> On 10/19/2010 10:51 PM, Eric Blossom wrote:
> >
> >>In both cases I can hear the dial tone fine. I'm curious why I get
> >>the shmat error the first time only.
> >
> >You should see it only once ever, if the program can write to
> >~/.gnuradio/prefs.  Generally this gets written during "make check".
> >
> >Does "make check" work?
> 
> Insert whining about make check for the cross compiled case :)
> 
> >Why are you running as root?
> 
> I am lazy :)

And foolish :)

> >>It looks like gnuradio falls
> >>back to another method of creating the shared segment.
> >
> >Yes it does.
> >
> >>I'd like to resolve the shmat issue though,
> >
> >Set a breakpoint with gdb, or add printfs.
> 
> OK, it looks like x86 sets SHMLBA to PAGE_SIZE and arm uses 4 *
> PAGE_SIZE. Need to puzzle through this a little more. This is the
> failing check in the kernel.

OK.  What's PAGE_SIZE on arm?

I wonder how we can determine the actual value of SHMLBA at runtime?
We currently use the result of gr_pagesize() as the required alignment value.

Eric

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

Re: [Discuss-gnuradio] shmat issue

[Eric Blossom]

On Tue, Oct 19, 2010 at 08:34:40PM -0400, Philip Balister wrote:
> I'm seeing this issue on my omap3 install with the dialtone flowgraph:
> 
> # python /usr/share/gnuradio/examples/audio/dial_tone.py
> 
> 
> gr_vmcircbuf_createfilemapping: createfilemapping is not available
> 
> gr_vmcircbuf_sysv_shm: shmat (3): Invalid argument
> 
> l# python /usr/share/gnuradio/examples/audio/dial_tone.py

>From $ man shmat

  EINVAL Invalid shmid value, unaligned (i.e., not page-aligned and SHM_RND  
was  not  speci-
 fied) or invalid shmaddr value, or can’t attach segment at shmaddr, or 
SHM_REMAP was
 specified and shmaddr was NULL.



> In both cases I can hear the dial tone fine. I'm curious why I get
> the shmat error the first time only.

You should see it only once ever, if the program can write to
~/.gnuradio/prefs.  Generally this gets written during "make check".

Does "make check" work?

Why are you running as root?

> It looks like gnuradio falls
> back to another method of creating the shared segment.  

Yes it does.

> I'd like to resolve the shmat issue though,

Set a breakpoint with gdb, or add printfs.

> because I am also trying to run the kalibrate program and have the
> same shmat issue there, but it does not have a fall back method.

Eric

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

Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy

[Eric Blossom]

On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote:
> I've noticed latency issues with one of the applications I'm working on.
> Latencies of up to tens of seconds
>   have been observed, which I tried to combat by specifying
> recv_buff_size in the parameter list.
> 
> Right now, I'm running with 4096 bytes, which at 400Ksps, gives me a
> roughly 1 second latency between
>   input and output (where output is both an audio sink, and a couple of
> different file sinks as well as a
>   scopesink2, and an FFT sink).  But increasing it beyond 4096 bytes
> causes the latency to go up very
>   quickly, and if I drop it to 1024 bytes, I start seeing over-runs.  If
> you do the math, however, 4096 bytes is
>   nowhere near 1 second worth of buffer.  One second is 1.6Mbytes
> (400Ksps x 4bytes per sample).

Since you've got a usrp* source and an audio_sink, what you're seeing
could be related to the two different clocks in the flow graph.  Do
you see the problem if the audio_sink is NOT in the graph?

Eric

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

[Discuss-gnuradio] 27C3-tickets available through pre-sale only

[Eric Blossom]

FYI,

Always a good time, the Chaos Communication Congress 27C3 will be held
from Monday December 27 to Thursday December 30, 2010 in Berlin,
Germany.

Eric
--- Begin Message ---
For those who haven't noticed yet but want to attend the CCC-congress 27C3 in 
december: tickets are pre-sale only this year due to the demand exceeding 
building capacity. Please also let other people know who you think may want to 
attend that they need to buy their tickets in advance. The process works as 
follows:

1. you go to https://presale.events.ccc.de/ and register a ticket account (at 
least 24 hours before the next batch is release)
2. tickets are sold in batches, next batch up 11th of November (announcement 
among other channels at Twitter @27c3)
3. with an account, you can order up to two tickets, the moment a batch is 
released (usually they are gone within a couple of hours)
4. pay tickets
5. enjoy the best hacker conference in Europe

For more details see: 
http://events.ccc.de/2010/10/10/how-to-survive-the-pre-sale-2/

There might be day-tickets available at the counter, but I really would not 
rely on that.

Thanks & Greetings from Berlin,

Frank

PS: for questions etc., please use the e-mail adresses provided at the 
events.ccc.de website, I am only the messenger here.
-
To unsubscribe, e-mail: main-unsubscr...@lists.airprobe.org
For additional commands, e-mail: main-h...@lists.airprobe.org

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

Re: [Discuss-gnuradio] Peak Hold in FFT display causing UI problems

[Eric Blossom]

On Tue, Oct 12, 2010 at 04:31:38PM -0400, Marcus D. Leech wrote:
> I have an Atom D-510 running Fedora 12, and the latest UHD+GnuRadio (as
> of this morning).
> 
> I've noticed that if I turn on "Peak Hold" in the FFT display, the
> entire input side of the GUI becomes
>   unresponsive to input, even for low input bandwidths, where the CPU
> usage is quite low.
> 
> Anyone else seen this?

Yes, I've seen this.

Eric

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

Re: [Discuss-gnuradio] RX Mux value with dissimilar d'cards, USRP1

[Eric Blossom]

On Tue, Oct 12, 2010 at 10:16:31AM -0400, Steven Clark wrote:
> Hi-
> 
> Is it possible to receive simultaneously from 1 WBX card, and 1 BasicRX
> card, on the same USRP1? Attempting this with GRC gives:
> "Cannot compute dual mux when mixing quadrature and non-quadrature
> subdevices"
> 
> I understand that the WBX is quadrature while the BasicRX is not, so this
> should require 3 of the 4 ADCs.
> 
> The WBX is in side A, the BasicRX is in side B, RXA slot.
> 
> ADC0 gets WBX I.
> ADC1 gets WBX Q.
> ADC2 gets BasicRX.
> ADC3 is ignored.
> 
> An RX Mux value of 0xF210F210 should accomplish what I want, but I see this
> note: "All Q's must be 0xf or none of them may be 0xf", which this violates.
> What gives? Where is this constraint coming from?
> 
> -Steven

The constraint comes from the implementation of the rx mux in the
FPGA.  It's configuration register contains a single bit that feeds
zeros to the Q input of all DDCs or not.

Details on the s/w to h/w mapping can be found in usrp_standard.cc
near line 469.

The software presents an interface that is more orthogonal than what
the fpga currently implements.

Eric

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

Re: [Discuss-gnuradio] how to generate a periodic pulse

[Eric Blossom]

On Wed, Oct 06, 2010 at 11:47:27PM -0700, jmiggal wrote:
> 
> Hi all,
> 
> I have the same doubt. I want to generate a pulse (with a duty cycle 
> less than 50%) and I do not know how to do it.
> 
> I saw gr.sig_source_x but this only generate pulses at 50% duty cycle.
> 
> I tried to multiply several squares pulses at different frequencies and 
> it works, I get a pulse of 12.5% duty cycle for example but it is 
> semi-random since all signal generators are not coherent.
> 
> Please Can somebody help me to generate a pulse signal which I can 
> change the pulse width?

  // High 12.5%
  src = gr.vector_source_f((1, 0, 0, 0, 0, 0, 0, 0), True)

  // High 25.0%
  src = gr.vector_source_f((1, 1, 0, 0, 0, 0, 0, 0), True)


Eric

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

Re: [Discuss-gnuradio] Stopping the UHD

[Eric Blossom]

On Mon, Oct 04, 2010 at 01:27:48PM -0400, devin kelly wrote:
> Hello,
> 
> I'm having a problem, where I want to receive data from a specified
> amount of time/samples and then stop.  I'm using a USRP2 with the UHD.
>  So far, everything works fine, except for when I try to stop.  My
> script exits ok, but the usrp2 keeps sending data over the ethernet
> bus.  The 'C' led is remains illuminated as well, indicating that the
> usrp2 is still receiving.
> 
> My code looks like this
> 
> self.ipAddr = '192.168.10.2'
> self.bufSize = '60e6'
> self.u = uhd.single_usrp_source('addr=' + self.ipAddr + ',
> recv_buff_size=' + self.bufSize, uhd.io_type_t.COMPLEX_FLOAT32)
> 
>  ...
> 
> if tb.u.stop() is False:
>print 'tb.u.stop() failed'
> if tb.stop() is False:
>print 'tb.stop() failed'
> sys.exit()
> 
> tb.u.stop() and tb.stop() both return true.  Is there something else I
> need to do stop my usrp2?  So far the only way I've found to stop it
> is to do a hard reset.

Try stopping the flow graph:

  tb.stop();

Eric

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

Re: [Discuss-gnuradio] Optimal way of performing multiple FFTs on a stream of data

[Eric Blossom]

On Wed, Sep 29, 2010 at 01:47:22PM -0700, John Andrews wrote:
> Hi,
> This is more of a programming question than a gnuradio question.
> 
> I am writing a C++ block that takes in a stream of complex data, an N
> element block {B} is chosen from the stream, this block is multiplied with a
> set {M1, M2, M3...Mn} where size of each set element is N (same as data
> block) too. I want to find FFT using FFTW library on each of the products
> {B.M1, B.M2,  B.Mn} in the general_work() function. As this can be an
> intensive task can someone suggest me what could be the optimal strategy to
> do without compromising efficiency and risk losing samples that is entering
> the machine from the USRP. I was thinking about multithreading. Do you think
> this is the way to go?
> 
> Thanks,
> John

I'd measure first, and see if you've really got a problem.
(Premature optimization is the root of all evil.)

Note also that GNU Radio itself is multithreaded, and if you're doing
substantial work in other blocks, your cores may already being put to
productive work.

Make sure that the version of FFTW you're using was built with SSE
support enabled.

  http://fftw.org/fftw3_doc/Installation-on-Unix.html

  ./configure --enable-sse --enable-float

Measure again :-)


If you do have a problem, and your cores are not already 100%
utilized, then you may want to look at using the FFTW's suport for
multithreading (inside of the package).  Note that it will only make
sense if you use one of the advanced interfaces that allows you to ask
it to compute multiple FFT's in one call to the API.  The standard
interface won't help, unless your FFTs are seriously big -- say, > 1M
points.

http://fftw.org/fftw3_doc/Multi_002dthreaded-FFTW.html
http://fftw.org/fftw3_doc/Advanced-Complex-DFTs.html

Eric

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

Re: [Discuss-gnuradio] Same File Size

[Eric Blossom]

On Wed, Sep 29, 2010 at 04:14:18PM -0400, Justin Bracken wrote:
> Hello All,
> 
> I am expecting to see a similiar file size in a simple test file that im
> running and I don't get that. Is there something Im missing?
> 
> USRP2->FileSink
> SignalSource->Throttle->FileSink
> 
> I have checked obvious things. The USRP2 block is set to a decimation of
> 400. Given the 100MS/s rate of the USRP2 I expect the stream to be 250e3
> MS/s. So I set the overall sample rate to 250e3. I have also set the
> datatypes of all the blocks to floats. The Throttle is set to 250e3.
> 
> If it matters the  signal source is set to a saw tooth,1Hz.
> 
> Im more interested in knowing that samples read back out of the files are
> synchronized. So I guess it doesn't matter if they are the same length if
> all this mean is that I need to trim the files to the same length.
> 
> Thanks,
> Justin

If you want a particular number of samples in a file, etc., 
use gr.head.

Generally you SHOULD NOT be using throttle.

throttle causes so much confusion, I'm of the opinion that we should
remove it from the code base.

Eric

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

Re: [Discuss-gnuradio] Debugging environment variables

[Eric Blossom]

On Mon, Sep 27, 2010 at 07:02:34AM -0400, Philip Balister wrote:
> It seems like there are some environment variables you can set to
> make GNU radio print some debug info. Does anyone have a list of
> these?
> 
> Philip

None that I'm aware of :-)

There are some #define's in parts of the runtime code that will
produce debugging output if you enable them.

For looking at scheduler behavior the one you want is at the top of
gr_block_executor.cc.  

  // must be defined to either 0 or 1
  #define ENABLE_LOGGING 0

Eric

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

Re: [Discuss-gnuradio] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.

[Eric Blossom]

On Mon, Sep 27, 2010 at 10:07:07AM +0200, Jorge Miguel wrote:
> Hi all!
> 
> I am Tx/Rx a FM signal at the same time, but I can see a lot of S
> messages that mean my CPU cannot keep up with all frames generated by the
> USRP2 and drop most of them.
> However I have a quite new laptop with a CPU:Intel(R) Core(TM) i5 CPU
> M 520  @ 2.40GHz  on Ubuntu 10.4
> 
> I guess that my laptop is enough to run my FM Tx/Rx and I wonder if I can
> balance the workload among all my four cores to see if my application
> improves (ethernet interface doens't drop any frame).
> 

First off, you don't really have 4 cores.  You've got 2 cores +
hyperthreading (they may have renamed it, but that's what you've got).

GNU Radio will automatically use whatever you've got, without you
having to do anything special.

Be sure that your laptop is in "Performance mode", and not trying to
save energy, or throttle back etc.  There are also some laptops out
there that have poor thermal design and can't really run at full speed
without overheating and thus throttling back the CPU.

Start with something like usrp_fft.py and see how low of a decimation
factor you can work with reliably.  That will give you a basic idea of
how your system is working.

If you're building your own flow graphs, it's quite easy to string
together more blocks, or use a a higher sample rate, than your machine
can keep up with.

After you've ruled out the stuff above, oprofile will help you sort
out which parts of your application are burning the most time.

Eric

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

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

[Eric Blossom]

On Sun, Sep 26, 2010 at 09:40:58AM -0400, Tom Rondeau wrote:
> On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum  wrote:
> >
> >>
> >> I agree with you it's not exactly right.
> >>
> >> I'm not sure about the right action.
> >>
> >> This issue should probably go onto the list of things to be considered
> >> in the grand build restructuring that was discussed by some of us a
> >> couple of weeks ago.
> >>
> >
> > Autotools is trying to be helpful by setting the "unspecified" prefix to
> > NONE during configure. But since gnuradio is using it as if it was always
> > set I suggest we do the following at the top of configure.ac
> >
> > if test "${prefix}" = "NONE"; then
> >    prefix=${ac_default_prefix}
> > fi
> >
> > We can put it on the next branch and hope it fixes more things than it
> > breaks... at least until the grand rebuild structuring comes along. :-)
> >
> > -Josh
> 
> 
> Thanks, guys. I've made a note of this to keep in mind while we're
> working on the restructuring.
> 
> Tom
> 

It looks like it's part of autoconf's machinery...
On my system I found it in /usr/share/autoconf/autoconf/general.m4
around line 558.

  AC_SUBST(prefix, NONE)dnl

There's a discussion here that's relevant:

  http://www.mail-archive.com/autoc...@gnu.org/msg15773.html


I think Josh's suggestion will work.  It probably has to occur after
AC_INIT (or maybe AC_PREREQ).  Not sure if there's anything else that
needs to run first.

Eric

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

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

[Eric Blossom]

On Sat, Sep 25, 2010 at 12:32:36PM -0700, Josh Blum wrote:
> 
> >Fair enough, Eric.  So do you suggest another approach that allows
> >boostrap/configure/make to "just work", or simply more notes
> >   about this in the build instructions when you're using UHD?
> >
> >
> 
> The issue being that all the gnuradio dependencies are distribution
> installable (on linux) so you dont need to set special paths and
> environment variables. However, UHD is not ready to be handed out as
> rpms and debs (though it can be) so it may need special paths set to
> use on operating system .
> 
> However, it looks like gnuradio wants to set your PKG_CONFIG_PATH to
> include the ${prefix}/lib${lib_suffix}/pkgconfig. So, if you happen
> to use the same prefix and lib_suffix as you built for UHD, gnuradio
> should be able to find the uhd.pc file without you needing to set
> PKG_CONFIG_PATH by hand.
> 
> The problem with this being, if --prefix is not set, gnuradio sets
> this to NONE/lib${lib_suffix}/pkgconfig which isnt going to work.
> Maybe ${ac_default_prefix} can be used when ${prefix} is set to NONE

That would probably be better than what we've got.

Independent of the use case you brought up, there's a couple of other
places we run afoul the same issue (prefix == NONE).  IIRC it gets
baked into some C/C++ strings somewhere too.

Eric

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

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

[Eric Blossom]

On Sat, Sep 25, 2010 at 12:23:19PM -0700, Josh Blum wrote:
> 
> 
> On 09/25/2010 12:01 PM, Eric Blossom wrote:
> >On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
> >>This turns out to be a bug in gnuradio configure  - when --prefix is
> >>not specified with ./configure, the ${prefix} variable is set to
> >>NONE
> >
> >Listen guys, you may not like this behavior, but it's not a bug.
> >If you read the makefile standards, it's to allow a package to be
> >installed into a different location at "make install" time.
> >
> 
> Thats fine, but is it fine that configure.ac sets PKG_CONFIG_PATH to
> NONE/lib/pkgconfig when --prefix is not specified. Thats not a
> problem?

I agree with you it's not exactly right.

I'm not sure about the right action.

This issue should probably go onto the list of things to be considered
in the grand build restructuring that was discussed by some of us a
couple of weeks ago.

Eric

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

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

[Eric Blossom]

On Sat, Sep 25, 2010 at 03:09:47PM -0400, Marcus D. Leech wrote:
> >
> > There definitely shouldn't be any PKG_CONFIG_PATH special case
> > handling for anything in grc_.m4.
> >
> > A ton of effort was put into making the building system work reliably
> > and consistently (mostly by Michael Dickens).  A lot of the details
> > are quite subtle, and the effort took a long time to stabilize, and
> > has proven itself to work on a wide variety of OS's and distributions.
> > All of the grc_.m4's should follow the same pattern.
> > There shouldn't be any divergence in the boilerplate.
> >
> > I removed the offending code because it was causing my build to break,
> > and noticed at that time that it shouldn't have been there in the
> > first place.
> >
> > Eric
> >
> >
> >   
> Fair enough, Eric.  So do you suggest another approach that allows
> boostrap/configure/make to "just work", or simply more notes
>   about this in the build instructions when you're using UHD?

This really doesn't have anything to do with UHD.  You'd see
the same problem with any other dependency installed outside of
/lib{,64} or /usr/lib{,64}

Just as you have to set your PYTHONPATH for stuff in /usr/local...,
set your PKG_CONFIG_PATH for stuff in /usr/local/lib{,64}

Eric

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

Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010

[Eric Blossom]

On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
> This turns out to be a bug in gnuradio configure  - when --prefix is
> not specified with ./configure, the ${prefix} variable is set to
> NONE

Listen guys, you may not like this behavior, but it's not a bug.
If you read the makefile standards, it's to allow a package to be
installed into a different location at "make install" time.

> http://www.mail-archive.com/autoc...@gnu.org/msg15772.html
> 
> The following code with yeild a PKG_CONFIG_PATH of NONE/lib/pkgconfig
> 
> >dnl add ${prefix}/lib${gr_libdir_suffix}/pkgconfig to the head of the 
> >PKG_CONFIG_PATH
> >if test x${PKG_CONFIG_PATH} = x; then
> >PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig
> >else
> >
> > PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig:${PKG_CONFIG_PATH}
> >fi
> >export PKG_CONFIG_PATH

There definitely shouldn't be any PKG_CONFIG_PATH special case
handling for anything in grc_.m4.

A ton of effort was put into making the building system work reliably
and consistently (mostly by Michael Dickens).  A lot of the details
are quite subtle, and the effort took a long time to stabilize, and
has proven itself to work on a wide variety of OS's and distributions.
All of the grc_.m4's should follow the same pattern.
There shouldn't be any divergence in the boilerplate.

I removed the offending code because it was causing my build to break,
and noticed at that time that it shouldn't have been there in the
first place.

Eric

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

Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?

[Eric Blossom]

On Tue, Sep 21, 2010 at 08:24:53PM +1200, John Shields wrote:
> I recently purchased a USRP and have a fresh install of WUBI (HP Pavillion 
> DV5 , Windows Home Vista) and used 
> gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall to install things. 
> 
> I passed 'make check' correctly
> 
> I have my username in the group usrp
> 
> j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp
> crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005
> 
> when I execute ./usrp_benchmark_usb.py I get:
> 
> 
> Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is not 
> available
> /home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission denied
> uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z
> 
> 
> and it hangs so I kill it
> 
> [1]+  Stopped ./usrp_benchmark_usb.py
> 
> I cannot repeat this operation as I get
> 
> Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed
> could not set alt intf 0/0: Connection timed out
> open_nth_cmd_interface: open_cmd_interface failed
> usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx.
> Traceback (most recent call last):
>   File "./usrp_benchmark_usb.py", line 106, in 
> main () 
> 
>   snip.

Just to rule out a flakey cable, can you try using a different USB 2 cable?

Eric

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

Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory

[Eric Blossom]

On Fri, Sep 17, 2010 at 05:02:00PM +0200, Fabrizio Tappero wrote:
> hello,
> I am trying to compile this C++ file:
> http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface
> by doing:
> g++ usrp_test_c++.cpp -o testusrp -lusrp
> 
> and I get the following error:
> test_usrp_standard_rx.cc:28:39: error: usrp_standard.h: No such file
> or directory
> 
> I am on a ubuntu 10.4 (32bit) system with gnuradio 3.3.0 properly (I
> guess) installer (from git) in /media/lin_sw/gnuradio/current
> from env I see that:
> 
> LD_LIBRARY_PATH=/usr/lib/:/media/lin_sw/gnuradio/current/lib
> 
> I do not seem to figure out what I am missing, can anybody please help.
>
> thanks a lot
> fabrizio
> PS "current" is actually a symbolic link to the folder 3.3.0 in the
> same location as suggested in here:
> http://wiki.frednet.org/index.php/GNU_Radio_Installation_Guide

Assuming you've done a "make install", pkg-config will tell you the
cflags and libs you need to use.  You'll need to have your
PKG_CONFIG_PATH set correctly for this to work.  If you installed into
the default prefix (/usr/local), the you'll need either:

$ export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig

  or

$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig

Depending on whether you're on a 64-bit machine and/or what OS and
distribution you're using

On my x86_64 machine running Fedora 13:

$ echo $PKG_CONFIG_PATH
/usr/local/lib64/pkgconfig


$ pkg-config --cflags usrp
-I/usr/local/include
$ pkg-config --libs usrp
-L/usr/local/lib64 -lusrp -lusb

Eric

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

Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard

[Eric Blossom]

On Thu, Sep 16, 2010 at 03:26:17PM +0200, Matthias Schäfer wrote:
>  Am 16.09.2010 07:49, schrieb Eric Blossom:
> > A couple of things.  32000 is likely to be too big and will probably
> > result in clipping.  Try 3200 to start with.
> >
> > It's unlikely that f/w can write samples to the buffer fast enough to
> > keep the data streaming. However in your case, you only need to
> > initialize the samples in the buffer once, then you can just keep
> > sending it over and over.  
> >
> > Do (2) once.
> >
> > // Start in known good state (IDLE)
> > bp_clear_buf(DSP_TX_BUF_0);
> >
> > // start first buffer xfer
> > bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> >
> > while (1){
> >
> >   // wait for xfer to complete
> >   while ((buffer_pool_status->status &
> >   (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
> > ;
> >
> >   // Reset flags
> >   bp_clear_buf(DSP_TX_BUF_0);
> >
> >   // start next xfer
> >   bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> > }
> >
> >
> > Eric
> Hi Eric,
> thank for your fast reply. I tried the things you told me but it doesn't
> work nevertheless. I'm using the txrx_uhd f/w with the additional void
> SEND_DATA() (see below). After tuning the USRP2 with the mentioned
> host-app (see above), I'm sending a UDP packet to the USRP2 with a
> special port which becomes filtered by the eth_pkt_inspector which then
> invokes SEND_DATA(). The serial port then tells me the following:
> 
> Waiting for the buffer pool.
> Buffer pool idles. Filling buffer.
> Filled buffer. Start sending.
> Done.
> Done.
> 
> and than the USRP2 stucks in the inner waiting-loop until I restart it.
> If the debug-symbols (putstr) make any problems here, I tried it several
> times without serial port but it didn't have any effect. The H/W seems
> to be okay, because sending and receiving with grc works fine.
> 
> Do I maybe have to set some dboard/buffer pool flags before sending?
> Does my tuning procedure maybe leave the dboard in a "no-sending"-state?
> 
> static void SEND_DATA () {
> putstr("Waiting for the buffer pool.\n");
> 
> while((buffer_pool_status->status & BPS_IDLE(DSP_TX_BUF_0)) == 0)
> ;
> 
> putstr("Buffer pool idles. Filling buffer.\n");
> 
> // fill buffer
> uint32_t *p = buffer_ram(DSP_TX_BUF_0);
> uint32_t i;
> uint32_t sample = (3200 << 16) | 0;
> 
> for (i = 0; i < BP_NLINES; i++) {
> p[i] = sample;
> }
> 
> putstr("Filled buffer. Start sending\n");
> 
> bp_clear_buf(DSP_TX_BUF_0);
> 
> // first xfer
> bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> 
> while (1) {
> 
> // wait for xfer to complete
> while ((buffer_pool_status->status &
>   (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
> ;
> 
> putstr("Done.\n");
> 
> bp_clear_buf(DSP_TX_BUF_0);
> 
> // fire it off
> bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> }
> }
> 
> 
> Cheers,
> Matthias


Matthias,

I'm not familiar with the changes that were made for the UDH fpga
image.  It may be that the timestamp checking is being done in the DSP
path.  If so, raw samples won't have the (possibly) required header.
I assume that there's a "NOW" flag that can be set in the header, but
I don't know the details.  Looking at the UHD host code should show
you how the packet is built.  Looking at the UDH firwmare will show
you which part of the header (UDP) is stripped off (probably by
adjusting the starting line number, passing on the VRT (or whatever)
header to the DSP pipe.

I believe the code above will work if you add the possibly required
header when you initialize the buffer.

Eric

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

Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard

[Eric Blossom]

On Wed, Sep 15, 2010 at 05:55:12PM +0200, Matthias Schäfer wrote:
>  Hi List,
> I'm currently working on a standalone firmware app for USRP2. My
> goal is to send a constant signal with the xcvr2450 dboard. I
> skipped the tuning via firmware by doing this prior from a host
> using the simple_usrp c++ interface:
> 
> uhd::usrp::simple_usrp::sptr sdev = uhd::usrp::simple_usrp::make(args);
> uhd::device::sptr dev = sdev->get_device();
> sdev->set_tx_rate(rate);
> sdev->set_tx_freq(freq);
> sdev->set_tx_gain(gain);
> 
> ===
> So back to the firmware. Assuming the tuning of the dboard is
> properly done from host, I basically understood the way sending is
> done as follows:
> 
> 1. Wait for the buffer pool to become idle:
> 
> while((buffer_pool_status->status & BPS_IDLE(DSP_TX_BUF_0)) == 0)
> ;
> 
> 2. Copy the data which should be send to the DSP into the DSP tx-buffer:
> 
> uint32_t *p = buffer_ram(DSP_TX_BUF_0);
> uint32_t sample = (32000 << 16) | 0; // for example
> for (i = 0; i < BP_NLINE; i++) {
> p[i] = sample;
> }
> 
> 3. Send the data to the DSP:
> 
> bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
> 
> 4. Wait until transaction is done or an error occured
> 
> while((buffer_pool_status->status & (BPS_DONE(DSP_TX_BUF_0) |
> BPS_ERROR(DSP_TX_BUF_0))) == 0)
> ;
> 
> 5. Clear the status flags and redo the whole procedure
> 
> bp_clear_buf(DSP_TX_BUF_0);
> // goto 1.
> 
> ===
> 
> Unfortunately this doesn't work for me like expected. I tried it in
> several variations and listened with another usrp2 for a signal but
> nothing happens. I think I understood something wrong and forgot
> something but it's hard for me to see the problem.
> 
> So maybe you guys can help me out with that.
> 
> Thanks in advance!
> 
> Cheers,
> Matthias

A couple of things.  32000 is likely to be too big and will probably
result in clipping.  Try 3200 to start with.

It's unlikely that f/w can write samples to the buffer fast enough to
keep the data streaming. However in your case, you only need to
initialize the samples in the buffer once, then you can just keep
sending it over and over.  

Do (2) once.

// Start in known good state (IDLE)
bp_clear_buf(DSP_TX_BUF_0);

// start first buffer xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);

while (1){

  // wait for xfer to complete
  while ((buffer_pool_status->status &
  (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;

  // Reset flags
  bp_clear_buf(DSP_TX_BUF_0);

  // start next xfer
  bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}


Eric

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

Re: [Discuss-gnuradio] Re: s/Eric/Tom/g

[Eric Blossom]

On Sat, Sep 11, 2010 at 04:57:26PM -0400, Andrew Ge wrote:
>  Eric,
> 
> Many of us are deeply grateful to you for what you have contributed
> to GNU Radio development, Q/A, and maintenance. Without your pioneer
> work, commitment and dedication, GNU Radio would not be like what we
> have today (this applies also to a few other folks you mentioned in
> your announcement). As far as I know, many many people, particular
> students all over the world,  have benefited greatly from your work.
> Twenty years after SDR was proposed, it is still hard to find low
> cost and relatively good performance SDR software packages and
> platforms. It's you, Matt, and a few others who have changed the
> landscape. Taking this opportunity, I'd like to show my gratitude to
> you folks.
> 
> I have personally worked with Tom Rondeau. Even though it was just a
> few months in 2007, I was able to find out that he is smart,
> skilled, dedicated, and passionate about SDR R&D. Since then, Tom,
> as I have observed,  has been continuously contributing greatly to
> GNU Radio development. His philosophy about open source project
> combined with his knowledge and skills, I believe, will enable him,
> together with this community,  to drive GNU Radio  to  new levels.
> 
> I hope that, after stepping down as the "Maintainer",  you will have
> more time for other things that you like to do in your life.
> 
> Best regards,
> 
> Feng (Andrew) Ge, Ph.D.
> Senior Research Scientist
> Telcordia Technologies, Inc.
> 

Thanks for the kind words!

Eric

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

[Discuss-gnuradio] s/Eric/Tom/g

[Eric Blossom]

As some of you know, I've been involved with GNU Radio for a long
time.  The idea that became GNU Radio started as a conversation over
dinner in San Francisco with John Gilmore, something like 10 years
ago.

Interest and use of GNU Radio is currently at the highest level it's
ever been.  I however, have come to a place in my life where I'd like
to devote less of my time to GNU Radio and more to other things.

After discussions with GNU Radio developers over the past several
months, I'm pleased to announce that long time GNU Radio contributor
Tom Rondeau has agreed to take over the GNU Radio "Maintainer" role
from me.  For those of you who don't know Tom, he's the perfect person
for the job.

He's smart, has a vision for the future, and has the "cat herding
instinct" required to succeed in the position.  Tom received his
Ph.D. in 2007 from Virginia Tech's Department of Electrical and
Computer Engineering.

Johnathan Corgan will continue to handle GNU Radio release
management and provide professional services related to GNU
Radio. 

Matt Ettus and the rest of the crew at Ettus Research will continue to
crank out low cost hardware for all of us to enjoy.

I plan to continue contributing to GNU Radio, and will be finishing up
some extensions for message passing, as well as some other things
where I'm probably best positioned to do the work.

Bottom line: business continues as usual, and you'll see more of Tom
and less of me.

Eric

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

Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.

[Eric Blossom]

On Fri, Sep 10, 2010 at 10:19:05AM +1200, Kieran Brownlees wrote:
> We have seen the same behaviour when trying to run overnight on the USRP1,
> the flowgraph was just doing FM mod (LFRX in LFTX out) and it had a
> graphical sink. Have the flowgraphs you used been made in GRC (ie could this
> be a wx issue?).

I've recently seen crashes (assert failures) directly related to wx,
gtk and opengl.  From looking at the stack traces on those, it didn't
appear to be our problem.  These were not running under GRC.

Eric

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

Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.

[Eric Blossom]

On Thu, Sep 09, 2010 at 01:32:01PM -0400, Marcus D. Leech wrote:
> On 09/09/2010 11:42 AM, Anil Sharma wrote:
> >Hi everyone,
> >   I want to test something with  usrp running continously under
> >normal environment.
> >Can someone tell me the real data of how long usrp is capable of
> >running continously.
> >Thanks.
> >
> >
> >___
> >D
> Three years ago, I used to run my USRP1-based radio astronomy
> software for months at a time
>   with no issue.
> 
> In the last year or so, I've been unable to maintain those kinds of
> uptimes with either USRP1 or
>   USRP2, which I ascribe to fundamental changes in Gnu Radio, but I
> haven't been able to put
>   my finger on exactly which flow-graphs will "wedge" after a few
> days, and which ones will
>   keep going and going.  I have one flow-graph that uses the USRP2
> at low bandwidths (400Ksps
>   or so) that seems to be able to run forever.  Another, similar
> flowgraph, will tend to "wedge"
>   after a few days.
>
> I also have a flow-graph that uses an ALSA source and sink, and it
> can only run for a few
>   days before "wedging".

Marcus,

It would be useful it you could provide a gdb stack trace of all
threads when you see the "wedged condition".

If it's a python program, run gdb against /usr/bin/python and use the
gdb attach command to attached to the wedged process.
Then issue

 thread apply all bt

to generate the stack traces and send them to me.

Eric

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

Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"

[Eric Blossom]

On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote:
> On 09/04/2010 08:08 PM, Tom Rondeau wrote:
> > On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech  wrote
> >   
> > Like Eric said, remove the throttle or at least change the rate and
> > that should clean things up.
> >
> > Tom
> >
> >   
> I also noted in the reply to Eric that I observe the same behaviour with
> an external source that is producing 4800 symbols/second--so
>   it's not the throttle *per se*, but rather the way that work "chunks"
> get scheduled in Gnu Radio.  With a "fast" source, you dont find yourself
>   in a situation where there aren't enough "chunks" to keep things busy.
> 
> But a very reasonable example would be something like a cross-band
> digital repeater application, where bits/symbols would be arriving
>   at the "channel rate", and need to leave the Tx in something at least
> approaching real time--you certainly need to have a bit of
>   elastic buffering to compensate for clock-skew between the two sides,
> but several-tens-of-seconds of latency isn't likely to be very
>   useful in the real world.
> 
> Note that I'm not criticizing anybody or anything.  I'm making
> observations, and I *do* understand *why* it is the way it is.
>   My little test flow-graph failed the "least astonishment test", which
> is why I felt I needed to comment.
> 
> Would it be reasonable to open a discussion about this class of
> flow-graph?  I think they can be characterized as flow-graphs with
>   a low symbol rate, and high interpolation (which I think is where the
> buffer-multiplier effect may be coming into play).  In such flow-graphs,
>   would it be reasonable to be able to "tweak" the scheduler to deal
> with this type of situation?  I have little insight into how the scheduler
>   works in detail, but I think I understand the "fits and starts" that I
> was observing.
> 
> So, is this a reasonable discussion topic?  Are other folks working on
> "stuff" that will run into part of the performance diagram I ran
>   into yesterday?  Or is everyone else working on high-event-rate type
> signal chains?

Marcus,

This is certainly a reasonable discussion topic.
I suggest before wading in that you first enable the scheduler logging
that I mentioned in a prior post and take a look at that.

Feel free to send me the logs too.

What we're looking for is which block is forcing the large chunk size.
If you were reading from a file using for example gr.file_source, it
won't return until until it's completely filled up the downstream
buffer given to it.  That's just how it's written.

A trivial change would be to have it loop until it it read
min(N_USER_SPECIFIED_ITEMS, noutput_items) items.

Eric

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

Re: [Discuss-gnuradio] GRC's graphical sinks performance issues

[Eric Blossom]

On Fri, Sep 03, 2010 at 04:21:53PM -0700, Jack Ott wrote:
> 
> 
> Matt Ettus wrote:
> > 
> > On 09/02/2010 07:09 AM, Jack Ott wrote:
> >>
> >> The strange thing is that when the fft's sample rate is at 25Msps which
> >> equals the USRP's bandwidth at a decimation of 4 everything works fine
> >> with
> >> the regular fft sink yet not with the OpenGL one. However when I increase
> >> the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both
> >> sinks
> >> work fine. What does this mean?
> >>
> >> I'm really convinced all this is because graphics are rendered strictly
> >> through software. Does GRC even support graphics hardware acceleration?
> >> how
> >> do I configure it?
> > 
> > Jack,
> > 
> > I think you are missing the point here.  There is no need to lie to the 
> > program.  If you are sending the FFT sink 25 MS/s, then tell it you are 
> > sending it 25 MS/s.  If you give it a different rate you will have all 
> > sorts of other issues, like incorrect frequency scales on the display. 
> > If you want to decrease the processor load then reduce the display 
> > update rate.
> > 
> > If you have unaccelerated OpenGL, then the OpenGL version will be 
> > unacceptably slow.
> > 
> > Matt
> > 
> 
> Thanks for pointing that out, I was wondering why the scales were acting up.
> Anyway, am setting up a fresh OS in a couple of days on a different machine,
> hopefully then I'll be able to pinpoint where I've gone wrong.
> 
> Thanks everyone.

FWIW, independent of GNU Radio, I've found that OpenGL support in
Linux still leaves a lot to be desired in the performance and
reliability departments.  (Spoken as someone who's recently tried high
performance cards from both Nvidia and ATI, trying both the
proprietary and open source drivers for each one...  on Fedora 13)

Eric

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

Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"

[Eric Blossom]

On Fri, Sep 03, 2010 at 10:09:01PM -0400, Marcus D. Leech wrote:
> I've got a flow-graph with a throttled random byte source, which is a
> test input for a modulator:
> 
> http://www.sbrac.org/files/fm4_test_modulator.grc
> 
> http://www.sbrac.org/files/fm4_test_modulator.py
> 
> The source is throttled to the byte rate required to produce the correct
> number of symbols/second (4800).

The throttle block was written so that the GUI elements could be
tested without an inherently rate limiting source being in the graph.
It is not designed to precisely rate limit anything.  For any use
other than that, you're asking for trouble.  Think about it:  what
definitely of time to you use?  Over what period of time do you
average, etc, etc.

/*!
 * \brief throttle flow of samples such that the average rate does not exceed 
samples_per_sec.
 * \ingroup misc_blk
 *
 * input: one stream of itemsize; output: one stream of itemsize
 *
 * N.B. this should only be used in GUI apps where there is no other
 * rate limiting block.  It is not intended nor effective at precisely
 * controlling the rate of samples.  That should be controlled by a
 * source or sink tied to sample clock.  E.g., a USRP or audio card.
 */


> What I've noticed is that this graph only runs in "fits and starts",
> rather than continuously.  I assume this has something to
>   do with the Gnu Radio buffering and internal scheduler.


> In the case of a "real" flow-graph, taking real data in at
> 4800symbols/second, going to a real USRP transmitter, will it still
>   run in "fits and starts" or will it "do the right thing"??

It will do the right thing, assuming that all blocks "do the right
thing" and compute as much output as they are asked to.

> I realize that buffering is an important part of Gnu Radio, but how do
> you actually send low-rate data in something approaching
>   correct real-time?

You don't send it at the right rate, you let the sink (or source)
handle the timing issues.


Note that NONE of GNU Radio has any idea of the actual sample rate.

There are some places where sample rates are used (e.g.,
gr.sig_source), but they are there as a convenience so that people
don't have to continually puzzle over normalized frequencies.
However, this may give the impression that "sample_rate" actually
means something in the real world, and it doesn't --- with the exception
of i/o devices connected to a sample clock.

> I at first thought this was due to the throttle block, so I replaced it
> with an external (via a FIFO) source that produced random bytes
>   at a 1200-bytes/second rate (2 bits/symbol), and it behaves exactly
> the same as a a throttled random source--the graph seems to run in
>   "fits and starts".

The display may appear to run in "fits and starts" because the
internal decimation rate of the sink may be too high for the throttled
data rate that you're sending.  It may take a long time to get enough
data for the FFT sink to display anything.  Or there could be bugs in
the sink...

E.g., the GL fft sink has at least a bug or two related to the
mis-specification of python's '/' operator.  If you use integers,
1/3 == 0, but 1.0/3 = .   The bug I'm thinking of shows up as a divide
by zero in the persistence code when the ftt sink is invoked with its
default parameters (sample_rate = 1, fft_rate = 15).  There may also
be problems with mapping the user provided fft_rate into the
decimation factor of the keep_one_in_n block.  Not sure about that
one, but this is a place where it's possible to ask for ill-specified
behavior.  E.g., if I say that the fft_rate is 15, and my sample rate
is 1, do I expect interpolation by 15???


See Python PEP-238 for background on the divide issue and the use of

  from __future__ import division

to debork the behavior of '/', and possibly help fix the sinks.


If you want to see the details of what the scheduler is doing,
change

  #define ENABLE_LOGGING 0

to

  #define ENABLE_LOGGING 1

at the top of gr_block_executor.cc  It will then create a separate ASCII
log file for each block.  They're named "sst-NNN.log".  The first line
of each log identifies the block.

Hope this helps!

Eric

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

Re: [Discuss-gnuradio] use of a "bulletin board" system in lieu of a mailing-list discussion

[Eric Blossom]

On Thu, Sep 02, 2010 at 01:47:34PM -0400, Dan Harasty wrote:
>  Hello, all.
> 
> OK, I know I'm just the "new guy" here, and it may be poor form to
> suggest that a well established forum should change its ways

:-)

> But I find the email-based discussion list VERY inefficient.
> - any sense of "threading" of a conversation is lost (at least for
> me: I receive the "digest" version.)
> - if there is a way for me to "search" for my issue in "prior
> threads", I haven't found it yet.  (Maybe I'm missing it or
> maybe it doesn't exist)

Google works for me:  

  gnuradio + 

gets me one of the N mailing list archives, where the messages are threaded.

> - email arrives even on days when I'm not focusing on my GNU radio projects.

Gee, that sounds like your mail handling tools suck.

I'd suggest the non-digest format, and have your MUA automatically
put the messages into a folder that you only look at when you care
about GNU Radio.  I'm assuming that your MUA can sort out the
threading.

> I'm part of other organizations that use a "web bulletin board" very
> effectively.  It addresses all the above issues: threading,
> searching prior discussions, and simply "being there" when one needs
> it.  One such system is vBulletin (http://www.vbulletin.com/).  This
> system is a bit different from a wiki (which has static pages that
> anyone can update).  Rather, someone posts a "post" in a "forum".
> Follow up posts are seen distinctly (you can't edit someone else's
> post), and all such follow ups to an original post are called a
> "thread".
> 
> Is there any interest in considering a shift to it or something similar?

Who knows?  You can of course subscribe an address that gets
gateway'd to where ever you like.

> Yes, it would need: a physical host, effort to set it up, an admin
> (for membership issues), and a panel moderators (to edit / move
> threads when necessary).  And maybe the cost of the software.
> 
> I understand that if there is a lack of interest (to participate),
> or if no one is available to set it up, it won't happen.  If so:
> /c'est la vie/...  However, I just wanted to float the idea in case
> there is general interest and the right set of volunteers.
> 
> -- Dan Harasty

Thanks for the suggestion and the links.

Eric

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

Re: [Discuss-gnuradio] USRP2, is that possible to skip the Ethernet and pass data through general purpose (physically accessible) inputs to the FPGA?

[Eric Blossom]

On Wed, Sep 01, 2010 at 07:07:26PM -0600, Malihe Ahmadi wrote:
> Hi,
> 
> I am using USRP2+RFX2400 board and trying to adapt our packetized
> communication on the board. As I understand the Ethernet does its
> own packetization on information data and we don't like that.
> therefore we are looking into avoid passing our information data to
> the board through Ethernet. We are also fine to make the
> configuration values for other peripherals on the board (such as
> DAC, ADC and daughter boards) fixed so that we still can get away
> with no Ethernet interface.  so we are interested to know if there
> is a general purpose input bus (at least 5 pins) that I can use to
> pass my data serially to the FPGA.

The MICTOR debug connector, J301, has 32 uncommitted pins and 2 clks.
It's currently configured as an output, but you can use it for whatever
you like.  Look in u2_rev3.v and/or u2_core.v.

   output [31:0] debug,
   output [1:0] debug_clk,

> That means I would like to see if
> it is possible to remove all the Verilog codes in FPGA related to
> handling the Ethernet interface and get the data I'd like to process
> through a general purpose input bus (at least 5 pins for clock and
> serial data input and 3 handshaking signals) instead of Ethernet
> port. For that reason, I need this general purpose bus to be
> physically accessible on the board so that I can connect them to a
> digital signal generator. Do you have any suggestion/recommendation
> for me?
>
> Thanks,
> Malihe

Eric

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

Re: [Discuss-gnuradio] Running GNU Radio before you install it

[Eric Blossom]

On Mon, Aug 30, 2010 at 08:42:51PM -0400, Philip Balister wrote:
> I've got gnuradio cross compiled for the armv7 and have it NFS
> mounted on the target hw. Is there an easy way to test gnuradio by
> running applications out of the build tree?

Easy way?  No.

> I know about running make check on the target, but I am interested
> in testing more complex flowgraphs.

Python or C++?

For python, take a look at gnuradio-core/src/python/gnuradio/gr/Makefile.am and
run_tests for clues about how you might be able to move forward.
(Note that we don't have any commitment to keep doing it the same way...)

Eric

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

Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration

[Eric Blossom]

On Sun, Aug 29, 2010 at 07:27:21PM -0500, Venkat Vinod wrote:
> Hello All,
> 
> I am having some difficulties implementing a cognitive receiver program that
> involves dynamically reconfiguring the USRP between sensing the spectrum and
> acting as a receiver based on the results of the spectrum sensing. The
> program I am developing is mostly based on the usrp_spectrum_sense.py for
> the sensing part and benchmark_rx.py for the receiving part. The
> specifications for our platform are at the end of the e-mail.
> 
> The general logic of my program is to run one flow graph which is connected
> in the same way as in the usrp_spectrum_sense program. After obtaining the
> results from the spectrum sensing, I wish to reconfigure the flow graph to
> connect the USRP to receive and demodulate a user-defined number of packets
> just as in the benchmark_rx program whenever we deem the spectrum to be
> free, after which we could revert to the configuration in the first flow
> graph and continue until the program is terminated.
> 
> Here is some code of the most relevant parts of the program:
> 
> 
> 
> #
> 
> CODE :
> 
> 
> else:
>   print "Receiver Mode : USRP to Switch to Receiving Packets "
>   self.tb.stop()

Don't call stop.  Just call lock.

>   self.tb.lock()   # THIS IS
> WHERE WE WANT TO RECONFIGURE TO RECEIVE
>   #
> PACKETS
> 

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

Re: [Discuss-gnuradio] Gnuradio website

[Eric Blossom]

On Sun, Aug 29, 2010 at 10:47:22AM -0400, Philip Balister wrote:
> gnuradio.org is showing a redmine internal error.
> 
> Philip

Fixed with big hammer :-)

Looks like the version of redmine we're using leaks memory and
eventually (a couple of weeks?) consumes all memory and swap...

Eric

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

Re: [Discuss-gnuradio] OFDM modulator and pilots

[Eric Blossom]

On Fri, Aug 27, 2010 at 12:19:53PM -0400, Srinivas wrote:
> 
> Another related question is: Who sets the parameters for the work function
> in this block ? particularly noutput_samples.
> 

Srinivas,

The parameters passed to work are determined by the GR runtime system.
Their values depend on a lot of things, including free space in the
upstream and downstream buffers, the return values from forecast;
various settings such as history and output_multiple.

Eric

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

Re: [Discuss-gnuradio] Gnuradio-3.3.0 on Ubuntu-10.04

[Eric Blossom]

On Wed, Aug 25, 2010 at 04:03:59PM -0700, Brook Lin wrote:
> 
> Thanks, Marcus.
> 
> I tried usrp_fft.py and got the same error. I also tried dial_tone.py under
> /gnuradio-example/python/audio, but I got the similar error:

I'm guessing that you have more than one installation on your system.
Perhaps one installed a while back using a .deb, and the one that
you're trying to build now.

Remove all traces of GNU Radio, then try again...

Eric



> 
> Traceback (most recent call last):
>   File "./dial_tone.py", line 24, in 
> from gnuradio import audio
>   File "/usr/lib/python2.6/dist-packages/gnuradio/audio.py", line 88, in
> 
> __init__()
>   File "/usr/lib/python2.6/dist-packages/gnuradio/audio.py", line 78, in
> __init__
> raise ImportError, 'Unable to locate an audio module.'
> ImportError: Unable to locate an audio module.
> 
> However, if I import audio from gnuradio using $ python, there is no error.
> 
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from gnuradio import gr
> >>> from gnuradio import audio
> >>> 
> 
> Thanks,
> Brook

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

Re: [Discuss-gnuradio] Gnuradio-3.3.0 on Ubuntu-10.04

[Eric Blossom]

On Wed, Aug 25, 2010 at 02:21:27PM -0700, Brook Lin wrote:
> 
> Thanks again for your replies. But, I did try:
> 
> $ cp /etc/ld.so.conf /tmp/ld.so.conf
> $ echo /usr/local/lib >> /tmp/ld.so.conf
> $ sudo mv /tmp/ld.so.conf /etc/ld.so.conf
> $ sudo ldconfig
> 
> Nothing helps. BTW, I used libboost-all-dev from synaptic package manager
> rather than boost_1_37_0. 
> 
> Doug, you are right. I find gnuradio under
> /usr/local/lib/python/dist-packages/. My old Ubuntu version has the path
> /usr/local/lib/python/site-packages/gnuradio. 
> 
> Other solutions?

Is your PYTHONPATH set to /usr/local/lib/python2.6/dist-packages?
Is your PYTHONPATH exported?

Does this work:

  $ python
  Python 2.6.4 (r264:75706, Jun  4 2010, 18:20:31) 
  [GCC 4.4.4 20100503 (Red Hat 4.4.4-2)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from gnuradio import gr
  >>> from gnuradio import usrp
  >>> exit()

Eric

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

Re: [Discuss-gnuradio] Changing four parallel pipes of ADC's into two parallel pipes of ADC's(having interleaved IQ as in the case of DAC's)

[Eric Blossom]

On Wed, Aug 25, 2010 at 11:53:02AM +0530, Sanjay Singh wrote:
> Hello Eric,
> 
> In USRP1, I don't want AD9862 to use in my application for many reasons.
> 
> Am looking for changing four parallel pipes of ADC's into two parallel pipes
> of ADC's(having interleaved IQ as in the case of DAC's).
> I need only changes required to be done in FPGA. Although i know that the
> ADC data bus to FPGA will have to be clocked twice the sampling rate.
> 
> I believe this may be a minimal change required in the FPGA.
> 
> Can anyone support me for doing this change.
> 
> Regards
> Sanjay

Sanjay, 

I'm sorry that I don't understand exactly what it is that you are
trying to do with the ADC path in the AD9862.  (Or what you hope to
accomplish with this change.)

By default we configure the AD9862 so that it's in "Dual Channel
Complex ADC Signal mode"  (Rev 0 datasheet pg 23, under "RECEIVE
APPLICATIONS SECTION").  This puts the I & Q out separate pins on the
chip.  We do not have the Hilter Filter enabled, so the two streams (I
& Q) are effectively independent.  (See Figure 6 on pg 22).

You could reprogram the AD9862 to put it into "Dual Channel Real ADC
Signal mode", but since we're not using the Hilbert Filter these two
modes are equivalent.

If you want interleaved I & Q, I suggest that you do that in the FPGA,
and not by changing the interface between the the AD9862 and the FPGA.
Why I say this is because the existing configuration is well tested,
and meets all the timing requirements for the interface between the
FPGA and the AD9862.

If I haven't answered your question, please try asking it again.

Eric

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

Re: [Discuss-gnuradio] Souce Block

[Eric Blossom]

On Wed, Aug 25, 2010 at 10:08:22AM -0300, John Li wrote:
> Hi!
> 
> I have many source blocks with different kinds of signal generator and I
> want to create a configurable unique block.
> 
> Can I make a source block with multiple outputs each one with a different
> rate?
> 
> Thank you,
> John

Yes you can in 3.3.*

Your block will need to derive from gr_block, and in general_work you
must call produce for each output streams, and general_work must
return WORK_CALLED_PRODUCE as it's value.

>From gr_block.h:

  //! Magic return values from general_work
  enum {
WORK_CALLED_PRODUCE = -2,
WORK_DONE = -1
  };

  ...

  /*!
   * \brief Tell the scheduler \p how_many_items were produced on output stream 
\p which_output.
   *
   * If the block's general_work method calls produce, \p general_work must 
return WORK_CALLED_PRODUCE.
   */
  void produce (int which_output, int how_many_items);


Eric

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

Re: [Discuss-gnuradio] Peak detector block does not really work. It need to be fixed

[Eric Blossom]

On Tue, Aug 24, 2010 at 01:49:09PM -0700, Phong Do wrote:
> 
> Hello Tom,
> 
> Can you explain me why should gr_peak_detector need negative inputs ?

If you use grep, you can find places in the code where it is used, and
then answer your own question.

> What about the variable "look ahead" ? I wrote in the last message that
> "look ahead" has no function in gr_peak_detector.

My guess is that look_ahead was a feature that turned out not to be
needed to solve the problem at hand, but was accidentally left in the
constructor. 

> Do you know how can I add this feature in peak detector ?

Yes.  Write the code that implements it.

Eric


> On Thu, Aug 12, 2010 at 8:26 AM, Phong Do  wrote:
> >
> > Hello,
> >
> > I'm working now with peak_detector block and find out that some functions
> > don't really work.
> > I've used the following 2 blocks:
> >
> > - Peak Detector (gr_peak_detector): the parameter "look ahead" seems have
> > no
> > function. I gave "look ahead" many values but the peak value did not
> > change.
> > I've seen in the gr_peak_detector_xx.cc that the variable d_look_ahead is
> > called but it is not used in the main program. So I think the developer
> > has
> > forgotten this function.
> >
> > - Peak Detector 2 (gr_peak_detector2): in this block "look ahead" is used,
> > but sometimes the peak detector freezes (output signal stops running in
> > scope sink).
> > I've changed the cpp code a little bit and it does not freeze anymore. But
> > I'm not sure if the detector will work correctly after that.
> > Here is what I've changed:
> > original code: return tmp - 1;
> > changed code: return tmp;
> >
> > Can anyone of the development team have a look at the 2 cpp ?
> >
> > best regards
> > Phong Do
> 
> Keep in mind that the gr_peak_detector actually expects negative
> inputs. So if your signal goes from 0 to 100, adjust it so that it
> goes from -100 to 0.
> 
> Of course, I say "keep in mind" even though we probably haven't
> provided any documentation in the code to that affect...
> 
> Tom

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

Re: [Discuss-gnuradio] doubt about the the DC offset

[Eric Blossom]

On Mon, Aug 23, 2010 at 05:18:58PM +0800, intermilan wrote:
> 
> hi Eric:
> 
>   I think I am the one who ask the same question in my last
>   e-mail.But there is no answer for it.I still can not find where is
>   the process of setting this value.and I do not understand why this
>   value is 4M.I hope someone can help me to figure it out.
> 

http://osdir.com/ml/discuss-gnuradio-gnu/2010-08/msg00122.html

We picked a value that improved the performance of the test cases we
looked at.  You are free to pick another value if it works better for
you, for whatever interpretation of "better" you like.



> > Date: Sun, 22 Aug 2010 20:16:30 -0700
> > From: e...@comsec.com
> > To: tianxia...@hotmail.com
> > CC: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] doubt about the the DC offset
> > 
> > On Mon, Aug 23, 2010 at 09:42:56AM +0800, intermilan wrote:
> > > 
> > > Hi all:
> > 
> > >  when I run the test program test_usrp_standard_tx/rx.cc, I
> > >  found that the DC offect is set to 4M. So can anyone tell me
> > >  how this value come out and where can I find the process of
> > >  setting this value? and can we set other values to instead of
> > >  this value?
> > 
> > Please search the mailing list archives.  This questions was asked and
> > answered in the last 10 days or so...
> > 
> > Eric

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

Re: [Discuss-gnuradio] doubt about the the DC offset

[Eric Blossom]

On Mon, Aug 23, 2010 at 09:42:56AM +0800, intermilan wrote:
> 
> Hi all:

>  when I run the test program test_usrp_standard_tx/rx.cc, I
>  found that the DC offect is set to 4M. So can anyone tell me
>  how this value come out and where can I find the process of
>  setting this value? and can we set other values to instead of
>  this value?

Please search the mailing list archives.  This questions was asked and
answered in the last 10 days or so...

Eric

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

Re: [Discuss-gnuradio] how to get dqpsk2 block?

[Eric Blossom]

On Fri, Aug 20, 2010 at 12:56:30AM -0700, Thunder87 wrote:
> 
> Somehow managed to install git and get gnuradio source. Now I have a problem
> with source installation. "sudo ./configure" says:
> 
> The following components were skipped either because you asked not
> to build them or they didn't pass configuration checks:

Do you have a C++ compiler installed?

The answer to your question will be in the output from configure.

Eric

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

Re: [Discuss-gnuradio] Distorted playback of real-time audio on Linux

[Eric Blossom]

On Sat, Aug 14, 2010 at 03:16:38AM +0400, Elvis Dowson wrote:
> Hi Eric,
> 
> On Aug 13, 2010, at 8:38 PM, Eric Blossom wrote:
> 
> > Given the interfaces exported by ALSA, you'd need to figure out how to
> > honor the condition "ok_to_block == False".
> 
> Could you please tell me the intent behind the ok_to_block flag? 

The name could be improved, but when "ok_to_block == False", the
interpretation should be that the GR interface to the audio subsystem
should attempt to rate match the data being consumed or produced by
the GR flow graph to the rate that the audio subsystem wants it.

> By blocking, do you mean a synchronous call, which will block and
> render the subsystem un-responsive, until, it completes?

Yes.  You should think of "ok_to_block == True" means that the audio
device is effectively setting the absolute (real-time) sample rate of
the graph.  This only makes sense when there is no other source or
sink that is also attempting to set the absolute (real-time) sample
rate.  Thus the problem shows up with flow graphs that contain either
a USRP source and a audio sink or an audio source and a USRP sink.
(It doesn't have to be a USRP --- any other i/o device that's tied to
a sample rate clock will show the problem.)

Note also that depending on which clock is faster rate matching requires
either dropping or adding samples on average.

> In this scenario, should the two subsystems be running
> asynchronously, with a buffer in between, so that the two can run at
> different clock rates? e.g. USRP2 running at a particular clock
> rate, and the alsa_audio_sink running at a different clock rate?

Yes.

The relative rates may be mismatched by less than 0.1%.  Even at that
level, on the average you'd need to be adding or dropping 1 sample
every 1000 to match the rates between the two clock domains.

> Or is the whole GNU Radio flow-graph a synchronous system, i.e. it
> completes execution and evaluation of the entire flow graph, every
> clock cycle, reading data from the environment, processing the
> inputs, and computing the output, for every clock cycle?

No, it doesn't work that way.  It buffers a certain amount of data
between blocks before running them.  

Elvis, do you understand the high level source of the problem?
That is, that there are two hardware devices whose clocks are not
synchronized?

Eric

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