Unable to receive using USRP N210, XCVR2450 daughterboards running benchmark programs

GNU Radio
1

Hi All,

I´m new to GNUradio and have run into the basic problem of the receiver
USRP device not being able to decode the senderś transmission. For our
experiments, we used GNUradio (MAJOR_VERSION=3, API_COMPAT=5,
MINOR_VERSION=1) and USRP N210 with XCVR2450 daughterboards, and the
benchmark_tx/rx programs for both narrowband and ofdm. We used the
following transmitter arguments and got the result below:

*./benchmark_tx.py -f 2.4G -r 2M -M 10 -v
*
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0

gr_fir_ccf: using SSE

Modulator:
bits per symbol: 4
RRC roll-off factor: 0.35
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes

No gain specified.
Setting gain to 17.500000 (from [0.000000, 35.000000])

UHD Transmitter:
Args:
Freq: 2.4GHz
Gain: 17.500000 dB
Sample Rate: 1Msps
Antenna: None
Subdev Sec: None

Modulator:
bits per symbol: 4
RRC roll-off factor: 0.35
Tx amplitude 0.25
modulation: psk_mod
bitrate: 2Mb/s
samples/symbol: 2.0000
Differential: True
…(sending the
data)

We invoked the receiver as follows:

./benchmark_rx.py -f 2.4G -r 2M -v

linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-f2388c0

gr_fir_ccf: using SSE

Demodulator:
bits per symbol: 4
RRC roll-off factor: 0.35
FLL bandwidth: 6.28e-02
Timing bandwidth: 6.28e-02
Phase bandwidth: 6.28e-02
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes

No gain specified.
Setting gain to 49.500000 (from [0.000000, 99.000000])

UHD Receiver:
UHD Args:
Freq: 2.4GHz
Gain: 49.500000 dB
Sample Rate: 1Msps
Antenna: None
Spec: None

Demodulator:
bits per symbol: 4
RRC roll-off factor: 0.35
FLL bandwidth: 6.28e-02
Timing bandwidth: 6.28e-02
Phase bandwidth: 6.28e-02

Receive Path:
modulation: psk_demod
bitrate: 2Mb/s
samples/symbol: 2.0000
Differential: True

At this point, even with the transmitter running, the receiver program
pauses for about a minute before bursting into a string of ´O´s. We
found
that our transmission was being detected by the receiving USRP, using
the
uhd_fft.py program. However, an interesting observation was that our
signal
was detected at center frequency 2.401GHz (screenshot attached). We
doubt
if this is due to oscillator differences, since switching the
transmitter
and receiver devices also resulted in detection at the same 2.401GHz
center
frequency.

We tried variations to the above programs by making the
benchmark_rx.pylisten in th 2.401GHz frequency, other modulation
schemes such as qam,
different transmission gains and also the OFDM benchmarks with similar
variations, but there was no output on the receiver. Could it be
possible
that the receiver can detect but cannot decode the signal? Your valuable
advice in this regard would be sincerely appreciated.

Thanks and Regards,
Dhrubojyoti.

2

Dhrubojyoti,

In ur program u have set the Bitrate rate to 2MB/s. It exceeds the
computing power of ur PC that is why u are getting “OOOO”. These ‘O’
means
overflow i.e. USRP is producing data at faster rate than the ability of
PC
to process
Try changing bitrate to 100-500 KB/s

-Adeel

On Sun, Jan 8, 2012 at 4:01 PM, Dhrubojyoti R.

3

Hi Dhrubojyoti,

I also observed the same experimental results, i.e., (1) fail to receive
packets using benchmark programs; (2) 1MHz shift with XCVR2450
daughterboard. Sometimes, the wider bandwidth (or higher sample rate)
and
shifted central frequency help.

Regards,
Lizhao

2012/1/9 Dhrubojyoti R. [email protected]

4

On 31/01/12 09:53 PM, shantharam balasubramanian wrote:

When the transmitter was producing the dots, are you 100% sure that
the packets were gettting transmitted in the first place?

cause i used spectrum analyser and i ran uhd_fft.py, and saw that no
signals were peaking up on that particular frequency. Even Tom had the
same doubt when he visited my lab today, and told me to check if the
transmitter was transmitting the packets. I dont think it does.

So, why not use uhd_siggen.py or similar to produce a simple
single-tone, at a desired frequency, and look for
that. Debug using the simplest tools at your disposal, not the most
complicated ones.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

5

When the transmitter was producing the dots, are you 100% sure that the
packets were gettting transmitted in the first place?

cause i used spectrum analyser and i ran uhd_fft.py, and saw that no
signals were peaking up on that particular frequency. Even Tom had the
same
doubt when he visited my lab today, and told me to check if the
transmitter
was transmitting the packets. I dont think it does.

6

Dear all,

I have fixed the 1MHz frequency shift issue with XCVR2450 daughterboard
after updating my UHD driver to the commit
5b06adb791https://github.com/EttusResearch/UHD-Mirror/commit/5b06adb7911727353938df84a0a6b71cda66c95c.
Now I can receive ofdm packets using ofdm programs in
gr-digital/examples.
Thanks for Josh’s help.

Regards,
Lizhao
5b06adb7911727353938df84a0a6b71cda66c95c
https://github.com/EttusResearch/UHD-Mirror/commit/5b06adb7911727353938df84a0a6b71cda66c95c
https://github.com/EttusResearch/UHD-Mirror/commit/5b06adb7911727353938df84a0a6b71cda66c95c

2012/2/1 You L. [email protected]