Вопрос к специалистам по помехоустойчивому кодированию.
Имеется свежеиспеченнная (мною) система с каскадным кодированием. Внешний код - Рида-Соломона с длиной блока 127, используется не только для коррекции ошибок, но и для отсеивания недекодируемых пакетов, т.е. вместо CRC. Внутренний - слабенький, 7-битные символы кодируются в символы с эквивалентной разрядностью где-то 9 бит, но зато декодируются по максимальному правдоподобию (демодулятор с мягким решением). Реализация программная.
Вобщем, все по науке, работает неплохо, но...в некоторых применениях (внешняя аппаратура с тупыми протоколами типа запрос-ожидание ответа) слишком медленно. Понимаю, чудес не бывает, однако все же хотелось бы уменьшить задержку, не сильно теряя в помехоустойчивости. Что бы такое применить в качестве внешнего кода? Внутренний код (символы 7 бит) менять затруднительно, так что внешний сверточный с декодером Витерби отпадает...
Заранее благодарен за советы.

А какое усиление даёт в итоге ваш каскадный код?

Непонятно почему внутренний код слабенький, обычно внутренний основное усиление и даёт. Что за код вообще?

Вообще тема интересная.

Внутренний код дает в районе 2 дБ. На самом деле, построен он таблично по критерию нулевой постоянной составляющей...ну и максимальной мощности сигнала, т.е. хилые символы отсеяны. Кодовое расстояние - в районе 2 (полоса, увы, поджимала), все усиление - за счет мягкого декодирования. Внешний нормально работает при SERR внутреннего порядка 3%.

Это очень мало и рид-соломон тоже мало даёт. Можно взять обычное свёрточное кодирование с мягкими решениями и получить около 6 Дб а ошибки обнаруживать простым CRC.

Спасибо, навели на мысли. В принципе, можно усилить внутренний код за счет отказа от внешнего. Получится хуже, но как опция low delay может быть, и сойдет...
По поводу сверточного - в свое время думал, но что делать с постоянной составляющей? Я сверточных кодов с нулевым DC не нашел и придумать не сумел.
А вообще - интересный вопрос: как соотносится помехоустойчивость сверточного и блочного кодов с равной избыточностью и при равной задержке в декодере?

Порядка 6 дБ может дать несистематический сверточный код с длиной кодового ограничения K>7 и относительной скоростью кодирования R=1/2 (с мягким алгоритмом декодирования по Витерби, при этом с ростом кодового ограничения резко (по экспоненте) возрастает сложность декодирующего устройства) либо систематический код с К>41 и с той же относительной скоростью кодирования (декодирование по алгоритму Фано). А по условию задачи относительная скорость кодирования приблизительно 7/9. Я бы порекомендовал использовать в качестве внутреннего кода блоковый турбокод (в качестве компонентных кодов можно использовать различные комбинации обычных блоковых кодов начиная от проверки на четность и заканчивая расширенными кодами Хемминга, БЧХ, Голея и др.). Кроме того в этом случае можно получить любую относительную скорость кодирования R и больший энергетический выигрыш кодирования по сравнению со сверточным кодом при прочих равных условиях. В качестве внешнего кода можно использовать все тот же CRC.

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

Так всякие разные коды бывают, насколько я знаю самую короткую задержку при усилении порядка 6 Дб имеет решётчатая кодированная модуляция(TCM) она как раз на основе свёрточных кодов. Большее усиление можно получить с помощью блочных турбо кодов, но там и длина блока побольше будет.

С меньшим усилением около 4.5 Дб есть код с длиной блока всего лишь 12 QPSK символов.

Сверточный по мощнее будет . К примеру расширенный код Голея (24,12) и все тот же НСК 1/2 (например, Intelsat (133,171) c K=7) имеют ЭВК 3,5 и 4 дБ при жестких алгоритмах декодирования при когерентной модуляции BPSK в канале AWGN. А если увеличить К то ЭВК будет еще больше.


Наверное все тот-же расширенный Голей (24,12).

Нет, это изобретение мастера TCM Lee-Fang Wei.

