Tracking a Carrier Frequency

GNU Radio
#1

Hello everyone,

I have an application in which I need the USRP to track a carrier
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.

Thanks,

Thomas

#2

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.
Don

Thomas

  _______________________________________________

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
Dr. Don L. AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com

#3

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.

Bob

Don L. wrote:

seems to me this would be a common problem, and there would already be a
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
(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.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn

#4

Okay, it looks like pll_carriertracking_cc might help me do what I want.
I’ll see if I can get it working.

Thanks for your responses!

— On Fri, 8/7/09, Bob McGwier wrote:

From: Bob McGwier
Subject: Re: [Discuss-gnuradio] Tracking a Carrier Frequency
To: “Don L.”
Cc: “Thomas”
Date: Friday, August 7, 2009, 1:54 AM

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.
Bob

Don L. wrote:

seems to me this would be a common problem, and there would already be a
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

   Â

  Â

– (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.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn