Спасибо, Алексей, за ответ) По первой ссылке я был и даже удалось пообщаться с автором статьи по некоторым непонятным вопросам. На базе этого примера алгоритма Чейза действительно не определить мягкие решения. Глянул вашу вторую статью, с ходу разобраться сложно, но наверно можно. В инете нарыл немного другую статейку с живым примером (прикрепил к сообщению), но и там увы не все понятно.
Пока у меня в голове получаются следующие этапы:
1. Находим позиции с меньшими вероятностями.
2. Заменяем их всеми возможными значениями 1 и 0, формируя тестовые последовательности.
3. Принимаем жесткие решения по остальным битам.
4. Декодируем полученные тестовые вектора БЧХ-декодером.
5. Далее модулируем их при образуя в вектора со значениями (1,-1).
6. Исходя из примера моей статьи проводим столько этапов, сколько у нас векторов.
7. Вычисляем вероятность L=1/2(S_плюс-S_минус).
Я на верном пути или где то глубоко заблуждаюсь?
В статье откуда то берутся значения p(c_i).. откуда они?

Всем привет! На днях закончил реализацию BTC-декодера (16,11,4)x (16,11,4)x (16,11,4). Получил BER(6дБ)=10^-5 и BER(8дБ)=10^-7. Использовал алгоритм Chase-Pyndiah. Хотелось бы попробовать чего-нибудь по мощнее. Нашел статью, прикрепленную к сообщению, там вроде как алгоритм посерьезнее описан, но к сожалению указана вспомогательная статья к которой не имею доступа.
Может есть у кого?
S.K. Shin, S.I. Lee, and S.P. Lee, “Evaluation of Block Turbo
Code Performance with the Reduced Search Trellis Decoding
Method,” IEE Proc. Communications, vol. 148, no. 3, June 2001

Буду признателен за помощь)

