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?
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