Для QPSK в блоке из 12 символов передаётся 18 бит, евклидово расстояние между кодовыми словами в 2 раза больше чем в исходном некодированном QPSK.

http://grouper.ieee.org/groups/802/3/z/pub...97/mhQAMfld.pdf

Лучше - вряд ли. В реальной жизни кроме AWGN еще и импульсные помехи бывают. А блочный код такие пачки очень неплохо давит, даже без перемежения. С модуляцией неохота связываться - полоса начинается всего-то от 100 Гц. Кстати, коды без DC - вообще темное дело, нашел по ним очень мало.
Прикинул - можно использовать блочный внутренний код типа 8/13(эквивалентных). Не густо, но с мягким решением...надо сгенерить его и посчитать, что выйдет.
За ссылку на 24D спасибо - штука очень интересная, хотя и не для данного применения.



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

Турбокоды могут дать вам любую длину блока (в этом и есть прелесть турбокодов когда можно получить абсолютно любую конфигурацию и длину кода) правда при этом возникает вопрос в помехоустойчивости в зависимости от того какие коды выбраны в качестве компонент. Один довольно распространенный турбокод с относительной скоростью кодирования 3/4 дает битовую ошибку 10^-6 при С/Ш= 3,5 дБ. Перемежение в блоковых турбокодах практически не применяется (используется так называемый helical Interleaving) так как по сути дела оно и так там присутствует правда не в явном виде. Дело в том что информация в блоковых турбокодах кодируется по строкам и столбцам и даже пачку ошибок в строке (столбце) можно исправить простым кодом проверки на четность.

Кстати какой алгоритм с мягким решением используете для декодирования блоковых кодов, какой ЭВК получаете и какую разрядность квантователя в демодуляторе используете

Алгоритм? Может, он как-нибудь красиво и называется, не знаю. По сути - просто поиск (перебором) кодового слова, находящегося на наименьшем евклидовом расстоянии от принятой последовательности отсчетов. Если еще построить таблицу опорных слов с учетом МСИ - декодер одновременно работает как простенький (+-1 отсчет) эквалайзер. Поскольку кодовых слов всего 128...256 - процессор не особо напрягается. Разрядность >12 бит, это непринципиально, но так вышло. На ARM что 4, что 32 бита - все одно...


Как и любой блочный код. Весь вопрос - в помехоустойчивости при коротком блоке...Если не затруднит, киньте ссылочку на что-нибудь простенькое по турбокодам, желательно коротким.

Обратите внимание что этот код и модуляция предлагались в качестве стандарта для 1000BASE-T Ethernet, там полоса тоже от нуля, в статье как раз картинки со спектрами есть.

Этот алгоритм называется алгоритм Чейза. Существует основные 3 разновидности в зависимости от объема генерируемых векторов ошибки. По сути этот алгоритм эквивалентен алгоритму максимального правдоподобия (аналог алгоритму Витерби только для блоковых кодов). В свое время сам его использовал. Кстати советую обратить внимание еще и на алгоритм Хартмана-Рудольфа. Этот алгоритм дает минимум битовой ошибки для символа (аналог MAP) и ничего лучшего не существует. В отличие то него Чейз дает минимум ошибки, но уже для всего кодового слова, что соответственно хуже. По поводу турбокодов сообщу вечером, сейчас надо уходить.

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

Читайте внимательнее с.160. Алгоритм Чейза это как раз и есть алгоритм максимального правдоподобия для последовательности.

2kons
По поводу турбокодов посмотрите на сайте AHA, круче их в этой области нет. Можно еще почитать у Скляра. Скажите какой вам нужен ЭВК, избыточность и длина блока, попробую подобрать код.

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

За AHA спасибо - попробую зарегистрироваться. Турбокодами интересуюсь пока теоретически.

Да, действительно, вы правы, почему-то я был уверен, что метод 1 в алгоритме Чейза как раз и делает полный перебор всех возможных гипотез. Но в полном переборе и нет смысла, особенно если длина кодового слова большая. Я в своем декодере использовал метод 2, мне кажется наиболее оптимальный вариант, работает нормально.

Какая задержка вас устроит ?

Ну, скажем, задержка в 3-5 байт максимум. И код - DC free.