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

[Josh Blum]

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