discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] saturation with multi_fft.py


From: Brian Padalino
Subject: Re: [Discuss-gnuradio] saturation with multi_fft.py
Date: Wed, 10 Oct 2007 16:44:13 -0400

On 10/10/07, address@hidden <address@hidden> wrote:
> Can you give me an example?  I've never worked with verilog code before.
>
> Also-  this fix you are proposing- is it a simple scaling of gain that
> would be independent of decimation?  Because as you can see from the
> following figure, the amplitudes scale directly with the decimation for
> values above 128 on the 4 rcv rbf.
>
> www.nd.edu/~ematlis/z.gnuradio/Amplitude_vs_decimation.jpg
>
> Both rbf's produce a flat response below 128 decimation; greater than this
> is where the change occurs.  The standard half-band rbf does have a couple
> of dips but is basically flat.

A question I can answer!  If you would take a look here:

    
http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/cic_dec_shifter.v

The CIC filter has some bit-growth associated based on your decimation
rate.  This growth is deifned for decimations up to 128 in that file.
It basically takes a different "slice" of the CIC "comb" section at
the end.

The reason it might be happening in the FPGA that doesn't have the
halfband filter is because the halfband filter also decimates by 2 -
so you would need 1/2 the decimation by the CIC.  So for cases where
you would normally decimate by 192, the CIC is decimating by 96 and
the halfband by 2.  In the case where there is no halfband, the CIC
takes on all the responsibility and the extra growth is not accounted
for.

If this was defined for values larger than 128, then the growth
wouldn't happen and it could all be alleviated in the FPGA.  Hopefully
this makes sense to everyone.

Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]