[Serg76 0]

Из статей мне почему то представляется, что проверочные биты проверочных бит формируются именно Y-кодером.

Именно так

[Neznaika 0]

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

[Serg76 0]

Или там проверочные биты проверочных бит в выходном сигнале считываются по колонке, а не по строкам?

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

[Neznaika 0]

Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера.

Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано.

В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными.

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

Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию?

168101.pdf

[Maverick_ 15]

Всем привет! Вот и пришло время связать меня крепкими узами любви с BTC-декодером стандарта WiMAX. Покопался в ИНЕТе, информации очень мало и она скудна. Лишь только в одной статье наших китайских друзей удалось найти более-менее разжеванную версию декодера. Но и в ней не очень много ясности. Исходя из просмотренной литературы многие склоняются к использованию алгоритма Чейза в этом типе декодера.

Как я понимаю на данный момент, процесс декодирования заключается в поиске среди мягких решений полученного кадра 2 или 3 значений с минимальными вероятностями. Какое количество брать и в связи с чем не очень понятно. Видел пример с 3. Это нам дает возможность сформировать 2^3=8 тестовых последовательностей. Далее проводим декодирование жестких решений 8 тестовых последовательностей, где на позициях с малой вероятностью располагаются все возможные биты, какие там могут быть, т.е. с целью перебора всех возможных вариантов. После декодирования БЧХ-декодером, получаем 8 возможных исправленных вариантов. Далее сравниваем их с кадром из мягких решений, смотрим какое максимально приближено, то и выбираем. Как получить далее новые мягкие решения мне пока не понятно, но пока еще рано.

В чем собственно вопрос?) В статье нашего китайского друга приведены несколько другие этапы декодирования. И в начале они делают жесткие решения, по ним проводят БЧХ-декодирование и получают синдром. Далее ищут позиции с самыми низкими вероятностями и выполняют какие то магические манипуляции с полученными данными.

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

Статью и блок-схему прикрепил к сообщению. Кто-нибудь из гуру блочных турбокодов может прокомментировать сложившуюся ситуацию?

очень сильно напоминает алгоритм Чейза

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

есть доработанный алгоритм - вложение

pyndiah1998.pdf

[Neznaika 0]

Спасибо, Алексей, за ответ) По первой ссылке я был и даже удалось пообщаться с автором статьи по некоторым непонятным вопросам. На базе этого примера алгоритма Чейза действительно не определить мягкие решения. Глянул вашу вторую статью, с ходу разобраться сложно, но наверно можно. В инете нарыл немного другую статейку с живым примером (прикрепил к сообщению), но и там увы не все понятно.

Пока у меня в голове получаются следующие этапы:

1. Находим позиции с меньшими вероятностями.

2. Заменяем их всеми возможными значениями 1 и 0, формируя тестовые последовательности.

3. Принимаем жесткие решения по остальным битам.

4. Декодируем полученные тестовые вектора БЧХ-декодером.

5. Далее модулируем их при образуя в вектора со значениями (1,-1).

6. Исходя из примера моей статьи проводим столько этапов, сколько у нас векторов.

7. Вычисляем вероятность L=1/2(S_плюс-S_минус).

Я на верном пути или где то глубоко заблуждаюсь?

В статье откуда то берутся значения p(c_i).. откуда они?

Vanst_IEEETransonCom.pdf

[Neznaika 0]

Всем привет! На днях закончил реализацию 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

 

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

25_01_01.pdf

[Serg76 0]

Всем привет! На днях закончил реализацию BTC-декодера (16,11,4)x (16,11,4)x (16,11,4). Получил BER(6дБ)=10^-5 и BER(8дБ)=10^-7. Использовал алгоритм Chase-Pyndiah.

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

[Maverick_ 15]

Всем привет! На днях закончил реализацию 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

 

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

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

[Neznaika 0]

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

icit2007xiao.pdf

ICIT2007cuhk.pdf

com7001.pdf

[Serg76 0]

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

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

[Neznaika 0]

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

Изменено 21 апреля, 2017 пользователем Neznaika

[Serg76 0]

Почему космос то? Я изначально указывал что при 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. Разберитесь, что и как Вы измеряли, может оказаться, что не все так плохо с декодером.

[Neznaika 0]

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

Последняя статья написана про железяку, которая сделана на базе микросхемы АНА, потому и характеристики такие мощные.

Изменено 21 апреля, 2017 пользователем Neznaika

[Serg76 0]

В моделе декодер работает как нужно, исправляя ошибки на очень низких отношениях сигнал/шум, а вот в железе получаю 8дБ. Но в моделе не учитываю модуляцию.

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

 

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