Jump to content

    

Корректирующие коды (эффективнее чем Голей, Хемминг)

Ваши Хэмминг и Голей тоже систематические линейные блоковые коды.

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

 

Хорошие коды подразумевают мягенькое декодирование,

поэтому там вообще-то нет понятия "ошибки".

Можно по-подробнее, желательно с названиями мягких декодеров?

 

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

Чтобы толк был (если вы вообще согласны задержку увеличить), нужно сделать пакет максимальной длины (исходя из приемлемой задержки),

как уже и сказал Петров.

 

BCH вселяют пессимизм...

Нашёл как расчитать общую длину пакета исходя из начального пакета и количества исправлений ошибок.

 

Мой исходный пакет: m=28 бит

Максимальное число ошибок при котором код ещё работает: S=7

 

Тогда n=m+k - общая длина кода

k=CEIL(log2(n+1))*S

 

Решив уравнение, получается что n(min)=77.

 

Итого: чтоб исправить любые 7 битов в пакете из 28 бит, надо расширить пакет до 77 бит.

 

И эти 7 бит уже как бы не в 28 битах исправляют , а в 77. Итого эффективность: 7/77=1/11 - это ещё меньше чем у простого (7,4).

 

Или я ошибся?

 

На этом фоне коды Файра смотрятся куда лучше.

 

Вот японец изобрел код (26,16) который исправляет до 5 ошибок! эффективность выше: 5/26=0,19 http://the-art-of-ecc.com/3_Cyclic_BCH/RBDS.c

 

Где заветные 25% исправленных бит от первоначальной(!) длины пакета?

Share this post


Link to post
Share on other sites
Ваши Хэмминг и Голей тоже систематические линейные блоковые коды.

 

 

 

 

:-)))))))))) Между 1/4 и 1/2 мягко говоря очень большая разница, примерно как между 1-ой космической скоростью и скоростью света :-)))))))

Можно бесконечно приближаться к 1/2, но при этом избыточность будет приближаться к 100% (из миллиона бит только 1 будет информационным, остальные проверочные).

(Не забываем, что вы просили 1/2 от ВСЕГО БЛОКА, а какова там полезная доля не сказали.)

Исправить 1/4 от всего блока уже вполне реально, но код будет длинный (десятки тысяч бит), а скорость кода будет ну где-то 1/4.

 

НАПОМИНАЮ:

Хорошие коды подразумевают мягенькое декодирование,

поэтому там вообще-то нет понятия "ошибки".

Ошибкой можно условно договориться считать LLR, сменивший знак.

 

 

 

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

Чтобы толк был (если вы вообще согласны задержку увеличить), нужно сделать пакет максимальной длины (исходя из приемлемой задержки),

как уже и сказал Петров.

 

 

 

Нет, науке не известно.

Да ладно тебе, у человека не гаусс канал, рэлей радиканал, перемежение очень эффективно где то на буфер порядка 100 мс а ля ГСМ, вот от свертки немного толку из за глубоких замираний, но иногда есть смысл.

 

Share this post


Link to post
Share on other sites
BCH вселяют пессимизм...

И эти 7 бит уже как бы не в 28 битах исправляют , а в 77. Итого эффективность: 7/77=1/11 - это ещё меньше чем у простого (7,4).

Или я ошибся?

Да нет, верно.

Только сравнение некорректное, для таких крошечных длин оно бессмысленно.

Представим себе мажоритарный код (3,1). Ну то есть передаём 000 или 111. Исправляется 1 ошибка.

По-вашему будет 1/3 эффективности :-)))))

 

На этом фоне коды Файра смотрятся куда лучше.

Вот японец изобрел код (26,16) который исправляет до 5 ошибок! эффективность выше: 5/26=0,19

Так эти коды исправляют БЁРСТЫ, а в контексте радиоканала это мухлёж.

 

Можно по-подробнее, желательно с названиями мягких декодеров?

Никаких названий нет, все актуальные коды сегодня декодируются мягко.

Смысл в том, что приёмник/демодулятор не имеет права делать выводы о том, какие биты передавались.

Это должен делать декодер. Поэтому демодулятор отдаёт ему вероятности, которые рассчитывает исходя из принятого сигнала

и модели канала, а декодер принимает решения о битах только при завершении декодирования.

Share this post


Link to post
Share on other sites

для малых битовых размерностей имхо хорошо помогает тройная одинаковая посылка. на мой взгляд эффективнее чем всё остальное.

Share this post


Link to post
Share on other sites

Тройная кодировка хорошо, но у меня условие - код-рейт не ниже 0,5 - что допустимо увеличить пакет до 2 раз!

 

Вот двойную бы кодировку как-нить сделать...

 

Подумалось мне и вот что придумал: а что если брать по 4 бита квадратом 2x2 и приписывать биты чётности по строкам и столбцам - что даст ещё +4 бита - уложился в зананный код-рейт <=0.5.

 

А корректировать просто: устанавливаем факт ошибок на столбце и строке - исправляем на пересечении :)

Как такой метод коррекции?

 

------

 

По кодам Файра, да в курсе что burst-ы, но ведь это как раз и предпочтительно когда бОльшая часть пакета выбита, а пакеты короткие 2-4 байта (чистый payload.)

 

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

Edited by Mister_DSP

Share this post


Link to post
Share on other sites
Как такой метод коррекции?

 

Не надо велосипед изобретать, всё уже придумано. Из коротких лучше Голея ничего нет.

 

Share this post


Link to post
Share on other sites

Расширенный БЧХ (32,16) - t=3, плюс к этому мягкая схема декодирования, если хватит ресурсов. с необходимостью перемежения определитесь сами.

Share this post


Link to post
Share on other sites

Моя задача улучшить существующий метод коррекции ошибок. Использую RFM96, LoRa FEC. Из даташита известно что он циклический. Возможные конфигурации - кодрейты:4/5 , 4/6, 4/7 и 4/8.

 

Так как в качестве подопытного кролика использую сейчас MELP 2400, то там 1 фрейм 54 бита - с двумя пустыми битами выходит 7 байт, расчёт пакета в LoRa Calculator.

 

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

Ниже о них...

 

Берём CR=4/7, это +3/4 к оригинальной длине пакета. Значит(полагая что FEC исправляет ошибки в таком же количестве как и Рид-Соломон) эффективность 21 % (отношение количества исправленных символов ко все длине).

 

Теперь делаем второй FEC - Рид-Соломон: 7 байт данные(1 фрейм MELP) + 8 байт проверочные: RS (15,7) - такой исправит до 4 ошибок (стирания в этом случае нас не волнуют, так как между кодами LoRa FEC и RS обмена данными нет!). Эффективность такого кода-РС: 4/15 = 27 %

 

А теперь ищем общий КПД этого итеративного(каскадного?) кодирования: 1-(1-kfec)(1-krs)=0,42 42% - тоесть около половины пакета может быть повреждено и восстановленно!

 

Отальные конфигурации с CR=4/5 или 4/6 - дают меньший итоговый КПД, а при CR=4/8 пакет уже не проходит максимально разрешённое время (не более длительности 1 фрейма) при сохранении той же чувствительности (без увеличения скорости).

 

Академические выкладки приложил ниже на бумаге.

 

Как вы думаете - взлетит?

 

post-94050-1485158786_thumb.jpg

Share this post


Link to post
Share on other sites
Академические выкладки приложил ниже на бумаге.

Как вы думаете - взлетит?

 

Взлетело ещё как! :)

Залил прошивку и с напарником проверили.

 

На граничной дальности связи были 4 вещи:

1) пакет принимался без коррекции

2) пакет принимался и успешно корректировался

3) пакет принимался и неуспешно корректировался (были артефакты в звучании)

4) пакет не принимался, приёмник спит

 

Все 4 состояния визуально наблюдал по индикатору (светодиод R,G,B, их сочетания) выведенному из корпуса трансивера.

 

За основу брал этот код: http://we.easyelectronics.ru/attachments/get/1392 (только РС.)

 

Хочу свёрточный + Рид-Соломон сделать с итеративным приближением - есть ли смысл делать это для улучшения приёма пакетов в случае 3) ?

 

Или если увлечься случаем 3) , то случай 4) будет чаще давать о себе знать - ведь бОльшая избыточность кодирования просто вынудит увеличить битовую скорость - а значит привет чувствительности...

Edited by Mister_DSP

Share this post


Link to post
Share on other sites
Как вы думаете - взлетит?

 

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

Share this post


Link to post
Share on other sites

Пробовал читать Скляра, и многих других авторов.

Слишком сухо, много матана и нет практических примеров (симуляция на языке Си или хотя бы блок-схемы алгоритмов).

Также нет привязки к реальным условиям.

Это - беда всех книг ...

 

Когда 2 абонента находятся в городе идут по улице между домами - какой канал - релеевский или гауссовский?

 

Когда канал чист и никто не мешает - как это отразить в теории?

 

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

 

Насколько оправдана потеря 3-6 дБ чувствительности приемника при применении коррекции?

 

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

 

И многое, многое другое не расписано вообще.

 

Иными словами, проблема: как связать тот матан в книгах с реальностью? И просимулировать в программах?

Share this post


Link to post
Share on other sites
Пробовал читать Скляра, и многих других авторов.

Слишком сухо, много матана и нет практических примеров (симуляция на языке Си или хотя бы блок-схемы алгоритмов).

