RE: [Discuss-gnuradio] Changing external reference frequency with USRP2...

[Ian Holland]

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.

-----Original Message-----
From: Ian Holland
Sent: Tuesday, 17 August 2010 11:33 AM
To: Ian Holland; Matt Ettus
Cc: address@hidden
Subject: RE: [Discuss-gnuradio] Changing external reference frequency with 
USRP2...

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.



-----Original Message-----
From: Ian Holland
Sent: Tuesday, 17 August 2010 9:24 AM
To: 'Matt Ettus'
Cc: address@hidden
Subject: RE: [Discuss-gnuradio] Changing external reference frequency with 
USRP2...

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.

-----Original Message-----
From: Matt Ettus [mailto:address@hidden
Sent: Tuesday, 17 August 2010 2:15 AM
To: Ian Holland
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Changing external reference frequency with 
USRP2...

On 08/16/2010 12:21 AM, Ian Holland 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.

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


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

This message is intended only for the use of the intended recipient(s) If you 
are not an intended recipient, you are hereby notified that any use, 
dissemination, disclosure or copying of this communication is strictly 
prohibited. If you have received this communication in error please destroy all 
copies of this message and its attachments and notify the sender immediately