6 и 8 дБ соответствуют Eb/No? Если так, то, очевидно, что у Вас просто ужасная реализация декодера. К примеру, AHA для вашей конфигурации кода дает следующие результаты: BER(Eb/No=1,7дБ)=10^-5 и BER(Eb/No=2дБ)=10^-7. Даже декодер с жестким решением даст больший ЭВК, нежели получился у Вас(((.

Ответил в почту

По поводу результата... АНА - это АНА, они всю жизнь занимаются помехоустойчивым кодированием и продвинулись в этой области очень далеко. Я ориентировался на результаты статей, которые нашел в ИНЕТе. Искал непосредственно реализацию 3D-кода, а именно (16,11,4)^3. Перебрав кучу статей у меня сложилось впечатление, что наиболее популярный метод декодирования Сhase-Pyndiah не так уж безгрешен. Обычно приводят результаты его работы на низком отношении сигнал/шум до 2.5дБ. Именно в этой области BER получается максимально приближено к границе Шеннона, а вот что происходит на больших отношениях сигнал/шум показывают редко. Все что удалось найти по этому вопросу прикрепил к посту.

АНА - это АНА, согласен, но приблизиться к их результатам, используя Чейза, вполне реально. Я привел результаты AHA к тому, чтобы продемонстрировать, что Вы не совсем полностью реализовали корректирующую способность алгоритма Чейза, а уже собрались переходить к другому алгоритму. В прикрепленной Вами последней статье как раз приведен результат для Вашей конфигурации кода - (16,11)^3. ЭВК составляет 8,5 дБ для Pb=10^-6, судя по Вашим результатм - это "космос". Кстати, может Вы не совсем верно сняли характеристики своего декодера?

Почему космос то? Я изначально указывал что при 8дБ Еb/No у меня BER=10^-7, мне видится это немного лучше, чем в третьей статье.. Хотя там указано про кодовое усиление... Наверно это все-таки разные вещи... Измерения проводил с живым шумом и с BPSK сигналом. Выигрывать 1-2 дБ за счёт оптимизации архитектуры пока не вижу смысла, а приближения алгоритма к результатам АНА не видел ни в одной статье. Однако есть патент АНА на SISO блочного турбо декодера, там описан как раз алгоритм, напоминающий Чейза. Но патент 2006 года, а кодеки они делают гораздо раньше. К сожалению в патенте не приводится BER и зачем он им мне пока не понятно. Попробую с ним пока покопаться.. Может они там не алгоритм, а какую то идею в этом алгоритме запатентовали..

Ну а как по-другому? Если у вас BER=10^-7 достигается при 8дБ Еb/No, а в AHA эта же вероятность достигается при Eb/No=2дБ, т.е разница в реализациях 6 дБ !!!!!, куда же это годиться?. Да и 1-2 дБ энергетического проигрыша - это тоже непозволительная роскошь, это примерно разница между жестким и мягким декодированием. Кроме того, в статье приведено значение Coding Gain, т.е. ЭВК - разница между кодированной и некодированной передачей, а не абсолютного значения Еb/No. Разберитесь, что и как Вы измеряли, может оказаться, что не все так плохо с декодером.

Да) С кодовым усилением я сел в лужу) А результат действительно плачевный.. В моделе декодер работает как нужно, исправляя ошибки на очень низких отношениях сигнал/шум, а вот в железе получаю 8дБ. Но в моделе не учитываю модуляцию. Просто к входной последовательности добавляю гауссовский шум разных значений. Уже прогнал кучу всевозможных тестов, метрики совпадают до бита. Разве, что в модель не могу подать сигнал со входа железячного декодера. Странно все это...
Последняя статья написана про железяку, которая сделана на базе микросхемы АНА, потому и характеристики такие мощные.

модуляция здесь ни при чем, не надо ее касаться. характеристики модели декодера снимали, а то понятие "как нужно" не очень информативно?

Еще момент: при испытаниях в железе потери демодулятора учитываете, а то демодуляторы тоже разные бывают?

В модели я контролирую количество ошибок на входе и на каждой полуитерации. При входном BER в 4*10^-2, декодер выдает чистые нули после 1.5 итераций. Такой входной BER характерен Eb/No около 2дБ.
В железе ошибки появляются на 8 дБ и сам характер работы декодера напоминает работу одной итерации. Что вторая итерация, что 4-ая... особой разницы не видел +-1дБ по BER. Первая итерация раз в 10 дает результат хуже, чем остальные.
К демодулятору также вопросов не имею, так как LDPC-декодер нормально работает с ним на 2.5дБ.
Убивает то, что по одинаковым входным значениям модель и железо работают одинаково) Либо я в модели не те тесты подаю или есть какая то серьезная ошибка в архитектуре, либо пора обращаться к экстрасенсам...
Архитектура без оптимизации, в канальной памяти хранятся данные из канала, они подаются на SISO, который выдает мягкие решения. Записываем их в RAM внешней информации. После, эти же значения складываем со значениями из канальной памяти и снова подаем на SISO и т.д. Первоначально обрабатываются строки по Х, потом колонки по Y и колонки по оси Z. Далее следует новая итерация, но уже на 2-ой итерации имеем внешнюю информацию от Z. В оптимизационных архитектурах видел, что внешняя информация двух осей складывается для вычисления мягких решений по третьей. Но в данном случае не верится, что это сильно поможет делу.

При Eb/No около 2дБ на входе, - 0 ошибок на выходе - это нормально, так и должно быть, хотя картина неполная, желательно промерять во всем рабочем диапазоне.

Эти 8 дБ - это SNR или Eb/No и в какой точке приемного тракта измерены и при какой модуляции? у меня сложилось такое мнение, что у Вас с методикой измерения не все в порядке.

эта фраза вообще ни о чем не говорит, LDPC и демодуляторы бывают разные.

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

На первом рисунке привел диалоговое окно модели. Длина кадра 3840 бит. Видно как исправляются ошибки от оси к оси. Если брать меньшее отношение сигнал/шум, то после первой уже полуитерации по оси Х ошибок почти нет.
Что касается демодулятора, то на втором рисунке приведена BER работы LDPC-декодера по стандарту DVB-S2 с длиной блока 16200 бит. Видно, что при BPSK модуляции и кодовой скоростью 11/15 на 2.5 дБ результат его работы неплохой. О чем я заключаю, что демодулятор в полном порядке.
А измерения проводил по разному. Первоначально оценивал BER на входе BTC-декодера и видел, что при входном BER 10^-2 (около 4 дБ некодированных данных) после декодера появляются ошибки. Так же проводил контрольные измерения Eb/No c помощью вражеского модема CDM-600 на тех же настройках, не меняя параметров генератора шума. И он подтверждал мои оценки Eb/No. Вот только на 5-8 дБ он давал нули, а мой декодер на 8дБ выдавал BER=10^-7.
Сергей, спасибо, за ваши ответы) Вы меня неплохо подзарядили. Очень надеюсь, что ошибка будет найдена в скором времени... Обычно всегда находилась)

