On Tue, Sep 6, 2011 at 2:25 PM, Ryan Pape
<address@hidden> wrote:
On Mon, Sep 5, 2011 at 11:55 AM, Tom Rondeau
<address@hidden> wrote:
On Sun, Sep 4, 2011 at 11:33 AM, Ryan Pape
<address@hidden> wrote:
We are successfully using the PFB filterbank to channelize 1-6mhz into a variety of channel widths (25K, 50K etc).
In one application, we have 25K channels which are then resampled using PFB resampler to 19.2K fed into gmsk_demod @ 9600bps with 2sps.
In this case, we may have 20-40 ports "active" (not null sink) with pfb resamplers connected to each.
Is there way to perform this resampling in the filterbank to avoid the need for many separate resampler blocks in an effort to improve performance?
We are pushing the limits of hardware already, so any efficiencies are helpful. We will consider a hierarchical filterbank structure if necessary, but our first goal is to do it with one filterbank, if possible.
Ryan,
What you are talking about is possible, but not with the current implementation of the GNU Radio channelizer. fred harris has recently published a few papers on doing arbitrary channel / arbitrary bandwidth channelizers that should meet your needs, but it would have to be programmed up.
Now, that having been said, there is a way to handle this. If you have a 9600 bps signal in a 25 ksps channel, you can switch to using the gr_pfb_clock_resampler_fff block, which allows you to specify a real number for the number of samples per symbol (2.6042 in this case) instead of integers. That should do the trick.
Tom,
Thank you.
To be clear I'm not looking for arbitrary channel size channelizer, when I said 25K/50K etc, I was just referring to the fact that we are using channelizers of various sizes.
This was related to not wanting to resample after every channel, not the different channel bandwidth.
the gr_pfb_clock_resampler looks like exactly what I need. Will give it a shot.
Great! It's worked great for me in the past. Interested to hear other's results, though.
Also, in our case where we are actively using 20% of channels from the channelizer, it is more advantagous to provide the filterbank with the least computationally intensive channel filter and add a more selective filter on only the channels we are using (but do so with N separate filter blocks), or is the filterbank implementation efficient enough to worry about it and we should design the channel filter to best fit the ultimate need?
For N channels, every N taps added to the prototype filter adds only 1 more tap per channel, so it shouldn't be too much overhead to provide a better filter in the channelizer. Now, the channelizer implementation uses time-domain FIR filters internally, so if you are asking to use hundreds of more taps, than it _might_ be more computationally efficient to use external FFT filters for the channels you need. But I doubt it, honestly. There's going to be some crossover somewhere that you might just have to experiment with to find out.
The other thing is that the PFB clock resampler is another filter. In the dbpsk2 and dqpsk2 demodulators that are currently in the master branch, I implemented the RRC filter for this, so it becomes the matched filter, too. You can use other filters for this stage, so you might think about how to pair this filtering stage with the channelizer filtering stage for the best computational and signal performance (choose the best point on the Pareto front, if you will).
Tom