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

 

[Serg76]

1. У меня, все-таки, остаются сомнения в правильности формирования кодовых слов с выхода Вашего кодера, может что-то упустили или не до конца все понимаете. Был бы штатный модем или имитатор, то вопросов с тестовым сигналом не было бы. Если, все-таки, в работе кодера Вы уверены, то я бы для начала посоветовал посмотреть работу декодера только на первой полуитерации, т.е. "заморозить" процедуру итеративного декодирования и влияние перемежителя. Для небольшого шума этого достаточно для исправления ошибок.
2. По поводу инверсии LLR все правильно.
3. Соотношение С/Ш на входе декодера проще брать с демодулятора, он ведь у Вас имеется в тракте, правда для корректной оценки нужно еще учитывать потери самого демодулятора, ну а BER декодера посчитать не трудно по известному патерну.

[Neznaika]

1. У меня, все-таки, остаются сомнения в правильности формирования кодовых слов с выхода Вашего кодера, может что-то упустили или не до конца все понимаете. Был бы штатный модем или имитатор, то вопросов с тестовым сигналом не было бы. Если, все-таки, в работе кодера Вы уверены, то я бы для начала посоветовал посмотреть работу декодера только на первой полуитерации, т.е. "заморозить" процедуру итеративного декодирования и влияние перемежителя. Для небольшого шума этого достаточно для исправления ошибок.
2. По поводу инверсии LLR все правильно.
3. Соотношение С/Ш на входе декодера проще брать с демодулятора, он ведь у Вас имеется в тракте, правда для корректной оценки нужно еще учитывать потери самого демодулятора, ну а BER декодера посчитать не трудно по известному патерну.

1. Я могу сгенерить любое кодовое слово, для тестового сигнала, если у вас есть модель этого кодека, и если вас не затруднит (требую конечно слишком многого ), то можно сравнить. Например, для R=1/2, N=864 (или ваш вариант) и можно взять тестовую последовательность из байтов x"87" или усугубить x"87" & b"10"... достаточно сравнить первые пары бит в проверочной информации (Y10,Y20,Y11,Y21...). Для N=64 все совпадает с примером, а вот для N=864... попробую проверить состояния цикла. При малом шуме я не вижу ошибок после первой полуитерации в мягких решениях. Ошибки появляются при отношениях С/Ш порядка 3.5-4 дб для R=1/2 и N=864, а их там быть не должно.
3. Одно время я тестировал демодулятор без кодирования с помощью BER-тестера... кривая соответствует BERу без кодирования, нарисованному в литературе. В модеме, для которого кодек и делается есть измеритель с/ш. Один и тот же генератор шума подключал как к импортному модему, так и к моему - измерения совпадают.

Вообще еще любопытен тот факт, что при измерениях BER ошибки появляются пачками... если например блок N=864... то кодек может работать какой то промежуток времени чисто, а потом выдать по блоку 30 битовых ошибок... это для QPSK 1/2... для QAM16, 3/4 вообще чистые паузы прерываются ошибками сразу 100-150 битами....

Сейчас еще глянул в ИНЕТе описание randG... единственная ссылка, которая говорит как она работает... http://delphi.scps.ru/math/math5301.htm
Но проверив у себя randG(0,0.2)... получил размах от -0.45 до 0.53... очень странно...

[andyp]

Но проверив у себя randG(0,0.2)... получил размах от -0.45 до 0.53... очень странно...

Правило 3 сигма слышали? 0.2*3 = 0.6 естественно ожидать, что отсчеты шума будут от -0.6 до 0.6 и очень редко вылетать за этот диапазон.

http://www.encyclopediaofmath.org/index.php/Three-sigma_rule

PS Чтобы минимально проверить генератор можно гистограмму построить и проверить, что получается знакомый гауссовский колокол. Но если охота всякие 1e-7 ловить, то лучше пользоваться генератором случайных чисел хорошего качества и хорошим алгоритмом для генерации нормального распределения.

Сообщение отредактировал andyp - Apr 10 2014, 11:54

[Neznaika]

Правило 3 сигма слышали? 0.2*3 = 0.6 естественно ожидать, что отсчеты шума будут от -0.6 до 0.6 и очень редко вылетать за этот диапазон.

http://www.encyclopediaofmath.org/index.php/Three-sigma_rule