Также нет привязки к реальным условиям.

Это - беда всех книг ...

 

Почти всё что вам нужно у Скляра описывается словами без всякой математики.

 

Когда 2 абонента находятся в городе идут по улице между домами - какой канал - релеевский или гауссовский?

 

Не сводится ничего к этим двум словам.

 

Когда канал чист и никто не мешает - как это отразить в теории?

 

АБГШ.

 

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

 

Насколько оправдана потеря 3-6 дБ чувствительности приемника при применении коррекции?

 

Как раз у Скляра всё это замечательно описано, в другой теме я вам даже ссылку приводил на конкретный график из книжки.

 

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

 

И многое, многое другое не расписано вообще.

 

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

 

Иными словами, проблема: как связать тот матан в книгах с реальностью? И просимулировать в программах?

 

Вникать.

Share this post


Link to post
Share on other sites
Иными словами, проблема: как связать тот матан в книгах с реальностью? И просимулировать в программах?

 

Простите великодушно, но почему бы Вам не попробовать простой путь вместо оставшихся семи кругов ада (Вы сейчас примерно во втором).

Абонент А вызывает Б. Приемник Б принимает вызов и фиксирует сбойные пакеты. Станция Б автоматически сообщает станции А об этом.

А автоматически поднимает мощность децибел на 10. Б автоматически подтверждает устойчивый прием. Если нет, то А опять же автоматически подкидывает еще децибел 10. Если это предельная мощность, то у А и у Б загорается индикация предельной дальности связи. Пара бит туда-сюда. Протокол ясен как слеза младенца. Времени все это удовольствие ничуть не пожрет...

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

Edited by Милливольт

Share this post


Link to post
Share on other sites
Абонент А вызывает Б. Приемник Б принимает вызов и фиксирует сбойные пакеты. Станция Б автоматически сообщает станции А об этом.

А автоматически поднимает мощность децибел на 10. Б автоматически подтверждает устойчивый прием. Если нет, то А опять же автоматически подкидывает еще децибел 10. Если это предельная мощность, то у А и у Б загорается индикация предельной дальности связи. Пара бит туда-сюда. Протокол ясен как слеза младенца. Времени все это удовольствие ничуть не пожрет...

При приёме сообщения от станции А станции Б может возникнуть также битый пакет "о битом пакете". Команда в лучшем случае будет проигнорирована, в худшем - исполнена некорректно.

 

Цель другая - исправлять пакеты от передатчика, когда приёмник на грани чувствительности. Допустим преамбула и первые байты - приняты без повреждений, а вот в середине у абонента дрогнула рука на долю секунды - связь оборвалась - и середина уже байты 3-5 приняты неверно, затем абонент повернулся и конец пакета был принят без ошибок.

 

Иными словами - вытаскивать тухлые биты и/или байты в пакете на граничных условиях приёма, там где враги: либо шум эфира, либо интерференция.

 

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

Я это решил путём введения нового состояния трансивера - когда загорается лампочка фиолетового цвета - то значит пакет был подвергнут коррекции, а значит связь тут уже неустойчива. Если абонент не дурак, то поймёт что это предел возможности аппаратуры :)

 

++++++++++++++++++

 

Почитал Скляра, кое-что стало проясняться.

 

А именно: три(!) модели канала: гауссовский, релеевский и райсовский по середине.

И чтобы добиться наилучших показателей - в каждом из видов канала - выбирают оптимальный коэффициент кодирования (coderate).

 

Для АБГШ - это 0,8 (небольшая избыточность), для Райса: 0,5-0,6 (в 2 раза медленнее скорость). для Релея - вообще -0,3 (тоесть в три раза медленнее).

С такими коэффициентами - не жалко расшириь полосу и увеличить скорость кодирования в 2 (Райс) или в 3 (Релей) раза.

 

++++++

 

Ещё совсем печально стало, когда узнал что RFM96 выносит жёсткое решение: доступен только выход декодера, демодулятор не доступен и поэтому вытащить вместо одного бита хотя бы 2 или 3 не представляется возможным.

 

А вот теперь реалия: есть RFM96 у которого данные аппаратно кодируется сверточным кодером FEC с опциями 4/5 4/6 4/7 4/8 для программиста это невидно.

Имеем декодированый FEC-декодером поток уже с жеским решением: ПАКЕТ.

 

Вопрос: эффективно ли на этот ПАКЕТ навернуть что-то (каскадные коды, турбо-коды, простой RS или просто Голей/Хемминг) - программно, чтобы потом этот ПАКЕТ, пройдя через аппаратный LoRa FEC , был более надёжнее принят?

 

Или если на выходе трансивера жесткое решение c аппаратного декодера , то бессмысленно внедрять дополнительную коррекцию ошибок?

 

 

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this