discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] PFB Arbitrary Resampler


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] PFB Arbitrary Resampler
Date: Tue, 8 Oct 2013 19:06:23 -0400

On Tue, Oct 8, 2013 at 6:54 PM, Nowlan, Sean
<address@hidden> wrote:
> In the benchmark_tx.py code for MPSK modulation, the pfb_arbitrary_resampler
> block is instantiated with 32 * 11 * floor(samples_per_symbol) taps. I
> understand that 32 is the number of filters in the filterbank, but I’m not
> sure what motivates the factor of 11. Has anybody been able to fine tune
> these numbers to improve performance of the resampling filter, e.g.,
> reducing the number of taps?
>
>
>
> Thanks,
>
> Sean

Good, undocumented, question.

As you say, the 32 comes from the number of filters. We're going to
create a large set of taps and distributed them over the N number of
filters. So each filter will have 11*sps taps in it.

Because we're using a non-Nyquist filter (the RRC), we are introducing
memory into our system. Ideally, these filters go from minus to plus
infinity. But we want to truncate it to a number that's practical, so
we have to make some assumption about how far away is good enough that
the effects of the symbol M samples away is too small to care. We (I
think Eric originally; before my time at least) came up with 11.

I've heard 7 is also a good number for this. It's likely that we could
calculate a good number based on the quantization effects we'll be
dealing with later in the hardware. I /think/ that if we figure out
what's the most amount of noise the filter can possibly add to a
symbol M samples away and make sure that that is just about the same
as the quantization noise. If it's the same or less, it should be ok
to use. If it's more, we might be introducing more ISI into our
system.

We assume, of course, a matched filter with the same channel length
will correct for this ISI at the receiver, but other channel
conditions may affect this assumption.

The 11 is probably more than necessary but also in a sense 'safe' to use.

Tom



reply via email to

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