Unable to tune Tx or Rx with XCVR2450 on USRP2

dcian · January 28, 2010, 4:57am

Hi All

I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.

The output of this portion of code is “Failed to tune Tx”, and the
frequencies are all 0, with spectrum_inverted being false.

I have also tried to use usrp2_fft.py, and this fails saying nothing is
received on channel 0.

Does anyone know what the problem could be?

Thanks

Ian.

/* try tuning Tx to a test frequency */

        double Fc = 2400000000.0;

        usrp2::tune_result TxTuneResult;

        bool successTx = device->set_tx_center_freq(Fc,

&TxTuneResult);

        if(successTx) {

                             cout << "Tx Tune Successful:\n";

             cout << "    Baseband Frequency: " <<

TxTuneResult.baseband_freq << “\n”;

             cout << "    DxC Frequency: "      <<

TxTuneResult.dxc_freq << “\n”;

             cout << "    Residual Frequency: " <<

TxTuneResult.residual_freq << “\n”;

             cout << "    Spectrum Inverted: "  <<

(TxTuneResult.spectrum_inverted ? “true” : “false”) << “\n”;

        }

        else {

                             cout << "Failed to tune Tx.\n";

             cout << "    Baseband Frequency: " <<

TxTuneResult.baseband_freq << “\n”;

             cout << "    DxC Frequency: "      <<

TxTuneResult.dxc_freq << “\n”;

             cout << "    Residual Frequency: " <<

TxTuneResult.residual_freq << “\n”;

             cout << "    Spectrum Inverted: "  <<

(TxTuneResult.spectrum_inverted ? “true” : “false”) << “\n”;

        }

        cout << "\n";

dcian · January 28, 2010, 6:04am

Ya, its failing for me too…set_tx_center_freq is always failing
(though I
am writing my code in python)…
not able to find the cause…

dcian · January 28, 2010, 11:49pm

On Wed, Jan 27, 2010 at 8:52 PM, Ian H.
[email protected] wrote:
Hi All

I have been trying to set the Tx and Rx frequencies when using an
XCVR2450 with a USRP2, but it seems these keep failing. A snippet of my
source code is below for setting the Tx frequency.
The output of this portion of code is “Failed to tune Tx”, and the
frequencies are all 0, with spectrum_inverted being false.
I have also tried to use usrp2_fft.py, and this fails saying nothing is
received on channel 0.
Does anyone know what the problem could be?

Thanks

Ian.

/* try tuning Tx to a test frequency */
double Fc = 2400000000.0;
usrp2::tune_result TxTuneResult;
bool successTx = device->set_tx_center_freq(Fc,
&TxTuneResult);
if(successTx) {
cout << “Tx Tune Successful:\n”;
cout << " Baseband Frequency: " <<
TxTuneResult.baseband_freq << “\n”;
cout << " DxC Frequency: " <<
TxTuneResult.dxc_freq << “\n”;
cout << " Residual Frequency: " <<
TxTuneResult.residual_freq << “\n”;
cout << " Spectrum Inverted: " <<
(TxTuneResult.spectrum_inverted ? “true” : “false”) << “\n”;
}
else {
cout << “Failed to tune Tx.\n”;
cout << " Baseband Frequency: " <<
TxTuneResult.baseband_freq << “\n”;
cout << " DxC Frequency: " <<
TxTuneResult.dxc_freq << “\n”;
cout << " Residual Frequency: " <<
TxTuneResult.residual_freq << “\n”;
cout << " Spectrum Inverted: " <<
(TxTuneResult.spectrum_inverted ? “true” : “false”) << “\n”;
}
cout << “\n”;

From: Manav Seth [mailto:[email protected]]
Sent: Thursday, 28 January 2010 3:29 PM
To: Ian H.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on >USRP2

Ya, its failing for me too…set_tx_center_freq is always failing
(though I >am writing my code in python)…
not able to find the cause…

Have you been able to get any of the pre-written scripts (e.g.
usrp2_fft.py or usrp_siggen.py) working? I can’t even get those to work.
I tried usrp_siggen.py in verbose this morning and noticed again it was
unable to set the Tx frequency. Also, I think the error I had mentioned
above re usrp2_fft.py would be because the rx frequency couldn’t be set.

