[Top][All Lists]

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

Re: [Discuss-gnuradio] Benchmark scripts

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Benchmark scripts
Date: Mon, 10 Jan 2011 16:58:52 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7

Make a simple little FFT sink in GRC and use it on one of the USRPs to
determine the received signal offset from the other USRP while it is
transmitting. Or receive a signal from a signal generator of known
frequency and note the offset for both USRPs. Or transmit a signal from
each USRP and receive it using a different receiver and note the
difference between the frequencies of the received signals. Or vary the
frequency of either benchmark_rx or benchmark_tx via trial and error
until you get proper transmission/reception. You will probably find less
than 20kHz of offset at 2.4GHz.


This topic comes up repeatedly on this list. When you have a radio "tuned" to a specific frequency, there is *nearly-always* a certain amount of residual frequency error. Synthesized LOs (local oscillators) have a frequency offset that is proportional to the PPM tolerance of the reference oscillator that they're using.

Let's say that the oscillator has a 10PPM tolerance (which is typical, I don't, off the top of my head, know what the PPM spec is for the XO in the USRP1). So, that's 10Hz for every MHz of crystal frequency. That error "carries through" the PLL synthesizer. In this case, we have an LO frequency of 2.4GHz, so, that 2.4GHz/10PPM which gives us a potential frequency offset error of 24KHz--let's be charitable and assume that means anywhere +/- 12KHz.

For wideband modulations (higher data rates), a small frequency offset is generally mostly-harmless, since *most* of the modulation energy falls within your passband, even if the edges of your passband don't fall where you think they fall. But for narrowband modulation schemes (low data rates, or narrow OFDM buckets), frequency offset can be disasterous, since an offset in the band-edge causes most of the energy to fall *outside* of your passband.

In "real" data receivers, particularly narrowband ones, there's generally a feedback mechanism that tugs on the LO circuit a little bit to try and zero-in on the correct frequency. In the analog world, FM stereo receivers have a so-called AFC circuit that uses noise estimates to steer the LO. Television does the same thing (so-called AFT).

In the world of software-defined radio, it's easy to forget about these things, because, hey, it's all *digital*, and therefore
   *perfect*, right?  Wrong.

So, an SDR-based analog data communications system needs to be able to deal with this. There are a couple of ways of doing this:

1) lock your PLL Synthesizer to a high-quality reference clock, usually improving the PPM error by an order of magnitude or more On the USRP2/N2XX/E100 there are explicit inputs for an external 10MHz reference clock, and UHD makes it easy to
         enable this feature when you create the UHD source/sink.

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.

This class of problem is in no way unique to SDR hardware. Ham radio operators on the list will tell you about many adventures (particularly in the old days) of tweaking the LO performance on their VHF receivers to allow "full quieting" reception of the local FM repeater, and as I observed, FM radios and televisions have had some kind of automatic-fine-tuning for many many decades.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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