Xcvr2450, v3.2 and usrp1

GNU Radio
1

Hi I am using Gnuradio v3.2 and usrp1.

I was using modified examples\digital\transmit_path, receive_path to
send and receive packets on the RFX2400. This was working alright.

I wanted more transmit power (+ adjustable gain) so I exchanged the
RFX2400 boards for XCVR2450 boards. However when I run my packet
transmitter program (which worked fine with RFX2400) the XCVR2450 boards
did not transmit! The program was not reporting any errors, but looking
at on usrp_fft or on a spectrum analyser, no signal was being output.
Likewise with my receiver: running usrp_fft with the XCVR2450 it could
not pick up signals.

Do I need to add in extra things to my code to get it to work with
XCVR2450 boards? I set the gain on the subdevs to maximum. Do XCVR2450
boards work with usrp1 and gnuradio v3.2?

Another question: When I transmit a packet it should occupy only a
limited bandwidth from the RRC filter. However in actual fact, running
it causes quite a jump in the noise floor. I also noticed with siggen
that there were considerable sidebands/harmonics being produced. Is
there a way to reduce or eliminate effect of packet raised noise floor /
harmonics?

I am working at ~2.4/2.5GHz (since my antennae work at this frequency,
although I am currently swapping between antennae and SMA cables)

2

Here is my console output for a transmit program:
The XCVR2450 doesn’t transmit.

python rx2_pu_tx.py -f 2.4G
xcvr2450: Setting reg 2 to 30072
xcvr2450: Setting reg 5 to 38225
xcvr2450: Setting reg 5 to 38A25
xcvr2450: Setting reg 6 to 4006
xcvr2450: Setting reg 7 to 627
xcvr2450: Setting reg 8 to 1C218
xcvr2450: Setting reg 9 to 68B9
xcvr2450: Setting reg 10 to 3C0A
xcvr2450: Setting reg 11 to 10B
xcvr2450: Setting reg 12 to 3FC
xcvr2450: Setting reg 3 to 963
xcvr2450: Setting reg 4 to 4
xcvr2450: Setting reg 5 to 38225
xcvr2450: Setting reg 5 to 38A25

tx tune result:
baseband freq: 2400000000.000000
dxc freq: -0.000000
residual freq: -0.000000

gr_fir_ccf: using SSE
xcvr2450: Setting reg 12 to 3FC
modulation: dbpsk
Channel freq: 2.4G
RX/TX bitrate: 250kb/sec
samples/symbol: 2
TX interp: 256
original_payload = 01:01:01
uUuUuU^Z
Suspended

3

The xcvr transmits at the incorrect frequency. I just looked at it with
a wider span of the spectrum analyser. Asking it to transmit at 2.45GHz,
it instead transmits signals at 2.58GHz. What could be causing this?

4

On Mon, Jun 22, 2009 at 06:30:26AM +0200, William Sherman wrote:

The xcvr transmits at the incorrect frequency. I just looked at it with
a wider span of the spectrum analyser. Asking it to transmit at 2.45GHz,
it instead transmits signals at 2.58GHz. What could be causing this?

Not sure.

Try using:

$ usrp_sigggen.py -f 2.45G --const -a 8000

Eric

5

On Mon, Jun 22, 2009 at 14:08, William Sherman[email protected]
wrote:

$ usrp_sigggen.py -f 2.45G --const -a 8000

No it still transmits at 2.58GHz.

I’ve confirmed normal operation with release 3.2 and the current trunk
in my lab.

What concerns me is that in your original email, there is debugging
output on the screen. This was disabled before the 3.2 release, so it
is possible you have a mixed installation, with some old files still
on the install path when you installed 3.2.

Can you elaborate on how you installed 3.2, and whether there was a
prior installation before that? If so, did you uninstall it first
before installing 3.2?

Johnathan

6

Eric B. wrote:

On Mon, Jun 22, 2009 at 06:30:26AM +0200, William Sherman wrote:

The xcvr transmits at the incorrect frequency. I just looked at it with
a wider span of the spectrum analyser. Asking it to transmit at 2.45GHz,
it instead transmits signals at 2.58GHz. What could be causing this?

Not sure.

Try using:

$ usrp_sigggen.py -f 2.45G --const -a 8000

Eric

No it still transmits at 2.58GHz.

I guess there’s a problem with db_xcvr2450.cc?

Here is the db_xcvr2450.cc set_freq code in my gnuradio 3.2
installation:

struct freq_result_t
xcvr2450::set_freq(double target_freq)
{
struct freq_result_t args = {false, 0};

double scaler;

if(target_freq > 3e9) {
d_five_gig = 1;
d_ad9515_div = 3;
scaler = 4.0/5.0;
}
else {
d_five_gig = 0;
d_ad9515_div = 3;
scaler = 4.0/3.0;
}

if(target_freq > 5.408e9) {
d_highband = 1;
}
else {
d_highband = 0;
}

double vco_freq = target_freq*scaler;
double sys_clk = usrp()->fpga_master_clock_freq(); // Usually 64e6
double ref_clk = sys_clk / d_ad9515_div;

double phdet_freq = ref_clk/d_ref_div;
double div = vco_freq/phdet_freq;
d_int_div = int(floor(div));
d_frac_div = int((div-d_int_div)65536.0);
// double actual_freq =
phdet_freq(d_int_div+(d_frac_div/65536.0))/scaler;

//printf(“RF=%f VCO=%f R=%d PHD=%f DIV=%3.5f I=%3d F=%5d ACT=%f\n”,
// target_freq, vco_freq, d_ref_div, phdet_freq,
// div, d_int_div, d_frac_div, actual_freq);

set_gpio();
set_reg_int_divider();
set_reg_frac_divider();
set_reg_bandselpll();

args.ok = lock_detect();
#ifdef NO_LO_OFFSET
args.baseband_freq = target_freq;
#else
args.baseband_freq = actual_freq;
#endif

if(!args.ok){
printf(“Fail %f\n”, target_freq);
}
return args;
}

7

On Tue, Jun 23, 2009 at 11:13, Johnathan
Corgan[email protected] wrote:

You may also have a mismatch between the 3.2 host code and the
firmware installed on the USRP2 SD card. Please ensure you are using
the firmware and FPGA image for 3.2 posted at:

I see now that you’re using USRP1, never mind.

Johnathan

8

On Mon, Jun 22, 2009 at 17:59, Johnathan
Corgan[email protected] wrote:

I’ve confirmed normal operation with release 3.2 and the current trunk
in my lab.

You may also have a mismatch between the 3.2 host code and the
firmware installed on the USRP2 SD card. Please ensure you are using
the firmware and FPGA image for 3.2 posted at:

http://gnuradio.org/releases/usrp2-bin/release

There is a situation which results in tuning 12.5MHz higher than what
you request, if you are using 3.2 with older firmware.

Johnathan

9

Johnathan C. wrote:

Can you elaborate on how you installed 3.2, and whether there was a
prior installation before that? If so, did you uninstall it first
before installing 3.2?

Previously I had v3.1.3 installed. This was uninstalled (all packages
removed) before installing v3.2 following the NetBSD build guide.

What concerns me is that in your original email, there is debugging
output on the screen. This was disabled before the 3.2 release, so it
is possible you have a mixed installation, with some old files still
on the install path when you installed 3.2.

I looked at the v3.2 firmware. In
gnuradio-3.2/usrp/host/lib/legacy/db_xcvr2450.cc line:375 the debugging
output of setting reg is not commented out:

void
xcvr2450::send_reg(int v)
{
// Send 24 bits, it keeps last 18 clocked in
char c[3];
c[0] = (char)((v >> 16) & 0xff);
c[1] = (char)((v >> 8) & 0xff);
c[2] = (char)((v & 0xff));
std::string s(c, 3);

usrp()->_write_spi(0, d_spi_enable, d_spi_format, s);
printf(“xcvr2450: Setting reg %d to %X\n”, (v&15), v);
}

In the usrp2 firmware it is commented out.

Are the xcvr2450 boards supposed to be able to be used with the usrp1 ?

10

OK I just did a full fresh reinstall of 3.2 (redownloaded from
http://gnuradio.org/trac/wiki/Download
ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.2.tar.gz) onto my NetBSD
machine and I still get:

Johnathan C. wrote:

On Mon, Jun 22, 2009 at 14:08, William Sherman[email protected]
wrote:

� $ usrp_sigggen.py -f 2.45G --const -a 8000

No it still transmits at 2.58GHz.

11

On Tue, Jun 23, 2009 at 17:37, William Sherman[email protected]
wrote:

I looked at the v3.2 firmware. In
gnuradio-3.2/usrp/host/lib/legacy/db_xcvr2450.cc line:375 the debugging
output of setting reg is not commented out:

You’re right. This was a missed merge from the trunk into the release
branch. However, the only difference between these two versions of
db_xcvr2450.cc is this line (commented out on the trunk.) I’ll fix
this for 3.2.1, however, it doesn’t make any functional difference in
the board operation.

Are the xcvr2450 boards supposed to be able to be used with the usrp1 ?

Yes. Earlier I confirmed proper tuning on transmit and receive in my
lab with the XCVR2450 and USRP1 and USRP2, using the development trunk
software (which, in this area, is identical still to the 3.2 release,
except for the commented line above.)

Johnathan

12

I would also like to report that when running

� $ usrp_sigggen.py -f 2.45G --const -a 8000

I get a big peak at 2.58GHz when looking at the plug connected to subdev
(0,0) on the spectrum analyzer, and a smaller peak at 2.58Ghz when
looking at (0,1). The mux setting the program automatically uses is: mux
= 0x89

13

On Thu, Jun 25, 2009 at 18:17, William Sherman[email protected]
wrote:

I managed to get the board to transmit at the frequency I want by
reverting to the db_xcvr2450 code existing before Changeset 10853
(r10400, r10165) [see http://gnuradio.org/trac/changeset/10853].

Thanks for the update. I’ll take a look at this changeset again to
see if there is anything that could cause your symptoms, though I am
unable to reproduce them here, and have normal operation of the
XCVR2450 with the 3.2 release and with the current development trunk.

Johnathan

14

Hi,

I managed to get the board to transmit at the frequency I want by
reverting to the db_xcvr2450 code existing before Changeset 10853
(r10400, r10165) [see http://gnuradio.org/trac/changeset/10853].