Constellation object

GNU Radio
1

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

2

On Sat, Jan 15, 2011 at 1:40 AM, Ben R. [email protected] wrote:

the ofdm receiver would
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

3

On Sun, Jan 16, 2011 at 2:52 PM, Tom R. [email protected]
wrote:

easily be used by different receivers (i.e. the standard receiver and
Cheers,
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.

4

On Tue, Jan 18, 2011 at 8:31 AM, Tom R. [email protected]
wrote:

It would also mean that the decision-making function for a given

https://github.com/benreynwar/gnuradio/blob/master/gnuradio-core/src/python/gnuradio/blks2impl/generic_mod_demod.py

gnuradio-core/src/python/gnuradio/blks2impl).
gr_constellation_decoder_cb uses minimum distance to determine the
bin based on the real and imag components.) These classes would not
e.g. gr_constellation_decoder_cb::gr_constellation_decoder(const
need to be cleaned up, but we have to do this carefully and slowly. So
This move will break the API of some blocks and we will probably

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

5

On Wed, Jan 19, 2011 at 11:55:30AM -0700, Ben R. wrote:

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.

You’ve got that right: a soft decider doesn’t really decide, but rather
gives a value how good the estimate is. Say you have a binary output,
1 and -1. A soft decider can also give any value in between. If you get
a 0, then the soft decider really has no clue what was actually
transmitted and instead of guessing a binary value, it relays this
uncertainty.
One place this is really important is the channel decoding.

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.

Just a couple of euro-cents I’d like to add:

  • White noise is a perfectly valid assumption. In most cases, your noise
    is WGN-ish anyway. If it isn’t, then the constellation demodulator is
    not the right place to handle it, you’d use some kind of pre-whitening
    filter a priori.
  • I’d say if you have to implement a soft- and hard-decider for each
    constellation anyway, you’re general enough. With the aforementioned
    point, this means the hard decider is sіmply always the minimum
    euclidean distance, as you said already.
  • After having a quick peek at your code, I wasn’t quite sure if you’ve
    thought of differential PSKs?

All that aside, I think this is a good approach. GNU Radio currently has
a lot of fantastic DЅP code; what I miss is more structure, and I’m glad
to hear about the plans to refactor the digital stuff.

Cheers,
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

6

On Mon, Jan 17, 2011 at 12:10 AM, Ben R. [email protected] wrote:

modulation could

correct symbol. I would guess this would become a bottleneck for
be signal-processing
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

7

On Thu, Jan 20, 2011 at 01:36:46PM -0700, Ben R. wrote:

than 2 symbols? Would you just give the distances to the closest n points?
Good question–but it also depends on where you need the soft values.
Say you have a 4-QAM and a binary channel code. Then you’d split every
symbol
in two soft values, one for each bit. In this case, assuming phase was
corrected, the real and imaginary values.

Cheers,
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

8

On Fri, Jan 21, 2011 at 1:31 AM, Martin B. [email protected]
wrote:

That makes sense. What kind of values would you output when you have more
than 2 symbols? Would you just give the distances to the closest n points?

Good question–but it also depends on where you need the soft values.
Say you have a 4-QAM and a binary channel code. Then you’d split every symbol
in two soft values, one for each bit. In this case, assuming phase was
corrected, the real and imaginary values.

OK. I think I need to do some reading on channel coding before I can
really get
what’s going on here. Thanks for your help.

Cheers,
Ben

9

On Thu, Jan 20, 2011 at 1:46 AM, Martin B. [email protected]
wrote:

You’ve got that right: a soft decider doesn’t really decide, but rather
gives a value how good the estimate is. Say you have a binary output,
1 and -1. A soft decider can also give any value in between. If you get
a 0, then the soft decider really has no clue what was actually
transmitted and instead of guessing a binary value, it relays this
uncertainty.
One place this is really important is the channel decoding.

That makes sense. What kind of values would you output when you have
more
than 2 symbols? Would you just give the distances to the closest n
points?

not the right place to handle it, you’d use some kind of pre-whitening
filter a priori.

Good to know.

  • I’d say if you have to implement a soft- and hard-decider for each
    constellation anyway, you’re general enough. With the aforementioned
    point, this means the hard decider is sіmply always the minimum
    euclidean distance, as you said already.
  • After having a quick peek at your code, I wasn’t quite sure if you’ve
    thought of differential PSKs?

I’ve just implemented it for PSK but have to tidy it up a bit before
pushing it to my github repo. Works fine for differential PSK,
although I had to put map_bb blocks into the generic blocks to get
gray coding working.