Re: [Discuss-gnuradio] constellation object

[Ben Reynwar]

On Tue, Jan 18, 2011 at 8:31 AM, Tom Rondeau <address@hidden> wrote:
> On Mon, Jan 17, 2011 at 12:10 AM, Ben Reynwar <address@hidden> wrote:
>> 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.
>
>
> Ok, Ben, I got you. I think this sounds like a good direction. Looking
> at your code, I notice that it somewhat duplicates the
> constellation_decoder and somewhat duplicates the mpsk_receiver, but
> it is perhaps better than either. We already have a lot of duplicated
> functionality here and blocks that need to get pruned and some that
> need to be cleaned up, but we have to do this carefully and slowly. So
> here's what I'm thinking.
>
> First, there has been ongoing discussion about a refactoring of the
> build system. We're going to take this a step at a time, but one of
> the first major steps is to build a gr-digital top-level component and
> move all of the digital modulation code here. We would then import
> from gr.digital instead of gr for things like the Costas loop and
> mpsk_receiver. As we do this change, I would want to take your ideas
> to simplify and streamline the digital code we have.
>
> This move will break the API of some blocks and we will probably
> remove other blocks as well. We can do this under the gr_digital scope
> as everyone moves over to it while leaving but deprecating the current
> digital code in gnuradio-core to be removed at a later time.
>
> The other thing that I would really like to see us do is, like I said
> before, make the constellation decoders able to output soft symbols.
> This could just be by having a "decision_maker_hard" and
> "decision_maker_soft" function for each decoder. Then we can have
> receiver_cb and receiver_cf depending on which type we want for a
> particular application.
>
> How does this sound?
>
> Tom
>

I'm new to all this, so I don't have a good handle on soft versus hard
decision making.  My understanding is that a hard decision maker
simply returns the symbol value, and a soft decision maker would
return probabilities for various symbols values.  Then this
probabilistic information would be interpreted by the decoder which
would make the hard decision for sets of symbols simultaneously.  I
don't understand what receiver_cf is doing if it returning a stream of
floats.

On a related note, I've read that the minimum euclidean distance
minimizes the chance of error if you have white gaussian noise.  Is
this always a sensible assumption or are there practical situations in
which a different measure would be better?  If not, then the distance
could be used as a proxy for probability.  If others measures are
sometimes better, then it would be nice to keep things more general.

Cheers,
Ben