USRP decimation range change while upgrading from gnuradio 3.1.2 to 3.2.2

I have been using the USRP and gnuradio version 3.1.2 to run the
back-end of a 4 channel UHF radio for about a year. I use the
std_4rx_0tx.rbf firmware and decimate by 250 to give me a 256 kHz
bandwidth. I recently upgraded to gnuradio version 3.2.2 to begin a
similar project. In this version I can only decimate up to 128 in the

Does this mean that the halfband filter is no longer implemented in the
firmware, or that it was never implemented and the decimation done
previously was erroneous (could contain aliased signals)?

Additionally some of the function calls for the usrp, such as nddc() and
nduc(), have been changed, to nddcs() and nducs(). Is there a
compatibility issue from the old usage to the new or was this a
stylistic change?

Thank you,
Todd Borrowman

Hi Todd

I had a look at convig.vh which determines what gets included with
different fpga firmware builds. It seems as if the 4 receiver, 0
transmitter version only uses CIC filters and no halfband filters
which explains why you should only be able to decimate by 128.

I don’t know what happened previously where you decimated by 250. The
low level C code which writes the FPGA registers checks whether the
build includes HB filters. If there are some, you are able to
decimate by up to 256. If there aren’t any, an exception should be
thrown when the decimation rate is above 128. In your case this
didn’t happen. This is all I know about your problem. Hopefully it
helps a bit. This from

usrp_standard_rx::set_decim_rate(unsigned int rate)
if (has_rx_halfband()){
if ((rate & 0x1) || rate < 4 || rate > 256){
fprintf (stderr, “usrp_standard_rx::set_decim_rate: rate must be
EVEN and in [4, 256]\n”);
return false;
else {
if (rate < 4 || rate > 128){
fprintf (stderr, “usrp_standard_rx::set_decim_rate: rate must be
in [4, 128]\n”);
return false;


Sebastiaan H.
Radar Remote Sensing Group, University of Cape Town, South Africa
Tel: +27 83 305 5667