PFB Arbitrary Resampler

In the 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?


On Tue, Oct 8, 2013 at 6:54 PM, Nowlan, Sean
[email protected] wrote:


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

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


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs