I’ve been exploring gr-trellis recently and have a few questions
relating to channel coding in gnuradio, and more specifically about
getting constellation objects to work with it.
Questions relating to channel coding:
Is gnuradio fast enough for channel coding for real applications?
At the moment Viterbi and BCJR (I think that’s what the siso blocks
are) are implemented. What other algorithms would be useful? The
docs suggest some suboptimal decoders (“eg, sphere decoding, M- and T-
algorithms, sequential decoding, etc.”).
It might also be nice to have more python hierarchical blocks for
example turbo coding and decoding blocks. What other hierarchical
blocks would be most useful?
How much of a problem is buffering really? I can imagine that if
the trellis.metrics_X is used with a big constellation then things
could get a bit hairy, but otherwise I don’t see any problem. At the
end of the gr-trellis docs there is a comment about turbo-decoding
having issues with buffering between the blocks, but the siso blocks
only output one float per bit, which doesn’t seem too outrageous
considering that the complex symbols that are getting passed around
all the time are two floats long.
Getting constellation objects to work with gr-trellis:
I’ve been adding constellation objects to gnuradio. It’s a minor
change and will just mean that algorithms that should be optimised
differently for different constellations are stored together with the
constellation points in an object. The generation of metrics for the
Viterbi and BCJR algorithms fall into this category.
gr-trellis is very flexible in that constellations are not
restricted to sets of complex points but rather can be sets of
n-dimensional real or complex points. Is it worth adding this
flexiblity into the constellation objects?
My inclination is to add trellis.constellation_metrics_X,
trellis.constellation_siso_combined_XX blocks that use the
constellation objects while leaving the existing blocks alone. Any