Problem of Frequency Offset

Unfortunately, the problem is inherent in all RF communications systems due to the fact all radios have an independent time base.

Lets visualize what is it actually :

I generated a sinusoid at 2.45GHz using uhd_siggen as follows in one usrp

uhd_siggen -f 2.45G -a "serial=1R270DU1"

In another usrp I started uhd_fft tuned at 2.45GHz

uhd_fft -f 2.45G -a "serial=4d9e2db2"

But what I observed was not centered at 2.45G but it was at 2.44999GHz i.e. an offset of 10KHz and that is quite large !!

Suppose you transmitted using bencmark_tx.py at 2.45GHz from usrp with
serial=1R270DU1 as follows :

./benchmark_tx.py -f 2.45G -a "serial=1R270DU1"

and the receiver side you started receiving at usrp with serial=4d9e2db2
at 2.45GHz as :

./benchmark_rx.py -f 2.45G -a "serial=4d9e2db2"

You will rarely see any data receiving.

You need to compensate for this frequency offset.

So once you know that there is a 10KHz frequency offset between the two usrp you shall tune the receiver at 2.45 GHz - 10KHz = 2.44999GHz

i.e. 
./benchmark_rx.py -f 2.44999G -a "serial=4d9e2db2"

One important thing. This offset thing is not kind of vice versa between the two. i.e say if offset is X KHz from usrp_a to usrp_b then need not the offset will be same from usrp_b to the usrp_a, it may be different.

So one need to check for both sides instead of just assuming.

There may also be the case when this frequency offset keeps changing with time, temperature and some other unknown conditions.

So you may need to recheck and re tune whenever you need to transmit and receive

Reason of offset :  

Because each local oscillator is not exactly 64.000000000MHz, when that signal is multiplied up by the PLL - so does the "offset".  You can reduce this by synchronizing yourself to a very reliable timebase, but you still get some residual shift.

Nice Question :

The tranceiver osillators tune as close as possible to the desired receiving frequency in steps of 4MHz,and the remaining frequency offset is downconverted by the USRP DDC. So if I am tuning to 2.40GHz(multiple of 4MHz), why a frequency offset occurs?

Although tuning is done to the best of the receiver's (synthesizer/PLL) ability.

Knowing that there is a 64MHz local oscillator reference on the board, that must somehow get "multiplied up" using a PLL to generate your 2.4GHz signal.  Some simple math follows:

    Multiplier = 2.4e9 / 64e6
    Multiplier = 37.5

So a 64MHz signal must be multiplied up by 37.5 to generate the desired frequency.

Now, lets imagine that our crystal oscillator is off by 320Hz(assuming this is a crystal oscillator rating of 5ppm so that the total offset = 64*5 = 320 Hz)

** 1 ppm means 1 Hz offset in 1MHz cycles hence for an oscillator of 64MHz and rating 5ppm there will be 64*5 = 320 Hz offset  

Establishing we have an oscillator with a 5ppm offset, and a multiplier of 37.5, we can then calculate what our frequency offset will be:

    Foffset = multiplier * LOoffset
    Foffset = 37.5 * 320Hz
    Foffset = 12kHz

By only being off by 5 cycles for every 1 million, we have created a 12kHz offset only at the transmitter.  This may be added or subtracted based on how the receiver is sampling as well.

 Reference : http://gnuradio.4.n7.nabble.com/Frequency-shift-in-the-received-and-generated-signals-of-the-USRP-tt24320.html#a24325

** If the two daughter boards are attached to the same USRP, there will be no
LO offset between them.

They are driven by a common ref clock provided by the USRP motherboard.