discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Benchmark scripts


From: John Gilmore
Subject: Re: [Discuss-gnuradio] Benchmark scripts
Date: Mon, 10 Jan 2011 15:41:01 -0800

>       2) Have your demodulator provide feedback to the
> frequency-setting code to tweak the actual LO frequency (or DDC
> frequency, which is usually faster).  This is the most general
> approach, since it makes your code work well even on a platform that
> doesn't have a high-quality external reference.  Note this is on the
> *receive* side.  No sense in tweaking the transmitter when you have
> potentially-many receivers.  The conventional thing to do is to have
> the receiver track wherever the transmitter is right now.

Two ideas:

  * You might need to tweak your transmitter's frequency in order to
keep it within your transmission boundaries (e.g. your license), or to
meet specs for interoperability.  For example, when using an
unmodified USRP as a GSM cell tower with the OpenBTS code, the
transmitter was too far off frequency spec for some cellphones to
interoperate with it.

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

        John




reply via email to

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