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

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

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

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

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

Разобрался, вопрос снят, при расчёте обратной рекурсии была наибанальнейшая ошибка в индексе Выражение должно быть таким: (gamma[k][s][z] + alfa[k][s] + beta[k+1][S_Out[s][z]]).

Неясно где была ошибка, согласно прилагаемого файла обратная рекурсия расчитывалась:

А согласно поправки написано выражение

как я понимаю для max[z] ?
так где же ошибка?

Всем привет! Нахожусь в затруднительном положении. Реализовывал TPC-кодек по стандарту DVB-RCS EML-MAP алгоритмом. Результаты BER для всех скоростей примерно на 1 дб S/N уступают ожидаемым. Может есть какие то ошибки в принципах реализации?
1. Использовал цикличное кодирование по заданным состояниям цикла в стандарте. Кодировал блок с 0-м состоянием кодера, потом вычислял состояние цикла и снова с этим начальным цикличным состоянием кодера кодировал блок данных, после отправлял к модулятору. В декодере на первой итерации всем метрикам прямой и обратной рекурсии присваивал 0-ые значения. Полученные значения метрик прямой рекурсии в конце итерации использовал на следующей итерации как начальные значения, т.е. в качестве метрик состояния цикла. После каждой итерации их обновлял.
2. Для расчета обратной рекурсии использовал метод окон и метод граничных метрик (Border metric). Разбивал блок на окна, причем при 1-ой итерации в качестве начальных значений метрик обратной рекурсии использовал 0, сохранял последние значения метрик обратной рекурсии каждого окна, чтобы использовать их в качестве начальных метрик для вычисления окон обратной рекурсии при последующей итерации. На каждой итерации значения обновлялись.
3. Масштабировал внешнюю информацию с коэффициентом 0.75, Lex=0.75*(Lapo-Lapr-Lin).
4. Вход 4-битный, со средним уровнем входных данных 0.5.

Видел в статьях что то про Tailing Bitting - не совсем понятно зачем и для чего... но какая то привязка к цикличному кодированию есть...
Вообще архитектура себя ведет вполне предсказуемо, с увеличением числа итерации качество BER, растет. Игра с коэффициентом масштабирования внешней информации тоже дает положительный результат... При 1 и при 0.5 BER заметно хуже, чем при 0.75.

Еще есть характерная особенность, что при достижении BER в 10^-7 появляется шумовая полка.. BER в нее упирается и уже не зависит от S/N.

Вы могли бы уточнить про 10^-7? т.е. если шума нет (передатчик и приемник соеденины золотой проволокой), то тоже 10^-7?

Вот самое главное.. BER) Без шума все по нулям работает. Привожу 3 графика. 1 - результаты полученные мной, 2 - результаты моделирования из статьи по стандарту DVB-RCS, 3 - FER, к сожалению, а не BER архитектуры декодера, аналогичной моей.

Конечно, готвых рецептов "как починить" у меня нет.

Но если бы я столкнулся с такой задачей, то
1. Посмотрел, правильно ли у меня работает перемежитель-деперемежитель. 10е-7 может говорить, что, например, 1 позиция в матрице перемежителя неправильная.
2. Посмотрел бы образующий сверточный кодер-декодер. Там, конечно, сложно так витьевато поломать, но хотя бы, что все лежит рядом с теоретическими пределами.
3. Генератор мягких выходов для декодера Витерби. Он может тупо шуметь.

Про tail-biting посмотрите у Морелоса для начала. Там чуть другая идея декодирования, чем при обычном zero-tail, и проще ее понять, если представить, что пути декодирования нарисованы на ленте, свернутой в кольцо.

Спасибо за ответ)
1. Перемежитель еще раз проверю. У меня есть модель на Си и проект на VHDL, работают они идентично (с точностью до младшего бита) с одинаковыми входными сигналами. Вот только для модели могу проводить приблизительные измерения, добавляя шум функцией randome, а проект уже работает с реальным канальным шумом от железячного генератора шума.
2. "Посмотрел бы образующий сверточный кодер-декодер. Там, конечно, сложно так витьевато поломать, но хотя бы, что все лежит рядом с теоретическими пределами." - вот тут не понял, что такое образующий сверточный кодек и как проверить, что все лежит с теоретическими пределами?
3. В этой же системе Декодер Витерби работает очень даже здорово, все его BER-ы входят с хорошим запасом в маску по Витерби. А вот может ли демодулятор подшумливать на S/N при 3 дб... вот тут как проверить?

