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 <[email protected]> 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 <[email protected]> wrote: > > Il 06/04/13 15:33, Tom Rondeau ha scritto: > > On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi <[email protected]> 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 > [email protected] > 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
