Re: [Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths

[bjoernm]

Hi,
thanks at first for the answer so far!

In my code are the following lines:

chan_coeffs = gr.firdes.low_pass(1.0,                  # gain
                  sw_decim * self._samples_per_symbol, # sampling rate
                                 1.0,                  # midpoint of  
trans. band
                                 0.5,                  # width of trans. band
                                 gr.firdes.WIN_HANN)   # filter type
self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs)

Now I can see that the channel coefficients fed to the fft_filter_ccc  
are computed at first using the gr.firdes.low_pass() function (Hence,  
it's a low pass filter :))

Anyway, there's the fourth parameter given to gr.firdes.low_pass  
function, which is supposed to represent the width of our transmission  
band. I guess this is the parameter I need to change to have the low  
pass filter filtering the correct spectrum containing (only) my  
signal. But a value of 0.5 looks to me a little strange? Is there a  
translation to Hz or a realation to the center freqeuncy (here 1.0,  
also strange)?

I guess I'm interpreting something wrong here... Can anyone help?

best,
B

Quoting "Tom Rondeau" <address@hidden>:

> On Thu, Sep 8, 2011 at 9:59 AM, <address@hidden> wrote:
>
> > Hi everyone...
> >
> > I'm currently working on/with the UCLA ZigBee Physical Layer implementation
> > on GnuRadio. Now my sender and receiver will change their bandwidth all the
> > time, hence I need to adjust the BandPassFilter at reception accordingly.
> >
> > Now I have seen that the signal goes through the C++ Signal Processing
> > Block "fft_filter_ccc" which, as I assume, filters the signal as a Bandpass
> > filter or low pass, not sure.
> >
> > Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc"
> > and was wondering if anyone of you knows which parameter of this signal
> > processing block responsible is for the width of the filter?
> >
> > best regards, and thank you all for answering...
> > B
>
> Hi B,
> The fft_filter_ccc can be a bandpass, low pass, high pass, etc... it takes
> as its arguments the decimation factor and the set of taps as a list of
> complex numbers. Whatever taps you put into it, it will filter based on
> that.
>
> It has a method called set_taps that also takes a list (or std::vector in
> C++) of complex numbers that you can use to change the filter structure. But
> whether or not this is really useful to you depends on how fast you need
> things to change. Using the set_taps function from Python gives you
> no guarantee about when the taps will change compared to when the samples
> are flowing through your flowgraph.
>
> What sort of information determines the filter structure that you need? If
> there is something before the filter that knows that a new set of taps is
> required starting at a particular sample, then the best bet would be to use
> the stream tagging interface. You could set the tag with the current sample
> number for when the new taps are required and also pass the set of taps in
> the tag itself. You would then have to rewrite the gr_fft_filter_ccc to look
> at the tag stream, pick out the tags when they arrive, and use the taps
> passed inside the tag to set up your new filter (keep in mind that if you
> change the number of taps in your filter, the history is going to change,
> too).
>
> Tom