По поводу Морелоса.... у меня даже книжка на русском в бумажном варианте, есть.. там есть пару абзацев про кольцевую конструкцию, но той информации мне не достаточно для понимания, чтобы использовать это в декодере, покопаюсь в ИНЕТе еще на эту тему.

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

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

.

Так это ж характерная особенность турбо-кодов. В них всегда есть слова с маленьким весом, которые изредка портятся - событие маловероятное, но случающееся. Таков уж спектр кода. Вон у народа тоже дуобинарный код и полка на уровне 1e-7 примерно:
http://koasas.kaist.ac.kr/bitstream/10203/...4445%5B1%5D.pdf

Гугл на запрос turbo code noise floor выбрасывает море информации.


PS Если крутизна кривой BER соответствует ожидаемой в теории, я бы перепроверил все условия эксперимента (правильное ли количество шума подается, сколько добавляет квантователь на входе и т.п.).

Нельзя так говорить. Еррор флор может быть особенностью какой-то конкретной реализации кода, но не всех турбокодов вообще. Обсуждаемый код мне неизвестен, но если в доке еррор флора на графике не видно, то его и не должно быть..

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

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

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

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

Могу только посоветовать ознакомиться со следующей статьей:
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.

При моделировании с функцией 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 такой? Там что то с цикличными состояниями кодера же связано? Я тупо в декодере использую последние значения рекурсий предыдущей итерации для последующей итерации. Для чего это надо? И куда вкрутить?



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


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


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

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

Для практики интересенее та ссылка, что я оставлял ранее



Если у Вас размер кодового блока и число итераций тот же, что и в статье, noise floor на том же уровне, и крутой участок кривой BER имеет ту же крутизну (т.е. фактически Ваш график BER просто сдвинут по горизонтали при прочих равных), то я бы сначала искал проблему в калибровке уровня шума на входе декодера и формировании входных LLR.

Так и чью точку зрения подтверждает ваша статья?
Мою.
Сначала вы говорите что 10е-7 "это нормально", а теперь оказывается, что асимптотика всё же чем-то определяется в каждом конкретном случае?
Но я это сказал с самого начала. Если в доке на данный код нет еррор флора на 10е-7, то его и не должно быть.
Если допустим он есть на 10е-12, то как будем считать, есть флор или нет?
На всякий случай сегодня код UMTS прогнал вплоть до 10е-9, флора нет.

Ну в первой ссылке, которую я приводил, ЕСТЬ error floor на 1e-7 для кодового блока 4800 бит. Там тот же код что и ТС, поэтому я и сказал, что это нормально.

А вот здесь он есть на 1е-6
http://www.csee.wvu.edu/~mvalenti/documents/DOWLA-CH12.pdf, смотри Figure 12.8, размер блока ~1500 бит.

PS может нужный паттерн не попадается во входных данных или шум не совсем случайный.

Пока ничего нового в своем декодере не нарыл и стал проверять очевидные вещи, в одной из статей по DVB-RCS прописано, что этаж ошибки напрямую привязан к интерливеру. Снова стал к нему внимательно приглядываться, вышел на неоднозначность своего представления о нем.
В стандарте указаны формулы для расчета адресов перемежения i на основе параметров Р и индекса входных мягких решений j. Напомню:
j=0,.. N-1
i(j)=(P0*j+P+1)modN.
Так вот.. к примеру для N=864 получились следующие адреса:
i(0)=1
i(1)=454
i(2)=55
i(3)=496
.....
Что это за адреса? Это адреса по которым в память интерливера записываются входные данные или считываются из нее? Мой интерливер работает с этими адресами как с адресами чтения, т.е. данные в буфер записываю в последовательном порядке, а потом считываю по вычисленным адресам, может в этом проблема?

Это адреса, по которым надо считывать данные из входного буфера перед перемежением, но они какие-то неправильные. Код дуобинарный, поэтому отсчеты обрабатываются парами, следовательно, перемежитель должен содержать парные индексы, например: 2,3; 461,460; 62,63 и т.д.

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

