[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] gr.fir_filter_ccf vs. gr.freq_xlating_fir_filter_
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] gr.fir_filter_ccf vs. gr.freq_xlating_fir_filter_ccf |
Date: |
Mon, 14 Jan 2008 09:06:51 -0800 |
User-agent: |
Mutt/1.5.17 (2007-11-01) |
On Mon, Jan 14, 2008 at 12:04:47AM +0100, ChoJin wrote:
> Hello,
>
> I'm still getting my hands on the gnuradio's code by walking though the
> examples and so on, and I'm looking at the differences between
> usrp_wfm_rcv.py and usrp_nbfm_rcv.py (from the gnuradio-example)
> and I would like to understand why in the latter we use the following
> code:
>
> # Create filter to get actual channel we want
> chan_coeffs = gr.firdes.low_pass (1.0, # gain
> self.if_rate, # sampling rate
> 13e3, # low pass cutoff
> freq
> 4e3, # width of trans.
> band
> gr.firdes.WIN_HANN) # filter type
>
> print "len(rx_chan_coeffs) =", len(chan_coeffs)
>
> # Decimating Channel filter with frequency translation
> # complex in and out, float taps
> self.ddc = gr.freq_xlating_fir_filter_ccf(if_decim, # decimation
> rate
> chan_coeffs, # taps
> 0, # frequency
> translation amount
> self.if_rate) # input
> sample rate
>
> whereas in the former we use this code:
>
> chan_filt_coeffs = optfir.low_pass (1, # gain
> usrp_rate, # sampling rate
> 80e3, # passband cutoff
> 115e3, # stopband cutoff
> 0.1, # passband ripple
> 60) # stopband attenuation
> #print len(chan_filt_coeffs)
> chan_filt = gr.fir_filter_ccf (chanfilt_decim, chan_filt_coeffs)
>
> What are the differences (apart from the cutoff values of course)?
> So basically why using gr.firdes.low_pass instead of optfir.low_pass
> and why using gr.freq_xlating_fir_filter_ccf instead of
> gr.fir_filter_ccf
> what difference does it make in these two examples?
>
> Could someone enlighten me?
>
Hi ChoJin,
In taking a look at the code, it looks like usrp_nbfm_rcv is using
gr.freq_xlating_fir_filter_ccf because it wanted to do a fine
adjustment on the center freqency. See line 367...
However, there's really no reason to use it since the residual
returned by usrp.tune is something on the order of a 0.01 Hz. It
wasn't always this way, but was fixed sometime in the last year or
so. Thus, the code should probably be changed to use
gr.fir_filter_ccf since it will be faster.
Thanks for the question.
Eric