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

Marcus D. Leech mleech at ripnet.com
Wed Apr 22 12:06:59 EDT 2015


On 04/10/2015 02:18 PM, Dario Fertonani via USRP-users wrote:
> We are seeing a weird behavior that hints at a problem in recovering 
> from U/L transmit errors. I wonder if we are using the timed send API 
> and tx_metadata_t properly.
>
> We call send within a loop, so that every time the transmission is 
> timed and that the interval between two consecutive transmissions is 
> equal to the desired chunk duration. Essentially, all is done with
> txMetaData.time_spec += ChunkDuration_s;
> with the loop.
>
> All goes well until an error U/L occurs. Soon after that, a few chunks 
> later (1-3 ms), the transmit stream appears to be misaligned. Still 
> nice and strong, but not aligned with the original timing.
> All we want is that, after a packet doesn't get transmitted properly 
> (U/L errors), the stream can go on as if nothing happened. Any special 
> care that should be taken to achieve this behavior?
>
> Thanks,
> Dario
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
You description sounds like continuous transmission--if that's the case, 
then why not just use continuous streaming?

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150422/c91b7632/attachment-0002.html>


More information about the USRP-users mailing list