On Thu, Sep 8, 2011 at 10:31 AM, <[email protected]> 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" <[email protected]>: > > On Thu, Sep 8, 2011 at 9:59 AM, <[email protected]> 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 >> >> > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
