Maximum possible transmission rate through the benchmark code

Hello,

I am running the benchmark_tx and benchmark_rx codes of the narrowband
and
ofdm folder (gr-digital/examples) between two USRP2’s. I have several
questions regarding the maximum possible transmission rate in these two
codes. I am listing the questions and my experiment details below:

USRP2 with GB Ethernet cable
Daughterboard: RFX400 (on the transmitter side) and FLEX400 (on the
receiver side)
GNUradio version: latest (downloaded on May 21, 2012)
Ubuntu: 12.04

Question 1: I ran the benchmark_tx.py OFDM code at 20 MHz bandwidth at
the
transmitter side and uhd_fft.py at the receiver side. The spectrum
analyzer
of the uhd_fft could correctly (approximately) estimate the power level
of
the received signal in the frequency domain. (I used a real spectrum
analyzer to check it). I read in the GNUradio tutorials that the FPGA
down-converts
the signal to 8 Mega complex samples per second for USB 2.0
compatibility.
Then how could I observe a signal with 20 MHz bandwidth in the uhd_fft
spectrum analyzer? I used the following commands:

./benchmark_tx.py -f 450M -W 25M --occupied-tones 400 -M 20M

./uhd_fft -s 25M

Question 2: When I was trying to receive the packets that were sent with
20
MHz bandwidth, I saw overrun in the receiver. I assume that the receiver
side computer is not fast enough to keep up with 20 MHz bandwidth. Then
how
could it detect the strength of the signal in the entire 20 MHz region?
Can
I record and store the received signal (with 20 MHz bandwidth) in the
time
domain just using the gnuradio softwares? (i.e. without doing any FPGA
programming)

Question 3: I tried to run the benchmark_tx.py code of the narrowband
folder at 20 Mbit/sec. But the code was showing underrun whenever the
bit
rate exceeded 6 Mbit/sec. I used the following command:

./benchmark_tx.py -f 450M -r 7M -M 20

The ofdm transmitter code is keeping up with high bandwidth but the
narrowband tx code is not. I just wonder what the reason might be.

Feedback on any of the questions will be highly appreciated. Thanks for
reading the email.

Nazmul


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

Nazmul,

Seems you are doing the similar experiment with me.

In my test for both OFDM and narrowband, the 20MHz bandwidth is too wide
to
be supported by my computer.

For OFDM, I am using the tunnel.py to test the ping, unfortunately, most
of
the time, the ARP query fails. So I have to use the static ARP to save
traffic. And when the bandwidth is more than 1.2MHz, the
dual-way communications suffers from overflow. The ping packet loss
reaches
30% even when the bandwidth is 500KHz. Some friends suggest to adjust
the
tx-amplitude due to high PAPR of OFDM, I tried the 0.2-0.3, but it does
not
help a lot. You can search the archive for my testing result and
complaining days ago. I have been querying for the performance for days
but
no latest reported result yet. Some students using the GNURadio as
master
thesis, ever reported that only 100kbps can be reached over GNURadio
provided OFDM.

For narrowband, GMSK, the life is much better. The tunnel.py runs with
bitrate up to 3Mbps, with 1% packet loss of ping test. Your result is
better than me.

On Wed, May 23, 2012 at 11:20 AM, Nazmul I.
[email protected]wrote:

GNUradio version: latest (downloaded on May 21, 2012)
Then how could I observe a signal with 20 MHz bandwidth in the uhd_fft
I record and store the received signal (with 20 MHz bandwidth) in the time
The ofdm transmitter code is keeping up with high bandwidth but the
Muhammad Nazmul I.
Discuss-gnuradio Info Page

Alex,
Dreams can come true just believe.

Alex,

Thanks for the email. I think that the high bitrate occuring at OFDM and
modulations except gmsk come mostly from peak to average power ratio
issues. GMSK works best for everyone, I guess.

I am just surprised to see how the uhd_fft.py is measuring the signal
strength in the 20 MHz band. I thought that the FPGA only allows 8 MHz
complex samples per second. Besides, I wonder why the narrowband
benchmark_tx shows underrun at 10 Mega Hz bandwidth whereas the OFDM
benchmark_tx doesn’t show this issue at the same bit rate.

Thanks,

Nazmul

On Wed, May 23, 2012 at 12:38 PM, Alex Z.
[email protected]wrote:

dual-way communications suffers from overflow. The ping packet loss reaches
better than me.

codes. I am listing the questions and my experiment details below:
analyzer of the uhd_fft could correctly (approximately) estimate the power

folder at 20 Mbit/sec. But the code was showing underrun whenever the bit

Alex,
Dreams can come true just believe.


Muhammad Nazmul I.

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.