On Mon, Nov 13, 2006 at 05:03:17PM -0800, Thomas Schmid wrote: > I am currently investigating different USRP delays. Some of them I can > explain, others not. For example, I see an average delay of 6.2ms > while receiving data from the USRP at a sample rate of 8MHz (short > real samples, i.e. I am using the usrp.source_s).
With usrp.souce_s, you still get 16-bit I & Q, they're just interleaved in the single stream. This may be the cause of some confusion. Thus, if you set decim == 8, you'll be getting 8 MS/s complex across the USB. This is 32MB/sec == 16 M shorts/sec. > Here is my setup: > - I have a function generator which generates a 1Hz square wave. This > signal is fed into a LFRX on the USRP and into CH1 of an oscilloscope. > - On the PC side, I modified the null sink to check for a pos/neg > signal (with some thresholding). When the signal is high, I output 1 > on the parallel port, when it is low, I output 0. The parallel port is > also hooked up to the Oscilloscope. This allows me to measure the > delay between the two signals. > - I usefusb_block_size=512, fusb_nblocks=1 I suspect that you are getting overruns with this configuration. You're not saying anything about this, but I doubt it's going to work well with fusb_nblocks = 1. Try running it with fusb_nblocks = 4. At the high data rates, this still isn't a reliable rate on my Core Duo laptop. > Here are some numbers I got: > - decimation 8: mean delay 6.1ms > - decimation 32: mean delay 6.4ms > - decimation 64: mean delay 4.3ms > - decimation 256: mean delay 14.7ms Have you logged the received data to a file? Remember, you're not getting "real" samples. You're getting interleaved I & Q. > First of all, I don't understand why we have such a high delay. > Shouldn't it be more in the hundreds of /mu s instead of in the ms > range? Yes, at the high input rates. > Second, why is the delay shorter for decimation 64, and again > larger for a decimation of 256? Underruns and/or incorrect examination of the incoming data? Also, the received data (and transmitted data too) is "quad buffered" in the FX2, so there's a maximum of 4 512-byte buffers between you and the data on the receive path. This could be reduced without much trouble to "double buffered". But I don't think this is really the problem. With the quad buffered case and decim = 8, the most data that could be buffered in the FX2 is 4*512 = 2048 --> 2048/32e6 = 64 us worth. Right now I'm looking at how the received data buffering is done in the usrp and gr-usrp code. Looks like there may be a problem/opportunity in the usrp1_source_base.cc. I'll get back to you with more info in a bit... Thanks for going to the trouble of making the measurements! Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
