Max-Log-MAP-декодирование свёрточного double-binary турбокода, Алгоритм реализован, но даёт неверный выход, нужна помощь Опции

[Coder2009]

Попробовал сделать программную реализацию алгоритма Max-Log-MAP для Double-Binary турбокода. Реализацию делал согласно источнику "Low-Power Traceback MAP Decoding for Double-Binary Convolutional Turbo Decoder" (прикрепленный файл mlmap.pdf), раздел II - это оказался единственным более-менее понятным документом с описанием алгоритма для недвоичных свёрточных кодов из всех, что мне удалось найти. Программу писал на Си.

Вроде бы, ничего сложного, сделал всё один в один как написано, а результат получается неверный. Причём неверный результат даёт декодер SISO уже на первой итерации, при том, что на вход подаётся ВЕРНОЕ кодовое слово, не содержащее ошибок. Апостериорные вероятности получаются либо неверными, либо, порой, неоднозначными, ибо получаются равновероятными сразу несколько вариантов.

Буду благодарен, если подскажете, что и где я делаю не так, что именно недопонимаю (а может, и в самом источнике где-то что-то неверно?).

Ниже, в прикреплённом файле lmap.txt, привожу полное описание алгоритма с комментариями и фрагментами кода на Си.

Заранее огромное спасибо всем, кто решится изучить мою проблему.

Сообщение отредактировал Coder2009 - Aug 10 2009, 13:09

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

 mlmap.pdf ( 136.81 килобайт ) Кол-во скачиваний: 200
 mlmap.txt ( 5.15 килобайт ) Кол-во скачиваний: 169

 

[Grumbler_2002]

Для начала надо посмотреть на "мягкие" решения с выхода MAP-декодера на каждой полуитерации. На первой полуитерации при замкнутой или приведенной в некоторое состояние решетке кодера не должно быть просадок в решениях. В идеале, они должны быть одинаковы. На второй полуитерации начинает влиять перемежитель, поэтому, например, при несовпадении матриц перемежения кодера и декодера и небольших шумах на фиксированных местах станут появляться ошибки.

Сам я применял tail-biting CTC с полным декодированием и с декодированием "скользящим" окном. Разницы между ними практически не было, но была исследовательская работа по определению величины перекрытия окна и анализу спектральных свойств синтезированных кодов.

[Neznaika]

Для начала надо посмотреть на "мягкие" решения с выхода MAP-декодера на каждой полуитерации. На первой полуитерации при замкнутой или приведенной в некоторое состояние решетке кодера не должно быть просадок в решениях. В идеале, они должны быть одинаковы. На второй полуитерации начинает влиять перемежитель, поэтому, например, при несовпадении матриц перемежения кодера и декодера и небольших шумах на фиксированных местах станут появляться ошибки.

Сам я применял tail-biting CTC с полным декодированием и с декодированием "скользящим" окном. Разницы между ними практически не было, но была исследовательская работа по определению величины перекрытия окна и анализу спектральных свойств синтезированных кодов.

