discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation


From: Arturo Rinaldi
Subject: Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
Date: Wed, 10 Apr 2013 02:45:11 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

Il 10/04/13 02:03, Ben Reynwar ha scritto:
No, there's no way you can pass in the list, rather than a constellation object.

Is there a reason that you can't make sure that the input to the
constellation_decoder is scaled such that the average amplitude is
1.0?  I believe that that would solve the problems you are having and
you could use digital.constellation_calcdist as you were previously.

On Tue, Apr 9, 2013 at 4:33 PM, Arturo Rinaldi <address@hidden> wrote:
Il 10/04/13 00:45, Ben Reynwar ha scritto:

Hi Arturo,

The constellation object scales the provided constellation points so
that the average magnitude of the points is 1.0.   This is causing the
difference between the two sets of points that you noticed.

To avoid the abstract class error, use
"digital.digital_constellation(rotated_const.base(), [], 1, 1)", where
the "base" method is casting the object to the base constellation
class.

Ben

On Tue, Apr 9, 2013 at 3:19 PM, Arturo Rinaldi <address@hidden> wrote:

Il 06/04/13 15:33, Tom Rondeau ha scritto:

On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi <address@hidden> wrote:

Hi folks, i have bumped into an error while updating my thesis research to
the latest version of gnuradio.
It is a simple tool to estimate the BER of the digital modulation. I had to
change some lines of code due to the
fact that now the block constellation_decoder_cb accepts as input a
"constellation object" and not a complex
point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code
in the following way (only the
deconding part). By asking to the gnuradio mailing list i got the following
advice :

rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)

rotated_const = map(lambda pt: pt * rot,
qam.make_nondifferential_constellation(16,gray_coded=True)
constell = digital.constellation_calcdist(rotated_const,[],1,1).base()   #
(1) to get the base points and constellation object
self.slicer = digital.constellation_decoder_cb(constell)

# if self._gray_code:
#         self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])
#     else:
#         self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])


# unpack the k bit vector into a stream of bits

self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol())  # (2)

self.connect(self,self.slicer, self.unpack,self)


which works fine for M-PSK modulation but since QAM is a mix of both phase
and amplitude modulation i can't
recover the exact position of the constellation points. I think the error
stays in a wrong calculation of the
euclidean distance. Any suggestions ? i really need help or otherwise the
functionality of my tool will be
dramatically reduced ! ! !

Thanks in advance,

                      Arturo

P.S. : The modulator block is shaped in the "old way", by just only passing
as parameter the constellation
points to the block

self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)

I also use (2) because of my way to compare original bit by decoded bit and
then calculating the BER. However
the main issue is the wrong decoding of the constellation points by (1)

Arturo,

Take a look at the constellation_decoder. This uses the constellation
objects and handles the symbol slicing for you. The slicers are
defined in constellation.{cc,h}, and if you come up with a
smarter/cheaper way of slicing, you can add it here. I think this
might help simplify things for you.

Tom


I still can't figure out which is the correct slicer to use. I can't use
digital.constellation_calcdist because it works only constellations with  a
small number of points (and for M-PSK is fine). I usually build the qam-16
constellation with the old source code of gnuradio (the 3.3.0 one, I really
prefer it......) and when using digital.constellation_rect().points() as
slicer i get different different points decoded instead of the ones i
originally sent, this is the code :

arity = 16

rot = (3.0/2.0)*sqrt((8.0/5.0)*1.0)   # base point distance. See "Simon
Haykin - Communication Sytems"

side = int(sqrt(arity))
width = 2.0/(side-1)
#
#
#
rotated_const = map(lambda pt: pt * rot, qam.constellation[arity])   # from
3.3.0 qam.py source
#
decoded_points =
digital.constellation_rect(rotated_const,[],4,side,side,width,width).points()
#
print "ORIGINAL POINTS\n"
print rotated_const
print " "
print "DECODED POINTS\n"
print decoded_points

returning :

ORIGINAL POINTS

[(-0.6324555320336758-0.6324555320336758j),
(-0.6324555320336758-1.8973665961010275j),
(-1.8973665961010275-0.6324555320336758j),
(-1.8973665961010275-1.8973665961010275j),
(-0.6324555320336758+0.6324555320336758j),
(-0.6324555320336758+1.8973665961010275j),
(-1.8973665961010275+0.6324555320336758j),
(-1.8973665961010275+1.8973665961010275j),
(0.6324555320336758-0.6324555320336758j),
(0.6324555320336758-1.8973665961010275j),
(1.8973665961010275-0.6324555320336758j),
(1.8973665961010275-1.8973665961010275j),
(0.6324555320336758+0.6324555320336758j),
(0.6324555320336758+1.8973665961010275j),
(1.8973665961010275+0.6324555320336758j),
(1.8973665961010275+1.8973665961010275j)]

DECODED POINTS

((-0.33385056257247925-0.33385056257247925j),
(-0.33385056257247925-1.0015517473220825j),
(-1.0015517473220825-0.33385056257247925j),
(-1.0015517473220825-1.0015517473220825j),
(-0.33385056257247925+0.33385056257247925j),
(-0.33385056257247925+1.0015517473220825j),
(-1.0015517473220825+0.33385056257247925j),
(-1.0015517473220825+1.0015517473220825j),
(0.33385056257247925-0.33385056257247925j),
(0.33385056257247925-1.0015517473220825j),
(1.0015517473220825-0.33385056257247925j),
(1.0015517473220825-1.0015517473220825j),
(0.33385056257247925+0.33385056257247925j),
(0.33385056257247925+1.0015517473220825j),
(1.0015517473220825+0.33385056257247925j),
(1.0015517473220825+1.0015517473220825j))

This issue, generally speaking, also breaks the compatibility with my
ASK-based modulation code. I really put an effort writing these source codes
on my own and now all my work is almost wasted.....:(.

A perfect solution would be to build a pure digital_constellation_sptr
object and pass it to the decoder but when i try to do it with

digital.digital_constellation(rotated_const, [], 1, 1)

but i obviously get an abstract class error. Do you mind to insert the old
constellation_decoder_cb module as a deprecated one in the next release ? It
would really solve my problems and my thesis research would be working again
as it should !

I hope you can help me out......thx in advance

Kind Regards,

                Arturo

P.S. : Would it be possible to get the source code of the old
constellation_decoder_cb from the 3.3.0 tarball and build as a new block
with gr-how-to-make-block by modyfing the *.i, *.cc and *.h files ?

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Ben, sorry if i bother you again. You were the first to help me when i asked
for help long time ago.

rotated_const is a "list" of points, it's not a constellation object, maybe
I explained the issue in a wrong way (but i stressed it after the # on the
same line I was using old source code). The qam points are generated with
the qam.py 3.3.0 tarball code and not by importing qam from digital because
the first one is more suitable to me than the other one. It's like doing :

rot = (3.0/2.0)*sqrt((8.0/5.0))
rotated_const_3.6.4.1 = map(lambda pt: pt * rot,
qam.make_non_differential_constellation(16,mod_codes.GRAY_CODE))   # returns
a list

getting a tuple of points and not a constellation object. What i really
meant by asking that was : is there a way to get a "pure"
digital_constellation_sptr object by only passing a list of points as the
previous ones as first argument and not getting an abstract class error ?

I hope I've made myself clear this time......;). I apologize again.....

Kind Regards,

               Arturo

No, there isn't....sorry :(. I really need that constellation(s) because all of my work is based on custom sets of points precisely calculated by following Haykin's theory in his book. This affects ASK modulations as well......the functionality of my thesis research is now almost halved since now i can get coherent results only with PSK modulations. I can't scale the average amplitude to 1.0 beacuse it will affect my AWGN channel model too....

I am really begging Tom and the others to re-introduce the previous version constellation_decoder_cb, maybe as a deprecated one because i really need it.

I am for sure not blaming you since yours is a very brilliant approach to build and handle constellations as well. In fact, for this very reason, I was asking Tom if I would be able to build the old block again with gr-how-to-make-a-block 3.6.4.1 by using the .h .cc and .i files from an old tarball.

If you come up with a solution please tell me. Until now you have been a really valuable resource to me ;)

Regards again,

                    Arturo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]