Re: [Discuss-gnuradio] Large RX Delay

[Thomas Schmid]

Hi Eric,

On 11/13/06, Eric Blossom <address@hidden> wrote:
> 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.

Ah, yes that makes sense. I will take that into considerations and go
through my calculations again.

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

I have to check that. I put stderr into a different file to see my own
"debug" output. Might very well be that I get a lot of underruns.

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

No, I do not log the received data into a file. I record the wave
forms on the oscilloscope and do a post processing on them in octave.

> > 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?

I think now, after considering your response, that this might be the
problem. I will check both things tomorrow and do the measurements
again. Hopefully I will find smaller delays.

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

Thank you very much. I am looking forward to your response.

Thomas