|
From: | Michael Ford |
Subject: | Re: [Discuss-gnuradio] where the carrier frequency is set |
Date: | Sun, 30 Jul 2006 14:42:42 -0500 |
On Fri, Jul 28, 2006 at 02:01:25PM -0500, Michael Ford wrote:
> Eric has already told me once that this is crazy, but I can't see any
> other
> way to do this. When Matt told me that the RSSI circuit measures
> interference +/-15Mhz from the carrier, I naturally went to the code for
> the
> read_aux_adc() function in usrp_prims.{cc,h} in order to see where the
> carrier frequency comes into play. I wanted to know where in the code I
> should be changing the carrier frequency. Just as I've been told, the code
> is confusing. I've read all the tutorials, I'm pretty knowledgeable about
> both python and C++; I'm not confused about the basic syntax of either
> language. Honestly, between the lack of comments for variables, and every
> file being inherited from some other class file, it's extremely easy to
> get lost in the code.
Michael,
To tune, use the u.tune(...) method. It's not hard to use; it works
with all daughterboards. It accounts for the RF front-end's finite
PLL step size, and manages the digital down converter.
FYI, we call the thing you're calling "carrier frequency" the "center
frequency". These two concepts are not necessarily tightly
coupled. There could be _many_ carriers in a digitized stream of
samples, and carrier(s) may not be at the center frequency.
Do you understand the comments below about tuning being a "two-step
process"? On the RFX boards, the PLL step size is 4 MHz.
Also, the return value from tune is an instance of tune_result which
can be examined to see how everything was setup. baseband_freq is the
RF frequency that corresponds to DC in the RF front-end's IF output
(the input to the A/D's and from there to the digital down-converter).
Note that this isn't necessarily the location of the signal of
interest. Some daughterboards have the signal of interest at a
non-zero IF frequency. dxc_freq is the frequency value used in the
digital down or up converter. residual_freq is a very small number on
the order of 1/100 of a Hz. It can be ignored. Inverted is true if
the spectrum is inverted, and we weren't able to fix it for you.
On the receive path, the end result of tune is that the signal at the
given target RF frequency ends up at DC in the complex baseband input
from the USRP.
From usrp.py:
class tune_result(object):
"""
Container for intermediate tuning information.
"""
def __init__(self, baseband_freq, dxc_freq, residual_freq, inverted):
self.baseband_freq = baseband_freq
self.dxc_freq = dxc_freq
self.residual_freq = residual_freq
self.inverted = inverted
def tune(u, chan, subdev, target_freq):
"""
Set the center frequency we're interested in.
@param u: instance of usrp.source_* or usrp.sink_*
@param chan: DDC/DUC channel
@type chan: int
@param subdev: daughterboard subdevice
@param target_freq: frequency in Hz
@returns False if failure else tune_result
Tuning is a two step process. First we ask the front-end to
tune as close to the desired frequency as it can. Then we use
the result of that operation and our target_frequency to
determine the value for the digital down converter.
"""
Eric
[Prev in Thread] | Current Thread | [Next in Thread] |