[USRP-users] UHD command delay is different in the first recv stream

Michael West michael.west at ettus.com
Mon Oct 19 15:00:32 EDT 2015


Hi Dario,

I wanted to follow up and let you know that we have filed a bug against UHD
on the issue, but we have not yet determined the root cause.  At first
glance, it appears to be an issue somewhere in the FPGA.  Until a root
cause can be determined and the issue resolved, a simple workaround is to
receive and discard a small burst and then at least you would have a
consistent and predictable delay.

Regards,
Michael

On Tue, Oct 6, 2015 at 4:26 PM, Michael West <michael.west at ettus.com> wrote:

> Hi Dario,
>
> Very interesting find.  I have found that changes to either the master
> clock rate or sample rate affect the delay, but the delays are constant for
> a given master clock rate and sample rate.  It looks like an FPGA issue of
> some sort and it will take a deeper dive into the FPGA code to resolve.  We
> will look into it.  Let me know if you notice any other correlations that
> may help identify the root cause.
>
> Regards,
> Michael
>
> On Mon, Oct 5, 2015 at 12:57 PM, Dario Fertonani via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> I brought this up when UHD 3.9.0 was released, in a thread with a
>> different main topic (CODED loopback issue on B210). I thought I'd open a
>> specific thread, now that the issue is present in UHD 3.9.1.
>>
>> Let's call "UHD command delay" the difference between the time stamp of
>> the first sample received and the time stamp of that sample as requested by
>> the recv stream command (see attached code). Until UHD 3.8.5, this delay
>> was constant within an error well below a microsecond. Starting with UHD
>> 3.9.0, this delay is much grater for the first run (off by several us
>> w.r.t. the next runs). This is not an issue for me, as long as I can assume
>> that what I measure for the second stream is good (within a fraction of a
>> us) for all following streams, which seems to be the case. We have been
>> making this assumption and discarding the first stream from the LTE
>> processing (we open/close streams every few tens of seconds).
>>
>> The absolute values depend on the sampling rate. See below the output of
>> a run at 4 MHz sampling rate.
>>
>> Thanks,
>> Dario
>>
>> $ g++ rxTest.cpp -o rxTest -std=c++11 -O3 -luhd
>> $ ./rxTest 739 4 1 1000 128 3 > /dev/null
>>
>> Run #0 completed without errors!
>> UHD command delay measured at 9625 ns.
>>
>>
>> Run #1 completed without errors!
>> UHD command delay measured at 3750 ns.
>>
>>
>> Run #2 completed without errors!
>> UHD command delay measured at 3750 ns.
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151019/907c66d0/attachment-0002.html>


More information about the USRP-users mailing list