Здравствуйте! Буду рад если если кто нибудь поможет=)

Разбираюсь с LDPC кодированием и вот какой возник вопрос.
Кто знаком, наверняка помнит граф Таннера(http://users.tkk.fi/pat/coding/essays/ldpc.pdf на второй страничке). В битах c0..cN присутствуют как информационные биты, так и проверочные? Каждый f0..fN должен быть равным нулю если нет ошибок?

Просто если я все верно выше написал, то вот какой вопрос. Информационные биты участвуют в нескольких проверочных уравнениях и могут быть исправлены, но как в таком случае могут быть исправлены проверочные биты?

Я понимаю что вопросы могут показаться примитивными для тех кто в теме, но как я уже сказал я только разбираюсь, не судите строго=)

Сообщение отредактировал slash_spb - Nov 25 2011, 14:08

Наверное задавать вопросы в пятницу вечером не самое лучшее дело

Относительно каждого символа всегда есть жесткое решение на текущий момент времени..
Если эти жесткие решения таковы, что синдром нулевой, декодироване прекращается.


Забудьте про информационные и проверочные биты. Это не имеет отношение к декодированию.
Есть просто проверки в проверочной матрице.
Декодируются просто символы зашумленного кодового слова. Все на равных условиях.
После декодирования можете думать, а где тут были информационные, а где проверочные.


Можно и в пятницу вечером. Не все соблюдают шаббат

Т.е. я правильно понимаю, к нам пришло слово b0,...,bN,c0,....,cN, где bN - информационные данные, cN - проверочные биты к ним. Далее на приеме мы проверяем, к примеру, b0+b3+b7+c1=0, если уравнение верно, то ошибок нет, ну и делаем проверки для оставшихся уравнений. Так?

Вот только у меня все никак не укладывается в голове что если в c1 была ошибка, то эта ошибка размножится на все биты в уравнении, я так понимаю решение о их правильном приеме принимается по оставшимся уравнениям в которых они участвуют?

Сообщение отредактировал slash_spb - Nov 26 2011, 21:11

В принципе, да. Но у вас сначала вопрос был другой. Первоначально вопрос был: как при декодировании отличаются информационные символы от проверочных. Сейчас вы фактически задаете вопрос: а как декодировать LDPC код? Можно и об этом поговорить, но только уточните немного постановку задачи..
Я немного подзабыл, что такое bit-flipping алгоритм? Это обычный мажоритарный? Но только многопроходовый, да?
И канал с жестким двоичным выходом?

Да, это обычный мажоритарный многопроходовый алгоритм с жесткими решениями. По крайней мере, для начала, я разбираю именно такой. Спасибо, я собственно только и хотел понять правильно ли я мыслю. Пока вопрос формулируешь, понимание и приходит=)

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

Нет, по работе. Вместо Рида-Соломона хочется более мощный код, ну и благо ресурсы есть=)

Постейшее декодирование LDPC в жестком канале вряд ли вам сильно много прибавит в помехоустойчивсти.
Расскажите о канале и сигналах, которые вы используете. Какие кодовые длины и кодовые скорости приемлемы.
Возможно, тогда можно что-то посоветовать.

Канал схож с каналом для DVB-T2. Сейчас стоит RS(239,255) со сверточным кодером 1/2 и Витерби на приеме, в общем классика жанра. Конечно LDPC с жесткими решениями вряд ли даст существенный выигрыш, как я уже сказал рассматриваю его только в учебных целях. Планируется, для начала использовать LDPC(324, 648), т.е. скорость кода будет 1/2 и скорее всего при декодировании использовать алгоритм суммы продуктов в логарифмическом домене.

Да, спасибо, было бы интересно услышать мнение со стороны, правильной ли дорогой идем. Думали использовать готовые решения, типа этого(http://www.aha.com/index.php/products-2/forward-error-correction/), но на письма не отвечают и по слухам данные чипы только в пределах США. Да и скорее всего сроки поставки будут большие и заказ наверное нужно делать большой.

Хотя вот, у нас в Питере, готовое решение(http://www.link2unit.ru/ld16eprodru.html).

посмотрите корки юникора, у них много разных LDPC на сайте анонсированно

Спасибо, не знал про ее существование. Будем думать.

Как-то привычнее, когда сначала указывают количество инф. символов, а потом длину кода. Обычно (n,k) или (n,k,d)
Ну, в DVB-T2 канал с непрерывным выходом. И ваша схема, конечно, не самая продвинутая. Думаю, пару-тройку дБ можно еще отжать.


Коротковат. Если позволяют ресурсы, то лучше выползть хотя бы за 1000.


Сумма продуктов - это сильно!! )) product - это еще и произведение



Да сейчас только ленивый не лепит LDPC. Там есть куча тонкостей, которые начинаешь понимать только опытным путем.
Так что удачи вам на этом долгом, но интересном пути!

Со всем согласен, спасибо Ну а куда же без тонкостей.

Исходя их своего опыта посоветовал бы Belief-Propagation (или даже лучше Layerd Belief Propagation алгоритм, если структура матрицы позволяет) с Min-Sum аппроксимацией (sum-product - дальше компьютерных симуляций использовать не стоит, слишком высока вычислительная сложность). В качестве кода лучше использовать QC-LDPC - они обладают лучшим потенциалом к эффективной аппаратной параллелизации-серелизации алгоритма декодирования.
А вообще переход на LDPC довольно грамотное решение, тут только надо учитывать доступные вычислительные ресурсы (размер ПЛИС) и желаемую пропускную способность декодера.