Re: [Discuss-gnuradio] where the carrier frequency is set

[Eric Blossom]

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