Re: [Discuss-gnuradio] USRP Delay Measurements

[Eric Blossom]

On Wed, Nov 08, 2006 at 03:14:01PM -0800, Thomas Schmid wrote:
> On 11/8/06, Eric Blossom <address@hidden> wrote:
>
> >Have you tried explicity setting the fast usb buffering?
> >Take a look at the examples in gnuradio-examples/python/digital/*.py
> 
> I set the fusb buffering for the square wave test, additional to
> setting real time scheduling. The result is similar. For different
> decimation factors I get delays. What I didn't notice before is the
> following: Now, the delay increases with higher decimation factor and
> it looks almost linear, i.e., if I double the decimation factor, the
> delay increases by a factor of two. Does that make sense?

Absolutely ;)

In your test case the ultimate flow control is the speed of transfer
across the USB.  This is determined by the decimation factor.  The
siggen block is going to run as fast as it can and *WILL* fill up all
available buffering downstream from it.  If your test case is a
gr.sig_source followed by the USRP, I would expect that the runtime
system would have allocated 32kB of buffering between the sig_source
and the usrp sink.

          
          gr_complex
  32kB  * ---------- = 4096 complex samples
           8 bytes

That's the buffering between the sig_source output and the usrp input.

That amount is constant (and known).  Note that if the sig_source
wasn't flow controlled by the usrp consumption rate, the buffer would
not be full.

So, you've got a 4096 sample fixed delay (probably actually 4095)
between the output of the sig_source.  You know your data rate across
the USB, and thus can subtract off the constant delay.

Also, the usrp.sink_c sets it's output_multiple to 128 samples, so it's
always going to wait until there's at least 128 complex samples
available before it runs (that's 1 full USB packet).

> I don't really understand that behavior, since I assumed that the
> delay should be constant.

It is, in samples.  Hope this helps.

Note that if you're not flow controlled (the typical
case with discontinuous transmission), you'll get a better measure.
You could test this with a source that returned 0 for noutput items,
except that every N seconds, it toggled the parallel port lines and
then produced its burst of output.

You'll want to be sure to calibrate out the time to wiggle to parallel
port lines.  I'm assuming you're doing it with a direct iob to the
parallel port control or data registers.

Eric