<div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>The absolute values depend on the sampling rate. See below the output of a run at 4 MHz sampling rate.¬†</div><div><br></div><div>Thanks,</div><div>Dario</div><div><br></div><div><div>$ g++ rxTest.cpp -o rxTest -std=c++11 -O3 -luhd</div><div>$ ./rxTest 739 4 1 1000 128 3 > /dev/null¬†</div><div><br></div><div>Run #0 completed without errors!</div><div>UHD command delay measured at <font color="#ff0000">9625</font> ns.</div><div><br></div><div><br></div><div>Run #1 completed without errors!</div><div>UHD command delay measured at <font color="#ff0000">3750</font> ns.</div><div><br></div><div><br></div><div>Run #2 completed without errors!</div><div>UHD command delay measured at <font color="#ff0000">3750</font> ns.</div><div><br></div><div><br></div><div><br><div><div><br></div></div></div></div></div>