I have tried two of the daughtercards on one USRP2, and one of those two
cards on the other USRP2, and still can’t get it to set, though it
worked fine using the same code for the BasicTx and BasicRx.

dcian · January 29, 2010, 2:42am

Actually no…its always returning false…
when I use usrp2_fft.py with -f 1000 then output does come but still it
is
unable to set the initial frequency though it did receive.

I am still trying to figure out the problem…

dcian · January 29, 2010, 3:09am

The -f argument to usrp2_fft.py is the frequency. By putting “-f 1000”
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY outside
of that range. I would suggest you try something like:

usrp2_fft.py -f 5.7G

Matt

dcian · January 29, 2010, 3:17am

Ya…i know…but if i put a legal value…its saying cannot receive on
channel 0…its strainge…but dont know what is happening…
can somebody please help…
its happening with all the example programs…I have also now modified
quite
a few example scripts which are for usrp older version to work with
usrp2…but for them also…its giving the same errors…though they use
to
work with the older usrp…

dcian · January 29, 2010, 3:18am

Hi Matt

I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:

usrp2: channel 0 not receiving
usrp2::rx_sample() failed

I only recently received my USRP2s and XCVR2450s, which were shipped at
the end of December. Are there any known issues with the firmware on the
SD cards at this time, or do you have any other idea why I can’t seem to
tune frequencies on these cards?

Thanks

Ian.

dcian · January 29, 2010, 3:29am

Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/
and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

-Josh

dcian · January 29, 2010, 7:09am

On 01/28/2010 09:17 PM, Ian H. wrote:

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency

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)

dcian · January 29, 2010, 7:14am

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

dcian · January 29, 2010, 6:25am

Thanks Josh

This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says “channel 0 not receiving”. However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can’t be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(…etc…)

Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/

and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

-Josh

On 01/28/2010 06:14 PM, Ian H. wrote:

Hi Matt

I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:

usrp2: channel 0 not receiving
usrp2::rx_sample() failed

I only recently received my USRP2s and XCVR2450s, which were shipped
at
the end of December. Are there any known issues with the firmware on
the
SD cards at this time, or do you have any other idea why I can’t seem
to
Cc: Ian H.; [email protected]
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
USRP2

The -f argument to usrp2_fft.py is the frequency. By putting “-f
1000”
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
it
is unable to set the initial frequency though it did receive.

I am still trying to figure out the problem…

On Thu, Jan 28, 2010 at 3:43 PM, Ian H.
<[email protected]mailto:[email protected]>
wrote:
 On Wed, Jan 27, 2010 at 8:52 PM, Ian H.

<[email protected]mailto:[email protected]>

 wrote:
 Hi All

 I have been trying to set the Tx and Rx frequencies when using

an

 XCVR2450 with a USRP2, but it seems these keep failing. A

snippet

of my

 source code is below for setting the Tx frequency.
 The output of this portion of code is "Failed to tune Tx", and

