У Glavieux в книге Channel_Coding_in_Communication_Networks написано что для жёстких TPC алгоритмов декодирования не придумали ещё, так что этот путь можно смело отбросить.

Синдромный декодер очень хорошо подходит для декодирования TPC с жестким решением, однако это действительно тупиковое решение, так как не получишь всей мощи энергетического выигрыша, для которого они, собственно, и разрабатывались

Я так понимаю что такой код будет хуже обычного БЧХ с аналогичным размером блока и скоростью, т. к. БЧХ любые комбинации ошибок может исправлять в пределах корректирующей способности, а жёсткий TPC на некоторых комбинациях с малым числом ошибок спотыкаться будет.

Он будет хуже БЧХ. У него будет меньше мин. расстояние.
Реализовать это расстояние не составляет труда, т.к. это обычный итеративный код
с известным (небольшим) мин. расстоянием. Алгоритмы декодирования всех ошибок
до половины минимального расстояния для итеративных кодов известны давно.
Изюминка турбо кодов в том, что они исправляют много ошибок веса
намного больше их минимального расстояния Хемминга (или эвклидова расстояния,
если речь о полунепрерывных каналах).
Для известных методов декодирования (в двоичном канале) итеративных кодов такой эффект тоже имеет место,
но совсем не в таком впечатляющем масштабе, как в канале с непрерывным выходом
и с алгоритмами многократного декодирования.

дело в том , что я не создаю оборудование и соответственно у меня нет цели, как бы канал упростить , но в тоже время все здорово работало. И вся мощь турбокодов мне нужна:-) Мне просто надо в той мере, какой это возможно (чем чище, тем лучше) декодировать принятый и демодулированный (т.к. это отдельное устройство с жестким решением на выходе ) сигнал. Остро вопрос быстродействия декодера тоже не стоит.

как выше правильно писал Вадим, считайте что просто LLR с высоким значением для каждого бита, и как я написал выше в случаях сверточных турбокодов с LLR классно работало.

Практического смысла мало в этом, энергетический выигрыш от жёстких кодов не стоит того.

Простите за опечатку : И вся мощь турбокодов мне НЕ нужна:-)

Простите Serg76, а что значит синдромный, я так понимаю что как я и выше писал только назвав это табличным, т.е. кодовое слово каждой строки делим на полином, получаем синдром, и по нему уже знаем в каком месте ошибка и инвертируем там бит, потом отдельно идем по столбцам, потом опять по строкам ну итд. Но в этом случае выползала такая проблема что при коде 127,120 допустим одну ошибку можно исправить, но если у нас две ошибки то принимает за другую кодовую комбинацию и фактически вносит третью, и при неблагоприятном стечении ошибок, он будет бесконечно там менять и от правильной комбинации очень сильно отдалится.
Или вы под синдромным что-то другое имели в виду?

Синдромный алгоритм это тоже самое, что и алгоритм табличного поиска. Ту ситуацию, которую Вы описали, исправить невозможно, ибо каждый код характеризуется своей корректирующей способностью в зависимости от используемого алгоритма декодирования, выше головы не прыгнешь. Либо обеспечьте необходимую энергетику на входе, либо используйте более помехоустойчивый алгоритм.

вот и весь вопрос, какой более помехоустройчивый алгоритм?

При наличии мягкого выхода демодулятора - это MAP, для жесткого решения - это синдромный, другого не дано

Нет, одна ошибка ничего не испортит. И 7 ошибок тоже не страшны
У вас код итеративный. Вы сначала его декодируете по строкам. По результатам декодирования выставляете надежности каждому символу кода.
Затем декодируете по столбцам с учетом этих надежностей. Для реализации минимального расстояния (у вас оно равно 16, т.е. должны исправляться все ошибки веса до 7 включительно), достаточно сделать одну попытку декодирования (со стираниями) для каждого столбца. Смотрите в и-нете декодирование итеративных кодов и декодирования каскадных кодов, декодирование блоковых кодов по МОР (алгоритм Форни).

нет, мне кажется вы что-то путаете, 127,120 код Хэмминга, Dmin=3

А это не вы писали сегодня?


Тут явно видно, что итерируются два расширенных кода Хемминга. У каждого мин. расст. 4, а у произведения 4*4=16.
Разве нет?

писал я, ааа, этого я не знал:-) всмысле таких формул.
я почитаю обязательно алгоритмы, которые вы советуете
в них есть ответ на вопрос каким образом выставлять надежность каждому биту по декодировании КС, и как потом декодировать столбцы с учетом этих надежностей, и что значит со стираниями для каждого столбца?

Если 7 ошибок в одной строке, то их исправить можно будет соответствующим декодированием по столбцам, но если представить себе мнимый прямоугольник, в вершинах которого ошибочные биты, то эти ошибки уже не исправить жестким декодером