[USRP-users] Filling gaps resulting from overruns, issue with (probably) power saving in USRP B210

Ian Buckley ianb at ionconcepts.com
Tue Mar 29 15:29:16 EDT 2016

To briefly answer various questions you have posed:

meta_data (aka timestamps/rx_time) is created using what is in Ettus
terminology the "dsp clock". The dsp clock is synonymous with the
master_clock_rate. A counter free run's on this clock, incrementing by one
every clock cycle, and it is from this counter that meta_data is created to
timestamp various events and packets. Now when the sample rate <
master_clock_rate, then this counter increments a number of times between
each sample being emitted from the output of the RX DSP logic that is
decimating the signal. It's important to understand that the dsp clock
drives all the DSP logic as well as the packetization logic, the sample
"clock" is merely a measure of data throughout (That's an integer fraction
of the dsp clock) , it doesn't exist in the sense of a real clock signal in
the H/W.

Thus when UHD sends control packets that write internal USRP registers that
enable the DSP to start operation, it starts either asynchronously on the
next dsp_clock edge after executing the control packet that arrived with
best effort through the transport, or it starts synchronously if the
control packet included synchronizing metadata that is compared against the
counter to delay its execution.

Now to understand how streaming stop's when an overflow event occurs,
consider the packet transport between the DSP and the UHD host as a series
of FIFO's. If the UHD host stops accepting data because of upstream
application events (such as a file system/disk issue in your case) then
those FIFO's start filling up in order, from egress point at the Host to
ingress point at the DSP. When the last FIFO is filled then the DSP must
immediately reset into an idle state because it has no further place to
store packetized sample data, nor any way to influence the downstream
application level problem. Thus as the DSP goes idle, it dispatches a
status packet to the host indicating an overflow event with accompanying
meta data including exactly when this condition occurred, and the last
packetized sampled data remains stalled in the USPR's FIFO's and drains out
as the back pressure eases from the Host at some time in the future. At
some point in the future UHD sends new control packets to the RX DSP to
resume streaming once the buffer overflow has resolved. When those commands
are executed is a function of many things including the actual cause of the
overflow and transport delays, but should be regarded as "ASAP". There is
no attempt to match the phase of the previous "sample clock" w.r.t the dsp
clock (nor previous CORDIC phase)

Note, at no point in this chain of event is there any requirement to make
programming changes to the radio (AFE + ADC)...samples arriving at an idle
RX DSP are simply dropped in the ground.

When the RX DSP goes idle, various decimating filters and the CORDIC
(including NCO phase) enter a reset state, and samples need to propagate
through the pipeline after a restart (hence the amplitude growth you

Operation of the LED's is controlled by the state of the RX (and TX) DSP.


On Tue, Mar 29, 2016 at 10:45 AM, Piotr Krysik via USRP-users <
usrp-users at lists.ettus.com> wrote:

> W dniu 29.03.2016 o 17:36, Sylvain Munaut pisze:
> >> Nobody is answering so maybe I'll ask a shorter question:
> >>
> >> There is a mechanism in the B210 FPGA that is turning off receiving
> >> chain when nothing is streamed to the PC. It is also turning off the
> >> receiving chain on any buffer overrun in the USRP and this isn't a
> >> feature but a bug.
> > I never heard of such a mechanism and it would be non-trivial to
> > implement so I somehow doubt it exists because I don't see why would
> > anyone have ever taken the time to implement that given there is no
> > advantages to it anyway ...
> >
> >
> > Cheers,
> >
> >     Sylvain
> >
> Hi,
> In the previous e-mail I have pointed few indicators that there is such
> mechanism (like amplitude changes after each buffer overrun, when
> recorded was GSM signal). For the next proof that it is the case look at
> the video:
> https://youtu.be/8pkpijfyq2c
> With each overrun there is correlated turning off of a LED corresponding
> to the receiving chain (it indicates that the receiver is working).
> Best Regards,
> Piotr Krysik
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160329/c21b8004/attachment-0002.html>

More information about the USRP-users mailing list