[Top][All Lists]
[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,
|
From: |
Eric Blossom |
|
Subject: |
Re: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and reading after stop always returns > 0 bytes |
|
Date: |
Sat, 26 May 2007 14:25:30 -0700 |
|
User-agent: |
Mutt/1.5.9i |
Admin note: please don't post HTML to the list. Thanks.
On Fri, May 25, 2007 at 04:23:29PM -0700, Dave Gotwisner wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <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
> processing.<br>
> <br>
> 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
> data).<br>
> <br>
> 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. I
> 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
> 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>
> <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>
> <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>
> <br>
> Thanks,<br>
> <br>
> Dave<br>
> </body>
> </html>
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.
Eric