Re: [Discuss-gnuradio] Freq_xlating filter parameter

[Michael Dickens]

I am using this function (now; wasn't then), with success: changing  
the sign of the "center_freq" argument definitely messes things up.   
The "center_freq" argument is:

  freq_xlating_center_freq_argument = current_center_freq -  
desired_center_freq

where "current_center_frequency" is defined by the returned  
structure, r = usrp.tune (..., target_frequency, ...):

  current_center_frequency = r.baseband_freq + r.dxc_freq +  
r.residual_freq

IME, I've never seen "r.residual_freq" be significant compared to the  
target frequency to which to tune, so I've always used  
current_center_frequency = target_frequency.

Example: Suppose you want 2 RX channels centered at 440 MHz and 443  
MHz, and that the USRP RX center frequency is tuned to 441 MHz.  Then  
the "center_freq" argument for the 440 MHz channel would be 1M and  
for the other would be -2M.

As you've stated: These results seem to be the negative of the  
description provided by "gr_freq_xlating_fir_filter_XXX" ... or, more  
to the point: IMHO the description needs updating to be more  
accurate, possibly with the example above?

Hope this helps! - MLD

On Sep 6, 2007, at 7:26 PM, Dan Halperin wrote:
> The comment for the filters gr.freq_xlating_fir_filter_XXX says (about
> the parameter "center_freq"):
>
> /*!
>  * Construct a FIR filter with the given taps and a composite  
> frequency
>  * translation that shifts center_freq down to zero Hz.  The frequency
>  * translation logically comes before the filtering operation.
>  */
>
> This implies that the frequency shift should be -center_freq, right?
>
> I think I'm observing the opposite; that is, you pass in the desired
> shift. All examples I can find that use this block pass in 0 as the
> frequency shift; does anyone else have experience with this block that
> can confirm or deny this?