Именно так

Тогда совсем не понятно как Xilinx умудрился получить задержку выходного сигнала кодера (8,4)*(8,4) в 13 тактов. Мне казалось, что они как раз идут на задержку входных данных до того момента, пока не сможет по колонке работать Y-кодер. Или там проверочные биты проверочных бит в выходном сигнале считываются по колонке, а не по строкам?

Насчет Ксайлинкса не скажу, но в канал биты "уходят", как правило, построчно

Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера.
Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано.
В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными.
Вообще полученный синдром нам уже дает позицию с ошибкой (декодер Хемминга как я понимаю способен исправить только 1 ошибку), в том случае, если она одна.. если больше, то позиции 2-х и более ошибок не определить.
Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию?

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

Спасибо, Алексей, за ответ) По первой ссылке я был и даже удалось пообщаться с автором статьи по некоторым непонятным вопросам. На базе этого примера алгоритма Чейза действительно не определить мягкие решения. Глянул вашу вторую статью, с ходу разобраться сложно, но наверно можно. В инете нарыл немного другую статейку с живым примером (прикрепил к сообщению), но и там увы не все понятно.
Пока у меня в голове получаются следующие этапы:
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 и зачем он им мне пока не понятно. Попробую с ним пока покопаться.. Может они там не алгоритм, а какую то идею в этом алгоритме запатентовали..

Сообщение отредактировал Neznaika - Apr 21 2017, 09:18

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

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

Сообщение отредактировал Neznaika - Apr 21 2017, 09:47

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

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