Re: [Discuss-gnuradio] constellation object

[Ben Reynwar]

On Sun, Jan 16, 2011 at 2:52 PM, Tom Rondeau <address@hidden> wrote:
> On Sat, Jan 15, 2011 at 1:40 AM, Ben Reynwar <address@hidden> wrote:
>> Hi all,
>>
>> What do people think of introducing a constellation object into gnuradio?
>>
>> It would hold the constellation points and also a decision-making function.
>> New modulations could then be easily created by subclassing a constellation.
>>
>> It would also mean that the decision-making function for a given
>> modulation could
>> easily be used by different receivers (i.e. the standard receiver and
>> the ofdm receiver would
>> both use the same decision making code for a given modulation).
>>
>> I've already had a go at implementing this on my repo.
>>
>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation.h
>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/lib/general/gr_constellation_receiver_cb.h
>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/qam.py
>> https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/generic_mod_demod.py
>>
>> Cheers,
>> Ben
>
>
> Ben,
> Are you talking about something different than
> gr_constellation_decoder_cb? I haven't looked at your code, but it
> strikes me that what you want is similar to that decoder code (you can
> find its use in dbpsk.py and dbpsk2.py in
> gnuradio-core/src/python/gnuradio/blks2impl).
>
> My only suggestion for this part is to have a constellation_decoder_cf
> that would output soft symbols instead of hard symbols.
>
> Let me know if I've missed something in what you are asking.
>
> Thanks,
> Tom
>

gr_constellation_decoder_cb uses minimum distance to determine the
correct symbol.  I would guess this would become a bottleneck for
large constellations.

My suggestion was to create c++ classes representing constellations which would
contain both the constellation points and a function to determine what
point a given
complex number corresponded to.  This way different decision making
functions could
be written for each modulation (e.g. for PSK you just bin based on the
phase, for QAM you
bin based on the real and imag components.)  These classes would not
be signal-processing
blocks, but rather would be passed to blocks as arguments.

Separating out this code from the receivers would mean that it didn't
have to be implemented
separately for each receiver.

This would effect gr_constellation_decoder_cb in that it would take a
constellation object when initialized,

e.g. gr_constellation_decoder_cb::gr_constellation_decoder(const
gr_constellation_sptr constell)

and would use constell.decision_maker to determine what symbol value to return.