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: ematlis
Subject: Re: [Discuss-gnuradio] saturation with multi_fft.py
Date: Wed, 10 Oct 2007 16:54:10 -0400 (EDT)

Well, this seems logical, and if so then we've finally stumbled on the point of the matter. So what's the fix? Is it a simple matter of extending the "definitions" to other decimations in the file Brian cites?

thanks Brian and Eric,

eric

On Wed, 10 Oct 2007, Brian Padalino wrote:

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]