Re: [Discuss-gnuradio] AWAL root raised cosine filter in the GRC trunk?

[Johnathan Corgan]

On Fri, Dec 12, 2008 at 2:42 PM, Glenn Richardson <address@hidden> wrote:

> Our transmit chain indeed follows this exact pattern.  The RRC was/is used
> to shape the data stream, and then we resampled in a second block.
>
> I would be interested to measure the performance gain by eliminating the
> extra block(s).  (There is a constant gain block as well, to bring the level
> up to the USRP's expectations.)  However, I'm still back working on
> understanding how all these taps are "properly created".  :)

You can eliminate the constant gain block by scaling the RRC taps by
that much.  In fact, the RRC tap calculator has a gain parameter to do
just that.

To "properly" calculate the RRC taps, you have to understand how the
polyphase rational resampler works.  First the incoming sample stream
is zero-stuffed by the interpolation rate, then this sample stream
goes into a polyphase FIR filter that produces output samples at the
decimated output rate. However, the taps for the FIR filter need to be
calculated as if you weren't decimating the result; that is, at the
input data rate * the interpolation rate.  The filter doesn't actually
run at this possibly very high rate--it only operates to produce
samples at the output that wouldn't get thrown away by the decimation,

For example, let's say you have a 7 Mbps QPSK transmitter and the
USRP1.  At some point in the flowgraph, the item stream will be 3.5
Msps QPSK constellation points.   If you set the USRP interpolation to
16, then it expects an item stream at 8 Msps.  This can be achieved by
using a rational resampler that interpolates by 16 and decimates by 7.
 You would calculate the RRC taps assuming an input rate of 1
sample/symbol and sample rate of 16 samples/symbol.  From Python (the
formatting probably won't survive):

 taps = gr.firdes.root_raised_cosine(interp*amplitude, #gain
                                    interp,           # sample rate
                                    1.0,              # symbol rate
                                    excess_bw,        # excess
bandwidth
                                    interp*taps_per_sym) # ntaps

The gain parameter is calculated assuming the QPSK symbols have unity
values and overcome the interpolation loss as well.  Taps per symbol
is based on how many symbol periods you want to apply the RRC filter
kernel over.

Hope this makes things more clear.  The perfomance gain is
demonstrable--you are eliminating a FIR filter and multiplier block,
both of which are operating at the highest data rate in your
flowgraph.

-Johnathan