Вопросы по итеративному декодированию, Реализация CTC/BTC/LDPC кодов Опции

[des00]

Добрый день!

Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация DVB-RCS/WiMAX CTC кодера на ПЛИС, часть проекта будет выложен в опенсорс. Решил создать отдельную тему для обсуждения вопросов по реализации

После штудирования литературы и примеров сорцов в сети возникла часть вопросов, на которые не хватает ума/настойчивости найти ответы:
1. Для DVB-RCS оговорены выкалывания под скорости кодирования 1/3, 2/5, 1/2, 2/3, 3/4, 4/5, 6/7. Почему не определены скорости 5/6 (удивляет "дырка" между скоростями 4/5 и 6/7) и 7/8? При этому матрица выкалывания под эти скорости возможна.
2. Полиномы RCS для Wimax и DVB одинаковые, но перемежители разные. Это сделано по политическим причинам или это результат "улучшения" характеристик декодера в процессе разработки стандарта?
3. В сверточных бинарных кодах, свойство tail-bitting используется при декодировании: В одной доке нашел что дополняют принятую последовательность вначале и в конце, затем декодируют по витерби и выкусывают нужное. В примере матлаба вообще составляют два фрейма, декодируют один за другим, потом из двух декодированных собирают один результат. Никакого намека на похожие операции в доках на турбокоды не нашел. Почему в алгоритмах SOVA/MAP/... для турбокодов это не делается?
4. По tail-bitting нашел в доках только то, что особым образом инициализируются рекурсия прямой и обратной метрики на первой итерации, а на всех остальных значения между итерациями сохраняются. Но
в сорцах от CML цикл по итерациям выглядит так :

Код

for it = 1:max_iterations
    inx1 = X + inner_extr;
    [outx1, outz1]=DuobinaryCRSCDecode( inx1, inz1, poly, decoder_type);
    
    llrx1 = outx1 - inner_extr;
    inx2(1:3*N) = llrx1( code_interleaver_GF4);
    [outx2, outz2, out_info]=DuobinaryCRSCDecode( inx2, inz2, poly, decoder_type);
    detected_data(code_interleaver.info_intl) = (out_info>0)+0;
    errors(it)= sum( sum(abs(detected_data - data)));
    if (errors(it) == 0)
        break;
    else
        inner_extr(code_interleaver_GF4) = outx2 - inx2;
    end
end

Т.е. видно что последовательные вызовы функции DuobinaryCRSCDecode между собой не обмениваются этой информацией. А в самих функциях

Код

    // initialization  for CRSC code
    for (i =0; i< max_states; i++)
    {
        alpha[i][0] = 0;
        beta[i][len] = 0;
    }

Т.е. не используется даже свойство одинакового начального состояния. Более того, в алгоритмах с оконным расчетом обратной рекурсии тоже забивают на свойство tail-bitting. Так насколько это важно и почему во всех доках настойчиво пишут кодировать данные 2 раза для определения состояния инициализации?
5. В алгоритмах, наследованных от Log-MAP метрика ветки считается как сумма корреляций метрик приемных битов с выходными битами решетки : gamma(Sk-1, S) = Lapri + (ys0*xs0 + ys1*xs1 + yp0*xp0 + yp1*xp1). При этом предполагается что y - надежность принятого символа , x = -1/1 выходной(переданный) бит. В сорцах от CML это место выглядит так :

Код

    int m_input = 2;  // 2 input bits,
    int max_states = 8; // total state numbers
    int M_input = 1<<m_input;
    int i, j, max_trellis = M_input * max_states;
.......
        for (j = 0; j< max_trellis; j++)
        {
            temp_input = j%M_input;
            temp_output = trellis_out[j];
            gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ];   //llr for systematic symbol
            gamma[j] += ( temp_output ==0)? 0: inz[ (temp_output -1)+ i*llr_height ];  //llr for parity symbol
        }

Насколько я понимаю Си gamma[j] = ( temp_input ==0)? 0: inx[ (temp_input -1)+ i*llr_height ] - берет надежности символов кроме нулевого. Диапазон изменения temp_input = 0..3 или в битах 00/01/10/11. Вот этот момент мне совсем не понятен.

Пока всё Прошу помощи тех кто в теме.

[des00]

Созрел следующий вопрос: метрики состояний проходят через процедуру нормализации. А как поступают с Lextrinsic и выходными LLR битов ? Судя по результатам моделирования, при сходимости декодера, Lextrinsic, а за ним и LLR выходных символов/битов имеют тенденцию к росту от итерации к итерации. Но, как я понимаю, нормализовать их нельзя, а логичнее использовать ограничение на определенном уровне. Правда упоминание об этом в статьях я не нашел, так ли это ?

[andyp]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

[des00]

Видел, что экстринсики скалили между итерациями (но не между полуитерациями) на что-то типа 0.8 - 0.9. Там же после первой итерации все равно их статистическая независимость нарушается и начинается сплошная магия.

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

[andyp]

да, где то в доке находил коэффициент 0.75, но это только для max-log-MAP алгоритма, для компенсации неидеальности аппроксимации логарифма суммы экспонент.

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

[des00]

Я встречал другое объяснение - от итерации к итерации информация о бите уменьшается, поэтому вводят нечто типа OOC, чтобы учесть это уменьшение.

хмм, надо еще будет эту тему прошерстить.

В приложении матлабовский примитивный, без какой либо оптимизации, декодер dvb-rsc, часть функций сделана близко к железу, позволяет покрутить/посмотреть что и как считается, что куда идет, как себя ведут метрики и прочее Содержит комментарии как что и куда. Перехожу к работе над HDL идеалкой.

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

 ctc.zip ( 12.61 килобайт ) Кол-во скачиваний: 39

 