Да не за что, в принципе. Да, видно, что Ваш декодер не дотягивает до фирменного, вопрос только в том, насколько? Давайте так, хоть это и не совсем корректно: Вы можете сказать, при каком соотношении Eb/No на фирменном модеме "практически" будут отсутствовать ошибки? По характеристикам кода это должно наступить где-то в районе Eb/No > 2...2,5 dB с учетом потерь демодулятора в BPSK/QPSK режимах. Если это наступит при более высоких значениях Eb/No, то тогда к ошибкам реализации декодера добавятся еще и ошибки методики измерений.

CDM-600 работает до Eb/No=5дБ с BER=0 на BPSK 5/16. Далее у него идёт срыв синхронизации. Фактически это уже 0 дБ, так как коэффициент сжатия приводит к входному Eb/No=5-10*log(16/5). Если взять мой демодулятор и результат работы LDPC на 11/15, то демодулятор нормально работает до Eb/No=3-10*log(15/11)=1,34дБ без срывов.

Вы ничего не путаете, как промышленный модем в такой мощной конфигурации BPSK + FEC 1/3 работает при Eb/No>5 dB. Он без проблем должен работать при более низкой энергетике, для Eb/No>2 dB он должен выдавать практически нулевой BER. Как измеряете Eb/No?


Так и есть, модем CDM-625, режим BPSK + FEC 5/16 дает BER 1e-6 при Eb/No = 2,5 dB, полдецибела на потери реализации.

В CDM-600 есть свой измеритель Eb/No, по нему и ориентируюсь. То что модем перестаёт работать при менее 5дБ, скорей всего связано с низким уровнем сигнала, идущего от генератора шума, он самопальный и собран на аттенюаторах. Модем фиксирует входной сигнал на уровне менее -75дБм.

Понятно, так Вы ничего не добьетесь. как итог, я бы банально посоветовал отладить и промерять декодер в модели, там это делается все проще.

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

Всем привет! Решил снова обратиться к гуру кодирования) 5/16 удалось временно победить, устранил пару ошибок в железе при работе с памятью и декодер на BPSK стал работать без ошибок до срыва синхронизации демодулятора при 5дБ, аналогично работе CDM-600. Стал копаться со скоростью 21/44 на BPSK. Длина кадра 25088 бит. Из-за того, что CDM-600 использует микросхему AHA, а в ней максимальный блок данных может быть около 4 кбит, то наши "партнеры" из Америки, решили выкрутиться и разбили 25088 бит на 7 блоков. Каждый блок состоит из 3 страниц полезной информации и 1 страницы, сформированной из предыдущих 3 путем операции XOR. Все 4 страницы кодируются 2D-кодером.
Вопрос встал, что делать с данными 4-ой страницы?..
Первоначально декодирую все 4 страницы по оси Х и Y декодером Чейза. Аналогично 3D-декодеру, по оси Z беру слова, состоящие из данных 4-х страниц: 3 бита полезной информации и 1 бит проверочный, полученный через XOR из предыдущих бит. Для параллельности процесса беру сразу несколько 4-к... В одном случае 5, в другом 6 (из-за укороченного кода по оси Y)... Провожу декодирование аналогичное декодированию по алгоритму Чейза... Нахожу позиции полезных бит с минимальными вероятностями, формирую тестовые вектора, а затем просто пересчитываю 4-ые биты. Далее вычисляю метрики и аналогично алгоритму Чейза вычисляю мягкие решения.
В результате, получаю, что декодирование по оси Z ухудшает кодовое усиление декодера. Результат декодирования только по осям X и Y заметно лучше, но BER=10^-6 на Eb/No=5дБ. Наверняка сидит что-то серьезное... но.. Что делать с осью Z?... Очевидно, что мой способ декодирования по Z дает ошибку.. Может кто знает или подскажет как использовать данные 4-ой страницы?

В очередной раз побеспокою кудесников блочного кодирования...
Уткнулся в реализацию BTC при QPSK, 3/4, совместимую с CDM-600. Нашел 30-битную метку в кадре и вычислил длину самого кадра с меткой в 4444 бит. Попытка разложить 3333/4414 на элементарные коэффициенты не приводит к положительному успеху. Может кто то занимался этой реализацией и подскажет как коллегам из Америки удалось получить этот коэффициент?

Всем спасибо) Может кому пригодится...
Параметры кода CDM-600 для TPC, QPSK 3/4:
2D-код с коэффициентами (39/46)*(57/64), 20-битная метка x"f50b8".