Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)

[Ben Reynwar]

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