[Mogwaika 0]

"Ужасно" и "нормально" это в децибеллах (до Шеннона) сколько?

 

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

 

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

 

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

Изменено 1 апреля, 2015 пользователем Mogwaika

[Dr.Alex 0]

предел шеннона для этого случая считаю за 0дБ

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

 

для min-sum у меня получилось при модуляции qpsk и коде 1024 бит r=1/2, 2.55дБ для вероятности 1е-5

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

Такое возможно лишь при недвоичном декодировании.

[Mogwaika 0]

Такое возможно лишь при недвоичном декодировании.

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

 

[Dr.Alex 0]

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

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

[des00 25]

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

Такое возможно лишь при недвоичном декодировании.

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

 

 

+ интересный факт, при вычислении llr если выбрать неправильную дисперсию шума, sum-product работает ужасно, а вот min-sum, которому не важен коэффициент при llr-ах работает нормально.

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

[Mogwaika 0]

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

Я вот сейчас глупость могу сморозить, т.к. не до конца понимаю определение двоичности.

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

Кодирование происходит умножением двоичного вектора на двоичную матрицу.

[des00 25]

Я вот сейчас глупость могу сморозить, т.к. не до конца понимаю определение двоичности.

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

 

[Dr.Alex 0]

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

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

 

Пример двоичного кода = LDPC/BCH, недвоичного ReedSolomon

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

[des00 25]

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

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

Fig. 4 shows the influence of the code rate on the BER curve, results are shown for all seven code rates when the block size is N = 212 message couples, ten iterations of Max-Log-MAP decoding are performed.

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

 

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

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

 

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

 

[Dr.Alex 0]

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

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

 

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

 

А вы не в курсе какие там ресурсы требуются для декодирования, по сравнению с бинарными LDPC кодами?

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

[Mogwaika 0]

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

 

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

 

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

 

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

 

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

ldpc_test.zip

Изменено 1 апреля, 2015 пользователем Mogwaika

[Dr.Alex 0]

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

 

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

 

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

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

[Mogwaika 0]

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

 

CCSDS 131.1-O-2

[Dr.Alex 0]

CCSDS 131.1-O-2

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

[Mogwaika 0]

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

 

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