[USRP-users] Timed transmission after U/L errors

Dario Fertonani dario.fertonani at gmail.com
Thu Apr 23 11:35:46 EDT 2015


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.
I'm still going to reply to the pending questions below.


> You description sounds like continuous transmission--if that's the case,
> then why not just use continuous streaming?
>

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.


> 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.
>   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
>   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
>   your stream several time-slots into the future.
>

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.

Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150423/870fac95/attachment-0002.html>


More information about the USRP-users mailing list