Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов Опции

[des00]

Т.е. это математически это все равно - скалить сигнал на входе или созвездие в демаппере.
...
суть вопроса от меня ускользает - можно отскалить вход как это будет удобно.

Согласен с вами во всем, похоже вопрос задал не совсем понятно. Задам с графическим материалом.
На рисунке qpsk - классический QPSK, с точками {4,4} и SNR 5дб, по стандарту так должно быть отмасштабировано созвездие для кодирования 1/2. На рисунке qpsk_sat тоже созведие, но после ограничения диапазона [-8,7]. Видно что такое ограничение не особо критично. На рисунке qpsk_6by7 созвездие перед ограничением отмасштабировано с коэффициентом (6/7)/(1/2). Видно что большая часть точек, ушла в зону ограничения. Это я и назвал термином "насыщение квантователя". Т.е. большую часть статистической информации тупо выкинули.

что ограничение на входе декодера полезно даже без квантования.

Да, вы про это уже писали. Возражений тут никаких, единственное что уровень ограничения в ПЛИС я делаю меньше, т.е. для QAM16 с уровнями 1 и 3, беру 2 бита запаса в сигнале в ару и перед декодированием ограничиваю по уровню 4, мне так проще в ПЛИС.

Видимо, провели моделирование какое-то, чтобы подтвердить результаты.

Похоже что вы правы, сам не додумался. ИМХО это сильно на шаманство похоже. Вырезать актуальную информацию из канала, вместо того что бы 1 бит в метрику накинуть или нелийнейное квантование сделать.

Эскизы прикрепленных изображений

 

[andyp]

Т.е. большую часть статистической информации тупо выкинули.

Тут стоит оценить дисперсию ошибки квантования vs дисперсия ошибки ограничения на рабочих SNR декодера для разных скоростей. Хотя даже это не будет критерием "лучшести" квантователя из-за нелинейности декодера. Нужно на BER смотреть.

Похоже что вы правы, сам не додумался. ИМХО это сильно на шаманство похоже. Вырезать актуальную информацию из канала, вместо того что бы 1 бит в метрику накинуть или нелийнейное квантование сделать.

Я тоже за дополнительный бит , но я ж софтверщик - он мне фактически ничего не стоит. В железе, думаю, сложность будет линейно расти с количеством входных бит. Авторы электричество и вентили экономят вовсю.

[des00]

Созрел следующий вопрос: метрики состояний проходят через процедуру нормализации. А как поступают с Lextrinsic и выходными LLR битов ? Судя по результатам моделирования, при сходимости декодера, Lextrinsic, а за ним и LLR выходных символов/битов имеют тенденцию к росту от итерации к итерации. Но, как я понимаю, нормализовать их нельзя, а логичнее использовать ограничение на определенном уровне. Правда упоминание об этом в статьях я не нашел, так ли это ?

[andyp]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

[des00]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

[andyp]

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

[des00]

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

хмм, надо еще будет эту тему прошерстить.

В приложении матлабовский примитивный, без какой либо оптимизации, декодер dvb-rsc, часть функций сделана близко к железу, позволяет покрутить/посмотреть что и как считается, что куда идет, как себя ведут метрики и прочее Содержит комментарии как что и куда. Перехожу к работе над HDL идеалкой.

Прикрепленные файлы

 ctc.zip ( 12.61 килобайт ) Кол-во скачиваний: 39

 

[Maverick]

хмм, надо еще будет эту тему прошерстить.

В приложении матлабовский примитивный, без какой либо оптимизации, декодер dvb-rsc, часть функций сделана близко к железу, позволяет покрутить/посмотреть что и как считается, что куда идет, как себя ведут метрики и прочее Содержит комментарии как что и куда. Перехожу к работе над HDL идеалкой.

спасибо...

[des00]

спасибо...

там я только немного "накосяпорил" когда считал оценочный FER (FEC Error Rate), затер некодированный BER. Только сейчас увидел, будете пробовать поправьте

[andyp]

Перехожу к работе над HDL идеалкой.

Поздравляю с завершением этапа

[des00]

Поздравляю с завершением этапа

