Re: Trellis in generic_mod_demod


Start with a simpler version of your design, ie

  1. At the Tx the convolutional code is BEFORE the gray_encoder
  2. At the Rx the Viterbi decoder operates with hard decisions (there
    is an option for that in the viterbi combined) and is AFTER the block
    that synchronizes with the encoded demodumated packet and extracts its

In other words, add coding/decoding to the payload of the original
uncoded system.


There is no logic at the moment to make the trellis encoder and
decoder sync their blocks with the packets. I would have thought that
if you don’t specify the starting and ending states, and the blocks
are reasonably long, then it would still work adequately but I could
be wrong.

If you want to sync the blocks with the packets then you could add a
stream tag to the start of each packet, and detect that with the
encoder and decoder.



At the moment when you feed into your viterbi decoder you still have
phase ambiguity i.e. you don’t know if the constellation is orientated
correctly. I imagine this would place a constraint on the code you
could use.

If you go with Achilleas’ suggestion then the differential decoding
would already have happened so you wouldn’t need to worry about it.


On Fri, Mar 1, 2013 at 11:05 AM, Achilleas A.