У меня очередная порция вопросов Вопрос касается кодовой скорости R (степень кодирования). Ладно, с кодовой скоростью 1/2 и 1/3 все просто, если есть необходимость мультиплексируем биты и пускаем по каналу. Интересуют кодовые скорости типа 6/7, 4/5, 3/4 и т.д. Взять к примеру кодовую скорость 6/7. т.е. на 6 входных бит приходится 7 выходных, по какому принципу происходит выкалывание? Зависит ли количество RSC-кодов кодера или количество полиномов генератора кодов кодера на блок формирования выходного пакета (т.е. блок выкалывания). Ставлю вопрос ребром: можно ли на классическом кодере турбокода с двумя идентичными параллельно расположенными сверточными систематическими кодами реализованных на двух полиномиальных генераторах сформировать скорость кодирования 6/7 и др. скоростя?

Заранее благодарен за ответ!

Можно. Используется схема как в стандарте dvb-rcs. Идея состоит в том, чтобы уйти от кодера 1/1 на, допустим, 2/2. При этом улучшается сходимость процесса декодирования, уменьшается чувствительность к выкалыванию, но декодер надо перевести в недвоичный режим.

Кратко ознакомится можно в прикрепленном файле.

 Ould_Cheikh_MouhamedouC2003C.pdf ( 568.88 килобайт ) Кол-во скачиваний: 540

А как быть с нормализацией? На аппаратном уровне все оперируемые величины представляют собой действительные числа с разрядностью R (в программном же эквиваленте при расчете LLR используют вещественные данные). Вот скажем такой пример:
Рассчитываем метрики ветвей Gamma. В программе можно было бы использовать выражение

где AP- априорная вероятность (т.е. апостериорная вероятность предыдущей итерации. При первой итерации AP=0.5), X-Систематические данные, Y-проверочные данные, U и V -данные определяющие выход кодера в момент времени k. Естественно Gamma имела бы тип double или float.

Так вот, для облегчения вычислений в аппаратуре, это выражение представляет собой как логарифм метрики ветви, т.е.:

Причем априорную вероятность хранят, я так понимаю, в ПЗУ (заренее вычисляется вобщем, т.к. натуральный логарифм вычислять это целое дело, хотя могу и ошибаться, так что это дело также пока под вопросом).
Основной вопрос такой, в каком виде лучше хранить вычесленные метрики, ну и соответственно логарифм априорной вероятности? Я представляю себе систему вот такую: на вход SISO декодера подаются мягкие решения с АЦП, допустим с 32-х уровневым квантованием. т.е. логический '0' будет представлять собой "00000", логическая единица - "11111", соответственно, например, аналоговый уровень 0.5, будет представляться как "10000". Далее, уже внутри системы разрядность может быть увеличена. Соответсвенно все вычисления на аппаратном уровне будут представляться именно в таком виде. Можно ли использовать такой подход к решению задачи? Или все-таки необходимо привести все к вещественному виду по правилу машинного представления дробных чисел. Соответственно при таком подходе увеличится и масштаб вычислений. Очень интересно Ваше мнение.

Сообщение отредактировал Rundll - Dec 13 2008, 17:15

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

Я не говорил что квантование 32-х битное Я сказал что оно 32-х уровневое, т.е. как раз 2^5=32, а значит шина 5 битная и соответственно АЦП 5-ти разрядный.
А как насчет логарифма априорной вероятности? Вычислять, квантовать и зашивать в ПЗУ?

Да, действительно, невнимательно прочитал. Я в своем декодере использовал Max-Log-MAP аппроксимацию и поэтому вычисление функций правдоподобия там делается просто: выбором максимального (минимального) абсолютного значения элемента с учетом знака. При использовании Log-MAP аппроксимации для вычисления LLR используется заранее подготовленная таблица всех возможных расчетных значений.