О правиле 3 сигм не слышал А вот то, что 2-м аргументом выступает среднее квадратичное значение, это где то видел. Я попробовал туда подставлять (0.4)^2 и получил значения (-0.4, +0.4), надеюсь что с нормальным распределением...

Сегодня пол дня мучил свой модем, сравнивая BERы (по внутренним измерителям и используя контрольный внешний) в тех же режимах, что у импортного. Мой модем ничуть ему не уступал, включал и выключал Витерби, смотрел без кодирования... все BER-ы идентичны... кроме TPC

Что касается кодовых слов... приведу 3 варианта мной полученных с помощью модели на Си (возможны опечатки):

1. Входной сигнал x"87" из примера к стандарту для N=64 и N=864 (кодовое слово идентично получилось)
A=x"99", x"99", x"99"...
B=x"33", x"33", x"33"...
W1=x"55", x"55", x"55"...
Y1=x"33", x"33", x"33"...
W2=x"aa", x"aa", x"aa"...
Y2=x"66", x"66", x"66"...
Кодовое слово для R=1/2:
I(A)=x"99", x"99", x"99"... I(Y1)=x"33", x"33", x"33"...
Q(B )=x"33", x"33", x"33"...Q(Y2)=x"66", x"66", x"66"...

2. Входной сигнал x"87" & b"10" для N=64
A=x"9" & '1', ...
B=x"3" & '0', ...
W1=x"b9", x"20", x"d5", x"0f", x"37", x"24", x"1a", x"a1"
Y1=x"ab", x"c3", x"23", x"6f", x"95", x"78", x"64", x"6d"
W2=x"99", x"ab", x"7f", x"ff", x"f8", x"7b", x"84", x"92"
Y2=x"67", x"b5", x"ec", x"b2", x"cd", x"72", x"9d", x"f7"
Кодовое слово для R=1/2:
I(A)=x"9c"... I(Y1)=x"ab"...
Q(B )=x"31"...Q(Y2)=x"67"...

3. Входной сигнал x"87" & b"10" для N=864
A=x"9" & '1', ...
B=x"3" & '0', ...
W1=x"83", x"54"...
Y1=x"0c", x"8d"...
W2=x"94", x"60"...
Y2=x"78", x"09"...
Кодовое слово для R=1/2:
I(A)=x"9c", x"e7"... I(Y1)=x"0c", x"8d"...
Q(B )=x"31", x"8c"...Q(Y2)=x"78", x"09"...

Что касается измерений в модели:
Взял N=64 и R=1/2. Пропустил через кодек около 10000 бит с шумом от randG, Pb вх=3.7*10^-2, получил BER=0, ни на одной из итераций не было допущено ошибок. Не уже ли глюк на VHDL закрался... из-за джиттера тактового сигнала или где-то сигнал управления буферами обрезается при живых клоках. В симуляторе VHDL для N=864... сравнивал по итерациям LLR с моделью на Си... совпадало до последнего бита... Надо снова все перепроверить...

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

[Serg76]

2. Входной сигнал x"87" & b"10" для N=64
A=x"9" & '1', ...
B=x"3" & '0', ...
W1=x"b9", x"20", x"d5", x"0f", x"37", x"24", x"1a", x"a1"
Y1=x"ab", x"c3", x"23", x"6f", x"95", x"78", x"64", x"6d"
W2=x"99", x"ab", x"7f", x"ff", x"f8", x"7b", x"84", x"92"
Y2=x"67", x"b5", x"ec", x"b2", x"cd", x"72", x"9d", x"f7"
Кодовое слово для R=1/2:
I(A)=x"9c"... I(Y1)=x"ab"...
Q(B )=x"31"...Q(Y2)=x"67"...

я так понимаю, что информационная часть кодового слова представляет собой меандр, т.е. "10101010..." в битовом виде? если так, то это несовсем удачный выбор как для декодера, там и для модема в целом. в таком случае первая половина проверки будет содержать "единицы" - "11111111...", а вторая половина - обратный меандр - "01010101" . я Вам предлагаю для сравнения свое кодовое слово, 256 бит которого выглядят следующим образом:

"000110010011111001010110100001011111011100011100001100100100100010101101101
100111110110110101000011011011111000101101100001001110111101011100101011010101011
011010101100000100001010011011111110100010011101010011000011010001111110110100111
1111110001101101100"