[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.&nbsp; I
> then do read() until I get the requested number of samples.&nbsp; 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).&nbsp; The decim rate used for the usrp_standard_rx constructor is 
> 8.&nbsp; 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.&nbsp; Drilling down, into
> the usrp_basic_rx::stop() command, we spend 6 seconds in
> d_ephandle-&gt;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&nbsp;
> fusb_devhandle_linux::_reap.&nbsp; 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).&nbsp; 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.&nbsp; 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?&nbsp; Is anyone else trying to use libusrp in a similar manner?<br>
> <br>
> Thanks,<br>
> <br>
> &nbsp;&nbsp;&nbsp; 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]