Похоже где то я ошибся Сделал идеалку на RTL, осознал откуда растут ноги у количества эффективных бит у метрик пар/ветвей/состояний/extinsic. Но? начал гонять и заметил расхождение в характеристиках декодера, по сравнению с используемым мной "референсным" документом. Документ в приложении, характеристики на странице 3 (466 страница документа). Набрел на него когда искал точки привязки BER для декодера(в других найденных документах приводился FER в качестве характеристик).

Первая мысль что используемый для моделирования в RTL генератор шума не верен. Отложил в сторону RTL. Взял матлабовский вариант без квантования, ограничений, честный Log Map и т.д. Тоже не бьются кривые с документом. Особенно если учесть тот факт, что в документе якобы рассмотрен Max Log Map без каких либо улучшений. Проверяю на QPSK, пакет длинной 64 пары, кодирование 1/3, 10 итераций. Пример расхождения характеристик : EbN0 = 2.5дб, в статье BER 5е-5, RTL код BER 4е-4, матлаб 2е-4.

Может кто нибудь поделиться ссылками на эталонные результаты или характеристиками своих декодеров? Интересует кривая для пакета 64 пары, кодирование 1/3, 8 итераций. Диапазон EbNo 0.5:0.5:4.

Прикрепленные файлы

 Design_and_Implementation_of_Low_Power_Turbo_Encoder_for_DVB_RCS_Software_Radio.pdf ( 436.62 килобайт ) Кол-во скачиваний: 84

 

[andyp]

Поделиться результатами не могу - давно было, так что нет под рукой ни результатов ни кода.

Посмотрел повнимательнее твой матлаб - есть один момент:

У тебя решетка циклическая, следовательно состояния решетки в начале и конце должны быть одинаковыми. Начинать нужно с альф. Доходишь до конца, используешь последние полученные альфы для инициализации (N+1)ых бет и идешь назад по решетке. Затем сохраняешь полученные 0ые беты для использования как 0ые альфы на следующей итерации.

[des00]

Похоже где то я ошибся

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).

У тебя решетка циклическая, следовательно состояния решетки в начале и конце должны быть одинаковыми. Начинать нужно с альф. Доходишь до конца, используешь последние полученные альфы для инициализации (N+1)ых бет и идешь назад по решетке. Затем сохраняешь полученные 0ые беты для использования как 0ые альфы на следующей итерации.

Понял, проверю. Цикличность отдельно альф от бет я сделал основываясь на разделе в стандарте (в приложении). С бет начинал потому что планирую в железе делать sliding window с двумя движками для бет и одним для альф. Уж больно не хочется два раза массив данных перебирать.

Когда искал в чем косяк созрел такой вопрос. Насколько правомочно формирование метрик отсчета L1,L2 для дебитов по правилу:
L00 = 0, L01 = L2, L10 = L1, L11 = L1+L2. По идее это результат вычитания из метрик L01/L10/L11 метрики L00. Но тогда должно быть так :
исходные метрики L00 = -L1-L2, L01 = -L1 + L2, L10 = L1 - L2, L11 = L1+L2 и после вычитания получается L00 = 0, L01 = 2*L2, L10 = 2*L1, L11 = 2*(L1+L2).

Казалось бы постоянный множитель LLR алгоритму не принципиален, но ведь этот множитель задает распределение надежностей. Например пусть L1/L2 = 4, тогда честные метрики будут : L00 = -8, L01 = 0, L10 = 0, L11 = 8. "Расстояния" между метриками L01/L10/L11 и метрикой L00 будет 0/8/8/16. Тогда как по упрощенному правилу метрики будут L00 = 0, L01 = 4, L10 = 4, L11 = 8 и расстояния 0/4/4/8. Как более правильно? Или этом пренебрегают в виду того, что exp(-4) = 0.0183 и exp(-8) = 3.3546e-04?

Эскизы прикрепленных изображений

 

[Mogwaika]

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).

Код запускаете напрямую или компилируете в mex или exe?
У меня для декодера компиляция дала прирост почти на порядок.

[des00]

Код запускаете напрямую или компилируете в mex или exe?
У меня для декодера компиляция дала прирост почти на порядок.

Судя по всему напрямую, рылся в хелпе как скомпилировать в mex (в симулинке такое делать умею), а тут так и не разобрался.