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

для 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" я нашёл логичным называя код исходить из длины информационного блока.