>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