Добрый день!

Наконец то появилось время подтянуть себя в вопросах реализации кодов с вероятностным декодированием. Первая задача реализация 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 цикл по итерациям выглядит так :

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

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

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

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

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

для min-sum у меня получилось при модуляции qpsk и коде 1024 бит r=1/2, 2.55дБ для вероятности 1е-5 (предел шеннона для этого случая считаю за 0дБ).

Для sum-product пока выбираю коэффициенты подгона для лучшего случая. (и да, не исключаю что это проблемы маленьких чисел с плавающей точкой)

Сообщение отредактировал Mogwaika - Apr 1 2015, 12:25

Это правильно.


Думаю вы где-то ошиблись. Столь короткий код не может работать на 2.5 дБ до Шеннона при таком убогом алгоритме как мин-сум.
Такое возможно лишь при недвоичном декодировании.

Да, декодирование мягкое, поэтому у меня и возникли сложности со входными llr.

Ясен перец мягкое, только к недвоичному (в GF(q)) это не имеет никакого отношения.

Могу ошибаться, но в статье Design and Implementation of Low-Power Turbo Encoder for DVB-RCS Software Radio, есть такой график(в приложении) код 424 бита данных 1/2 (848 бит всего) 10е-5 дает при EbN0 ~2.25дб. Как так ?



ИМХО ничего удивительного, про этот эффект написано в любом материале про декодирование с непосредственным (не логарифмическим) использованием вероятностей

Я вот сейчас глупость могу сморозить, т.к. не до конца понимаю определение двоичности.
Но вычисление генераторной матрицы из проверочной в работе, которую я взял предлагают вычислять в двоичной форме в кольце по модулю (x^m+1) с двоичными коэффициентами.
Кодирование происходит умножением двоичного вектора на двоичную матрицу.

Насколько я понимаю, это относится к тому, в каком поле представляется символ и в каком поле идет математика с ним. Двоичные поля GF(2), недвоичные поля GF(2^N). Пример двоичного кода = LDPC/BCH, недвоичного ReedSolomon

Ну так это нормальный турбокод, и декодер там по-видимому никто не опошлял такими методами как мин-сум. Я с именно этим не знаком, но результат тоже удивительно хорош, надо разобраться. 3GPP показывает примерно такой результат при скорости 1/3, а не 1/2.


В том-то и дело, что короткие LDPC уже тоже в GF(256) декодируют с выигрышем примерно 1 дБ.

В том то и дело, что автор пишет что

использует самый дубовый алгоритм. И в сети есть сравнения Duo-Binary CTC vs LDPC с эквивалентными короткими размерами блоков до 1024бит, LDPC проигрывает где то 0.5дб. т.е. в районе 2.5-2.7дб где то и получается


Настолько скилл я еще не прокачал. Запишу в TODO на когда нибудь. А вы не в курсе какие там ресурсы требуются для декодирования, по сравнению с бинарными LDPC кодами?

ЗЫ. в ответе я имел в виду LDPC коды в поле GF(2).

Если кому-то действительно удалось сделать код 848 1/2 2.2 дБ до Шеннона на "самом дубовом алгоритме", это успех. Надо разбираться, как будет время.

Если кто-то думает, что декодирует двоичный LDPC 1024 1/2 по тупому алгоритму с таким же успехом, это наверняка ошибка, либо хочу взглянуть на статью с графиками BER.


Увы нет у меня такой инфы.

вот скрипт для матлаба, нужна 64 битная система, comm toolbox и parallel computing toolbox (можно parfor заменить на for) или запустить декодер из м-файла, что значительно медленнее. Построит график ber от количества итераций.

Eb/No задается для канала, но есть пересчёт для информационных бит.

Буду благодарен за комментарии.

да, уточню, 1024 информационных, 2048 бит в кодовом слове.

Сообщение отредактировал Mogwaika - Apr 1 2015, 14:55

Скажите хоть для начала какой стандарт вы делаете..

CCSDS 131.1-O-2

Так. То есть код всё-таки не 1024 а 2048?

ну в стандарте в этом пишут "код длины k=1024, скорость 1/2, 2/3, 4/5" я нашёл логичным называя код исходить из длины информационного блока.