# Maximum possible transmission rate through the benchmark code **URL:** \ **Category:** GNU Radio\ **Created:** [May 23, 2012, 6:22pm UTC](https://www.ruby-forum.com/t/maximum-possible-transmission-rate-through-the-benchmark-code/219975 "2012-05-23T18:22:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Gurdipe\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b77776/32.png) [@Gurdipe\_D](https://www.ruby-forum.com/u/Gurdipe_D)\ **Post date:** [May 23, 2012, 6:22pm UTC](https://www.ruby-forum.com/t/maximum-possible-transmission-rate-through-the-benchmark-code/219975/1 "2012-05-23T18:22:22Z")
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. ---
**Author:** ![Nazmul\_I](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@Nazmul\_I](https://www.ruby-forum.com/u/Nazmul_I)\ **Post date:** [May 23, 2012, 6:39pm UTC](https://www.ruby-forum.com/t/maximum-possible-transmission-rate-through-the-benchmark-code/219975/2 "2012-05-23T18:39:48Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) – Alex, _Dreams can come true just believe._ ---
**Author:** ![Nazmul\_I](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/e495f1/32.png) [@Nazmul\_I](https://www.ruby-forum.com/u/Nazmul_I)\ **Post date:** [May 23, 2012, 8:06pm UTC](https://www.ruby-forum.com/t/maximum-possible-transmission-rate-through-the-benchmark-code/219975/3 "2012-05-23T20:06:38Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)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.