Может кто подскажет где поискать детальное описание MAP алгоритма (или его аппроксимаций Log-MAP или Max-Log-MAP) декодирования блоковых турбокодов. Может где есть ссылки на исходный код? Заранее благодарен за любую информацию по этому вопросу.

кой-что можно почерпнуть в книге 2006 г
The Art of Correctin Coding, by Robert Morelos-Zaragoza
http://www.edaboard.com/viewtopic.php?t=17...moreloszaragoza
На edaboard нужно регистрироваться, потом давите на FreeMirror

Тексты частных программок к книге здесь официально
http://the-art-of-ecc.com/topics.html
и на его страничке
http://eccpage.com/

Большое спасибо за эти ссылки, книга и данные исходники у меня есть. К сожалению в книге описан MAP-алгоритм применительно к сверточным турбокодам (хотя сверточные коды можно рассматривать как блоковые). В книге также рассмотрен хороший алгоритм Чейза для декодирования блоковых кодов с мягким решением, пробовал его использовать для декодирования TPC (блоковые турбокоды), результат сочетает в себе достаточно хорошую корректирующую способность и скорость обработки (на мой взгляд оптимальное сочетание). Однако данный метод не дает оптимальной помехоустойчивочти, т.к. дает минимум вероятности ошибки для кодовой последовательности (кодового слова - аналог алгоритма Витерби), в отличие от алгоритма MAP, котрый дает минимум вероятности ошибки для каждого символа этой последовательности.

Здесь можно найти Matlab код для имплементации/simulation of turbo-encode and turbo-decode Log-MAP алгоритмов. Если вы хотите имплементировать turbo coding для IEEE 802 16e Convolutional Turbo Code (CTC), и готовы это предпринимать для на ПЛИС, у Xilinx есть LogiCORE (encoder/decoder), и они возможно находятся в Xilinx Coregen на FTP.

Спасибо за ссылки, но опять же повторюсь, что речь идет о БЛОКОВЫХ (компонентных) кодах - Turbo Product Codes (TPC), а не о сверточных - Convolutional Turbo Code (для них более - менее все ясно).

А где бы эту книжку еще можно качнуть ? Потому как едабоард говорит что нет такого топика.
Заранее спасибо.

Я недавно, с некоторыми затруднениями, но скачал ее через бесплатное зеркало по приведенной выше ссылке (за нее спасибо) - нужно только залогиниться. Книжка в целом неплохая, 2002 года, без огравления, и списка литературы, но в коллекции не будет лишней.

А по поводу ознакомления с соответствующим TPC ядром Xilinx лучше не строить лишних иллюзий - заявку на это будут рассматривать под микроскопом, в составе Coregen оно никогда не поставлялось, и продукт рассматривается фирмой как "стратегический".

Да дома ;-)

http://lord-n.narod.ru/walla.html

А может проще сразу микросхему поставить и не связываться с программированием ?
http://www.aha.com

Эта книга есть в продаже на русском (правда стоит у нас (Минск) - 15 долл.) Всё равно на русском читать приятнее, чем на английском. Алгоритмы с сайта проверяли - рабботают - и уже пыаемся их засунуть в наш VC5509a

народ, помогите пожалуйста, мне надо сделать программку для компа для турбокодов на кодах Хемминга, информация после демодулятора с жестким решением поступает.
Пробовал табличным методом (т.е. каждую строку и каждый столбец декодирую незавизимо), но для скоростей 7/8 например блоков (128,120)х(128,120) очень неэффективно работает.
Продумывал алгоритм Чейза2, но если я все правильно понял, то он хорошо работает с поступающей мягкой информацией, т.к. ему тогда легче расставить надежность бит , а в данном случае получается . что надежность у всех одинаковая и ему легко ошибиться с выявлением ненадежных бит.
Продумывал LLR, наверно это даже самое надежное средство было бы. Но как я понял по Скляру где пример приводится с двумя инфо битами и битом четности, и по приложению 8A в книге вывел формулу для четырех инфо бит и одной проверки (для примера), уже получается довольно большое уравнение, а для 127 инфо бит(блок выше ), вообще нереальная формула будет.
Подскажите, или я что то не правильно понимаю или может другие алгоритмы эффективные есть для данной задачи?

по-моему без мягких решений демодулятора смысла в турбокодах мало

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

Вот Вам ссылка
http://electronix.ru/forum/index.php?showtopic=56005

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

У 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 ошибок в одной строке, то их исправить можно будет соответствующим декодированием по столбцам, но если представить себе мнимый прямоугольник, в вершинах которого ошибочные биты, то эти ошибки уже не исправить жестким декодером

Легко. Просто немножко почитать книжек.


Да.

Ещё раз, не тратьте время впустую, прочитайте в выше приведённой книге страницы 111-113, для таких кодов неизвестны нормальные алгоритмы декодирования либо они вообще не существуют.

Каким образом?

Описывать в форуме алгоритмы не имею времени.
Если будет какой-то уточняющий вопрос по алгоритму - тогда конечно.
"Уклончиво отсылать к первоисточникам" Вас тоже нет смысла.
Так что вся надежда на топикстартера, который нароет что-то в интернете.

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

SKov Вопрос снимается, был не прав . Приношу свои извинения. Проблема снимается локализацией ошибок на пересечениях с последующим инвертированием ошибочных бит.

Правильно ли я понял, что турбокоды можно пирменять только с мягким решением?

Отчего же? Можно и в хардеке, но зачем?

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

Возникла необходимость реализовать декодер с мягким решением на ПЛИС, причём срочно. Подскажите, возможно ли найти готовый проект с исходниками. Если нет, то где купить, и за какой примерно порядок денег. TurboConcept не подходит.

приветствую,

просматривая графики из документации на модем цдм600, заметил что небольшое внешнее ("на глаз")отличие в кривых помехоустойчивости на светочные коды и турбо коды блоковые.

интересует такой вопрос, вот эти изломы криые BER это свойство алгоритма или в принципе блочного турбо кода?
если это свойствово кода, можно ли где-нибудь прочитать об этом?



-спасибо

Режим насыщения скорее всего, он и более сильным бывает, упирается в возможности свёрточного кода.

это свойство "современных" кодов (turbo, ldpc, etc.). гуглите "Error Floor"