|
| From: | Dave Gotwisner |
| 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 17:24:18 -0700 |
| User-agent: | 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"> <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
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> <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 doessomething similar to what you are doing.
Eric
Thanks, Dave
| [Prev in Thread] | Current Thread | [Next in Thread] |