Hi, all
I set the frequency of USRP to be 910MHz, but I noticed that
the central frequency of the signal is 914MHz. Why there is 4Mhz
frequency offset.
I also found that there is also a signal comeing up in 896Mhz. The
amplitude of
the signal in 914MHz is 20dB higher than the amplitude of the signal in
896Mhz.
I also tried to change the LO Frequency Offset from -8MHz to
+8MHz, but the frequency of the signal is still 914MHz.
Does anyone who can give me some comments and help?
Thanks a lot!
On Wed, Sep 02, 2009 at 09:14:52AM +0800, fangming he wrote:
Hi, all
I set the frequency of USRP to be 910MHz, but I noticed that
the central frequency of the signal is 914MHz. Why there is 4Mhz frequency offset.
I also found that there is also a signal comeing up in 896Mhz. The amplitude of
the signal in 914MHz is 20dB higher than the amplitude of the signal in 896Mhz.
Did you call u.tune(…, 910e6, …) to set the frequency?
If so, it adjusts the LO and DDC together such that the signal that
you want (910e6) ends up at DC in the baseband.
If you are looking at the usrp_fft.py display, it displays the LO
frequency in the status area, but the actual frequency that
corresponds to baseband (post DDC) will be the frequency that you asked
for.
I also tried to change the LO Frequency Offset from -8MHz to
+8MHz, but the frequency of the signal is still 914MHz.
Do not mess with the LO offset until you understand in detail what’s
going on; and even then, think twice about it
Eric
Eric B. wrote:
On Wed, Sep 02, 2009 at 09:14:52AM +0800, fangming he wrote:
Hi, all
I set the frequency of USRP to be 910MHz, but I noticed that
the central frequency of the signal is 914MHz. Why there is 4Mhz frequency offset.
I also found that there is also a signal comeing up in 896Mhz. The amplitude of
the signal in 914MHz is 20dB higher than the amplitude of the signal in 896Mhz.
Did you call u.tune(…, 910e6, …) to set the frequency?
Thats news to me! The grc generated code here just calls set lo.
The temporary solution would be to create a gui control for the
frequency and to change the frequency at runtime. This will cause
u.tune(…) to be called.
-Josh
On Tue, Sep 01, 2009 at 07:18:02PM -0700, Josh B. wrote:
From usrp_standard.h:
usrp_standard_rx:
/*!
- \brief High-level “tune” method. Works for the single channel
case.
-
- This method adjusts both the daughterboard LO and the DDC so that
- target_freq ends up at DC in the complex baseband samples.
-
- \param chan which DDC channel we’re controlling (almost always 0).
- \param db the daughterboard we’re controlling.
- \param target_freq the RF frequency we want at DC in the complex
baseband.
- \param[out] result details how the hardware was configured.
-
- \returns true iff everything was successful.
*/
bool tune(int chan, db_base_sptr db, double target_freq,
usrp_tune_result *result);
usrp_standard_tx:
/*!
- \brief High-level “tune” method. Works for the single channel
case.
-
- This method adjusts both the daughterboard LO and the DUC so that
- DC in the complex baseband samples ends up at RF target_freq.
-
- \param chan which DUC channel we’re controlling (usually ==
which_side).
- \param db the daughterboard we’re controlling.
- \param target_freq the RF frequency we want our baseband translated
to.
- \param[out] result details how the hardware was configured.
-
- \returns true iff everything was successful.
*/
bool tune(int chan, db_base_sptr db, double target_freq,
usrp_tune_result *result);
If you don’t adjust both the LO and DDC/DUC, on most boards you can’t
ensure that your desired frequency is at 0 Hz in the baseband. (The
4 MHz offset is to move some spurs away from 0 Hz.)
Eric
On Wed, 2009-09-02 at 12:15 -0700, Josh B. wrote:
I made a branch with this fix:
http://gnuradio.org/cgit/jblum.git/log/?h=lo_fix
Does the usrp2 have a similar issue: Does set_center_freq() have to be
called after set_lo_offset()?
Yes.
Johnathan
I made a branch with this fix:
http://gnuradio.org/cgit/jblum.git/log/?h=lo_fix
Does the usrp2 have a similar issue: Does set_center_freq() have to be
called after set_lo_offset()?
-Josh