LDPC код из стандарта DVB-S2, BER, отношение сигнал-шум, DVB-S2, LDPC Опции

[Vehfl]

Есть программа на C++ для моделирования кодов LDPC для стандарта DVB-S2, в программе есть матрицы из стандарта, задающие коды, есть модем и канал связи с возможностью установки отношения Eb/No. Для всех кодов кроме скоростей 2/5, 1/3, 1/4 получились приемлимые графики зависимости BER (Bit Error Rate) от Eb/No, сходящиеся с теоретическими из статей. Для скоростей 1/4, 1/3, 2/5 декодер не работает, сам добавляет ошибки даже, если в канале ошибок не было. Может это опечатка в матрицах, взятых из стандарта. Ниже приведен стандарт. Не знаете с чем может быть связано, что не работают три скорости?

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

 DVB_S2_en_302307v010201p.pdf ( 682.13 килобайт ) Кол-во скачиваний: 181

 

[Neznaika]

Спасибо за ответы) Со стандарта я конечно же и начинал... в нем указано как формируется кодовое слово (считаются проверочные биты), про матрицу не помню. Что касается разных переводов, то в одной литературе variable node и information node, как я понял одно и тоже... смысл один и тот же. Ну да бог ним) Почесал в очередной раз репу... пригляделся к способу формирования проверочных битов в памяти приведенной выше архитектуры. В первой строке похоже стоят проверочные биты... P0, P90, P180... и т.д... а в первом столбце P0, P1, Р2 и т.д.... Тогда действительно можно первую строку посчитать за один такт, зная правильные индексы информационных бит и применяя сдвиг в 360-битных регистрах, так чтобы, например, P0 соответствовали биты в регистрах его формирующих. Информационные биты идут в последовательном порядке... и правильно сдвинув регистры, а потом сложив мы получив верные Рi во всей 360-битной строке. Эти самые индексы можно, как мне кажется легко вычислить используя таблицы из Appendix A прикрепленной статьи. Но вот дальше интересно... пусть сохраним первую строку в буфере... вычисляем 2-ую строку... складываем ее с первой... вычисляем третью.. складываем со второй... вроде все получается... Р1=Р1 xor P0, P2=P2 xor P1... это что касается первого столбца... Р91=Р91 xor P90, P92=P92 xor P91... что касается второго... Но! Нет связи между Р89 и Р90... в стандарте вроде процесс идет непрерывно... и мы должны проделать операцию P90=P90 xor P89.... здесь же она выпадает... Почему? Или я опять не правильно где то понял?

Ну во-первых для кода 1/2 кол-во рёбер графа ("эджей") равно (226800 - 1), то есть всего 3.5 штуки на один выходной бит.
Один эдж это один ксор, одно чтение и одна запись. Так как у вас память двупортовая в плисине, то значит частота повысится всего в 3.5 раза, а для самого злостного кода 3/5 - в 4.4 раза.

Распараллеливание в любое кол-во раз до 360 тоже легко делается, вечером объясню, если ещё нужно будет, а щас времени совсем нет..

Спасибо) Да, было бы интересно... я не считал вашим способом, немного не понятно. Мне казалось, что частота для 1/2 может повыситься только в 2 раза, ведь на 1 информационный приходится 2 бита кода. В предложенной архитектуре пока не понятно что там происходит с частотами. Допустим есть 2 входных буфера (по 90 регистров в 360 бит), пока вычисляем проверочные биты, входные записываем во второй входной буфер... а дальше нужно как то считать с удвоенной скоростью и входные биты и проверочные... но пока подвис вопрос с потерей одного вычисления...

Сообщение отредактировал Neznaika - Jan 21 2014, 11:57

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

 Investigation_of_LDPC_code_in_DVB_S2.pdf ( 1.49 мегабайт ) Кол-во скачиваний: 228

 

[Dr.Alex]

Мне казалось, что частота для 1/2 может повыситься только в 2 раза, ведь на 1 информационный приходится 2 бита кода.

Ну вы же сами писали про "использование опорной частоты минимум в 5 раз выше информационной скорости", только посчитали неверно.
На каждый парити-нод в коде 1/2 влияют 7 инфо-нодов (это называется "градус" нода). Кроме нулевого парити-нода - у него градус всегда на 1 меньше. Всего парити-нодов 32400, а всего бит на выходе 64800. Поэтому на каждый выходной бит по 3.5 операций.

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

Разбираться досконально с первой половиной вашего поста у меня нет возможности, так что просто скажу в каком порядке вам нужно работать::

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

2) Написать кодер, использующий "инверсную" таблицу из вашей доки, опять же безо всякого параллелизма. Сравнить с образцовым.

3) Если правильно, добавить параллелизм (раз 4-8, больше не нужно).

С проблемой из первой половины поста вы разберётесь ещё когда будете делать первый пункт.