Re: [Discuss-gnuradio] Benchmark scripts

[Marcus D. Leech]

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