[USRP-users] Purpose of 24-bit CORDIC in DDC chain?

Ian Buckley ianb at ionconcepts.com
Thu Apr 4 11:31:51 EDT 2013

On Apr 4, 2013, at 1:00 AM, Florian Schlembach <florian.schlembach at tu-ilmenau.de> wrote:

> On 04/03/2013 05:40 PM, Johnathan Corgan wrote:
>> On Wed, Apr 3, 2013 at 4:48 AM, Florian Schlembach
>> <florian.schlembach at tu-ilmenau.de> wrote:
>>> It seems both HB filters are activated by the UHD interface (enable_hb1/2),
>>> how is the actual decimation rate fed to both decim_i and hb_i if both are
>>> fed through a common wire cic_decim_rate?
>>> Is the CIC then actually be activated using decim_rate with multiples of 4?
>> See the logic in the UHD host code:
>> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/rx_dsp_core_200.cpp#L170
>> ...to understand how the host code decides how the half-band filters
>> and CIC filter are configured.
> the code in rx_dsp_core_200 (l.174-185) is actually what I was wondering about. So far, I understood the logic that the first halfband decimates by a fixed factor and the second takes over the residual decimation of multiples of two, e.g. decim_rate=8->hb1->4->hb2->1, which is WRONG (I misunderstood the term second (large) hb which is actually related to the filter order of the second hb).
> In fact, the second half-band is only decimating by another factor of 2. Hence, the second HB2 serves the purpose of making the passband response more linear and further suppresses aliasing spectral components implied by the decimation.
> I would now conclude with the following to sum this thread up for others ;-) :
> -CIC decimation filter is always activated
> -decim_rate equals 4: HB1 enabled, HB2 enabled, CIC-decim=1 (no decimation)
> -decim_rate equals 2 (not possible actually): HB1 enabled, HB2 disabled, CIC-decim=1
> -decim_rate multiple of 4: HB1 enabled, HB2 enabled, CIC-decim=decim_rate/4
> -decim_rate multiple of 2: HB1 enabled, HB2 disabled, CIC-decim=decim_rate/2
> Hence, decim_rate should always be of multiples of four, otherwise you will get a poor roll-off. Further decimation should take place in software.
> Please correct me if I am wrong.
That's a perfectly accurate summary.

More information about the USRP-users mailing list