Давайте тогда разбираться, что в Вашем случае N. Я посчитал, что N - это длина информационной части пакета в битах (108 байт), т.е. в парах отсчетов это будет 432, такой режим в DVB-RCS тоже есть. Для этого случая я Вам выдал закон битового деперемежения, вернее сказать его начало. эта последовательность - адреса, по которым надо считывать данные из входного буфера в процессе деперемежения, т.е. перед декодированием на второй полуитерации. можете проверить правильность этого закона у себя в перемежителе. если сойдется - значит все правильно, я реализовывал этот кодек, все работало на живом сигнале. если Вы говорите, что N - это все-таки число пар отсчетов, то закон будет, конечно же, другой. сейчас я не имею возможности его вывести, может завтра. Такой режим тоже имеется в перечне стандарта.

Посмотрел перемежитель для данного случая, адреса для пар отсчетов рассчитаны правильно: 1, 454, 55, 496, 77, 530, 131, 572, 153, 606, .....

Сегодня нашел ошибку с своем перемежителе. Теперь приведенный пример полностью соответствует моему кодовому слову. Рассчитанные адреса - это адреса чтения, у меня собственно так и было сделано. А вот инверсия в паре была выполнена не в тот момент. Я принимал индексы j=0... N-1, за индексы пар информационной последовательности, а это индексы перемежителя. В моделе на Си удалось быстро скорректировать эту оплошность, а вот на VHDL закопался, прежние тесты не проходят, где то что то поменял и забыл при последнем тестировании. Но все-равно как то не верится, что место инверсии пар в перемежителе/деперемежителе может испортить качество работы кодека.
Проверил... так и вышло, это практически никак не сказалось на качестве декодера... увы

Инверсия пар сама о себе - штука крайне нужная. Без нее будет хуже работать. Узнать подробности можно набрав в гугле interleaver local disorder. На счет поиска ошибок только могу посоветовать оставить VHDL и снова обратиться к модели на C. В модели добиться соответствия кривой FER/BER с другими результатами (см. например прицепленный файл, 16-state coder или другие результаты Клода Берро по дуобинарным кодам) для параметров кодирования, указанных в статье. После этого придется снова привести в соответствие VHDL и модель.

Neznaika , а что, собственно, из себя представляет тестовый сигнал? Вы генерируете его своими средствами, может проблема в неправильной работе кодера?

Сергей!) Спасибо, за ваш отзыв на мою проблему) Я использую разные тестовые сигналы, и случайные и не случайные. Кодер формирует кодовое слово как из последовательности x"87", так и из случайной последовательности полученной BER-тестером для VHDL модели или функцией Random для Си-модели. Одно время рассматривал сигнал для декодера по последовательности x"87"... с N=64 (число пар). По осциллографу записывал мягкие решения по которым были ошибки и подавал их в Си-модель, ошибки повторялись. Поколдовав с усечениями, округлениями внешней информации, а так же с коэффициентом внешней информации удавалось их устранить, но при том же отношении С/Ш появлялись другие ошибки.
Сейчас кодер заработал как и в примере стандарта после исправления места перестановки в интерливере/деинтерливере, но это не заметно сказалось на общей работе системы.
Сегодня вычитал что такое tail-biting) Как я понял это просто операция предвычисления кодового слова, для получения состояния цикла на основе конечного состояния (начальное состояние 0). Потом с помощью него можно получить проверочные биты с кодера, который будет в конечном состоянии равном начальному. У меня как раз это и выполняется, я только не знал, что это так называется.
Вроде логически все понятно, но почему то не работает, стал сомневаться уже во всем...
Вот например, в деинтерливере мягких решений LLR(01), LLR(10), LLR(11) в том месте где должна быть инверсия пары, я просто меняю местами LLR(01) и LLR(10).. LLR(11) не трогаю. - это правильно или я заблуждаюсь?
И что касается модели на Си.. использую мягкие решения в диапозоне [-1.000...1.000) - 4 бита, т.е. x"8"=-1.0, x"7"=0.875. Для добавления шума использую функцию RandG(0,noise), где noise=[0.000,1.000]. Для получения зашумленного мягкого решения просто складываю эти значения. Например, задавая амплитуду мягкого решения в 0.5, а амплитуду шума 0.4... получаю на входе декодера сигнал S=0.5*c+RandG(0,0.4), где с - это бит кодового слова из диапазона (-1,1)... -1 - соответствует 0, а 1 - единице, сигнал S на всякий случай квантую 4 битами. Будет ли такой способ верным для формирования зашумленных мягких решений для декодера? И можно ли из этих чисел вычислить отношение сигнал/шум на входе декодера? Если конечно тупо взять 20log(0.5/0.4)=1.94дБ - не уверен, что это верно...

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... очень странно...