[andyp]

Перехожу к работе над HDL идеалкой.

Поздравляю с завершением этапа

[des00]

Поздравляю с завершением этапа

Похоже где то я ошибся Сделал идеалку на RTL, осознал откуда растут ноги у количества эффективных бит у метрик пар/ветвей/состояний/extinsic. Но? начал гонять и заметил расхождение в характеристиках декодера, по сравнению с используемым мной "референсным" документом. Документ в приложении, характеристики на странице 3 (466 страница документа). Набрел на него когда искал точки привязки BER для декодера(в других найденных документах приводился FER в качестве характеристик).

Первая мысль что используемый для моделирования в RTL генератор шума не верен. Отложил в сторону RTL. Взял матлабовский вариант без квантования, ограничений, честный Log Map и т.д. Тоже не бьются кривые с документом. Особенно если учесть тот факт, что в документе якобы рассмотрен Max Log Map без каких либо улучшений. Проверяю на QPSK, пакет длинной 64 пары, кодирование 1/3, 10 итераций. Пример расхождения характеристик : EbN0 = 2.5дб, в статье BER 5е-5, RTL код BER 4е-4, матлаб 2е-4.

Может кто нибудь поделиться ссылками на эталонные результаты или характеристиками своих декодеров? Интересует кривая для пакета 64 пары, кодирование 1/3, 8 итераций. Диапазон EbNo 0.5:0.5:4.

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

 Design_and_Implementation_of_Low_Power_Turbo_Encoder_for_DVB_RCS_Software_Radio.pdf ( 436.62 килобайт ) Кол-во скачиваний: 84

 

[des00]

Похоже где то я ошибся

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).

У тебя решетка циклическая, следовательно состояния решетки в начале и конце должны быть одинаковыми. Начинать нужно с альф. Доходишь до конца, используешь последние полученные альфы для инициализации (N+1)ых бет и идешь назад по решетке. Затем сохраняешь полученные 0ые беты для использования как 0ые альфы на следующей итерации.

Понял, проверю. Цикличность отдельно альф от бет я сделал основываясь на разделе в стандарте (в приложении). С бет начинал потому что планирую в железе делать sliding window с двумя движками для бет и одним для альф. Уж больно не хочется два раза массив данных перебирать.

Когда искал в чем косяк созрел такой вопрос. Насколько правомочно формирование метрик отсчета L1,L2 для дебитов по правилу:
L00 = 0, L01 = L2, L10 = L1, L11 = L1+L2. По идее это результат вычитания из метрик L01/L10/L11 метрики L00. Но тогда должно быть так :
исходные метрики L00 = -L1-L2, L01 = -L1 + L2, L10 = L1 - L2, L11 = L1+L2 и после вычитания получается L00 = 0, L01 = 2*L2, L10 = 2*L1, L11 = 2*(L1+L2).

Казалось бы постоянный множитель LLR алгоритму не принципиален, но ведь этот множитель задает распределение надежностей. Например пусть L1/L2 = 4, тогда честные метрики будут : L00 = -8, L01 = 0, L10 = 0, L11 = 8. "Расстояния" между метриками L01/L10/L11 и метрикой L00 будет 0/8/8/16. Тогда как по упрощенному правилу метрики будут L00 = 0, L01 = 4, L10 = 4, L11 = 8 и расстояния 0/4/4/8. Как более правильно? Или этом пренебрегают в виду того, что exp(-4) = 0.0183 и exp(-8) = 3.3546e-04?

Эскизы прикрепленных изображений

 

[smoke_111]

Ошибся в добавлении шума к сигналу в тесте на SV. Забыл про одну из типовых System Verilog gotcha, в результате при добавлении к сигналу шум становился не AWGN, со всеми вытекающими. Поправил это место и характеристики легли близко с "референсным" декодером в статье. Почему матлаб работает не так еще не понял, может быть сказывается количество бит. RTL гоняю на 8М бит(15 минут на тест), матлаб на 200К (это он ночь стоит, очень уж медленно он работает).


Понял, проверю. Цикличность отдельно альф от бет я сделал основываясь на разделе в стандарте (в приложении). С бет начинал потому что планирую в железе делать sliding window с двумя движками для бет и одним для альф. Уж больно не хочется два раза массив данных перебирать.

Когда искал в чем косяк созрел такой вопрос. Насколько правомочно формирование метрик отсчета L1,L2 для дебитов по правилу:
L00 = 0, L01 = L2, L10 = L1, L11 = L1+L2. По идее это результат вычитания из метрик L01/L10/L11 метрики L00. Но тогда должно быть так :
исходные метрики L00 = -L1-L2, L01 = -L1 + L2, L10 = L1 - L2, L11 = L1+L2 и после вычитания получается L00 = 0, L01 = 2*L2, L10 = 2*L1, L11 = 2*(L1+L2).

Казалось бы постоянный множитель LLR алгоритму не принципиален, но ведь этот множитель задает распределение надежностей. Например пусть L1/L2 = 4, тогда честные метрики будут : L00 = -8, L01 = 0, L10 = 0, L11 = 8. "Расстояния" между метриками L01/L10/L11 и метрикой L00 будет 0/8/8/16. Тогда как по упрощенному правилу метрики будут L00 = 0, L01 = 4, L10 = 4, L11 = 8 и расстояния 0/4/4/8. Как более правильно? Или этом пренебрегают в виду того, что exp(-4) = 0.0183 и exp(-8) = 3.3546e-04?

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