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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio