Ben,
I have a simple example of turbo coding/decoding (i think it is a sccc)
in the examples section of gr-trellis. It is SLOW!
I don't think there is any particular reason other than you are
essentially have to run 2 siso blocks per iteration, ie, roughly
4 VA's per iteration (recall forward/backward pass)...
The comment i made about buffering is from my experience:
You can always get a better performance if you combine the functionality
of multiple gnuradio blocks into one gnuradio block...
Regarding suboptimal receivers, I don't have any intention of writing
code for them, but if anyone is willing to work seriously on that i can
help (maybe an undergrad student project for the summer...)
Similarly, for a turbo decoding hierarchical block: it is trivial to put
together siso blocks and do it (the code is essentially there: see the
python code in the examples). I can think of an sccc and a pccc block
whereby you define the 2 constituent FSMs (or even more), an interleaver
structure, and the number of iterations; that's all there is to it.
Regarding integration with the "constellations" class i think it is a
wonderful idea. When I was writing gr-trellis I thought of
constellations as arbitrary one-dimensional look-up tables with n-dim
entries. Repackaging the "metrics" code to use constellations would be
great.
YES, I believe that the "constellations" class has to be general enough
to include n-dimensional constellations. What if you want to implement
4-FSK, or even arbitrary CPM (I am currently working on that).
Also, there are trellis-codes that output 2 QPSK (or 2 8PSK) symbols at
every step and having these constellations as 1 2D complex constellation
makes integration with gr-trellis very easy...
Achilleas
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
