The FFT divides the frequency range into bins. While you can do some computation based on the window function you use and how much power is in adjacent bins based on this knowledge and get a refined offset, from your proposal that sounds like it might be a step or two down the road for you rather than your first step. The gist of this is that the FFT will not
be any more accurate than the bin width allows.
A better plan is to allow the FFT to "get you close" , and then use the FFT bin center as the initial condition for a PLL, and then use the actual phase locked loop based carrier routines with a noise bandwidth smaller than the bin width in the FFT. This will refine the estimate of the frequency nicely by using phase lock.
Don Latham wrote:
> Hi Thomas: What you propose might work; it's a simple bang-bang servo
> frequency control. It's success depends a lot on the frequency
> characteristics of the drift you are trying to track. I have absolutely no
> idea about the difficulty of implementation in Gnuradio, I'm sure that
> depends a lot on the rest of your app.
>> Hello everyone,
>> I have an application in which I need the USRP to track a
>> frequency being received. What I mean by "tracking the carrier" is I need
>> the USRP to stay tuned to the carrier frequency even if the carrier
>> frequency drifts (or if the USRP's frequency reference drifts).
>> I was thinking that I could peridically (perhaps once per second) take the
>> FFT, find the frequency of the greatest magnitude, and re-tune the USRP to
>> this frequency.
>> Is there any reason why this wouldn't work, and is there a better way? It
>> seems to me this would be a common problem, and there would already be a
>> good solution, but I haven't been able to find one.
>> Discuss-gnuradio mailing list
-- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.