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

[Ian Holland]

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

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.

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.

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

Best Regards

Ian.


-----Original Message-----
From: Matt Ettus [mailto:address@hidden 
Sent: Thursday, 4 February 2010 4:24 PM
To: Ian Holland
Cc: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2


Ian,

When you said "it fails to lock over the full high band and low band" do

you mean it locks nowhere, or do you mean that it locks on some 
frequencies, but not everywhere?  If the latter, can you be more 
specific about where it locks and where it doesn't?

Also, what are the serial numbers of your USRP2s and your XCVRs?  Which 
are the working combos and which combos fail?

Thanks,
Matt


On 02/03/2010 04:56 PM, Ian Holland wrote:
> Hi Josh
>
> I am now in a position to summarise what I have observed.
>
>   - 1 of our 2 XCVR2450s works with both of our USRP2s.
>   - The other XCVR2450 works with only one of our USRP2s (i.e., it
fails
> to lock over the full high band and low band on the second USRP2).
>
> Do you have any idea what might be wrong? Has such behaviour ever been
> previously observed? Also, can you please comment as to whether it is
> likely that the other XCVR2450 will keep working with at least one
> USRP2?
>
> Cheers
>
> Ian.
>
>> Hi again Josh
>
>> Since my below post this morning, the 2nd XCVR2450 card that had
> repeatedly>failed this morning, is now working with the other USRP2,
> though still>unable to tune reliably near band edges.
>
>> I will probably try swapping the XCVR2450/USRP2 combination and see
> whether>somehow one XCVR2450 has an affinity for one particular USRP2,
> and won't>work on the other, but I can't really understand why that
> should be the>case. Can you think of what might cause such a
behaviour?
>
>> For now, I was just glad that I could successfully transmit a 5 GHz
> signal>from one USRP2's antenna and display the correct spectrum on
the
> receiving>USRP2.
>
>> Best Regards
>
>> Ian.
>
>
>> Is it failing to lock at all different frequencies? and in the high
> band
>> and low band ranges? Do you have more than one XCVR board with this
>> problem?
>
>> It could be possible that for this board, and the frequencies you
have
>> chosen, the N divider value teeters on the border or locking/not
>> locking. You may want to modify the usrp2 firmware code and build
> custom
>> image. The file to modify is
>>
http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/
> lib/>db_xcvr2450.c
>
>> Add some printfs to the xcvr2450_set_freq function and try to raise
the
>
>> value of N_DIV_MIN_Q16 and see if you can get it to lock.
>
>> I hope that helps,
>> -Josh
>
> On 02/01/2010 06:08 PM, Ian Holland wrote:
>> Thanks Josh
>>
>> I can now confirm that it is definitely failing to lock. I have
> noticed
>> on some rare occasions that it actually does lock. However, as soon
as
>> the USRP2 is power-cycled it goes back to the default behaviour of
> being
>> unable to lock.
>>
>> What can be done to make sure that it will lock? Is this likely to be
> a
>> hardware issue specific to our daughtercards, or is there something
> else
>> we can do in software to get around it?
>>
>> Thanks
>>
>> Ian.
>>
>>> It could be failing to lock. You may want to watch the debug port on
>> the
>>> usrp2. If the lock detect is failing, it will print out on the
serial
>>> console. attach a 3.3v level serial port
>>
>> On 01/28/2010 10:09 PM, Ian Holland wrote:
>>> Hi Josh
>>>
>>>> The xcvr has a high band and a low band, which means there is a gap
>> in
>>>> the tunable frequency range for the xcvr. Therefore, the
>>>> "auto-calculated mid-point frequency" is an invalid frequency for
> the
>>>> xcvr. Pick a frequency in the high band or low band range:
>>>
>>>> #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9)
>>>> #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9)
>>>> #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9)
>>>> #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9)
>>>
>>> Thanks - I will keep that in mind when using usrp_siggen.py in
> future.
>>>
>>> However, I have tried 2.4G with the source code from my original
post
>>> (relevant code snippet for Tx tuning just below this paragraph, for
>>> which successTx is 0 and all frequency properties in TxTuneResult
are
>>> 0), and also with usrp2_fft.py -f 2.4G, after burning the latest
>> images.
>>> I still face the same problem that neither the Tx nor the Rx will
>> tune.
>>>
>>> /* try tuning Tx to a test frequency */
>>> double Fc = 2400000000.0;
>>> usrp2::tune_result TxTuneResult;
>>> bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio