A report on dqpsk modulation in gnuradio

GNU Radio
1

Hello, everyone!

I am working on using USRP to realize mutirate transmission. I have
spent these two days trying to transmit data with dqpsk modulation
scheme, and the file I used is python/digital/benchmark_tx.py and
benchmark_rx.py. Below is the conclusion I could reach based on the data
I got:

1, I changed the tx-amplitude to different values ranging from 1000 to
12000 with two USRP 5 feet apart and the rssi values I tested at the
receiver side are quite great, but no matter the tx-amplitude was the
minimum value or the maximum value, the PER was CONSTANT which was
arount 12%. While I was doing these experiments, the size of the packet
was set to 40 which was actually too small.

2, While from the experiments I described above we know the PER was not
changing with the transmission power, after I changed the size of the
packet to 100, the PER was changed to 30%, which was still a CONSTANT
level. After I changed the number of samples per symbol to 4, the PER
was decreased to 20%.

So, it looks like that if the transmission power is large enough, the
PER of dqpsk modulaiton scheme in gnuradio is only related to the packet
size and the samples per symbol, which means dqpsk modulation scheme is
not functioning well in gnuradio, am I right?

Has anybody come across the same problem as me? Is the dqpsk modulation
scheme in gnuradio working fine? Can we use that in our experiment? What
kind of workaround I should do for the dqpsk if it is proved that dqpsk
cannot work as well as dbpsk? Thanks a lot for all!!!

Bill

2

On Tue, 2008-11-25 at 14:55 -0800, Bill S. wrote:

Is the dqpsk modulation scheme in gnuradio working fine?

Bill, there was a recent (yesterday) update to the qpsk demodulator code
that fixed an issue with the carrier offset tracking. Could you please
update to the most recent trunk code and retry your tests?

-Johnathan

3

On Tue, 2008-11-25 at 20:29 -0800, Johnathan C. wrote:

In any case, unless you are willing to use svn and download from our
trunk software, you won’t see an update until 3.1.4 is released.

Forgot to copy the list on this.

-Johnathan

4

From: Johnathan C. [email protected]
To: Bill S. [email protected]
Sent: Tuesday, November 25, 2008 11:29:06 PM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

On Tue, 2008-11-25 at 18:43 -0800, Bill S. wrote:

OMG!!! Thank you for your information, it will be really helpful!!! I
will update my code soon. For updating, do I just need to download the
gnuradio-3.1.3.tar.gz and rebuild it? Thank you!!!

I’m sorry, I hadn’t realized you were using the official release. I
haven’t checked yet whether the bug that was fixed on our “trunk”
software branch exists in that version, so I don’t know if it affected
you.

In any case, unless you are willing to use svn and download from our
trunk software, you won’t see an update until 3.1.4 is released.

-Johnathan

Thank you, Johnathan. Anyway, I would like to use svn and download the
fixed code from the trunk software! Do I just need to type in the
command:
$ svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio
in the terminal?

But, is there anything else I should do after downloading the code? I
would like to devote to the development of our

gnuradio code and I am not scared of sacrificing!

Bill

5

On Mon, Dec 1, 2008 at 1:07 PM, Bill S.
[email protected] wrote:

python benchmark_tx.py -f 2479M -r 2000k -m dqpsk -s 100 (-s 800 or -s 1500)
python benchmark_rx.py -f 2479M -r 2000k -m dqpsk

What is the CPU type and speed you are using? In my experience, data
rates above about 500 kbps are difficult to receive on a typical
laptop platform due to lack of sufficient CPU cycles. On an Intel
Core2 Duo at 2.1 GHz (IBM Thinkpad T60), I can’t go above 800 kbps.
Your rate of 2 Mbps is likely much too high. Are you seeing any “uO”
on your output?

-Johnathan

6

From: Johnathan C. [email protected]
To: Bill S. [email protected]
Sent: Thursday, November 27, 2008 3:02:23 AM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

No problem, Johnathan. After reading this, I did my experimentation in
several different configurations. The commands I used in the transmitter
and receiver side are:
python benchmark_tx.py -f 2479M -r 2000k -m dqpsk -s 100 (-s 800 or -s
1500)
python benchmark_rx.py -f 2479M -r 2000k -m dqpsk

I still got the same result: when packet size is 100, the PER is around
20% no matter what the distance between two USRPs and transmission power
are; when packet size is 800, PER is around 50% and when size is the
default value, PER is around 66%. This result is the same as that I got
before I updated our gnuradio codes. Could you tell me which demo file
you used for your configuration, what your configuration looks like and
what kind of commands you used for your Tx and Rx part? Thank you so
much!!!

Bill

On Wed, Nov 26, 2008 at 3:39 PM, Bill S.
[email protected] wrote:

Hello, Johnathan. I have implemented the entire codes in the trunk step by
step, but unfortunately this time I cannot receive any correct packets under
the dqpsk modulation scheme even after I set the packet size to 40.
Actually, before I installed the SVN codes, I was able to get 90% correct
packets when I set the packet size to 40 and samples per symbol to 4, but
this time it failed sadly. Is there anything going wrong in your new carrier
offset tracking tactics? Thank you!

This code is working correctly in a number of different configurations
in my lab.

Unfortunately, I will be out of the office for the rest of the week
and early next week, so will be unable to assist you further.

-Johnathan

7

On Thu, Dec 4, 2008 at 1:04 PM, Bill S.
[email protected] wrote:

-r 400k -s 1500: 50% of the transmitted packets are received, but 0 right.

For comparison purposes, can you try using the GMSK modulation? Just
remove the ‘-m dqpsk’ from the command line.

-Johnathan

8

From: Johnathan C. [email protected]
To: Bill S. [email protected]
Cc: [email protected]
Sent: Wednesday, December 3, 2008 2:57:55 PM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

Thank you, Johnathan! I did my experimentation again with different
configuration. Below are the arguments I used for my experimentation:

-r 400k -s 1500: 50% of the transmitted packets are received, but 0
right. The received packet number increased continuously.

-r 400k -s 500: 66% of the transmitted packets are received, but 0
right. The received packet number increased continuously.

-r 400k -s 300: 71% of the transmitted packets are received, but 0
right. The received packet number increased continuously.

-r 400k -s 200: 93.6% of the transmitted packets are received, but 0
right. The received packet number increased irregularly.

One USRP is controlled by my laptop (Compaq Presario C700, 1.46GHz
Dual-Core Pentium, 1GB RAM), which is used for Tx and another USRP is
handled by a desktop (Gateway, 2.40GHz, Core 2 Dual, 2GB RAM), which is
used for Rx. The two USRP are 3m apart from each other. The reason why
we used 2Mbps for dqpsk case was that when the bit rate is up to 2Mbps,
the PER ratio could somehow reach its ‘minimum value’, and there is no
uO sign on my desktop PC, but there was one or two uU signs on my laptop
part when s is set to 100. I really cannot figure out why I cannot get
dqpsk scheme done when you have successfully verified it works fine in
your configuration. I am totally confused, is there anything wrong with
my setup described above, Johnathan? I really need guidance. Thank
you!!!

BillÂ

On Mon, Dec 1, 2008 at 1:07 PM, Bill S.
[email protected] wrote:

python benchmark_tx.py -f 2479M -r 2000k -m dqpsk -s 100 (-s 800 or -s 1500)
python benchmark_rx.py -f 2479M -r 2000k -m dqpsk

What is the CPU type and speed you are using? In my experience, data
rates above about 500 kbps are difficult to receive on a typical
laptop platform due to lack of sufficient CPU cycles. On an Intel
Core2 Duo at 2.1 GHz (IBM Thinkpad T60), I can’t go above 800 kbps.
Your rate of 2 Mbps is likely much too high. Are you seeing any “uO”
on your output?

-Johnathan

9

From: Johnathan C. [email protected]
To: Bill S. [email protected]
Cc: [email protected]
Sent: Thursday, December 4, 2008 6:25:24 PM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

On Thu, Dec 4, 2008 at 1:04 PM, Bill S.
[email protected] wrote:

-r 400k -s 1500: 50% of the transmitted packets are received, but 0 right.

For comparison purposes, can you try using the GMSK modulation? Just
remove the ‘-m dqpsk’ from the command line.

-Johnathan

Johnathan,

IÂ tried gmsk and dbpsk once again, the results of PERÂ are shown below:

for gmsk:

-r 400k -s 200Â nearly 100% right
-r 400k -s 500 nearly 98% right
-r 400k -s 1500 nearly 97% right

for dbpsk: all of the cases gave almost 0% PER, which means
communication were very good!

Johnathan, could you tell me the detailed configurations of your setup,
for example, which demo files were you using, what were the arguments
you used for your transmission? I also hope the data I got is useful for
your development. Thank you!!!

Bill Â

10

From: Bill S. [email protected]
To: Johnathan C. [email protected]
Cc: [email protected]
Sent: Thursday, December 4, 2008 9:57:02 PM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

From: Johnathan C. [email protected]
To: Bill S. [email protected]
Cc: [email protected]
Sent: Thursday, December 4, 2008 6:25:24 PM
Subject: Re: [Discuss-gnuradio] a report on dqpsk modulation in gnuradio

On Thu, Dec 4, 2008 at 1:04 PM, Bill S.
[email protected] wrote:

-r 400k -s 1500: 50% of the transmitted packets are received, but 0 right.

For comparison purposes, can you try using the GMSK modulation? Just
remove the ‘-m dqpsk’ from the command line.

-Johnathan

Johnathan,

I tried gmsk and dbpsk once again, the results of PER are shown below:

for gmsk:

-r 400k -s 200 nearly 100% right
-r 400k -s 500 nearly 98% right
-r 400k -s 1500 nearly 97% right

for dbpsk: all of the cases gave almost 0% PER, which means
communication were very good!

Johnathan, could you tell me the detailed configurations of your setup,
for example, which demo files were you using, what were the arguments
you used for your transmission? I also hope the data I got is useful for
your development. Thank you!!!

Bill

Hello, Johnathan,

I also checked the new code once again, but could not find any mistake
in the code. Actually, the members in my team are mainly focusing on
communications or networkings, and we do not have any computer guy. We
just want to use USRPs system to realize a new idea in Communication
Networking, but the results from dqpsk make us frustrated. Does any
other USRP fan have the same problem as us? How could we overcome this
problem, and is there any work around that could take effect? Thank
you!!!

Bill

11

On Sat, Dec 6, 2008 at 12:29 PM, Bill S.
[email protected] wrote:

Johnathan, could you tell me the detailed configurations of your setup, for
example, which demo files were you using, what were the arguments you used
for your transmission? I also hope the data I got is useful for your
development. Thank you!!!

The likely culprit here is the default values of the frequency/phase
tracking loop and bit timing recovery gain parameters. There really
isn’t a one size fits all value for these.

These are configured on the command line of benchmark_rx.py:

–costas-alpha=xxx
–gain-mu=xxx

Try setting the first to 0.05 and the second to 0.001 as a starting
point; these are what I use successfully with otherwise default
parameters. Unfortunately, tweaking these is a trial and error
process; the correct values depend on your USRP crystal stability,
receiver signal to noise ratio, and samples per symbol value.

-Johnathan

12

Hi,

just a different suggestion - have you tried to determine if there is a
frequency offset between the receiving and the sending USRP? I did some
tests
with the digital/benchmark_?x.py / qpsk code before the recent changes,
but
for me it worked quite well when I adjusted the center frequency of the
transmitter or the receiver by their respective offset, eg:

./benchmark_tx -f 2.40001e9 …
./benchmark_rx -f 2.4e9 …

To measure the offset, I built simple flowgraph with a constant value as
a
signal source, which gives just a carrier, which should be (in an ideal
world) at the selected center frequency, visible e.g. in usrp_fft.py

Hope this helps,

Stefan

–
Stefan Brüns / Bergstraße 21 / 52062 Aachen
mailto:lurch at gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/
phone: +49 241 53809034 mobile: +49 151 50412019