Changing external reference frequency with USRP2

GNU Radio
1

Hi

I have read on the FAQ that is possible to change the external reference
frequency for the USRP2 from 10 MHz to another value simply by changing
one line in the firmware.
However, I have as yet been unable to locate the actual source file in
which I need to make this change, and what the name of this variable is.
Could someone please let me know?

Many Thanks

Ian.

2

gnuradio/usrp2/firmware/lib/clocks.c, starting at line 40. You probably
want to read the AD9510 datasheet to help with selecting values.

Matt

3

Thanks Matt

I tried to change to get the external reference frequency to be 36 MHz,
by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do this, I
modified lines 43 and 85 respectively to the following:

ad9510_write_reg(0x06, 0x32);
ad9510_write_reg(0x0C, 0x24);

However, when I rebuilt the firmware (txrx.bin) and wrote it to the SD
card,
I was no longer able to see an OFDM signal I had been transmitting from
another SDR at 2.4 GHz. This occurred both when I had configured the
receiving SDR to lock onto the 36 MHz reference
(device->config_mimo(usrp2::MC_WE_LOCK_TO_SMA))
And when I configured the receiving SDR to use its internal reference
(device->config_mimo(usrp2::MC_WE_DONT_LOCK))

Have I done something wrong in my modifications? If so, can you please
suggest what I am doing wrong? According to the AD9510 datasheet I
believe my changes should have been correct.

Best Regards

Ian.

4

On 08/16/2010 12:21 AM, Ian H. wrote:

Thanks Matt

I tried to change to get the external reference frequency to be 36
MHz, by setting B to 50 (i.e. 0x32) and R to 36 (i.e. 0x24). To do
this, I modified lines 43 and 85 respectively to the following:

ad9510_write_reg(0x06, 0x32); ad9510_write_reg(0x0C, 0x24);

If you set R to 36 then your compare frequency is 1 MHz. A setting of B
= 50 means you are trying to lock at 50 MHz, which won’t work. The
crystal is at 100 MHz, so you need to use B=100.

This will cause you to be way off in frequency (maybe 100 to 150 ppm).
It should still function, however.

datasheet I believe my changes should have been correct.
If it doesn’t work with either setting then it is likely your firmware
is bad. Check to make sure you are using a good Microblaze compiler.

Matt

5

Hi Matt

I will try this, though given P = 2, I was under the impression the
resulting VCO frequency should have been 1 MHz * P * B = 100 MHz when I
have B = 50. At least, that is what the equation in the datasheet
suggests.

Regards

Ian.

6

Hi Matt

Further to below, I tried your suggestion, and still it didn’t work.
In fact, I have now found that the only thing that does work now is to
use a pre-compiled binary that I downloaded for txrx.bin (since
recompiling with the original gnuradio source code didn’t work).

This suggests indeed the problem is either the Microblaze tools I have
(since recompiling with the original gnuradio source code didn’t work)
or that the version of source I had (from March 21, 2010) was corrupt to
begin with. However, I even tried updating to the latest git via git
pull, and tried to remake using the original clock settings. Still, it
doesn’t work. Hence I suspect the microblaze tools as you suggested.

I got the Microblaze tools from the gnuradio website. I would have
though these should work fine, but perhaps not. Is there another source
you can suggest?

Best Regards

Ian.

7

On 08/16/2010 09:22 PM, Ian H. wrote:

Please disregard my last. I must have got something wrong in my
testing. It now compiles, but it seems I need to use txrx_xcvr.bin
instead of txrx.bin with the latest git trunk. Please correct me if
this is wrong (note I have XCVR2450 as my daughterboard).

This is correct. Due to the size of the code, the xcvr was split out to
its own file. Also, you are right about the prescaler.

Nonetheless, I still seem to get a time varying frequency offset
between a transmitted and received BPSK waveform, when using the same
local oscillator of 36 MHz at each end. In fact, about every million
samples, this frequency offset disappears, then comes back getting
larger, then smaller and disappears again about 1 million samples
later.

Is this expected when using a reference different to 10 MHz? When I
have used two USRP2s both locked to a 10 MHz reference, I never saw
this problem.

No, you should not see that. It sounds like it is not locked, and I
think the reason is loop bandwidth. The original setup is for a 10 MHz
compare frequency, and you are using a 1 MHz compare frequency. This
will mess up the loop dynamics by dividing the loop bandwidth by 10.

The greatest common divisor of 100 MHz and 36 MHz is 4 MHz, so I would
use that for the compare frequency. Then also increase the charge pump
current to the maximum. That should bring you closer to the original
loop bandwidth.

Matt

8

Hi Matt

Thanks so much for your help. I tried your latest suggestion, and this
gets my frequency offset between Tx and Rx down to a mere 1 Hz. This is
much better and should make my testing considerably simpler.

Cheers

Ian.

9

Please disregard my last. I must have got something wrong in my testing.
It now compiles, but it seems I need to use txrx_xcvr.bin instead of
txrx.bin with the latest git trunk. Please correct me if this is wrong
(note I have XCVR2450 as my daughterboard).

Nonetheless, I still seem to get a time varying frequency offset between
a transmitted and received BPSK waveform, when using the same local
oscillator of 36 MHz at each end. In fact, about every million samples,
this frequency offset disappears, then comes back getting larger, then
smaller and disappears again about 1 million samples later.

Is this expected when using a reference different to 10 MHz? When I have
used two USRP2s both locked to a 10 MHz reference, I never saw this
problem.