При моделировании с функцией randG неоднократно рассматривал мягкие решения. Как правило если после первой итерации наблюдается какое то число ошибок, то в дальнейшем приблизительно с коэффициентом 2-3 оно снижается до 0... вот например результат: 61 14 6 4 - итог 4 итераций... причем те самые 4 пропущенные ошибки прошли сквозь все операции без исправления. Изначально использовал архитектуру из одной статьи, где на второй SISO подавались только LLR с первого SISO и проверочные мягкие решения для 2-го SISO. Система исправляла, но из-за аналогичного недобора в S/N.. решил использовать стандартный вариант с добавлением перемешенных входных данных, те ошибки которые наблюдались в блоках в первом варианте ушли, но декодер хоть и стал работать лучше, но не намного. Буквально только что проделал еще некоторые исследования с LLR.
Например на входе пара мягких 4-битных решений (доп. код) ( A,B )=(x"b",x"f"), без шума д.б. (1,1). LLR (11 бит) для нее по полуитерациям:
Ит.1 {LLR(01),LLR(10),LLR(11)}: {x"000",x"030",x"000"} {x"7f8",x"02c",x"000"}
Ит.2 {LLR(01),LLR(10),LLR(11)}: {x"7fc",x"018",x"018"} {x"7f0",x"018",x"034"}
Ит.3 {LLR(01),LLR(10),LLR(11)}: {x"7e0",x"024",x"044"} {x"7e8",x"00c",x"054"}
Ит.4 {LLR(01),LLR(10),LLR(11)}: {x"7d0",x"7f0",x"050"} {x"00c",x"014",x"094"}
Решения принимаются по значениям в доп. коде. Видно, что первоначальная операция определяет 10, но к 4-ой операции получаем 11, причем LLR(11) в 7 раз больше, чем LLR(10). Вроде бы неплохая сходимость.
Стал добавлять уровень шума до тех пор пока декодер не ошибся в блоке, причем по итерациям выдал ошибок: 9 6 4 5. Посмотрел LLR ошибочных бит. Без шума пара (0,1):
Ит.1 {LLR(01),LLR(10),LLR(11)}: {x"008",x"008",x"014"} {x"008",x"000",x"01c"}
Ит.2 {LLR(01),LLR(10),LLR(11)}: {x"004",x"004",x"010"} {x"7f0",x"7e8",x"018"}
Ит.3 {LLR(01),LLR(10),LLR(11)}: {x"004",x"7ec",x"024"} {x"000",x"7fc",x"02c"}
Ит.4 {LLR(01),LLR(10),LLR(11)}: {x"008",x"000",x"02c"} {x"00c",x"7e4",x"014"}
Вроде бы сходится, но очень медленно... к 4-ой итерации ошибка - вместо (0,1) - (1,1), решил добавить коэффициент 0.5 перед внешней информацией. При том же отношении С/Ш декодер не ошибся и выдал по итерациям: 11 4 2 0. Глянул LLR той же пары...
Ит.1 {LLR(01),LLR(10),LLR(11)}: {x"008",x"008",x"014"} {x"00c",x"000",x"01c"}
Ит.2 {LLR(01),LLR(10),LLR(11)}: {x"008",x"004",x"00c"} {x"7f4",x"7ec",x"010"}
Ит.3 {LLR(01),LLR(10),LLR(11)}: {x"00c",x"004",x"010"} {x"004",x"7f0",x"00c"}
Ит.4 {LLR(01),LLR(10),LLR(11)}: {x"018",x"00c",x"014"} {x"008",x"7e4",x"000"}
---
Ит.8 {LLR(01),LLR(10),LLR(11)}: ------- {x"010",x"7e0",x"7f0"}
Не ошибся и сходимость видна, ввел этот коэффициент и в проекте, но все заработало гораздо хуже. Вообщем я снова подвис.
Что касается интерливера/деинтерливера... то вчера успел проверить только интерливер, и ручкам посчитал и в симуляторе адреса перепроверил, все верно....
А что за tail-biting CTC такой? Там что то с цикличными состояниями кодера же связано? Я тупо в декодере использую последние значения рекурсий предыдущей итерации для последующей итерации. Для чего это надо? И куда вкрутить?

Могу только посоветовать ознакомиться со следующей статьей:
L. C. Perez, J. Seghers, and D. J. Costello, ”A distance spectrum interpretation of turbo codes,” IEEE Trans. Inform. Theory, vol. 42, pp.1698–1709, Nov. 1996
http://wireless.ece.ufl.edu/eel6550/lit/Tu...um_Costello.pdf

Там написано, чем определяется асимптотика кривой BER любого турбо-кода при высоких-средних SNR и почему в графике BER присутствует waterfall region на низких SNR.

Спасибо, продуктивная статья.. напоминает мой случай... но только диапазоны величин S/N другие... в статье около 1-2 дб... я же застЬял на 1-2 дБ выше... Но формы кривых похожи...

Насколько я понимаю, кодер для турбо-кода строится вокруг кодера для систематического сверточного кода: проверочные символы формируются для входного блока и для входного блока, прошедшего через перемежитель.

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

Я понял, спасибо.. хорошая идея для проверки перемежителей)

Что касается демодулятора:
- для начала демодулятор хорошо бы проверить и отладить, если нет возможности работать без него

потом:
- определяете чувствительность по любому критерию
- ставите сигнал на 20 дБ выше уровня чувствительности. демодулятор уже влиять не должен. проверяете это прогоном: ошибок быть не должно
- добавляете шум от внешнего генератора.

Без демодулятора скорее всего не получится, надо много железа переворотить, чтобы выбросить его из цепи. Чувствительность демодулятора около -85дБм... уровень сигнала около -70 дбм, я думаю демодулятор не должен ничего серьезного вносить. Есть конечно на 8PSK и 16QAM легкие раскачки фазы, но они на глаз малы, есть слабая размазанность точек без шумов, но тоже на мой взгляд ничего серьезного.


Сообщение отредактировал Neznaika - Apr 4 2014, 08:53