On Thu, Sep 8, 2011 at 10:31 AM,
<address@hidden> wrote:
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
If you put in the real sample rate (in samples/second) as the second parameter, everything else will be in Hz. The filter only really cares about normalized values, so the sampling rate is essentially a coefficient to translate from there to what you want; in this case, Hz.
This filter should be specified at the sample rate that you see into the filter; that is, before the sw_decim decimation is applied.
Also, the filter bandwidth is determined by the third parameter; so that's really the filter width. The fourth parameter is the width of the transition from the end of the pass band to the start of the stop band, so you might want to play with both. The bandwidth gives you the passband and the transition band will determine how many taps your filter has.
Tom
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