Forum: GNU Radio AWAL root raised cosine filter in the GRC trunk?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3980c022386330e4fae18e33966fb566?d=identicon&s=25 Glenn Richardson (Guest)
on 2008-12-12 20:55
(Received via mailing list)
Where did the root_raised_cosine filter go?

I recently began exploring GRC in the svn trunk, and quickly realized
that the root_raised_cosine filter has gone missing.

Missing is perhaps too strong of word... the filter exists in the
gr_firdes general library, but isn't brought out to a GRC block of that
name that I can find.  Do I simply need to create a custom XML wrapper
for it, or is it hidden in another filter as an option?  I've begun to
edit my "custom" XML filter, but am second guessing myself now.  Is
there some other SDR black magic (math) that I don't know?  I'm new to
fairly gnuradio and still getting oriented to the source code.

Thanks in advance,
Glenn
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2008-12-12 22:48
(Received via mailing list)
See http://gnuradio.org/trac/wiki/GNURadioCompanion#FilterDesign

you have access to all the firdes function from inside grc. Just pick
out an FIR filter block, and enter firdes.root_raised_cosine(...) for
the taps parameter.

I made a few wrappers around the FIR filters for the pass band taps: low
pass, high pass... are all in grc. I could easily make another for the
root raised cosine FIR filter, so you dont have to type this firdes....
nonsense.

The issue is that there are a N blocks that take taps as a parameter,
and there are M taps generators, and it would be hell to make MxN
convenience wrappers for all of them.

However, I would like to make these convenience blocks for some of the
combinations. Would RRC FIR be useful? Any other suggestions for some
practical combinations?

-Josh
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-12 23:20
(Received via mailing list)
On Fri, Dec 12, 2008 at 1:47 PM, Josh Blum <josh@joshknows.com> wrote:

> However, I would like to make these convenience blocks for some of the
> combinations. Would RRC FIR be useful? Any other suggestions for some
> practical combinations?

A rational resampler that used RRC taps would be useful as a transmit
side RRC interpolator.

A common MPSK transmitter chain is to create a symbol stream at a
particular number of samples per symbol (related to your input data),
perform RRC filtering, then resample to meet the rate expected by the
USRP at some particular hardware interpolation rate.

You can economize CPU cycles by merging the RRC and resampling filter
stages, that is, by using properly calculated RRC taps in the place of
the resampler lowpass filter.

You could make a GRC wrapper for this.  Come to think of it, this
would be a good opportunity to make a hierarchical block for the blks2
namespace.

-Johnathan
3980c022386330e4fae18e33966fb566?d=identicon&s=25 Glenn Richardson (Guest)
on 2008-12-12 23:43
(Received via mailing list)
Johnathan Corgan wrote:
>
> A common MPSK transmitter chain is to create a symbol stream at a
> particular number of samples per symbol (related to your input data),
> perform RRC filtering, then resample to meet the rate expected by the
> USRP at some particular hardware interpolation rate.
>
> You can economize CPU cycles by merging the RRC and resampling filter
> stages, that is, by using properly calculated RRC taps in the place of
> the resampler lowpass filter.
>
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".  :)
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-13 00:25
(Received via mailing list)
On Fri, Dec 12, 2008 at 2:42 PM, Glenn Richardson <glenn@spacequest.com>
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
This topic is locked and can not be replied to.