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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio