# PFB Arbitrary Resampler

**URL:** <https://www.ruby-forum.com/t/pfb-arbitrary-resampler/236875>\
**Category:** GNU Radio\
**Created:** [October 9, 2013, 12:55am UTC](https://www.ruby-forum.com/t/pfb-arbitrary-resampler/236875 "2013-10-09T00:55:56Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [October 9, 2013, 12:55am UTC](https://www.ruby-forum.com/t/pfb-arbitrary-resampler/236875/1 "2013-10-09T00:55:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\
**Post date:** [October 9, 2013, 1:08am UTC](https://www.ruby-forum.com/t/pfb-arbitrary-resampler/236875/2 "2013-10-09T01:08:13Z")

</div>

On Tue, Oct 8, 2013 at 6:54 PM, Nowlan, Sean  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> 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