Это скорее теоретичекое объяснение, почему в графике 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 может нужный паттерн не попадается во входных данных или шум не совсем случайный.

Сообщение отредактировал andyp - Apr 5 2014, 05:55

Пока ничего нового в своем декодере не нарыл и стал проверять очевидные вещи, в одной из статей по 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 закопался, прежние тесты не проходят, где то что то поменял и забыл при последнем тестировании. Но все-равно как то не верится, что место инверсии пар в перемежителе/деперемежителе может испортить качество работы кодека.
Проверил... так и вышло, это практически никак не сказалось на качестве декодера... увы

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

Инверсия пар сама о себе - штука крайне нужная. Без нее будет хуже работать. Узнать подробности можно набрав в гугле 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, посмотрим проверочную часть.
А пачечная структура ошибок и должна быть, код то сверточный, а следовательно, неисправимая ошибка и будет "размазана", для устранения такой ситуации, к примеру, для внутреннего кода Витерби добавляли внешний РС код.

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