[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and

From: Dave Gotwisner
Subject: [Discuss-gnuradio] usrp_basic_rx::stop appears to take a long time, and reading after stop always returns > 0 bytes
Date: Fri, 25 May 2007 16:23:29 -0700
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

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.

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).

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.

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.

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.

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?



reply via email to

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