Re: [Discuss-gnuradio] Benchmark scripts

>> 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.
An excellent point, to be sure. The transmitter carrier frequency
should be adjusted to be as close to
spot-on as as practical, given test equipment accuracy, etc. [Some
frequency counters have
woefully-inadequate clock crystals on them, so using them for
fine-scale tweaking is just asking
for trouble].

But *dynamic* tweaking of the transmitter frequency often leads to
trouble in a multi-receiver scenario.

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

Too bad the galaxy is in rotation, else you could use 1420.4058MHz and a
small dish as a super-accurate frequency standard :-)
[Actually, if you have precise notions of the rotation curve along
your line of site, you can correct, but, I digress....]

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio