On Mon, Nov 13, 2006 at 05:03:17PM -0800, Thomas S. 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
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
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!