discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths
Date: Thu, 8 Sep 2011 10:17:35 -0400

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


reply via email to

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