[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Benchmark scripts

From: Patrick Yeon
Subject: Re: [Discuss-gnuradio] Benchmark scripts
Date: Mon, 10 Jan 2011 19:09:00 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101207 Thunderbird/3.1.7

On 1/10/2011 6:58 PM, Marcus D. Leech wrote:
* It seems to me we could minimize this problem by writing a small
program that would tune an over-the-air frequency standard (like one
of the WWV broadcasts) and compare it to the local oscillator. The
resulting frequency offset could then be stored as a default setting
for subsequent GNU Radio runs, so that e.g. if your program asked to
tune to 250.000 MHz and the USRP's LO was slow by 50 kHz (0.050 MHz)
then internally it would know to tune to 250.050 which is probably
closer to where the real signal will be. Of course the LO would shift
slightly based on temperature, but if you measured and stored the
value after warm-up, it would probably be relatively stable.


Probably reasonable as a first-order approach. That assumes that
frequency errors are more-or-less linear.
Further, you want to store the result as a PPM estimate, rather than an
absolute frequency offset. For some
cards, the difference won't matter, but for something like the WBX, with
a very-wideband synthesizer, it
does matter.

FM radio stations also tend to use very-high-quality LOs for their
transmitters, although the wideband nature of their
signal makes it somewhat awkward to do fine tweaking. Hmmm, I wonder
about the audio carrier of a TV signal, that
might also be reasonably stable.

I haven't used it, but kalibrate [1] seems to do what we're all talking about, using GSM base station clocks (that are required to have an accuracy of 50 parts per billion). Maybe see what that code is all about?

[1] http://thre.at/kalibrate
Patrick Yeon
613-369-5104 x418

reply via email to

[Prev in Thread] Current Thread [Next in Thread]