Необходимо использовать арифметику в поле Галуа. Для реализации в ПЛИС вам синдромный полином не нужен, нужны компоненты синдрома, которые потом используются в алгоритме для нахождения коэффициентов полинома локаторов ошибок. Разберитесь для начала как находятся компоненты синдрома и с арифметикой в поле Галуа, а потом уже к алгоритму переходите. Хорошо написано это в статье Рахман П.А. Основы защиты данных от разрушения. Коды Рида-Соломона.

Спасибо, обязательно воспользуюсь Вашими рекомендациями

Не смог разобраться с системой накопления статистики. Смысл графика также не очень ясен. И к своему стыду не понял, что имеется в виду под spike.
У меня была более простая моделька (так сказать, показательно-учебная), но идентичная по сути. Ваш пример «хавает», исправляя 36 стираний при нуле ошибок.
Кол-во исправляемых стираний + ошибок, действительно, по формуле 2b + u < d, где b — кол. битовых ошибок, u — количество стираний.

Нажмите для просмотра прикрепленного файла
Если, конечно, актуально.

spike - импульсная ошибка, моделирую канал с импульсными ошибками, при наличии 100% ой схемы их обнаружений. статистика - кол-во выбитых бит на блок и итоговый бер


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

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

Лучше ныряйте в LDPC.

не не не, я этим для себя занимаюсь. решил идти последовательно : коды хэминга, бчх, рс, витерби, турбо и только потом 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

На 200-400 бит вполне пойдет код Рида-Соломона...
Этот код достаточно прост в реализации до (255, на сколько нибудь там) так как единица с которой прийдется оперерировать при декодировании равна 8 битам тоесть одному байту что значительно упощает програмную реализацию. Если хотите брать блоки большей длинны то уже будет не байта 9 бит 10 и.т.д. ... максимально возможная длинна блока при разрядности n определяется как 2 в степени n минус 1.
Пример:
вот как раз если рассматривать единицу кодирования-декодирования как байт(8 бит) получается 2^8 - 1 = 255

Число на сколько нибудь выбирается в зависимости от того сколько информации хотите передать и сколько ошибок в блоке хотите исправить

Пример:
В начале выбиаем размер блока допустим 200
Затем Кол-во ошибок которое хотим исправить допустим 10
Теперь прикидываем для того чтобы нам исправить 10 ошибок нам над добавить 20 дополнительных символов к информационным
(Напоминаю что мы говорим про единицу 1 байт что означает если 10 ошибок значит 10 байт = 80 бит)
в итоге получается что информационных символов у нас остается 200 - 20 = 180 получаем код (200,180)

Спрашивается если код такой хороший почему бы его не пнррименять вместо турбокодов и LDPC? Я уже говорил что алгоритм декодирования кда единица кодирования равна 1 байту достаточно быстр но с 9 битами уже сложнее и далее если будем увеличивать алгоритм будет замедляться и избыточная информация рости (никто же не будет при коде 10000 исправлять в нем только 10 ошибок это малавато будет)
Алгоритм декодирования тубокодов намного быстрее потому и применяют ....

Уважаемый Михалыч, не могли бы Вы перезалить вашу подборку, а то на депозите ее уже нет.
Заранее спасибо

Код плох тем, что вероятность исправления 20 доп. символов ниже чем у 180 передаваемых.

Почитал всю тему. Удивило то, что для кодовых блоков в несколько (2-4) сотен бит никто не посоветовал стандартные сверточные коды с длиной кодового ограничения 9 или 7 (чуть похуже работает). Это как бы стандаратный путь. Если после кодера используется расширение (spreading) функциями Уолша, то его можно представить как внутренний код Адамара и использовать турбо алгоритмы для декодирования получившейся последовательной схемы. Если совсем жалко избыточности, то можно использовать сверточные коды без терминирующих бит и алгоритм tailbitting. Если есть возможность, также можно использовать один из видов trellis-coded modulation.

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

Всем привет! Недавно приступил к изучению кодов БЧХ. После изучения нескольких статей появились вопросы, касающиеся вычисления синдромов.
В стандартном варианте достаточно пропустить принятое кодовое слово через сумматор и умножитель на элементы поля Галуа первых степеней. Например, синдром с индексом 1 получается равным элементу с индексом, соответствующим номеру позиции ошибки, если ошибка одна. Если их несколько, результат синдрома будет равен элементу, полученному в результате сложения элементов поля Галуа с индексами, соответствующих позициям ошибочных бит в кодовом слове. Но в одной из статей предлагается вычислять синдромы с помощью деления входного кодового слова на порождающий полином. Т.е. входное кодовое слово пропускают через сдвиговый регистр, структура которого определяется порождающим полиномом. А потом из полученного значения умудряются каким то образом получить величину синдрома. Написал программку, чтобы посмотреть, что за значения получаются. Как оказалось результат деления равен значению элемента синдрома. Но как уверяется в статье (прикрепил к сообщению) это еще не есть значение синдрома. Вообще для дальнейших операций декодирования нужно ведь знать индексы элементов? Они определяются с помощью ROM, содержащих элементы поля Галуа?

Появились определенные успехи в изучении БЧХ-кодов. Наткнулся на хорошую статью, где приведен пример умножения 2-х элементов поля Галуа через представление их в композитном поле. Все здорово и прекрасно, вроде как стало понятно. Взял даже другие элементы поля из примера и перемножил, все получилось верно. Но стоило попробовать повторить эту процедуру в поле со степенью 14, разложив его на 2 и 7, и ничего не получилось. Кто-нибудь возился с композитными полями и может легко посчитать матрицу перехода?

Ура! У меня получилось)) Ошибка была в том, что я вместо обратной матрицы посчитал транспонированную) Всем спасибо)

Пусть синдромный полином s(x) является остатком от деления принятого полинома r(x) на генерирующий полином кода g(x):

r(x) = quotient(x) * g(x) + s(x);


Значения синдромов вычисляются как r(a_i), a_i - корни генерирующего полинома в поле-расширении, т.е. g(a_i) = 0 - это свойство кода БЧХ;

Поэтому

r(a_i) = quotient(a_i) * 0 + s(a_i);
r(a_i) = s(a_i);

Т.е. синдромы можно считать как значения синдромного полинома-остатка. Достоинство в том, что степень синдромного полинома меньше степени принятого.

Так то оно так.. но как я понимаю, мы получаем путем деления r(x), а не r(a_i). Хотя по полученному результату очень похоже на r(a_i)=s(a_i). А значения s(a_i^2), s(a_i^4)... они как получаются? Там нарисовано волшебное облако. Кроме как поставить там умножители s(a_i)* s(a_i) и s(a_i)* s(a_i)*s(a_i)* s(a_i)... у меня идей нету. Но по ресурсам это не оправдано, можно же просто вычислять s(a_i), s(a_i^2) по отдельности с помощью одного умножителя, регистра и сумматора. Хотя... может и оправдано. Получится, что нам не потребуются на a_i^2, a_i^4.. регистры и сумматоры, но появится задержка в вычислении. В статье говориться про какую то магическую матрицу - не понимаю как она может помочь делу.

В статье все сделано "в лоб":

1. сначала считают остатки от деления принятого полинома на 13 минимальных. В результате получается по 16 коэффициентов полинома-остатка. Коэффициенты из GF(2). Это регистровая логика.
2. затем для каждого a_i, для которого требуется подсчитать синдром, из таблицы элементов поля по степеням i выбирают a_i, (a_i)^2, (a_i)^3 и т.п полученные значения суммируют (xor - ят) друг с дружкой, если коэффициент при этой степени с полиноме-остатке, полученном на предыдущем шаге, ненулевой. Это у них облачко с комбинаторной логикой. Значения степеней, записанные по столбцам - это у них матрица В.

Т.к. в зависимости от i элемент поля a_i попадает в тот или иной циклотомический класс, то в зависимости от класса берут тот или иной минимальный полином на первом шаге. Какие элементы соответствуют какому полиному, показано на картинке.

