-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
Thanks!
Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG4Iypy9GYuuMoUJ4RAujGAJ0Rqnx8tyQvLabBtS6qe95oJn/gIwCgmF0Y
EwRcHt95AAVwYtWh+m96tg8=
=OfSO
-----END PGP SIGNATURE-----
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