Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

[Matt Ettus]

On 02/03/2010 10:19 PM, Ian Holland wrote:
> Hi Matt
>
> Sorry I wasn't completely clear in my previous post below. Specific
> details are as follows:
>
> When I say "it fails to lock over the full high band and low band", what
> I mean is as follows. I ran a test program to step through the
> frequencies
> 2.3 GHz to 2.6 GHz, and 4.8 to 6.1 GHz in 10 MHz increments, and for
> every single one of those frequencies, it failed to tune the Rx
> frequency and it also failed to tune the Tx frequency. This was, based
> on earlier debugging, shown to be due to it not locking (i.e. Lock
> detect bit was not set).

Clearly locking nowhere is a problem.

> Serial number combinations are as follows. Please note that by
> "Working", I mean not all frequencies fail to tune. However, some
> frequencies near the edges of the lower band, and the upper edge of the
> higher band, intermittently fail to tune even for combinations of cards
> I refer to in the table as Working.

You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9 
to 5.9 GHz.  When we test XCVRs before shipping, we make sure that they 
will lock from 2.35 to 2.55 and 4.85 to 5.95 so that there is 50 MHz of 
margin in case of variation due to temperature or other factors.  But 
there is no reason to think that they would lock all the way to the 
edges of the ranges you list since those are well outside of what we 
(and the chip manufacturer) specify.


> Combination ID | USRP2 Serial | XCVR2450 Serial | Working
>       A         | 933          | 990             | YES
>       B         | 933          | 988             | NO
>       C         | 1159         | 990             | YES
>       D         | 1159         | 988             | YES
>
> In my testing today, an additional problem was also noticed, as below.

To simplify testing, you only need to run either RX or TX since they 
both share the same synthesizer on the XCVR2450.

Normally I would tell you to send the parts back for me to check them, 
but since you are in AU, it would be expensive and take a long time. 
Instead, we may be able to debug this if you have an oscilloscope.  If 
so, can you look at the signal on R45 and R56 on the XCVR?  Note the 
frequency, and high and low voltages for each of the 4 combinations you 
mention above.  They should look like a square wave in all cases.

> Whilst using the internal clocks, a test was run to compare sampling
> rates using combination A as Rx and combination D as Tx. As would be
> expected without locked clocks, the sampling rates at Tx and Rx
> differed. Then, another test was performed using the same external 10
> MHz reference to both Tx and Rx USRP2s. As soon as the external
> reference signal was fed into the reference clock input of combination D
> (Tx), the transmitted signal level was observed to drop into the noise
> floor, hence, I was unable to reliably detect the transmitted signal
> with locked clocks. (I had previously run the same test with the BasicTx
> and BasicRx daughterboards, connected by and SMA-SMA cable, and this
> effect had not occurred with the BasicTx/BasicRx. Instead, the sampling
> rates at Tx and Rx were identical, and I was able to successfully
> demodulate a file transmitted using BPSK).


Assuming the signal you were transmitting was a sine wave with a 
baseband frequency of 0, then what you are seeing here is completely 
expected and normal.  When the clocks are not locked to the same 
reference, there is some frequency error, and the signal received is at 
some frequency other than exactly on the LO of the receiver, and it will 
get through just fine.  However, when the 2 clocks are locked to the 
same reference, the transmitted tone will be received exactly on the LO 
frequency of the receiver.  When this is downconverted to baseband, it 
will appear at DC, and it will be nulled out by the DC offset 
correction, which occurs in both the analog and digital domains.  You 
can turn off the digital one, but not the analog one on the XCVR.

To demonstrate this, you can run the following commands:

- To show a good tone being received:
    usrp_siggen.py -f 5.65G -A 0.1 -x 100k --sine
    usrp2_fft.py -f 5.65G

- To show the tone being nulled out:
    usrp_siggen.py -f 5.65G -A 0.1 -x 0 --sine
    usrp2_fft.py -f 5.65G


Matt