On 03/03/2020 06:16 PM, Sam Reiter via USRP-users wrote:
Hey Francisco,
Interesting question. I remember reading this when it was initially
posted, giving it some thought, and promptly forgetting to respond.
It's a question that is difficult to give a "yes" or "no" to. Similar
to statistics, I think the answer to this question only comes by
disproving the null hypothesis that "no part of the signal chain is
damaged with an underflow". If you can't prove that damage will occur,
then you're probably in the clear, but you also can't be positive that
the null hypothesis is true. That being said, I don't think underflows
are bad for the hardware in any way.
An underflow is typically caused when a bottleneck on the host side
prevents data from filling USRP buffers quickly enough to be pushed
through the DAC at the requested rate. As I see it, the only place in
the signal chain that /might/ exhibit unexpected behavior in the face
of samples not being present would be at the DAC (don't ask me why,
but that would be my best guess). The way UHD operates, the DAC and
ADC are initialized and running as soon as the streamer objects in UHD
are initialized, and they sit there processing nothing (similar to an
underflow state) until a TX stream command from the host tells the
USRP radio core to release it's queued samples to the converter(s).
Maybe that was all nonsense. In any case, I wouldn't worry about radio
damage, I'd worry about fixing your underflows :)
Best,
Sam Reiter
I'd have to agree with Sam here.
An underflow on the TX will just mean that whatever the DAC last saw
will be presented to the analog interface during the underflow period.
Which means perhaps a few microseconds of no level change coming out
of the DAC. Not a problem at all, as far as I know.
The main thing is to optimize your code/computer-hardware to prevent them.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
