Ya, what I mean is that for you too the problem may be the SD card only.
Actually we had got around 20 USRP’s/daughterboards from Ettus and none
of
them were working with the SD cards they supplied with them (20 in all).
When I tried with an older SD card, it worked.
Ian-
Perhaps? We only have two USRP2s and 2 XCVR2450s. However,
if it was the SD card, I would think both XCVR2450s should
have the problem. Actually, even the better of the two
occasionally fails, so I can’t be sure.
If you rule out the SD card, then is there a way you and Manav can
compare PCB revisions for USRP2 and XCVR2450 – and
USRP2 logic revision – and make sure your systems are absolutely
identical? Even a small rework or logic change
might make a difference…
-Jeff
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.
Hi Josh
Thanks for the advice. I tried the full range of low and high band
frequencies, in increments of 10 MHz with 2 different XCVR2450 boards.
This was done at least 4 times after power cycling for each card. I
noticed the following:
- For one of the XCVR cards, it repeatedly failed for all frequencies.
- For the other card, it intermittently failed for frequencies at the
lower and upper end of the low band, and at the higher end of the high
band. I tried several values of N_DIV_MIN_Q16, and expect with a really
large value (131 << 22), which seemed to fail for almost all
frequencies, and also seemed to cause the USRP2 to “freeze up” a few
times, I noticed negligible difference in the behaviour of this
daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the
USRP2 either froze when I tried to run my test, or it was unable to be
found by my host PC in some cases. - I tried (131 << 16) (i.e. original) value for N_DIV_MIN_Q16 and also
(131 << 19) on the card that failed for all frequencies, and that made
no difference.
I am not hugely concerned about the band-edge instability for the
working card (although of course it would be nice to get to the bottom
of that issue), but do you have any idea what could be wrong with the
2nd card, that fails for all frequencies?
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 H. 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
elseOn 01/28/2010 10:09 PM, Ian H. 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.
double Fc = 2400000000.0;
usrp2::tune_result TxTuneResult;
bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Manav,
Sorry for not being active in this thread. Things have been very busy
here. In any case, it sounds like you are seeing something very
different from Ian. You are having one of 2 problems –
- You received bad SD cards. If you power up your USRP2 with the SD
card in it, and you don’t see 2 LEDs light up on the front panel, then
this is what you are seeing, and it has nothing to do with the XCVR2450.
Go to this page and follow the directions there:
- If the card is not bad, then you have a flash version which does not
match your GNU Radio install. Newer flash cards come with new versions
of the firmware and FPGA, but these will only work with updated GNU
Radio code. If this is the case, you either need to update GNU Radio,
or put an old version of the FPGA and firmware on your card. I
recommend the first option.
Matt
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 H. 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
elseOn 01/28/2010 10:09 PM, Ian H. 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.
double Fc = 2400000000.0;
usrp2::tune_result TxTuneResult;
bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
Hi Matt
Are you able to also comment on the problem that I am having? (Summary
below):
- 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).
Thanks
Ian.
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.
On 02/03/2010 10:19 PM, Ian H. wrote:
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).
Clearly locking nowhere is a problem.
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.
You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9
to 5.9 GHz. When we test XCVRs before shipping, we make sure that they
will lock from 2.35 to 2.55 and 4.85 to 5.95 so that there is 50 MHz of
margin in case of variation due to temperature or other factors. But
there is no reason to think that they would lock all the way to the
edges of the ranges you list since those are well outside of what we
(and the chip manufacturer) specify.
Combination ID | USRP2 Serial | XCVR2450 Serial | Working
A | 933 | 990 | YES
B | 933 | 988 | NO
C | 1159 | 990 | YES
D | 1159 | 988 | YESIn my testing today, an additional problem was also noticed, as below.
To simplify testing, you only need to run either RX or TX since they
both share the same synthesizer on the XCVR2450.
Normally I would tell you to send the parts back for me to check them,
but since you are in AU, it would be expensive and take a long time.
Instead, we may be able to debug this if you have an oscilloscope. If
so, can you look at the signal on R45 and R56 on the XCVR? Note the
frequency, and high and low voltages for each of the 4 combinations you
mention above. They should look like a square wave in all cases.
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).
Assuming the signal you were transmitting was a sine wave with a
baseband frequency of 0, then what you are seeing here is completely
expected and normal. When the clocks are not locked to the same
reference, there is some frequency error, and the signal received is at
some frequency other than exactly on the LO of the receiver, and it will
get through just fine. However, when the 2 clocks are locked to the
same reference, the transmitted tone will be received exactly on the LO
frequency of the receiver. When this is downconverted to baseband, it
will appear at DC, and it will be nulled out by the DC offset
correction, which occurs in both the analog and digital domains. You
can turn off the digital one, but not the analog one on the XCVR.
To demonstrate this, you can run the following commands:
-
To show a good tone being received:
usrp_siggen.py -f 5.65G -A 0.1 -x 100k --sine
usrp2_fft.py -f 5.65G -
To show the tone being nulled out:
usrp_siggen.py -f 5.65G -A 0.1 -x 0 --sine
usrp2_fft.py -f 5.65G
Matt
Hi Matt
Apologies is you got a similar reply about 10 minutes ago, but the
webmail logged me out whilst I was trying to send it and it didn’t
appear in my sent items when I logged back in.
You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9
to 5.9 GHz. When we test XCVRs before shipping, we make sure that they
will lock from 2.35 to 2.55 and 4.85 to 5.95 so that there is 50 MHz of
margin in case of variation due to temperature or other factors. But
there is no reason to think that they would lock all the way to the
edges of the ranges you list since those are well outside of what we
(and the chip manufacturer) specify.
Thanks. I had thought the low and high limits in the source code were
the spec’d ones. Based on your above comment, combinations A, C, and D
would seem to be within spec, though I didn’t try all the stepped
frequencies for case C or D, but just a few (e.g. 2.4G, 2.462G, 5G).
Combination ID | USRP2 Serial | XCVR2450 Serial | Working
A | 933 | 990 | YES
B | 933 | 988 | NO
C | 1159 | 990 | YES
D | 1159 | 988 | YESIn my testing today, an additional problem was also noticed, as below.
To simplify testing, you only need to run either RX or TX since they
both share the same synthesizer on the XCVR2450.
Thanks. I will do this in future.
Normally I would tell you to send the parts back for me to check them,
but since you are in AU, it would be expensive and take a long time.
Instead, we may be able to debug this if you have an oscilloscope. If
so, can you look at the signal on R45 and R56 on the XCVR? Note the
frequency, and high and low voltages for each of the 4 combinations you
mention above. They should look like a square wave in all cases.
We have a borrowed oscilloscope spec’d to 1.5 GHz with no probe. I will
try to borrow or buy a suitable probe. Can you confirm R45 and R56 are
just digital logic signals, as would seem to be the case from what you
state above?
can turn off the digital one, but not the analog one on the XCVR.
To demonstrate this, you can run the following commands:
- To show a good tone being received:
usrp_siggen.py -f 5.65G -A 0.1 -x 100k --sine
usrp2_fft.py -f 5.65G
- To show the tone being nulled out:
usrp_siggen.py -f 5.65G -A 0.1 -x 0 --sine
usrp2_fft.py -f 5.65G
Whoops. Didn’t think about the DC offset correction. It was a sine wave
at the carrier frequency that I tried. I will hence try your suggestion
tomorrow, as it is evening here and I am at home without access to the
radios.
Thanks
Ian.
Hi Matt,
Ya, I am having the second problem. But, I have the gnuradio 3.2.2 code
base
only. Will try to checkout again from the git repository and build.
Anyways, I did have a working card. So if this does not work, I will try
to
copy this card to all the other cards.
Can you please guide me how to copy a SD hard having a working image to
another using a card reader. Today I tried doing this but the card was
not
being recognised.
Thanks,
Manav
Hi Matt
Additional to below:
I tried to resume normal testing with A as Rx and D as Tx. Now, it seems
I have an offset of about 2 MHz using internal clocks and running
usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am
unable to tune D for the low (2.4 GHz) band anymore. In fact, when I
just tried again I don’t even seem to be able to detect any received
signal even in the high band, and even though it appears to lock on D.
Regards
Ian.
Hi Matt
I have completed the probing as you suggested. The results are in the
following table. Please note that the voltages did not seem to be stable
when I tried reprobing in some cases. An example of this is for R45,
where I give two sets of results for Combo D. Also, please note the
following expanded definitions for comments in the table.
Triangle = The wave looked more like a triangular wave, never really
settling on a fixed high or low level.
Square50 = The wave looked approximately square, with equal time in
low/high states.
Square33 = The wave looked approximately square, with approx. 1/3 time
in the high state, and 2/3 time in the low state.
Results for probing R45:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -12.8 | 100 |
Triangle
B | 933 | 988 | NO | 19.6 | -16 | 100.184 |
Triangle
C | 1159 | 990 | YES | 20.8 | -19.2 | 100 |
Triangle
D(1st)| 1159 | 988 | YES | 21.2 | -20 | 100.125 |
Triangle
D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)|
Triangle
Results for probing R56:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -7.6 | 33.3 |
Square33
B | 933 | 988 | NO | 15.2 | -6 | 33.3 |
Square33
C | 1159 | 990 | YES | 15.2 | -6.8 | 33.3 |
Square33
D | 1159 | 988 | YES | 12 | -11.6 | 49.969 |
Square50
I guess, the difference in the R56 for case D (the only case for which
XCVR 988 was able to set the frequency) may shed some light??? Anyway,
hopefully from these results you will be able to determine which card is
suspected to have the problem.
Thanks
Ian.
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Matt
I have completed the probing as you suggested. The results are in the
following table. Please note that the voltages did not seem to be stable
when I tried reprobing in some cases. An example of this is for R45,
where I give two sets of results for Combo D. Also, please note the
following expanded definitions for comments in the table.
Triangle = The wave looked more like a triangular wave, never really
settling on a fixed high or low level.
Square50 = The wave looked approximately square, with equal time in
low/high states.
Square33 = The wave looked approximately square, with approx. 1/3 time
in the high state, and 2/3 time in the low state.
Results for probing R45:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -12.8 | 100 |
Triangle
B | 933 | 988 | NO | 19.6 | -16 | 100.184 |
Triangle
C | 1159 | 990 | YES | 20.8 | -19.2 | 100 |
Triangle
D(1st)| 1159 | 988 | YES | 21.2 | -20 | 100.125 |
Triangle
D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)|
Triangle
Results for probing R56:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -7.6 | 33.3 |
Square33
B | 933 | 988 | NO | 15.2 | -6 | 33.3 |
Square33
C | 1159 | 990 | YES | 15.2 | -6.8 | 33.3 |
Square33
D | 1159 | 988 | YES | 12 | -11.6 | 49.969 |
Square50
I guess, the difference in the R56 for case D (the only case for which
XCVR 988 was able to set the frequency) may shed some light??? Anyway,
hopefully from these results you will be able to determine which card is
suspected to have the problem.
Thanks
Ian.
Hi Matt
Additional to below:
I tried to resume normal testing with A as Rx and D as Tx. Now, it seems
I have an offset of about 2 MHz using internal clocks and running
usrp2_fft.py on A, when I transmit a BPSK signal from D. Moreover, I am
unable to tune D for the low (2.4 GHz) band anymore. In fact, when I
just tried again I don’t even seem to be able to detect any received
signal even in the high band, and even though it appears to lock on D.
Regards
Ian.
Hi Matt
I have completed the probing as you suggested. The results are in the
following table. Please note that the voltages did not seem to be stable
when I tried reprobing in some cases. An example of this is for R45,
where I give two sets of results for Combo D. Also, please note the
following expanded definitions for comments in the table.
Triangle = The wave looked more like a triangular wave, never really
settling on a fixed high or low level.
Square50 = The wave looked approximately square, with equal time in
low/high states.
Square33 = The wave looked approximately square, with approx. 1/3 time
in the high state, and 2/3 time in the low state.
Results for probing R45:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -12.8 | 100 |
Triangle
B | 933 | 988 | NO | 19.6 | -16 | 100.184 |
Triangle
C | 1159 | 990 | YES | 20.8 | -19.2 | 100 |
Triangle
D(1st)| 1159 | 988 | YES | 21.2 | -20 | 100.125 |
Triangle
D(2nd)| 1159 | 988 | YES | 12 | -15.6 | 99.83(?)|
Triangle
Results for probing R56:
Combo | U2# | XCVR# | Set freq? | Vh (mV) | Vlow (mV) | f (MHz) |
Comment
A | 933 | 990 | YES | 16 | -7.6 | 33.3 |
Square33
B | 933 | 988 | NO | 15.2 | -6 | 33.3 |
Square33
C | 1159 | 990 | YES | 15.2 | -6.8 | 33.3 |
Square33
D | 1159 | 988 | YES | 12 | -11.6 | 49.969 |
Square50
I guess, the difference in the R56 for case D (the only case for which
XCVR 988 was able to set the frequency) may shed some light??? Anyway,
hopefully from these results you will be able to determine which card is
suspected to have the problem.
Thanks
Ian.
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio