QPSK phase noise

GNU Radio
1

Dear All,

I am trying to demod a qpsk from another USRP but with the setup below I
get
a really noisy constellation:

http://img231.imageshack.us/img231/2465/screenshotysh.png

The 2 USRPs are connected via a SMA cable with 40 db attenuators and DC
blocker.
I have also played with the costas alpha, samples per symbol, gain mu,
frequency fine tunning and this is the best result I can get.

./benchmark_tx.py -m dqpsk -f 1.25G -m dqpsk --tx-amplitude=10000 -r 1M
-M
99999999 --excess-bw=0.35
./benchmark_rx.py -r 1M -m dqpsk --log --costas-alpha=0.05 -S 4
–verbose -r
1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G

Thanks for your help.

–
View this message in context:
http://www.nabble.com/QPSK-phase-noise-tp22934944p22934944.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

Dear All, I’m looking for a processing block to calculate the medium
value of a signal. In fact, I should implement the expression attached.
Is there anybody here who knows the block I’m looking for? Thanks for
your help.

–

Alysson Vasconcelos Gomes de Menezes
Graduando em Engenharia Elétrica
Universidade Federal de Campina Grande - www.ufcg.edu.br
Centro de Engenharia Elétrica e Informática - www.ceei.ufcg.edu.br

3

On Tue, Apr 07, 2009 at 11:07:54AM -0700, Paco G. wrote:

I have also played with the costas alpha, samples per symbol, gain mu,
frequency fine tunning and this is the best result I can get.

./benchmark_tx.py -m dqpsk -f 1.25G -m dqpsk --tx-amplitude=10000 -r 1M -M
99999999 --excess-bw=0.35
./benchmark_rx.py -r 1M -m dqpsk --log --costas-alpha=0.05 -S 4 --verbose -r
1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G

Thanks for your help.

Are you getting overruns (“uOuO”) on the rx side?
If so, try running at a lower data rate, say 500k.

Eric

4

Thanks for your email Eric,

no, there is no underrun or overrun, the CPU usage is really low (even
with
the loggin activated), i am running it on a i7 processor.

you usually get a much sharper constellation, don’t u?

5

Thanks for your email Eric,

no, there is no underrun or overrun neither at the Tx or Rx side, the
CPU
usage is really low (even with the loggin activated), i am running it on
a
intel i7 processor.

you usually get a much sharper constellation, don’t u?

On Tue, Apr 07, 2009 at 11:07:54AM -0700:

Are you getting overruns ("uOuO") on the rx side?
If so, try running at a lower data rate, say 500k.

Eric

–
View this message in context:
http://www.nabble.com/QPSK-phase-noise-tp22934944p22935373.html
Sent from the GnuRadio mailing list archive at Nabble.com.

6

On Tue, Apr 7, 2009 at 11:49 AM, Paco G. [email protected] wrote:

you usually get a much sharper constellation, don’t u?

That depends on your overall SNR. I’d suggest trying lowering your
transmit power, as the amplitude you are using is driving the RFX into
non-linearity, and with the raised cosine filter you are using, the
modulation is no longer constant envelope, so you are generating
unnecessary distortion. The RFX boards typically remain linear up to
an output amplitude of about 2000.

Similarly, on receive, it looks like you are using the default
mid-point gain of the RFX, which likely too high for a path loss of
only 40dB. I’d suggest experimenting with lower receive gains to see
if things improve.

Johnathan

7

Johnathan, you were right with the distortion issue at the TX, I am now
using
these parameters:

./benchma-m dqpsk -f 1.25G -m dqpsk --tx-amplitude=500 -r 1M -M 99999999
–excess-bw=0.35
./benchmark_rx.py -r 1M -m dqpsk --log --costas-alpha=0.05 -S 4
–verbose -r
1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G --rx-gain=45

