[Mister_DSP 0]

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

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

 

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

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

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

 

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

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

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

 

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% исправленных бит от первоначальной(!) длины пакета?

[DASM 0]

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

 

 

 

 

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

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

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

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

 

НАПОМИНАЮ:

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

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

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

 

 

 

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

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

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

 

 

 

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

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

 

[Dr.Alex 0]

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

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

Или я ошибся?

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

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

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

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

 

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

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

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

 

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

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

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

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

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

[krux 8]

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

[Mister_DSP 0]

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

 

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

 

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

 

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

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

 

------

 

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

 

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

Изменено 22 января, 2017 пользователем Mister_DSP

[petrov 6]

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

 

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

 

[Serg76 0]

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

[Mister_DSP 0]

Моя задача улучшить существующий метод коррекции ошибок. Использую 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 фрейма) при сохранении той же чувствительности (без увеличения скорости).

 

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

 

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

 

[Maverick_ 15]

посмотрите это

[Mister_DSP 0]

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

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

 

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

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

Изменено 23 января, 2017 пользователем Mister_DSP

[petrov 6]

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

 

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

[Mister_DSP 0]

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[petrov 6]

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

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

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

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

 

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

 

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

 

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

 

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

 

АБГШ.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Вникать.

[Милливольт 0]

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

 

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

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

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

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

Изменено 23 января, 2017 пользователем Милливольт

[Mister_DSP 0]

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

А автоматически поднимает мощность децибел на 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 аппаратного декодера , то бессмысленно внедрять дополнительную коррекцию ошибок?