Да, но если Ваш декодер итеративный, то вы должны были использовать выходную апостериорную вероятность (внешнее LLR декодера) в качестве входа априорной вероятности. Кстати, я так понял, что в принципе, от алгоритма Max-Log-MAP к алгоритму Log-MAP перейти довольно таки просто. Поэтому я решил пока с Max-Log-MAP аппроксимацией поэкспериментировать, он по-проще.
Вот, схемку прикрепил. Интересует блок Look-up Table в котором вычисляются, то-ли хранятся логарифмы априорной вероятности.

Сообщение отредактировал Rundll - Dec 13 2008, 20:01

Декодер, конечно, итеративный, в этом и заключается принцип турбокодирования. После каждой итерации значения внешних LLR одного декодера служат для обновления априорной информации другого декодера и, соответственно, после каждой итерации оценки выходных LLR каждого из декодеров будут расти в правильном направлении. После определенного количества итераций решающее устройство выносит жесткое решение в пользу того или иного бита (0 или 1) в зависимости от знака апостериорного значения последнего декодера (выходного LLR).
По поводу схемы отвечу Вам в понедельник, есть кое-какие описания, но они на работе.

Благодарю, буду ждать.

Начните с этих материалов.

 valenti2001c.pdf ( 281.3 килобайт ) Кол-во скачиваний: 639

 TurboDSP_Ref3.pdf ( 59.93 килобайт ) Кол-во скачиваний: 596

 MOU03_ISTC_DVB_RCS_Decoding.pdf ( 537.45 килобайт ) Кол-во скачиваний: 498

 ieee_fb.pdf ( 729.69 килобайт ) Кол-во скачиваний: 481

 98_162.pdf ( 192.17 килобайт ) Кол-во скачиваний: 519

2Rundll
В принципе все то, что я хотел посмотреть изложено в доках, которые привел Grumbler_2002. В log-MAP алгоритме основные вычислительные затраты связаны с вычислением ф-ции логарифма

xEy = min ∗(x, y) = -ln(e^x + e^y) = x - ln (1+ exp(x-y)) = y - ln (1+ exp(y-x)) =

= min(x, y) - ln (1+ exp(−|x-y|)) = min(x, y) + fc (|y − x|) ,

которую необходимо затабулировать. На основании этой ф-ции происходит вычисление LLR.
Приведу код расчета на С для расчета ф-ции Е.

#define QQTZ_BIT 16
#define E_FUNCTION_SIZE (1<<QQTZ_BIT)

/* E function look-up table */
float E[E_FUNCTION_SIZE];


/* E function
compute min(x,y)-ln(1+exp(-abs(x-y)))
*/
float E_function(x,y)
float x,y;
{
long z;
float ab;
ab = fabs(x-y);
if (ab>16.0) return min(x,y);
z=(long) (ab*4096.0);
return min(x,y)+E[z];
}

/* Generate look-up table */
for (int k=0;k<E_FUNCTION_SIZE;k++)
{
E[k]=(float) -log(1.0 + exp(-(float)k/4096.0));
}

Сообщение отредактировал Serg76 - Dec 15 2008, 16:26

На самом деле нужно задать себе вопрос, так ли необходимо использовать log-map алгоритм? На практике используют много более простые для реализации аппроксимации, указанные в одном из файлов. Лично я пользовался constant-log-map аппроксимацией на сигнальнике.

Я пользовался Max-Log_MAP аппроксимацией. Энергетические потери для разных кодов составляли значения в диапазоне от 0,5 до 1,5 дБ. Хватит ли ему такой помехоустойчивости при планировании бюджета канала связи или может не хватить. Окончательный выбор, конечно, за разработчиком.

Коррекцию extrinsic information использовали? У меня разница max-log-map и log-map от силы пару десятых дБ была.

Внешние LLR конечно использовал, это же вытекает из принципов турбокодирования. Просто я сравнивал свой декодер с реализованным фирмой AHA (лучше их в этой области нет) для различных компонентных кодов, построенных на базе кодов Хемминга, модуляция QPSK, квантование 3-х битное. Скорее всего у них есть какие-то фирменные примочки типа дополнительных коэффициентов обратных связей и пр.

Сообщение отредактировал Serg76 - Dec 16 2008, 19:23