Forum: GNU Radio QPSK phase noise

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Paco G. (Guest)
on 2009-04-07 22:10
(Received via mailing list)
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-tp22934944p...
Sent from the GnuRadio mailing list archive at Nabble.com.
Alysson Menezes (Guest)
on 2009-04-07 22:36
(Received via mailing list)
Attachment: gama_max.PNG (0 Bytes)
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
Eric B. (Guest)
on 2009-04-07 22:37
(Received via mailing list)
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
Francisco Garcia (Guest)
on 2009-04-07 22:55
(Received via mailing list)
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?
Paco G. (Guest)
on 2009-04-07 22:56
(Received via mailing list)
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-tp22934944p...
Sent from the GnuRadio mailing list archive at Nabble.com.
Johnathan C. (Guest)
on 2009-04-07 23:03
(Received via mailing list)
On Tue, Apr 7, 2009 at 11:49 AM, Paco G. <removed_email_address@domain.invalid> 
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
Paco G. (Guest)
on 2009-04-08 17:42
(Received via mailing list)
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-tp22934944p...
Sent from the GnuRadio mailing list archive at Nabble.com.
Bill S. (Guest)
on 2009-04-10 20:09
(Received via mailing list)
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. <removed_email_address@domain.invalid>
To: removed_email_address@domain.invalid
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-tp22934944p...
Sent from the GnuRadio mailing list archive at Nabble.com.
Bill S. (Guest)
on 2009-04-11 17:50
(Received via mailing list)
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 <removed_email_address@domain.invalid>
To: Bill S. <removed_email_address@domain.invalid>
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.
<removed_email_address@domain.invalid> 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
Alysson Menezes (Guest)
on 2009-05-25 22:35
(Received via mailing list)
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
Eric B. (Guest)
on 2009-05-26 05:11
(Received via mailing list)
Attachment: simple-example.py (0 Bytes)
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
This topic is locked and can not be replied to.