<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The problem has disappeared after the last "UHD maint" update. Also, we changed our code so that zeros are transmitted when we have nothing to send in a slot (earlier we just didn't call "send" for that slot). Which of the two fixed the problem is not clear.</div><div>I'm still going to reply to the pending questions below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    You description sounds like continuous transmission--if that's the
    case, then why not just use continuous streaming?<br></div></blockquote><div><br></div><div>Yes, that is the case. We would want continuous transmission and continuous reception. The reception part goes well, since an explicit "continuous" stream command is available and errors are returned when continuity isn't achieved. I would like to use the same strategy at the transmit side, setting the start of transmission time and then going continuously from there. However, I can't find the API for doing that. I can get something close to that by setting the has_time_spec to false after the first packet, but the documentation says that this transmits "ASAP", which I interpreted as "if you want a specific time, just use has_time_spec=true always", since we really can't have "holes", or worse "holes" that accumulate over time causing a drift between transmission and reception. If my interpretation of the API is wrong please correct me. Currently, to achieve continuous full-duplex streams, we run "continuous" reception and "timed" transmission (has_time_spec always true) with self-incrementing time_spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Also, "L" means 'late', which means that by the time the USRP went
    to send the frame of samples, the time given in the header has
    already passed.<br>
      If you're you're doing very-tight timing, not accounting for
    average latency through the stack, and you're getting underruns, I
    can imagine things<br>
      starting to go badly off the rails.  My suggestion would be to,
    when you get an 'L' or 'U' indication, hold-off on transmitting for
    a while, and restart<br>
      your stream several time-slots into the future.<br></div></blockquote><div><br></div><div>That is essentially what we do. There is a tradeoff on how early to send the future packet (too soon doesn't allow time to "prepare" the future packet, too late causes L/U errors). Hence, we go aggressively late while capturing things that go wrong.</div><div><br></div><div>Thanks,</div><div>Dario</div><div> </div></div></div></div>