Job Opportunities at Planet Labs!
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
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
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...
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
On Tue, Dec 07, 2010 at 11:36:19AM +0100, Anton Blad wrote:
On Mon, 29 Nov 2010 09:30:11 -0800, Eric Blossom e...@comsec.com 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(whats-physically-available, your-limit)
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] Tesla C2000 series and CUDA and Gnu Radio
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] Broken gr_fir_fff ?
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] TPB scheduler fills block buffers
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(whats-physically-available, your-limit)
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
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([my-pattern], 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 = generate carrier mult = gr.multiple_ff() sink = something-downstream 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] Not getting Makefile after bootstrap configure?
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
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] call set_output_multiple() on the fly
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] Carrier frequency mismatching?
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?
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 e...@comsec.com 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] question about import a new block in gnuradio-3.3.0
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 stdin, line 1, in module
File /usr/local/lib/python2.6/dist-packages/test_example/__init__.py,
line 40, in module
from test_example_swig import *
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 24, in module
_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] Help - Custom block generating data @ 1:5115 input to output ratio causes flowgraph to hang -- how to prevent this
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;idata_items;i++){
if(in[i]0x01){
for(int j=0;jinterpolation();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;jd_length_PN*d_n_pn;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] Re: get fatal IO error 11 when running usrp2_fft.py (USRP2 + XCVR2450)
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] GNU Radio Unstable Behavior
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] 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 stdin, line 1, in module
File /usr/local/lib/python2.6/dist-packages/test_example/__init__.py,
line 40, in module
from test_example_swig import *
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 24, in module
_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] gnuradio-3.3.0 Build Error On Fedora 14 (x86_64)
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
Re: [Discuss-gnuradio] config.guess and config.sub in git
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] USRP2 printing of character S bothersome!!
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
[Discuss-gnuradio] Re: TPB update
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::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) 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::complexfloat 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::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) 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::complexfloat const*) 5502238.8294 /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 gr_sig_source_c::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) 2484203.9864 /usr/local/lib64/libgnuradio-core-3.3.1git.so.0.0.0 gr_rational_resampler_base_ccc::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) 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] Using Both Input Channels of a Sound Card
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] Cannot build USRP. ./configure reports sdcc is missing in spite of it being installed!
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] Pipelined processing with the Thread-Per-Block scheduler?
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] question on howto write a new block
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 my-module-name 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] Basic analog USRP2 transmitter
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] Basic analog USRP2 transmitter
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] USRP BasicRX read_io() from pins
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
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 e...@comsec.com 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] gcc 4.5 and GNU Radio 3.3.0
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_ptrusrp2::usrp2 value;
+boost::weak_ptrusrp2 value;
-usrp_table_entry(const std::string _key, boost::weak_ptrusrp2::usrp2
_value)
+usrp_table_entry(const std::string _key, boost::weak_ptrusrp2 _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] Linking Gnuradio with SWIG
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] Re: ATSC decoding - Now Working!
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] gcc 4.5 and GNU Radio 3.3.0
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] CPU Utilization and USRP2
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] RF Gain and BB gain of XCVR2450
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] howto module ... please help
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) 21 | 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: gr_block vector_source_f (1) sqr: gr_block square_ff (2) 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] understanding MUX registers
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: mailto:srbou...@nps.edu srbou...@nps.edu ___ 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
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] FM-Preemph block does nothing..
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
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 path-to-tarball 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] Re: unable to compile firmware with microblaze
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
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] remark on custom block + python behavior on Beagleboard
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] GR Block Input Item Size
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: gr_block lfm_demod_cf (8) 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] RAM consumption
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] RAM consumption
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] help to compile gnuradio
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] Gnuradio Mode S project released
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] More on latency
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] More on latency
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] Questions on multiple outputs and produce()
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] shmat issue
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] Moon Bounce Experiment
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 type '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] Error when installing Boost
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] shmat issue
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
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
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 ---BeginMessage--- 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] RX Mux value with dissimilar d'cards, USRP1
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] Stopping the UHD
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] Same File Size
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] Optimal way of performing multiple FFTs on a stream of data
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] How to balance workload among cores? Laptop cannot keep up with the USRP2 data flow.
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] Debugging environment variables
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] UHD Announcement - September 23rd 2010
On Sun, Sep 26, 2010 at 09:40:58AM -0400, Tom Rondeau wrote:
On Sat, Sep 25, 2010 at 6:23 PM, Josh Blum j...@joshknows.com 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
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_component_name.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_component_name.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] UHD Announcement - September 23rd 2010
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_component_name.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_component_name.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
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
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 X.
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] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?
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 module 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
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
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
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
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 RD. 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
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.
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] Flowgraph running in fits and starts
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 mle...@ripnet.com 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] Flowgraph running in fits and starts
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] GRC's graphical sinks performance issues
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] use of a bulletin board system in lieu of a mailing-list discussion
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 + whatever I care about 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?
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
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] Gnuradio website
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] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration
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] OFDM modulator and pilots
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] Souce Block
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] Changing four parallel pipes of ADC's into two parallel pipes of ADC's(having interleaved IQ as in the case of DAC's)
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] Gnuradio-3.3.0 on Ubuntu-10.04
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] Gnuradio-3.3.0 on Ubuntu-10.04
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 module from gnuradio import audio File /usr/lib/python2.6/dist-packages/gnuradio/audio.py, line 88, in module __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] Peak detector block does not really work. It need to be fixed
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 stadtwald...@yahoo.de 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
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
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?
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
On Fri, Aug 13, 2010 at 09:59:20PM +0400, Elvis Dowson wrote: Hi Eric, Before I dive into it, I just have a quick question. Why is it that others are not encountering the same issue? The same example code was run on a Mac Pro dual quad machine belonging to another member of this forum, and he didn't face the issue of crackling and distorted audio with the audio sink. There has been the problem with the two clocks since the code was written. The symptoms and how bad they are depend on how far the clocks are apart, and which one's fast wrt to the other. Anyway, I guess from a logical stand-point if the wave file sink writes to the file correctly, then the data is coming in correctly, and its only the real-time rendering of the audio using the alsa audio sink that's not working correctly. Perhaps. You're on a VM right? As I mentioned above, I believe the problem is the two clock problem. Still, I wonder what the difference could be, it working consistently for others, but not for me. Best regards, Elvis Dowson ___ 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
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
Re: [Discuss-gnuradio] Build failing, any ideas?
On Mon, Aug 16, 2010 at 09:49:21AM +0200, Moritz Fischer wrote: Hi List, I have been trying for a considerable amount of time now to build either 3.3.0 stable or 3.3.1git and always fail at this point: http://pastebin.com/ss7c356x I noticed while googling around that someone pasted a (as it seems to me) similar error a while before under: http://pastebin.com/7nB0DbEh but I could not find the corresponding message to the list. I'm using Boost 1.43.1 with gcc 4.5.1 on amd64 and my configure line looks like: ./configure --prefix=/usr --with-boost-thread=mt --with-boost-program-options=mt All the best and thanks for your help (again), Moritz The bug is fixed in the master, maint and next git branches. Also, there shouldn't be a need to specify the --with-boost-thread and --with-boost-program-options options. 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
On Fri, Aug 13, 2010 at 03:47:12AM +0400, Elvis Dowson wrote: Hi Eric, I came across an old thread, http://www.ruby-forum.com/topic/107228 There is a general issue related to the fact that when using usrp_wfm_rcv and similar applications that there are in fact two clock domains, and that they are guaranteed not to match. There's an osc on the USRP and an osc associated with the sound card. We made an API change in the audio interfaces that can specify that it's NOT OK to block when accessing the audio interface. When used in a flow graph that contained both an audio sink or source and a USRP sink or source, this would result in the USRP being the master clock, and would dodge the two clocks problem. Although the parameter was added to all (most) audio interfaces, I believe that it currently only works on the portaudio interface. Please feel free to fix this for gr-audio-alsa, gr-audio-oss and gr-audio-osx. This could potentially explain the issue I have, with distorted and crackling audio. It might also explain the nearly un-reproduceable random behaviour when it sometimes works giving clear audio output (so far has happened only 4 times in 6 weeks, approx 16 hours a day). How would one go about fixing this for gr-audio-alsa? Perhaps if you can give me some high level tips and pointers, I could try to make the changes. Thanks for being willing to take a look at this! First off, you'd need to read the docs on ALSA and understand the interfaces that are available to work with. I think that fixing it in audio_alsa_sink should be enough. Once the sink is working you could go after the source if you like. Given the interfaces exported by ALSA, you'd need to figure out how to honor the condition ok_to_block == False. There are two cases. (1) audio clock is slower than usrp clock (2) audio clock is faster than usrp clock In (1) you'll want to avoid an ever growing queue of samples by somehow giving the driver samples when it wants them, but dropping the excess samples (hopefull in a way that nobody notices) every now and then. In (2) you'll need to insert an extra sample every now and then to keep the audio from underruning. It's been a long while since I looked at the ALSA docs, but there may be some kind of callback that you can arrange for the ALSA code to call when it needs (or provides) samples. Right now we just naively block when reading or writing. You may want to look at audio_portaudio_sink. It's got at least partial support for this feature, although the interface to the driver will be different than ALSA. 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
On Thu, Aug 12, 2010 at 09:29:35PM +0400, Elvis Dowson wrote: Hi, Would anyone happen to have an idea where I should start looking, in order to debug the audio under-runs for the audio sink? Does the dial_tone.py example sound OK? Eric Best regards, Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Inband firmware questions
On Thu, Aug 12, 2010 at 09:51:31AM -0600, Eric Schneider wrote: On Thu, 2010-08-12 at 17:14 +0200, Sylvain Munaut wrote: Mmm, in the code I've read, the tx timestamp counter was different than the rx timestamp counter and with different reset signals. This is all from memory... There were two clocks, but the resets should have been tied together. If the tx and rx clocks were not synchronized that would defeat the whole point... I do remember experimenting with a single counter. I do not remember if I ended up using 1 or 2 though. I do recall that timing was harder to meet with a single clock. I'm looking at git://git.ettus.com/ettus/fpga.git which AFAIK it the most 'official' repo I could find. I think that one is broken. In which git is that code ? And more importantly, why isn't it in the main repo :) It was in the old svn repo. It seems to have been migrated to git: http://gnuradio.org/cgit/ets.git/tree/usrp/fpga/inband_lib?h=inband I'm not sure why it didn't merge into master. Probably because there is not much use or interest in it. Actually, I think it was because we weren't sure it worked and/or that there was no test code, and/or nobody said, hey it really works! It would be great to get it integrated somehow, since I know that Eric fixed many problems. The main-line usrp source is now hosted by Ettus, so we will have to work with them to make anything official. As I'd like the inband function to become mainline in the future UHD support, I think it's important to make sure the code is pushed. There was some recent chat about that... --Eric S. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
