Коды БЧХ, Вопросы по алгоритмам декодирования Опции

[des00]

Гуру кодирования, просвятите по теме

Потребовалось мне для проекта сделать БЧХ декодер работающий в поле GF(2), реализовал его по алгоритму Берлекэмпа-Месси приведенному на рисунке. Мне интересно, чем определяется необходимость последней проверки алгоритма перед процедурой Ченя(на рисунке выделено)? Ведь для бинарных БЧХ кодов четные невязки всегда будут равны нулю, а на нечетных проходах, по блок-схеме алгоритма, мы всегда попадаем на изменение длинны и степени полинома локатора ошибок. Т.е. эта проверка ничего не определяет. Тогда зачем она нужна? Или такая ситуация возможна только для не бинарных кодов?

И вопрос по алгоритму Евклида. Во всех книгах написано что он лучше подходит для аппаратной реализации, чем алгоритм Берлекэмпа-Месси, из-за своей регулярной структуры. Но один из шагов алгоритма деление полинома на полином. В железе же это делается с помощью регистров с линейными обратными связями, что приводит к многотактному делению и появлению лишних задержек, что ИМХО не айс. Так в чем же его преимущество перед алгоритмом Берлекэмпа-Месси ?

Спасибо.

Эскизы прикрепленных изображений

 

[des00]

Гуру кодирования прошу вашей помощи. Как поступают в том случае если число ошибок больше корректирующей способности БЧХ кода, а декодер считает что количество ошибок равно t и что-то исправляет?
Пример такого количества и местоположения ошибок для кода 15,5,7 в приложении.

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

 bch_feature.zip ( 8.56 килобайт ) Кол-во скачиваний: 72

 

[petrov]

Гуру кодирования прошу вашей помощи. Как поступают в том случае если число ошибок больше корректирующей способности БЧХ кода, а декодер считает что количество ошибок равно t и что-то исправляет?

ИМХО это нормальная ситуация, графики BER для кодированной и не кодированной модуляции пересекаются в области высокой вероятности ошибки, и не кодированная передача становится лучше, а в кодированной происходит размножение ошибок, шум превышает расстояние евклида или хемминга до границы принятия решения и декодер начинает принимать за истинные другие кодовые слова.

[des00]

ИМХО это нормальная ситуация, графики BER для кодированной и не кодированной модуляции пересекаются в области высокой вероятности ошибки, и не кодированная передача становится лучше, а в кодированной происходит размножение ошибок, шум превышает расстояние евклида или хемминга до границы принятия решения и декодер начинает принимать за истинные другие кодовые слова.

то что ситуация обычная это понятно, но ведь должен же существовать какой то способ, для определения того, что ошибок больше чем корректирующая способность(t)? На степень полинома локаторов надежды нет, т.к. он, алгоритмически ограничен t, поиск корней полинома тоже может дать сбой (как в этом примере). Вот мне и интересно, как определить что ошибок больше чем нужно и выдать сигнал decfailed, вместо мусора %)

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

[Mikhalych]

Вот мне и интересно, как определить что ошибок больше чем нужно и выдать сигнал decfailed, вместо мусора %)

может CRC считать?

[des00]

может CRC считать?

это для протокола более высокого уровня, мне нужно другое %)

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

да и не получится так, потому что синдром по определению определен на множестве элементов alpha^1 ...alpha^2t.

[Mikhalych]

это для протокола более высокого уровня, мне нужно другое %)

а если сделать декодер на t+1 ошибку... и если ошибок t и меньше - то всё хорошо, а если t+1 - то недоверяем и говорим decfailed?

[des00]

а если сделать декодер на t+1 ошибку... и если ошибок t и меньше - то всё хорошо, а если t+1 - то недоверяем и говорим decfailed?

тогда есть опасность не влезть в требуемую полосу пропускания и что делать если ошибок будет ну например t+5 ?

ИМХО не должен, если только дополнительную избыточность на это тратить.

хмм, неужели в и RS кодерах всё так же плохо. И даже проверка нулей спектра кода не поможет?

ЗЫ. Мне сильно желательно диагностика такой ситуации для канала без явной синхронизации. Чтобы лучше работала система синхронизации. Подобное я делал на корке RS, но никогда не задумывался, до сего момента, что decfailed корки мне врал %(

[vadimuzzz]

хмм, неужели в и RS кодерах всё так же плохо.

как бы RS - это подмножество BCH

но никогда не задумывался, до сего момента, что decfailed корки мне врал %(

он не врал, ЕМНИП у этого сигнала вполне конкретный смысл, он показывает неисправимые ошибки, но не все.

[des00]

как бы RS - это подмножество BCH

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

он не врал, ЕМНИП у этого сигнала вполне конкретный смысл, он показывает неисправимые ошибки, но не все.

под врал я понимал то, что когда он не показывал decfail нельзя было однозначно сказать были ошибки или нет %)

Подводя итог, как я понял бороть сей эффект бесполезно. Ну разве что расширить код добавив символ четности. Немного поможет %)

[GetSmart]

Ну разве что расширить код добавив символ четности. Немного поможет %)

Разве этого недостаточно?