Да можно и проверить, сгенерируйте кодовое слово, допустим для N = 64, посмотрим проверочную часть.
А пачечная структура ошибок и должна быть, код то сверточный, а следовательно, неисправимая ошибка и будет "размазана", для устранения такой ситуации, к примеру, для внутреннего кода Витерби добавляли внешний РС код.

Не должно, у меня при моделировании такой конфигурации получается следующее:
Eb/No = 2,5 дБ; Pb вых = 1,2e-6; Pb вх = 3,4e-2
т.е. можно сказать, что ошибок на выходе практически нет

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

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

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

О правиле 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 с моделью на Си... совпадало до последнего бита... Надо снова все перепроверить...

Ну так 0.4^2 * 3 = 0.48 - все должно в этих пределах быть. То, что второй аргумент - именно стандартное отклонение написано у Вас по ссылке

http://delphi.scps.ru/math/math5301.htm

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

"000110010011111001010110100001011111011100011100001100100100100010101101101
100111110110110101000011011011111000101101100001001110111101011100101011010101011
011010101100000100001010011011111110100010011101010011000011010001111110110100111
1111110001101101100"

Сергей! Не могли бы вы немного пояснить, где что в вашем кодовом слове. Я понимаю это N=64 и R=1/2... а само кодовое слово представляет последовательность, если привязываться к дуо-бинарному коду (A,B,W,Y): A0,B0,A1,B1,A2,B2.. A63,B63, Y10,Y20,Y11,Y21....Y163,Y263. Так? И сформировано оно с учетом состояния цикла двух кодеров? Если, да, то у меня все не так

В моем примере я расписал все биты в соответствии с названиями бит в стандарте...

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"...

Т.е... А и B - это пары информационной последовательности. Если представить битовую последовательность информационного блока, то она будет иметь вид A0,B0,A1,B1,A2,B2.. A63,B63 или согласно тесту, где A0,A1,..A4=b"10011", а B0,B1,..B4=b"00110"... в итоге получаем:
b"1000011110,1000011110..." или x"87" & b"10", x"87" & b"10"... Я тестовый сигнал сделал периодическим, чтобы легче было его проверять и воспроизводить визуально... ну и использовал 16-ичное представление тоже с этой целью... Извините, что не очевидно расписал свой тест

Не получается у меня по Вашему примеру, проверочные биты не совпадают. Во-первых, проверка формируется на основании состояний двух кодеров С1 и С2, соответственно, для прямой и перемеженной (и попарно инвертированной) информационной последовательностей. Во-вторых, для скорости 1/2 выход W перфоратора не используется, на выходе будут присутствовать только Y проверочные биты.

В моем примере я привел Вам все биты кодового слова, где первая половина соответствует входной информационной последовательности А(0), В(0), ..., А(N-1), В(N-1), а вторая половина состоит из проверочной части Y1(N), Y2(N), ..., Y1(2*N-1), Y2(2*N-1), полученной на основе прямой информ. последовательности ( длина будет рвна четверти от общей длины всего кодового слова, т.е. 64 бита) и перемеженной последовательности ( ее длина тоже будет составлять 64 бита). Итого получаем 128 + 64 + 64 = 256

Посмотрел еще раз, похоже что первая половина проверочной части совпадает, а вторая, которая должна инициализироваться состоянием С2 по прежнему неправильная, потому как она у Вас не учитывалась до сих пор. Посмотрите этот момент.

