[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Large RX Delay
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Large RX Delay |
Date: |
Mon, 13 Nov 2006 21:01:35 -0800 |
User-agent: |
Mutt/1.5.9i |
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