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