1
$\begingroup$

I understand that the difference between convolutional and block-based FEC is that convolutional codes can be used in a continuous stream – however every implementation I saw still uses blocks.

So I wrote some code using turbofec's library to see if I could decode a stream of blocks starting from an arbitrary point (so that the decoder's blocks are not in sync with the beginning of a convolutional packet), and it looks like I can't get it to work properly (while it works with zero offset).

Does this mean that Viterbi, turbo codes, etc., require a sync to the beginning/end of the blocks at the decoding phase, or is my problem in the library I'm using? (it's a bit suspect since that some of the status of the decoder is re-initialised at every call, but the library specifically only exposes the function forcing this initialisation)

|improve this question
$\endgroup$
  • $\begingroup$ Blocks are only for convenience. If you traceback from the state with the best metric, your decoder should work, no matter what the initial state was. $\endgroup$ – MBaz Apr 15 '18 at 21:49
  • $\begingroup$ Do you have any suggestion on a convolutional encoder/decoder I should use (N=2, K=5,7), written in C, or I should hack the one I linked to? I also tried the whole decoding operation in one huge chunk of n * block size bytes, but even if I get most of it decoded successfully, I still have some errors. $\endgroup$ – Mara Ara Apr 15 '18 at 23:09
  • $\begingroup$ I've tried hacking the code to preserve the metric between calls, but I still have decoding errors. Does tail-biting make any difference in what you said by any chance? $\endgroup$ – Mara Ara Apr 15 '18 at 23:10
  • $\begingroup$ And it looks like I can decode from a subset of the encoded block. As in, if the encoded block is 200 bytes, I can decode an arbitrary 100 bytes starting anywhere in it. However I can't concatenate multiple blocks on the transmitter side with encoded and not (data, sync pattern) interleaved... That is kinda of what my application was supposed to be. $\endgroup$ – Mara Ara Apr 15 '18 at 23:42
  • $\begingroup$ There may be a handful of erroneous bits because a false starting point usually means that the initial decoder metrics don't match the state of the encoder. It should sort itself out in due time, after processing a few trellis sections. I recall some former colleagues using 2 x constraint length as a rule of thumb, when e.g. parallelizing the decoding of a long turbo code block (in that case they did know the starting point, but a similar ambiguity about the current state was there because they started in the middle of a long block). $\endgroup$ – Jyrki Lahtonen May 17 '18 at 4:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.