But still, for a 40dB SNR (
http://img149.imageshack.us/img149/4583/screenshot4h.png ) I think we
should
get a much better constellation than this one (
http://img149.imageshack.us/img149/7968/screenshot3t.png )

I am using the latest gnuradio trunk and the
…/gnuradio-examples/digital/benchmark…
I have disabled all the data loggins but the rx_receiver.dat from the
/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/dqpsk.py to
reduce
the computational requirements.

I tried the 0.5M as eric suggested but the results are even worse (
http://img18.imageshack.us/img18/2306/screenshot5hhm.png )

The 2M rate constellation is the same as 1M.

If I go with BPSK, I get this:
http://img212.imageshack.us/img212/3010/screenshot10.png
using
./benchmark_tx.py -m dbpsk -f 1.25G -m dbpsk --tx-amplitude=500 -r 200k
-M
99999999 --excess-bw=0.35
./benchmark_rx.py -m dbpsk --verbose -S 4 -r 200k --excess-bw=0.35 -f
1.25G
–rx-gain=30 > debug

The image below shows the costas loop error:
( http://img156.imageshack.us/img156/1521/screenshot11.png )
(zoom frequency >
http://img514.imageshack.us/img514/2173/screenshot12.png )
blue: phase
red: phase_error
cian: Q
purple: I
green: freq

So once the costas locks, there is still some error which is causing the
blur constellation. But I think that for an almost 40dB SNR signal (
http://img212.imageshack.us/img212/551/screenshot13.png ) we should get
much
better results.

The M&M block influences a lot, if I change the samples per symbol to 2
I
get this: ( http://img201.imageshack.us/img201/9436/screenshot14.png )

I have also tried via air interface getting similar results. My question
is
whether this is normal for the mpsk gnuradio block receiver
implementation
or I am doing something wrong.

What are your thoughts about this?

Thank you for your time.

–
View this message in context:
http://www.nabble.com/QPSK-phase-noise-tp22934944p22950446.html
Sent from the GnuRadio mailing list archive at Nabble.com.

8

Hi,

We can output the data to a sink file, from which we load the data using
Matlab. Then we use scatterplot.

Thanks!

Bill

From: yufeng wang [email protected]
To: Bill S. [email protected]
Sent: Friday, April 10, 2009 12:22:15 PM
Subject: Re: [Discuss-gnuradio] QPSK phase noise

Hi, Bill,

Regarding to Paco’s images, I wonder which programme did you use to
display the output of the images that he had got? like the
constellations?

I’m using benchmark.py to transmit and receive BPSK signals. I can use
usrp_fft.py to display the output of the transmitter. Thanks in
advance!

On Fri, Apr 10, 2009 at 12:03 PM, Bill S.
[email protected] wrote:

Sent: Wednesday, April 8, 2009 9:26:36 AM
1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G --rx-gain=45
the computational requirements.
99999999 --excess-bw=0.35
green: freq
whether this is normal for the mpsk gnuradio block receiver implementation

–
Best wishes,

Yufeng

9

Hi, Paco

Actually, I got the similar result as you did. I think there was
something wrong in the mpsk_receiver block. I am checking it. Thanks!

Bill

From: Paco G. [email protected]
To: [email protected]
Sent: Wednesday, April 8, 2009 9:26:36 AM
Subject: Re: [Discuss-gnuradio] QPSK phase noise

Johnathan, you were right with the distortion issue at the TX, I am now
using
these parameters:

…/benchma-m dqpsk -f 1.25G -m dqpsk --tx-amplitude=500 -r 1M -M
99999999
–excess-bw=0.35
…/benchmark_rx.py -r 1M -m dqpsk --log --costas-alpha=0.05 -S 4
–verbose -r
1M --gain-mu=0.01 --excess-bw=0.35 -f 1.25G --rx-gain=45

But still, for a 40dB SNR (
http://img149.imageshack.us/img149/4583/screenshot4h.png ) I think we
should
get a much better constellation than this one (
http://img149.imageshack.us/img149/7968/screenshot3t.png )

I am using the latest gnuradio trunk and the
…/gnuradio-examples/digital/benchmark…
I have disabled all the data loggins but the rx_receiver.dat from the
/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/dqpsk.py to
reduce
the computational requirements.

I tried the 0.5M as eric suggested but the results are even worse (
http://img18.imageshack.us/img18/2306/screenshot5hhm.png )

The 2M rate constellation is the same as 1M.

If I go with BPSK, I get this:
http://img212.imageshack.us/img212/3010/screenshot10.png
using
…/benchmark_tx.py -m dbpsk -f 1.25G -m dbpsk --tx-amplitude=500 -r 200k
-M
99999999 --excess-bw=0.35
…/benchmark_rx.py -m dbpsk --verbose -S 4 -r 200k --excess-bw=0.35 -f
1.25G
–rx-gain=30 > debug

The image below shows the costas loop error:
( http://img156.imageshack.us/img156/1521/screenshot11.png )
(zoom frequency >
http://img514.imageshack.us/img514/2173/screenshot12.png )
blue: phase
red: phase_error
cian: Q
purple: I
green: freq

So once the costas locks, there is still some error which is causing the
blur constellation. But I think that for an almost 40dB SNR signal (
http://img212.imageshack.us/img212/551/screenshot13.png ) we should get
much
better results.

The M&M block influences a lot, if I change the samples per symbol to 2
I
get this: ( http://img201.imageshack.us/img201/9436/screenshot14.png )

I have also tried via air interface getting similar results. My question
is
whether this is normal for the mpsk gnuradio block receiver
implementation
or I am doing something wrong.

What are your thoughts about this?

Thank you for your time.

–
View this message in context:
http://www.nabble.com/QPSK-phase-noise-tp22934944p22950446.html
Sent from the GnuRadio mailing list archive at Nabble.com.

10

Hello everybody. I was trying to use the gnuradio complex_to_float ()
block just to understand its functioning. Unfortunately, the conversion
not happened and apparently there was no problem. The code is below.
What’s the problem with this so simple code?
One more thing, it would be so helpful a dictionary with all
the gnuradio blocks and usage examples. Examples are fundamental to help
us reach a good level to be able to contribute for the gnuradio project,
without waste so much time. Thank you very much.

#!/usr/bin/env python

from gnuradio import gr, eng_notation, gru, window, blks
from gnuradio import audio
from gnuradio import usrp
from gnuradio.eng_option import eng_option
from optparse import OptionParser
from gnuradio import gr_unittest

class my_graph(gr.flow_graph):

def __init__(self):
gr.flow_graph.__init__(self)

self.data = (1, 2, 3)
self.converte = gr.complex_to_float()
self.src = gr.vector_source_c (self.data)
self.vetor2 = gr.vector_sink_f ()

raw_input (self.data)

self.connect (self.src, (self.converte,0))
self.connect ((self.converte,0), self.vetor2)

self.rst = self.vetor2.data ()

raw_input (self.rst)

if name == ‘main’:
try:
my_graph().run()
except KeyboardInterrupt:
pass

–

Alysson Vasconcelos Gomes de Menezes
Graduando em Engenharia Elétrica
Universidade Federal de Campina Grande - www.ufcg.edu.br
Centro de Engenharia Elétrica e Informática - www.ceei.ufcg.edu.br

11

On Mon, May 25, 2009 at 09:34:51PM +0300, Alysson Menezes wrote:

Hello everybody. I was trying to use the gnuradio complex_to_float
() block just to understand its functioning. Unfortunately, the
conversion not happened and apparently there was no problem. The
code is below. What’s the problem with this so simple code?

Hi Alysson,

I’ve attach a modified version of your code that works with GNU Radio
3.1 and 3.2. I suggest that you try using the 3.2 release.

If you happen to be running Ubuntu 9.04 (Jaunty) you can download
prebuilt binaries:

http://gnuradio.org/trac/wiki/DebianPackages

Otherwise, please download the source and build it:

http://gnuradio.org/trac/wiki/Download
http://gnuradio.org/trac/wiki/BuildGuid

One more thing, it would be so helpful a dictionary with all the
gnuradio blocks and usage examples. Examples are fundamental to help
us reach a good level to be able to contribute for the gnuradio
project, without waste so much time. Thank you very much.

http://gnuradio.org/doc/doxygen/index.html
http://gnuradio.org/doc/doxygen/modules.html

There are many examples, see

gnuradio-examples/python//

If you haven’t already, please take a look at

http://gnuradio.org/trac/wiki
http://gnuradio.org/trac/wiki/ReportingErrors

Welcome!
Eric