Hi Tom, I read that page before making my post, and that's what lead me to conclude the symbol map wasn't working as intended. I ran a test by changing the symbol map array [0, 1, 3, 2] vs [1, 0, 3, 2] and noticed the output didn't change. Only changing the constellation point order made a change in the output. [1+1j, -1+1j, -1-1j, -1+1j] vs [-1+1j, 1+1j, -1-1j, -1+1j]
This lead me to conclude the symbol table wasn't controlling anything, it was the index of the constellation point array that was mapping symbols. Correct me if you experience different. Rich Sent from my iPad > On Nov 10, 2014, at 10:04 AM, Tom Rondeau <[email protected]> wrote: > >> On Tue, Nov 4, 2014 at 9:11 PM, Richard Bell <[email protected]> wrote: >> The symbol map feature of the constellation object doesn't seem to do >> anything. In fact, you can leave it blank. The index of the constellation >> points is used to map the complex points to bits. The documentation leads >> one to believe otherwise. Working as intended? >> >> v/r, >> Rich > > > The symbol map is a list that maps to the constellation points. So > constellation_points[i] holds the symbol defined in symbol_map[i]. An easy > test to see this working is to take the default Constellation Object in GRC, > which is defined for QPSK, and change the map to [0,1,3,3] and notice that > the symbol 2 (10b) is missing in the output constellation. Without a symbol > map defined, it defaults to it being [0, ..., i-1]. The alternative is to > crash or catch that the vector is empty and exit on an error. > > There is the Digital Modulation page in the manual that describes these > things. If you have suggestions for how to improve them, please send them > along: > > http://gnuradio.org/doc/doxygen/page_digital.html > > Tom >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