Я понял.. это ВЫ маг и волшебник) А я всего лишь плохо учюсь..
Попробуем меня пробить по примеру.
Допустим мы имеем 2 ошибки в 40 и 57 битах.
Остаток деления от первого полинома будет регистровое число равное значению элемента поля с индексом 40+57=97.
Нужно вычислить синдромы s1(a_1), s2(a_2), s3(a_3), s_4(a_4).. По остатку от первого полинома можно вычислить s1(a_1), s2(a_2), s4(a_4) и т.д...
Для вычисления s1(a_1) берем из поля Галуа значение (пусть 16 бит) 0100 0000 0000 0000, начиная с младшего. Для a_1 выбираем из таблицы поля Галуа элементы с индексами а_(1*2), а_(1*3), а_(1*4)... а_(1*16). Затем XORим те значения индексы которых соответствуют не нулевым битам результата деления. Т.е. если мы получили в регистре полинома регистровое значение 1001 0010 0000 0000, то XORим значения a_1 xor a_4 xor a_7=s1(a_1). Так?

А для s2(a_2)= a_2 xor a_8 xor a_14. Угу?

Матрица B - просто список степеней относящихся к каждому а_i. Т.е. имеем 16 матриц. Матрица для а_1 содержит адреса степеней. По 0-му адресу этой матрицы - просто 1-ца, по 1-му - 2, по 2-му - 4... по 15 - 1*16=16. И так для каждого а_i?

Получается по реализации структуры с умножителем на a_i, регистром и сумматор значительно меньше кушают ресурсов, чем вычисление полинома-остатка и использование матрицы B?

Поправьте меня, пожалуйста, где я заблуждаюсь. Спасибо)

Давайте так: я задам один вопрос, если ответ вам ясен, то дальше разбираться смысла нет (Вы все поняли). Если ответ не ясен, я тогда еще пояснить попробую.

Вопрос: На картинке с облачками в статье на ножке S1 облачка нет. Почему?

А то писать много и матлабить не очень хочется.

Как я понимаю, результат деления на первый полином является значением синдрома s1(a_1). А те облака - это матрица B, по которой определяем индексы (a_1)^2, (a_1)^4, (a^1)^8 и (а^1)^16 и в зависимости от ненулевых бит s1(a_1) ХОRим значения элементов этих квадратных индексов из поля Галуа. Матрица В нужна нам для получения индексов степеней, относящихся к квадратам. Угу?

Да, все так и есть. Вы молодец. Вот пример кода на октаве, рассчитывающий полиномы-остатки и собственно значения синдромов


И результат выполнения:

>> synd_test
Syndrom polynomial: 0000101110011011
S1: 2971 = alpha^824
S4: 39678 = alpha^3296

Надеюсь, что нигде не накосячил.

Спасибо, большое) Вы сделали все возможное и невозможное для разрешения моего вопроса.
Стал замахиваться на реализацию умножителя в композитном поле Галуа на базе умножителей в базовом поле GF(2^2). Нашел любопытную статью с более-менее внятным описанием того, как это делается.. но первое же вычисление вызвало недоумение.
Они взяли два элемента из GF(2^2) и перемножили их в параметрическом виде, т.е.:

C=c0+c1*alpha=(a0+a1*alpha)*(b0+b1*alpha)=a0b0+a1b1+(a1+b1+a1b1)*alpha

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

После моего перемножения получается немного другой результат и на его основе можно получить значения из таблицы:

С=a0b0+a1b1+(a1b0+a0b1+a1b1)*alpha

Может я чего то не понимаю и там подключены более высокие материи?

Статья - ужас какой-то.

Любой элемент поля GF(p^m) может быть представлен как линейная комбинация
базисных элементов {a^0,a^1,...a^(m-1)} с весами из GF(p)

Рассмотрим умножение в поле GF(2^2). Элементы могут быть представлены как a + b * A;

A - примитивный элемент поля

Умножение:

c= c0 + c1 * A;
с = (a0 + b0*A) * (a1 + b1*A) = a0b0 + (a0b1+a1b0) * A + b0b1*A^2 (*)

Вспоминаем, что А является корнем примитивного полинома p(x) = x^2+x+1, p(A) = 0. Отсюда:

A^2 = A+1.

