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

Dario Fertonani dario.fertonani at gmail.com
Mon Oct 5 15:57:58 EDT 2015


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151005/85c4c2ca/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rxTest.cpp
Type: text/x-c++src
Size: 4789 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151005/85c4c2ca/attachment.cpp>


More information about the USRP-users mailing list