не не не, я этим для себя занимаюсь. решил идти последовательно : коды хэминга, бчх, рс, витерби, турбо и только потом LDPC. потому и сорцы все отдаю, т.к. работа опыта ради

и для одного проекта мне нужен декодер для короткого блока (200-400 бит), насколько я читал про LDPC, смысла его ставить на такие блоки нет никакого. А вот какой нить турбокод на основе кодов хэмминга почему бы и нет.

Еще хотелось бы порыть арифметическое декодирование кодов РС, из обзора я понял что занятная вещь, посмотрим будет ли время

где-то встречал, что есть уже такие короткие LDPC, но сейчас уже не вспомню где именно

Блоковый турбокод - это обычный итеративный код. Что вы собрались итерировать? 16*16 ? Будет слабый код.
32*32 ? Это будет уже длинный слабый код. Трехмерный 32*32*32 или 16*16*16 будет неплохо, но сложно и длинно.
Некоторые тупиковые ветви теории кодирования надо знать, но не надо использовать

чтобы знание было обоснованным нужно прочувствовать это на себе, в книгах умные вещи пишут, спортить с ними глупо, но владеть аппаратом считаю нужно %)

petrov в свое время упоминал неплохой турбокод, где то у меня в запасниках записано, как раз для коротких блоков.


я видел короткие LDPC коды на ~4000-5000 бит, на 200-400 не встречал пока %) если такие существуют то рано или поздно доберусь и до них

Чем LDPC лучше БЧХ при той же избыточности?

в приличном обществе такой вопрос не задавайте, засмеют %)))) Хотя бы обзорную статью в википедии прочитайте.

При какой избыточности?
Если при ОЧЕНЬ большой, т.е. асимптотически большой, то у БЧХ кодов d|n стремится к нулю с ростом n при ненулевой скорости. У случайных LDPC d|n НЕ стремится к нулю, хоть и лежит ниже границы ВГ. И, что самое приятное, существует очень простой алгоритм декодирования (со сложностью n*log_n), который реализует асимптотически ненулевую часть этого ресурса.
Если говорить о конечных длинах, то на малых длинах (ну, скажем, до 100) БЧХ ничем не хуже.
Если говорить о средних и больших длинах, то тут ситуация такая. БЧХ коды имеют хорошее d|n для длин
до десятков тысяч и алгоритм декодирования дискретных ошибок с приемлемой сложностью даже для больших длин.
Конкретные LDPC имеют, обычно, неизвестное d или существенно хуже, чем у БЧХ, но зато они имеют алгоритм декодирования, позволяющий очень хорошо работать в канале с непрерывным выходом, чего не умеют БЧХ.
На больших длинах плохое мин.расст. не явяется определяющим, пока выходная вероятность декодирования
не станет достаточно маленькой (известный эффект "error floor").
Поэтому на длинах > 1000 в канале с непрерывным выходом принято использовать LDPC,
и тут их сравнивать с БЧХ нет смысла, т.к. БЧХ не имеют хорошего алгоритма декодирования,
заточеного под непрерывный выход.
Если сравнивать длинные БЧХ с длинными LDPC в канале с двоичным выходом,
то по моим наблюдениям, LDPC начинаю проигрывать БЧХ при выходных вероятностях порядка 10E-5.. 10E-7.
И чтобы окончательно затуманить все картину
надо сказать, что сложность декодера LDPC может в десятки раз превышать сложность декодера БЧХ
(если считать в каких-нибудь гейтах).
А по сложности кодера разница может составлять тысячи раз.
Так что ответить однозначно на ваш вопрос трудно, т.к. очень много дополнительных нюансов.
В Википедии можете не смотреть про LDPC - там ничего нет, кроме исторических справок
и корявого описания BP-алгоритма для декодирования LDPC.

хмм, свое первое знакомство с LDPC кодами я начал с External Links в википедии, достаточно вменяемые документы

На сколько увеличивается размер декодера, если использовать мягкое решение (3-4 бита)? Применительно к ПЛИС. Кто-нибудь делал?

des00-"на 200-400 не встречал пока %) если такие существуют то рано или поздно доберусь и до них "
Посмотрите NASA.uplinkOrange.pdf http://www.google.ru/url?sa=t&rct=j&am...pPrbLm5c_MbkiNA . И блоковые турбо-коды (TPC) себя при таких размерах тоже прилично ведут. Если "пол ошибки" на уровне 10^-6...10^-7 не смущает, то PCCC при R<2/3 лучше всего при коротких блоках.

Нет, ну если еще посмотреть список литературы внутри этих "External Links", то вообще картина будет исчерпывающая


Вопрос поставлен некорректно.
Есть разрядность входных данных. И есть разрядность данных внутри декодера, которая даже для двоичного входа уже не двоичная. Так что увеличение разрядности входа очевидно повлечет пропорциональное увеличение
размера входного буфера. А как уж там внутри декодера вы организовали вычисления, и на сколько нужно поднять разрядность этих вычислений - тут можно только гадать. Вообще, есть довольно много статей по реализации LDPC на FPGA.
Поищите в и-нете. Но не в Википедии

Спасибо за наводку, поставлю себе в TODO %)

Если не сложно объясните термины что такое "пол ошибки" и РССС ?


Насколько я знаю для БЧХ мягкое решение это только алгоритм чейза, ему как таковое увеличение по боку. А вот для LDPC, коллега сделал декодер на 5000-10000 бит. весит порядка 5 тысяч логики (сыклон 3) для 8/9, мягкое решение +3 бита, BPSK - QAM256.

"Если не сложно объясните термины что такое "пол ошибки" и РССС ? "

PCCC- parallel concatenated convolutional codes. Можно посмотреть стандарты CCSDS, UMTS. Есть разновидность PCCC - DUO-BINARY (стандарт DVB-RCS, Wimax тоже кажеться). У PCCC присутствуют кодовые слова с "очень" малыми весами Хэмминга, их немного и при больших вероятностях ошибки они не сказываются, со снижением вероятности ошибки скорость спада кривой Pb(Eb/N0) меняет свой наклон и спадает очень медленно (со скоростью определяемой словами с малыми весами) это называют error floor (пол ошибки). Т.е. кривая Pb(Eb/N0) вместо "водопадной" становиться похожа на кочергу

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

Немного не в строчку...
BCH + LDPC => http://dvb-t2-csp.sourceforge.net