[USRP-users] Timed transmission after U/L errors
mleech at ripnet.com
mleech at ripnet.com
Thu Apr 23 11:40:15 EDT 2015
Look at a simple example like tx_waveforms, or tx_samples_from_file.
They both use continuous transmission.
On 2015-04-23 11:35, Dario Fertonani wrote:
> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users