the

 /* try tuning Tx to a test frequency */
             double Fc = 2400000000.0;
             usrp2::tune_result TxTuneResult;
             bool successTx = device->set_tx_center_freq(Fc,
 &TxTuneResult);
             if(successTx) {
                                  cout<<  "Tx Tune

Successful:\n";

                                  cout<<  "Failed to tune Tx.\n";


  >Ya, its failing for me too...set_tx_center_freq is always

failing

 (though I>am writing my code in python)..
  >not able to find the cause...

 Have you been able to get any of the pre-written scripts (e.g.
 usrp2_fft.py or usrp_siggen.py) working? I can't even get those

to

 cards on the other USRP2, and still can't get it to set, though

it

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

dcian · January 29, 2010, 7:44am

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

dcian · January 29, 2010, 8:42am

Hey Ian,

How did the problem get fixed? I mean what frequency you are setting
with
the “-f” option?

Regards,
Manav

On Thu, Jan 28, 2010 at 10:17 PM, Ian H.

dcian · January 31, 2010, 11:37pm

Hi Manav

I haven’t really fixed it, but rather get a different error. To do this,
I updated to the latest copy of firmware and fpga images as Josh had
suggested.

I am yet to try the debug port and see if it is failing to lock.
Hopefully I can try this today.

Ian.

From: Manav Seth [mailto:[email protected]]
Sent: Friday, 29 January 2010 6:11 PM
To: Ian H.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2

Hey Ian,

How did the problem get fixed? I mean what frequency you are setting
with the “-f” option?

Regards,

Manav

On Thu, Jan 28, 2010 at 10:17 PM, Ian H.
[email protected] wrote:

Thanks Josh

This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says “channel 0 not receiving”. However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can’t be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(…etc…)

Your firmware and fpga images on the sd card are probably out of sync.
You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/

and here are instructions on how to burn:
http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

-Josh

On 01/28/2010 06:14 PM, Ian H. wrote:

Hi Matt

I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
suggest below. In both cases, the fft window opens but no trace is
displayed, and I see the following output in the terminal:

usrp2: channel 0 not receiving
usrp2::rx_sample() failed

I only recently received my USRP2s and XCVR2450s, which were shipped
at
the end of December. Are there any known issues with the firmware on
the
SD cards at this time, or do you have any other idea why I can’t seem
to
Cc: Ian H.; [email protected]
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
USRP2

The -f argument to usrp2_fft.py is the frequency. By putting “-f
1000”
you are telling the system to try to tune the xcvr2450 to 1 kHz. The
specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
it
is unable to set the initial frequency though it did receive.

I am still trying to figure out the problem…

On Thu, Jan 28, 2010 at 3:43 PM, Ian H.
<[email protected]mailto:[email protected]>
wrote:
 On Wed, Jan 27, 2010 at 8:52 PM, Ian H.

<[email protected]mailto:[email protected]>

 wrote:
 Hi All

 I have been trying to set the Tx and Rx frequencies when using

an

 XCVR2450 with a USRP2, but it seems these keep failing. A

snippet

of my

 source code is below for setting the Tx frequency.
 The output of this portion of code is "Failed to tune Tx", and

the

 /* try tuning Tx to a test frequency */
             double Fc = 2400000000.0;
             usrp2::tune_result TxTuneResult;
             bool successTx = device->set_tx_center_freq(Fc,
 &TxTuneResult);
             if(successTx) {
                                  cout<<  "Tx Tune

Successful:\n";

                                  cout<<  "Failed to tune Tx.\n";


  >Ya, its failing for me too...set_tx_center_freq is always

failing

 (though I>am writing my code in python)..
  >not able to find the cause...

 Have you been able to get any of the pre-written scripts (e.g.
 usrp2_fft.py or usrp_siggen.py) working? I can't even get those

to

 cards on the other USRP2, and still can't get it to set, though

it

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

dcian · February 2, 2010, 8:06am

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

dcian · February 2, 2010, 3:17am

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 H. wrote:

Hi Josh

The xcvr has a high band and a low band, which means there is a gap
in

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.

dcian · February 3, 2010, 1:17am

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
else

On 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.

dcian · February 3, 2010, 1:33am

Hi,

The problem I guess is with the SD cards only. Even I was facing the
same
problem. But today I tried with an old SD card and it worked.
I am not able to catch hold of a card reader and the one in my laptop is
not
working.

manav

dcian · February 3, 2010, 1:47am

Hi Manav

I tried both of my daughterboards with the same SD card in the USRP2, so
perhaps we were actually facing different problems, or at least I am
facing an additional problem with one of my cards.

Your problem may be resolved once you try Josh’s earlier suggestion of
reflashing the latest FPGA and firmware images, but of course you will
need an SD card reader to do this. You should be able to find them at
any electronics/photography/home entertainment store, and they are quite
cheap.

Ian.

From: Manav Seth [mailto:[email protected]]
Sent: Wednesday, 3 February 2010 10:54 AM
To: Ian H.
Cc: [email protected]; [email protected]
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on
USRP2

Hi,

The problem I guess is with the SD cards only. Even I was facing the
same problem. But today I tried with an old SD card and it worked.
I am not able to catch hold of a card reader and the one in my laptop is
not working.

manav

On Tue, Feb 2, 2010 at 5:14 PM, Ian H.
[email protected] wrote:

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/
<http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/
%0Alib/> >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
else

On 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.

dcian · February 3, 2010, 2:29am

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.

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.
On Tue, Feb 2, 2010 at 5:43 PM, Ian H. [email protected] >wrote: