[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time,
Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and reading after stop always returns > 0 bytes
Sat, 26 May 2007 17:24:18 -0700
Mozilla Thunderbird 1.0.7 (Windows/20050923)
Eric Blossom wrote:
Admin note: please don't post HTML to the list. Thanks.
Sorry, hope this is better. I should have caught that before sending.
My preference was to use the default settings, which the documentation
indicated should be sufficient. When we got overruns, and before
looking into the stop() not working, I bumped the values as a test.
On Fri, May 25, 2007 at 04:23:29PM -0700, Dave Gotwisner wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
I am working on an application that will tune to multiple frequencies,
and capture a small number of samples at each frequency for further
The program loop, is essentially, a series of configuration commands
(such as set_rx_frequency, etc.), followed by a start() command. I
then do read() until I get the requested number of samples. I then do
a stop(), and for the hell of it, loop on a read (until there is no
For the purpose of the test, I am using the default buffer sizes for
the ::make call (I also tried fusbBlockSize == 1024 and fusbNblocks =
8K). The decim rate used for the usrp_standard_rx constructor is 8.
am trying to capture 100,000 samples at each frequency.<br>
There's absolutely no reason to be using fusb_nblocks == 8192.
Try using fusb_block_size = 4096 and fusb_nblocks = 16
No, we aren't using the GNU Radio code. We are using libusrp directly,
since the target platform for this work won't have Python. We are using
Gnuradio-3.0.3, and In looking at that directory, I don't see the
usrp_spectrum_sense.py program. I'll upload a more recent version of
gnu radio on Tuesday, and look for it then.
What I am observing is that it takes a very small fraction of a second
to get to my 100,000 samples (as expected), but when I do the stop(),
it is hanging in the stop() command for 8 seconds. Drilling down, into
the usrp_basic_rx::stop() command, we spend 6 seconds in
d_ephandle->stop(), where it is trying to free up 8189 URB requests
in fusb_devhandle::_cancel_pending_rqsts() [1 IOCTL per
USBDEVFS_DISCARDURB call] and 2 seconds in
fusb_devhandle_linux::_reap. A capture that takes approximately 1/16
of a second shouldn't then take 8 seconds closing itself out.<br>
The second observation, is that I loop forever (30 minutes before I
gave up) after doing the stop, where read() is still returning data
(valid or not, I don't know). I would expect that stop() should flush
any data, or at least, prevent any new data from coming into the
system, but this doesn't appear to be the case. Given my application,
I must tie the data for each sample to a specific frequency, so
guaranteeing that the first (through last) reads for any tuning
operation all apply to that tuning operation.<br>
Is something broke, or (as is more likely the case), am I missing
something? Is anyone else trying to use libusrp in a similar manner?<br>
In the GNU Radio code, which you don't appear to be using, we have
gnuradio-examples/python/usrp/usrp_spectrum_sense.py, which does
something similar to what you are doing.