Подставляем это в (*) и для коэффициентов разложения результата получаем:

с0 =a0b0 + b0b1 = b0(a0 + b1)
c1 = a0b1+a1b0 + b0b1 = a0b1 + b0(a1 + b0)

Может, это как-то дальше и упрощается, чтобы получить меньше логики.

Дальше пока не читал.

======================================================================
С формулами таки накосячил
с = (a0 + b0*A) * (a1 + b1*A) = a0a1 + (a0b1+a1b0) * A + b0b1*A^2 (*)

и соответственно:
с0 =a0a1 + b0b1

Статей на эту тему много, и одно время было очень модным при декодировании длинных БЧХ переходить от 2^14 к 2^7.
Однако, на практике оказывается, что особого выигрыша это не дает.
Удобно реализовывать прямое умножение элементов в полном поле и использовать декодер без обратных элементов.
Все это ИМХО, разумеется.

Ну как так то!? Столько времени потратил, чтобы разобраться с композитными полями, вспомнить полиномиальную логику.. и уже почти реализовал умножитель через композитное поле... думал, вот я молодец.. да я бог и властелин полей Галуа! А вы посадили меня в лужу. А я то думал.. придется теперь 2 умножителя сделать, чтобы посмотреть и сравнить.. э-эээх..
Но очень странно, что про эти поля твердят в новых статьях 2013-2014 года...

Не расстраивайтесь. Все равно с этим полезно разобраться. Даже просто для общего кругозора.
Бесполезных знаний не бывает

Вот теперь точно накосячили)) Не мучайтесь, вы и так очень помогли, спасибо) Изначально вы перемножили так же как и я, правда с одной опечаткой, но это несущественно. Статья просто странная... говорят об одном, а рисуют другое.

Сделал два умножителя в поле GF(2^14). В одном реализовал прямое умножение (Результат 1), в другом умножение через композитное поле GF((2^2)^7) (Результат 2). Оценку быстродействия и ресурсов делал с помощью Quarus II на ПЛИС Altera EP3SL70F780I4L.

Результат 1:

116 - ALUT
421,76 МГц

Результат 2:

171 - ALUT
405,84 МГц

Для чего нужно городить огород с композитными полями не понятно...

Ну, не могу с Вами согласиться.
Сейчас уже не помню подробностей, но году этак в 2005 с интересом разбирался в этой теме и, в частности,
смотрел статью по оптимизации маленького поля. И там были данные, что если для прямого умножения (в 2^14)
требуется 500 сумматоров XOR и еще сколько-то AND и еще сколько-то чего-то
(все цифры сейчас беру с потолка, но идея будет понятна), то для реализации такого же умножителя, использующего переход в поле
2^7, требуется только 300 сумматоров XOR, чуть меньше AND и еще меньше чего-то еще. Но главноый результат статьи заключался в том,
что, как оказалось, сложность реализации умножителя в маленьком поле зависит от выбора полинома для построения маленького поля.
Ребята перебрали все неприводимые полиномы для маленького поля и нашли,
что оптимальный выбор может сэкономить дополнительно еще 50 XOR-ов и еще 10 AND-ов. Совершенно нормальная статья
Другими словами:
1) Переход в маленькое поле все-таки дает некоторый выигрыш по сравнению с прямым умножением (если все аккуратно сделать).
2) Статьи на это тему как появлялись, так и будут появляться с подобными вполне "печатными" результатами.
3) Практическая ценность этого не очень значительна, т.к. экономия в пару сотен XOR-ов почти
не заметна на фоне 150K гейтов общей сложности декодера для длинного кода.
А "прозрачность", "читабельность" и удобство отладки программы (особенно вериложной) заметно страдает от использования двух полей.
Так что выигрыш есть, но стоит ли за ним гнаться - этот вопрос решает для себя каждый проектировщик индивидуально

Я не буду спорить, наверняка где то что то не так сделал. Но по факту... пересчитал количество элементов AND и XOR в каждом их умножителей... В обычном умножителе их получилось около 1000, в умножителе через композитное поле 2735. Компилятор конечно, что то убрал лишние и преобразовал их в ALUT. Но даже визуально видно. что второй умножитель будет кушать больше. В нем же используются матрицы перехода из одного поля в другое и обратно, навалом умножителей в поле GF(2^2) при перемножении полиномов 6-ой степени. Для любопытных прикрепил к сообщению файл с реализацией на VHDL... Может кто то сразу скажет в чем я заблуждаюсь?..

Принялся вычислять синдромы разными способами и разными умножителями. Получил странные результаты. Если допустить одну ошибку на позиции t в кодовом слове и вычислять напрямую синдромы, умножая принятую последовательность на a^1, a^2.. a^24, то синдромы s(a^1)=a^t, s(a^2)=a^2t и т.д., для всех a^i, кроме i=9,18, т.е. s(a^9)!=a^9t и s(a^18)!=a^18t. Почему так получается?..
В стандарте DVB-S2 дано несколько порождающих полиномов. Поле Галуа формировал по первому. Такое ощущение, что поле формируется как то иначе.

Урааа! Нашел ошибку) Сразу не посмотрел все синдромы и ушел далеко в лес. При отсутствии ошибок синдромы 9 и 18 были не нулевыми, следовательно а^9 и a^18 не являлись корнями общего порождающего полинома кода. Эти корни принадлежали 5-му полиному стандарта DVB-S2. В нем и обнаружил ошибку. Теперь все работает как нужно, всем спасибо за внимание и беспокойство)

При одной ошибке для синдромов должно выполняться: S_i = (a^t)^i для всех i. a^9,18 являются корнями минимального полинома g_5 из статьи про вычисление синдромов. Если считаете синдромы по принятым битам, то скорее всего дело кодере.

Всем привет! Продолжаю грызть БЧХ-декодер. Собрал его на простеньких алгоритмах BMA и Ченя. Все получилось, находится полином локатора ошибок и по нему поиском Ченя определяются позиции. Решил усугубить декодер более продвинутыми алгоритмами. Взялся за iBM и riBM. Нашел статью с описанием алгоритмов. Решил начать с riBM. Получил странные коэффициенты полинома локатора ошибок отличные от тех, которые получаются в обычном BMA. При 3-х ошибках лямбда(0)!=0, лямбда(1)!=0, лямбда(2)!=0, лямбда(3)!=0, остальные ноль. При 1 ошибке лямбды только с индексами 0 и 1 не равны нулю. Пропустил их через поиск Ченя и он выдал на местах, где допущена ошибка, вместо нулевых значений - одинаковые константы. Написал программку iBM, к моему удивлению получились те же коэффициенты, что и в riBM. В связи с этим появилось пара пока не разрешимых для меня вопроса к гуру БЧХ:

1. Должны ли совпадать лямбды в обычном BMA и iBMA?
2. Полученные значения лямбды(2t) в iBMA и riBMA - это коэффициенты полинома локаторов ошибок или нет?

В прицепленной статье сказано (втрой абзац в правой колонке на стр. 3), что iBM ищет полином-локатор, коэффиценты (лямбды) которого умножены на некий постоянный множитель. Очевидно, что корни у полинома f(x) и полинома a*f(x) совпадают.

PS Ненулевые значения при поиске Ченя могут быть вызваны тем, что реализация поиска считает, что lambda0 = 1. В случае iBM, судя по статье, свободный член равен некоторой константе lambda0 = a;

Спасибо огромное!)) Вы мне сэкономили как минимум день! При поиске ошибки в алгоритме обращал на не единичную лямбду(0) и не понимал почему она имеет какое то значение. Описание про то, что именно алгоритм вычисляет, также вчера разглядывал, но не увидел, что полученные коэффициенты полинома умножены на константу. Подкорректировал поиск Ченя, он действительно был сделан под свободный член полинома локатора ошибок равный 1. Теперь все работает как надо) Спасибо) Теперь настал черед siBM и tiBM! Трепещите!)

гляньте здесь, может поможет...

да-да, спасибо) Про ошибку в статье о siBM я видел ранее. Действительно пока не заработало. Файлы проекта dess00 у меня есть, там видно отличие. Еще не разобрался что не так...