[USRP-users] B210 -- various questions on sampling/clock rates

Rob Heig robhhh6 at gmail.com
Wed Oct 25 01:58:26 EDT 2017


I am experimenting a bit with the B210 board and I have a couple of
questions concerning sampling/clock rates:

- is it normal that, on a decent modern PC with plenty of cores, memory,
and working on a SSD, a simple program that dumps I/Q data on file gives
more often than not overflows ("OOOO" messages from UHD) starting at around
40Msps (sometimes, with a very lightweight charge of the CPU, even at
10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
anything's wrong, and it seems that from time to time the transmission
simply stops and gets reset after a few seconds (meaning that the board's
buffers overflowed, I guess), but I couldn't find a reason why this
happens. I have asked a colleague to increase the size of the buffers on
the FPGA, but that improved the situation only slightly... Is there any
architectural documentation explaining the behavior of UHD with a USB
device to see where the bottleneck could be (without having to delve into
the UHD code)?

- playing with filters I saw that, when the sampling rate is set below
16Msps, the clock rate is set at a multiple of the desired sampling rate
(for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
it only after having spent a whole morning wondering why a custom FIR
filter that was supposed to work nicely at 8Msps was not filtering at all
(I guess the messages printed on the console are there for a reason....
;)). What is the reason behind this choice? Is it imposed by the RFIC (I
couldn't find anything on the reference manual, but I might be
mistaken....) or by the board design? What is the rule that governs the
choice of the clock rate? Is there any documentation about it?

Thanks a lot in advance and have a nice day!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/1caf4924/attachment-0002.html>

More information about the USRP-users mailing list