А у вас получается кодовое слово примера из стандарта, где тестовый сигнал x"87", x"87"... я как раз из-за него определил, что изначально перестановки для интерливера у меня были сделаны не верно и скорректировал их. В первом примере, который я привел, получается так же как и в стандарте. У вас тоже сходится с его примером? Просто очень похожая ситуация к которой я пришел чуть ранее обнаружив, что есть расхождения моего кодового слова с кодовым словом из стандарта именно в проверочных битах Y2.

Выложите стандарт с этим примером

Конечно... вот страница 39...
http://www.etsi.org/deliver/etsi_tr/101700...790v010401p.pdf

Хммм...., вот это уже интересно, с этим примером не сходится )))

Ура! Спешу поделиться хорошей новостью) Благодарю, Сергей, за помощь) На QPSK, R=1/2, S/N=3.2 дБ BER=0!!!!! На S/N=2.5дБ BER=8*10^-7. Как здорово, что вы попросили выложить этот стандарт, рядом с примером обратил внимание на странице 40 на абзац:

Measurements, using samples from a real demodulator with Automatic Gain Control, have put into evidence that the
position of the "sample clouds" within the quantizer range could be optimized for Turbo decoding. One implementation
uses the following rule-of-thumb: "multiply the analogue samples of the demodulator by a constant so that after 4-bit
quantization, the average of the unsigned values is equal to Rate Ч 8, Rate being the Turbo code rate (6/7, 4/5, 3/4,
etc.)".

Про это масштабирование натыкался 2 недели назад, изучая документацию на AHA4540, но решили, что оно не очень важно и не стали корректировать. Сегодня же снова уткнулся в этот текст и от безысходности решили ввести этот коэффициент. Декодер тут же откликнулся с благодарностью, выдав нужную BER. Ввели для R=1/2 коэффициент 1.5. А вот R=3/4 заработало хуже, чем было, коэффициент то 1.5 остался, нужен видимо другой. Похоже все-таки здесь причина))) Спасибо, еще раз! А то я уже стал унывать, а тут такая поддержка. Вы очень меня подзарядили и с шашкой на голо бросившись на декодер, удалось таки нанести ему брешь в непоколебимую броню! Ура! Ура! Ура!)))

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

Я рад, что Вы рады, поздравляю ))), но по характеристикам под S/N я так понимаю подразумевается Eb/No, а то как-то круто получается?

еще вопросик, немного отойду от темы: с LDPC (DVB-S2) получилось?

Да, конечно Eb/N0) С LDPC по DVB-S мне удалось разобраться в тонкостях реализации... я остановился на пол пути, отвлекшись на TPC. Кодер у меня реализован в моделе и на VHDL... а вот декодер... дошел только до отладки блоков FU, которые вычисляют метрики ветвей в двух режимах. Самое сложное было понять организацию памяти для сохранения метрик и как работает сдвигатель Барреля, остальное пока не вызывает вопросов кроме одного маленького, но пока не буду на него обращать внимания. По-моему не очень существенен) Но вот еже ли не заработает?...)

Всем привет) Застьял на измерениях BER) Ситуация следующая... меряю BER BPSK и QPSK без кодирования - все здорово как в книжке. Включаю TPC-кодек R=1/2 и меряю BER систематических данных без декодирования, т.е. вычленяю из кодового слова информационные биты и подаю их на BER-тестер. BER-тестер выдает BER на 1.5-2 дБ хуже, чем должен. Прогонял свой тестовый сигнал, посмотрел как разбросаны ошибки - никакой закономерности не увидел, их много и размазаны. Без шума ошибки исчезают. Пробовал делать искусственный джиттер приемника, делая скорости на передачу и прием немного разные - ошибок нет. Я подвис(

Вообще-то обычная ситуация при неоптимальной/ошибочной реализации декодера..

Декодер то тут причем? Я BER меряю на его входе...

Этого я не заметил.

В таком случае непонятно, что вообще у вас написано.

Если гоните на тестер случайные данные (+шум), то БЕР совпадает с расчётным, а если случайные данные заменить на кодовые слова, то БЕР меняется? Я так понимаю?

Все точно) Именно так... либо так мерить нельзя, но непонятно почему... либо как то кодовое слово влияет на BER... Кодовому слову добавляется синхрометка... 16 пар бит к 864 + 864 (R=1/2) парам бит информационной и проверочной информации.

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