Issues with benchmark_tx and benchmark_rx codes

GNU Radio
1

Hello All,

I am trying to measure packet error rates for different modulation
schemes
using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450
USRP2
dughterboard and I am using the UHD_003_002_001 image (That image was
downloaded on June, 2011 from the website, I believe). Now, I am getting
strange results in terms of packet error rate. The benchmark_rx codes
don’t
receive anything for d8psk modulation. It receives packets for dqpsk and
qbpsk, but the work-ability depends on the inputs in a weird way. I am
listing down some of the results that I have observed for different
commands:

Scenario 1:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m
dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05
–gain-mu 0.01

Results: All packets receiverd.

Scenario 2:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m
dbpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dbpsk --costas-alpha 0.05
–gain-mu 0.01

Results: All packets are received as false.( The only difference between
scenario 1 and scenario 2 is the in the increase of --tx-gain (from 20
to
25).)

Scenario 3:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m
dqpsk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05
–gain-mu 0.01

Result: All packets are received as OK. (The difference between scenario
2
and scenario 3 lies in the change of modulation (from dbpsk to dqpsk).)

Scenario 4:

./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m
d8psk

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m d8psk --costas-alpha 0.05
–gain-mu 0.01

Result: No packet gets received. The receiver sits idle waiting for the
packets.

I observed my transmitted signal in the spectrum analyzer and I did not
see
any carrier offset, i.e., the received signal was centered at 2.4 GHz. I
think that the error is coming from either over-saturation of
transmission
signal or the costas-loop at the receiver. At present, I am simply
walking
in the dark and trying random input values to make the schemes work. Is
there any suitable range for these options? (–tx-ampl, --tx-gain,
–costas-alpha, --gain-mu, --rx-gain, etc.)? Please let me know if any
of
you have found a suitable range for these options. Your suggestions will
be
valuable.

Thanks for reading the long email.

Nazmul

–
Muhammad Nazmul I.

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

2

On Wed, Nov 23, 2011 at 1:49 PM, Nazmul I.
[email protected]wrote:

commands:

Thanks for reading the long email.

Nazmul

Nazmul,
You could try upgrading to version 3.5 of GNU Radio. There are a lot of
changes in the digital modulation blocks that might help. There’s still
some work to be done with them, but the recovery loops used are more
stable
to the parameter settings than previously. It should help.

My guess from your post above is that, yes, you are having some issues
with
overloading the transmitters.

Tom

3

On Sat, Nov 26, 2011 at 12:13 PM, Nazmul I.
[email protected]wrote:

daughterboards?

No since this is going to depend more on what USRP and daughterboard you
are using (or some other RF platform if it’s not a USRP). We have not
made
any measurements or analysis of this (and if you do, I hope you will
share
it with the rest of us; since there are manufacturing tolerances on all
of
these, any measurement should also come with a range (max/avg/min)).

So right now, you’re going to have to look at the output of your
transmitter to see if there is any distortion and play with the signal
levels to understand your system’s behaviro.

No, there is nothing on this, yet. You’re right that there should be
though…

For now (so as to be cataloged on this mailing list at least), the
difference between --tx-ampl and --tx-gain is this.

–tx-gain is a USRP/HW setting. It is the gain value (in dB) that is
applied by the analog stages of the USRP and daughterboard.

–tx-ampl is a digital setting that sets the scale of the transmitted
signal. In the UHD world, all signals are between +/-1, so this scaling
factor should be < 1.0.

Tom

4

Hi Tom,

Thanks for the reply. I have a few more question on this regard and also
some additional questions on benchmark_rx and tx.

  1. There is a ‘thres’ parameter in the receive_path.py code, associated
    with the benchmark_rx.py code. The default value is 30. It says, thres =
    30, # in dB, will have to adjust. What does it mean?

  2. Does the ‘packet Ok = true’ in benchmark_rx inherently perform a CRC
    check? I implemented a CRC separately in the received payload, i.e., I
    was
    watching if there is a single bit error in the packet. I saw that
    whenever
    the benchmark_rx says ‘packet Ok = true’, it passes my CRC test and vice
    versa. It can’t be coincidence, can it?

  3. I am using the June 2011 version of gnuradio. My colleague just
    recently
    downloaded the latest version and he is trying to install the firmware
    in
    the SD cards. Now, with that June 2011 version, my benchmark tx and rx
    codes work predictably for gmsk modulation. By predictable, I mean that
    the
    codes work for --tx-ampl ranging from 0.05 to 0.9. At very low and high
    tx
    amplitude, it probably suffers from low signal strength and saturation.
    However, the dbpsk and dqpsk modulation work somewhat randomly, i.e., at
    one moment dbpsk may receive 100% packets at --tx-ampl 0.1. But, in the
    next moment, it may receive all packets as false at --tx-ampl 0.1.
    Therefore, I think that the problem is arising from the phase
    synchronization in the receiver. You talked in great details about
    control
    loop gain variables in
    http://gnuradio.squarespace.com/blog/2011/8/13/control-loop-gain-values.html.
    I just wonder which options in benchmark_rx are associated with these
    variables, i.e., the options that we can control? I can think of
    –costas-alpha, --gain-mu, alpha (in the receive_path.py code). Is there
    any other?

  4. What is the difference between --costas-alpha (benchmark_rx option)
    and
    alpha (given with default value = 0.001 in the receive_path.py code)?

Sorry for the long email. Your feedback will be very appreciated.

Thanks,

Nazmul

On Sat, Nov 26, 2011 at 12:23 PM, Tom R.
[email protected]wrote:

–costas-alpha, etc). For example, the values of alpha and thresh are given

For now (so as to be cataloged on this mailing list at least), the

schemes using benchmark_tx and benchmark_rx codes. I run my codes on
./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 20 -m
./benchmark_tx.py -f 2.4G -r 1M -e eth2 --tx-ampl 0.8 --tx-gain 25 -m
Scenario 3:

packets.
suggestions will be valuable.
some work to be done with them, but the recovery loops used are more stable

–
Muhammad Nazmul I.

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

5

Tom,

Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio
3.5. But I have a few more questions on the options.

  1. Is there a roughly standard range of the option values that one
    should
    use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha,
    –costas-alpha, etc). For example, the values of alpha and thresh are
    given
    as 0.001 and 30 in the receive_path.py program. Shall I change these? If
    so, by how much? Are these values completely dependent on the local
    daughterboards?

  2. Is there any file or document that describe these options in more
    details? From my communication systems course, I can roughly understand
    these options. But some options, e.g. the effect of --tx-ampl versus the
    effect of --tx-gain are not clear to me.

Any feedback will be really appreciated.

Thanks,

Nazmul

On Sat, Nov 26, 2011 at 11:36 AM, Tom R.
[email protected]wrote:

dqpsk and qbpsk, but the work-ability depends on the inputs in a weird

./benchmark_tx.py -f 2.4G -r 1M -e eth2 -m dqpsk --costas-alpha 0.05

transmission signal or the costas-loop at the receiver. At present, I am

Tom

–
Muhammad Nazmul I.

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