Добрый день.

Есть небольшой пакетик из 3..4 байт, который пуляется передатчиком в эфир потоком.

Возможности организовать протокол перезапроса пакета приёмником нет и не будет.

В приёмнике и передатчике требуется организовать эффективную битовую коррекцию ошибок.

Читал про коды Хемминга и Голея: код Хемминга (7,4) исправляет 1 ошибку - эффективность: 1/7
Код Голея (24,12) исправляет 3 ошибки - эффективность 3/24 = 1/8

Существуют ли другие алгоритмы коррекции битовых ошибок в коротких пакетах, которые исправляют 1/4 - 1/2 числа бит от общего потока?

К примеру, из общего кодового слова длиной 24 бита исправить 6... 12 бит?

Каков предел эффективности?

Блочные коды (работающие с блоками бит типа RS- и Turbo- code) не предлагать.

Зависит от характера ошибок. Например, сверточные коды эффективно исправляют битые пачки, блочные - единичные ошибки.
Для повышения эффективности применяют каскадное кодирование, например, Рида-Соломона поверх БЧХ.
Но естественно, за это придется заплатить. (в смысле, дополнительными контрольными блоками)

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

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

Исходный пакет очень короткий - 3-4 байта, допустимо навернуть до 2 раза больше, тоесть код-рейт 0,5 не ниже.

Для кода Хэмминга : эффективность кода растет при увеличении информационных блоков. Так, для кодирования 7 бит данных избыточность составляет чуть больше 57%, для кодирования 256 бит избыточность будет 3.5%, а для 1024 – 1%.

http://all-ht.ru/inf/systems/p_0_14.html

Вы представляете что такое 256 бит на скорости 700 бит/с (вокодер)?
Это 0,73 секунды задержки звука в симплексном канале (половина времени - задержка на передачу и столько же на приём).

Нужен алгоритм именно для коротких пакетов.

Пока рассматриваю вот это : http://www.iz-news.ru/lect/04/

И это (клондайк программиста-цифровика ) : http://the-art-of-ecc.com/topics.html

Ну и тут http://the-art-of-ecc.com/3_Cyclic_BCH/RBDS.c в исходнике реализация кодера/декодера (26,12) с исправлением до 5 ошибок, эффективность 5/26 = 0,192 - почти 1/5, оно эффективнее Голея и Хемминга будет

Если искажается весь пакет - надо размазать данные по другим пакетам, а не исправлять ошибки в искаженном

Допустим ваш код (7,4,3) исправляет 1 ошибку

При байтовом доступе к данным:

Берём 14 исходных байт (28*4)
кодируем -> (28*7)
перемежаем -> (7*28)
отправляем 7 пакетов по 32 бита (4 можно использовать для синхронизации)
декодируем в обратном порядке

Вывод:
любой из семи пакетов может быть полностью искажен
наворот (7*32)/(28*4)=2
при 700 бит/с в эфире:
невоспреимчивость к помехе длиной 32/700 = 46мС
задержка в приёмнике 7*32/700=320мС

Можно кодировать полубайтами по 7 байт, а отправлять также по 32 бита по 2 группы в пакете (4+14+14)
если считать, что убивается только последняя половина пакета - тогда задержка 160мС

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

Для BSC - граница Хамминга (https://en.wikipedia.org/wiki/Hamming_bound).

_4afc_, большое Вам спасибо!

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

В случае с вокодером Codec2 на 700 бит/с, составил свой пример:

Берём 8 фреймов вокодера по 28 бит каждый - это 56 x 4 бит
Далее кодируем с избыточностью (56 x 4) => (56 x 7)
Перемежаем: (56 x 7) => (7 x 56)
Отправляем 7 пакетов по 56 бит (по 7 байт).

Декодирование в обратном порядке.
Из 7 пакетов один любой может быть полностью испорчен(не подлежать восстановлению?)

При 700 бит/с невосприимчивость к помехе: 56/700 = 80 мс - это два речевых фрейма Codec2 !

Итого 8 фреймов из них допускается 2 битых.

Всё ли верно?

Есть ли более эффективные коды, чем (7,4) - либо бОльшее число ошибок при заданной длине или более короткая длина на 1 ошибку?


А если приемник не примет пакет? Будет нарушение синхронизации, в итоге все 8 фреймов потеряны.

может еще посмотреть например на кодирование 8b/10b или подобное?

спасибо, почитаю.

На счет пакетов, ведь можно не отправлять в моём случае 7 пакетов по 56 бит - можно сгруппировать в один длинный пакет, один фиг - коррекция ошибок будет просто идти на несколько блоков. Зато это исключает синхронизацию.(точнее - дает право её не делать)

Берите максимально длинный бинарный БЧХ, который устроит по задержке и слышимым искажениям от потери всего пакета, их полно, есть из чего выбрать. В перемежении нет толка в смысле усиления в АБГШ канале.

Это совсем другое, для устранения длинных последовательностей нулей и единиц и улучшения синхронизации. Что-то сродни манчестеру, в некотором смысле.

я это понимаю....
но иногда ошибки могут возникть именно из-за рассинхронизации приемника и передатчика...

Про физику канала ТС ничего не написал...

Создатель Codec2 Дэвид в своем сайте пишет, что планирует добавить FEC к своему детищу - защитив только важные биты фрейма:
http://www.rowetel.com/?p=5373 читать со слов "Next Steps Some thoughts on FEC. A (23,12) Golay code........"

Только что проанализировал важность битов фрейма, путём инверсии по отдельному биту и слушал результаты.
В общем: важны только 13 бит из 28 - биты кодовой книги, старшие биты тона и усиления.
Остальные не дают теряться разборчивости речи: попробовал занулить их - в итоге речь как была так и осталась.

Так что... (13/28)*700 = 325 бит/с - до такого можно снизить битрейт.

Ну а идею защиты только важных бит можно принять на вооружение.

Cделал запись с занулёнными незначимыми битами, оставив 13 из 28.

Звучит ИМХО не дурно, что дает 325 бит/с
Нажмите для просмотра прикрепленного файла

Код:



Выпадают пакеты при передвижении в граничных условиях когда расстояние на пределе. БЧХ поможет в этом случае? Каков выигрыш в отношении сигнал/шум ожидать - на сколько снизится?

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




:-)))))))))) Между 1/4 и 1/2 мягко говоря очень большая разница, примерно как между 1-ой космической скоростью и скоростью света :-)))))))
Можно бесконечно приближаться к 1/2, но при этом избыточность будет приближаться к 100% (из миллиона бит только 1 будет информационным, остальные проверочные).
(Не забываем, что вы просили 1/2 от ВСЕГО БЛОКА, а какова там полезная доля не сказали.)
Исправить 1/4 от всего блока уже вполне реально, но код будет длинный (десятки тысяч бит), а скорость кода будет ну где-то 1/4.

НАПОМИНАЮ:
Хорошие коды подразумевают мягенькое декодирование,
поэтому там вообще-то нет понятия "ошибки".
Ошибкой можно условно договориться считать LLR, сменивший знак.



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



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

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


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



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

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

Да нет, верно.
Только сравнение некорректное, для таких крошечных длин оно бессмысленно.
Представим себе мажоритарный код (3,1). Ну то есть передаём 000 или 111. Исправляется 1 ошибка.
По-вашему будет 1/3 эффективности :-)))))


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


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

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

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

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

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

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

------

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

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

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

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

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

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

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

Нажмите для просмотра прикрепленного файла

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

Взлетело ещё как!
Залил прошивку и с напарником проверили.

На граничной дальности связи были 4 вещи:
1) пакет принимался без коррекции
2) пакет принимался и успешно корректировался
3) пакет принимался и неуспешно корректировался (были артефакты в звучании)
4) пакет не принимался, приёмник спит

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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



АБГШ.



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



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



Вникать.

Простите великодушно, но почему бы Вам не попробовать простой путь вместо оставшихся семи кругов ада (Вы сейчас примерно во втором).
Абонент А вызывает Б. Приемник Б принимает вызов и фиксирует сбойные пакеты. Станция Б автоматически сообщает станции А об этом.
А автоматически поднимает мощность децибел на 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 аппаратного декодера , то бессмысленно внедрять дополнительную коррекцию ошибок?

Бог в помощь!

тоесть в моем случае восстановить пакет программными методами не удастся?

Инными словами: Если приёмник на грани чувствительности и я не дурак, то пойму что на этот ПАКЕТ с пользой не навернуть?

И всё-же я не могу точно утверждать что приемник на грани возможностей, поэтому вопрос остается в силе:

Для коротких пакетов в этом случае бессмысленно.
Вот если бы были радиомодули типа RFM с выходом оцифрованных IQ...но я таких не знаю.

А раньше куда смотрели? В Этих модулях не доступны, выходы после детектора. Для них почти все бесполезно наворачивать кодирование сверху. Просто подумайте о том, при ваших коротких пакетах, что ваш синхропакет недоступен и основная проблема при дальней связи будет начинаться с него. Все же перед Скляром нужно основы освоить с примерами, ... короче курс пройти. Кстати у Si4432 можно данные вывести наружу и получить дополнительный выигрыш, есть такие наработки и ранее тут обсуждали.
А так да, вы очередной грабленаступальщик, шишконабиватель. Но сильно не беспокойтесь, за вами еще огромная очередь вам подобных. Видимо так природа устроена, что нужны такие как вы.


приёмник на грани чувствительности ... ну вот нет такого понятия в цифровой радиосвязи. Еще раз вы забываете про синхру, она порой главнее всего при коротких пакетах!
Грани возможности определены даташитом у таких законченых решений, особо более ничего не добится. Разве самому что либо делать на чипах, к примеру у CML, AD, RF, ... есть все необходимое для вас, но не дешево.

Именно. Но у ув. Мистера есть законченное изделие. Он хочет улучшить его дальность при неизменной сверхмалой мощности методом посткоррекции уже дешифрованных пакетов. Черт его знает, может быть полдецибельчика и удастся вытащить (хотя вряд ли). Но нельзя же забывать об остальных потребительских свойствах изделия, которое должно "пойти в люди". Конкуренция на этом рынке жесточайшая.
Надо, как мне кажется, немножко подвинуть радиолюбительскую мечту о рекордной экономии батарей, тем более, что авторегулировка мощности передатчика может не только повышать энергопотребление, но и снижать его (как это происходит в GSM стандарте).
А если сопоставить трудозатраты на АРМ и на эвристическую коррекцию уже покалеченных цифровых пакетов, то выбор очевиден: мечту надо временно отправить, как сейчас принято говорить, - ффтопку.

Все кто написал ответы - верно написали!

У меня была цель - я её достиг, а именно : сделать пару небольших раций с дальностью связи до 1-1,5 км при максимальных битрейтах 2400-4800 бит/с.
Цель достигнута!

Но захотелось большего!!! А именно - проверить - что можно улучшить чтоб выжать хотя бы ещё 20-40% дальности. А вдруг в Semtech что-то сделали не совсем хорошо? Вот исходя из таких позиций хотел решить вопрос программными методами.

Понятно, что нужно аппаратно решать - переходить на другую элементную базу, при условии изменения цели, например: дальность 10 км при мощностях 100 мВт на портативках с битрейтом 2400. Как вы думаете - реально(если антенны укорочены) ? В итоге восходим к теме Ане Иволгиной которая тут уже писала

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

Ну и по моему RFM96 может работать в сыром режиме - валить всю кашу с эфира, но она однобитовая.

Ещё есть GFSK режим с отключениями преамбулы, синхры и кодового слова - может тут есть поле для улучшения?

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

Почему дальность во многом определяется антенной, простая аналогия. То пространство между двумя станциями это такой условный 3D "кабель", а коаксиал 2D. А антенны это просто трансформаторы волнового на концах этого условного 3D "кабеля", со своими кпд, и тп.
Так вот если выбраны равные условия для этого 3D "кабеля" сравнения корректны, если нет то сравнивать не получается, пример ровнина, город, горная месность, пром объекты и тп.
Чтобы хотеть бльшего надо антеннами также заниматься.

В LoRa RFM96 не может работать в сыром режиме. Другие режимы, тотже GFSK, может дать вам такую же дальность, если сумеете повторами как у LoRa, обеспечить энергию на инфобит.


К сожалению нет, ... .

Да, уважаемые Милливольт и Aner были правы: бесполезно с практической точки зрения наворачиваь дополнительные корректирующие коды, когда аппаратный декодер уже выносит жесткое решение.

Экспериментально я испытал 2 реализации коррекции ошибок, реализуемых программно:

1) код Рида-Соломона, о нём писал выше

2) Свёрточный кодер Витерби с перемежением и де-перемежением на приемной стороне.

Выигрыша в устойчивости связи я не получил. Даже со свёрточным кодером Витерби получился проигрыш, из за того что пришлось уменьшить код-рейт аппаратной коррекции ошибок LoRa FEC чтоб уложиться в пакет с заданным битрейтом для сохранения той же чувствительности.

А вот переход от CR=4/5 к CR=4/8 аппаратной LoRa FEC - действительно ощутимо даёт выигрыш! Связь устойчивая в "злачных местах" на границе приёма.

Все эти выплакивания децибелл из приёмника путём заужения полосы, снижения скорости - всё в прошлом!

Вот испытал новый LoRa-модуль LoRa1278F30 мощностью 1Вт - c MELP 2400 дало 3 км устойчивого уверенного приема: передатчик был внутри балкона, приемник во внутреннем кармане куртки !!! Ура!

Ну и с китайским Новым Годом всех поздравляю!

Подробнее тут: http://vrtp.ru/index.php?showtopic=27904&st=600

Lora модулей таких не знаю, но CC1125 есть такие недокументированные возможности: https://electronix.ru/forum/index.php?showtopic=112978

А куда же делось понятие "чувствительность"? При заданном виде модуляции для достижения максимально допустимой вероятности ошибки требуется совершенно конкретное соотношение сигнал/шум, которое в случае канала АБГШ будет определяться мощностью передатчика, антеннами и их направленностью, затуханием в канале, тепловым шумом (который, в свою очередь, определяется полосой сигнала). Например, в стандартах ETSI четко указаны требуемые значения чувствительности для базовых и мобильных станций (например, для телефона GSM -102 дБм, для TETRA -112 дБм (для АБГШ канала)).

Находил статью по "мягкому" Голею. Никто не встречал готовой С-реализации?

PS:

у SX1276 аппаратный FEC мягкий, поэтому городить свое после жесткого решения нет смысла. Но можно использовать IC880A
там "сырой" сигнал от SX1257 обрабатывается baseband-процессором SX1301, если есть желание - невспаханное поле для творчества. Исходники прошивки FPGA для обработки LoRa закрыты, используются в виде hex.

Так кто же не хочет "мягкого" Голея в готовой С-реализации. Еще как хотим, но пока не встретил в инете. Да и не все там просто в связке с железом.
А с доступностью SX1301 пока трудновато, семтех только крупным продает. Да и доки закрытые пока. Подозреваю, что невспаханное поле для творчества корпораций с ёмкими фин ресурсами. И количество таких будет ограничено, дав им фору перед остальными на пару, тройку лет. Как это неоднократно повторялось ранее с перспективными технологическими решениями. Бизнес должен взять своё.

А в чём сложность с мягким Голеем? Алгоритм Чейза даёт 2 дБ, плата - увеличение количества вычислений. Можно построить код Рида-Маллера на основе функций Уолша, тогда для декодирования используется быстрое преобразование Адамара, т.е. честные мягкие решения. Так сделано кодирование TFCI для UMTS (см. 3GPP 25.212).

А всегда ли стоит двухдецибельная овчинка выделки?

Нажмите для просмотра прикрепленного файла

Причем при ухудшении С/Ш выигрыш падает нелинейно, а на плохих каналах асимптотически бежит к нулю.
Т.е. план ув. Мистера был изначально неудачным.

Реально существуют с 2006.
Нажмите для просмотра прикрепленного файла
https://www.google.com/url?sa=t&rct=j&a...bGs&cad=rjt

Табличка то откуда? ... источник дайте.
Для ряда задач, вероятно вам незнакомых, выигрыш в полдецибела решает задачу. Посему овчинка выделки стоит но не для всех решений.
И таки да, при улудшении С/Ш выигрыш лучше лиенйного.

А чö, классная штука....... 25 дБ до шеннона :-)))))))))))

Ну чел то не в теме, смысл ему отвечать ... ?

Ссылка под табличкой.
http://electronix.ru/redirect.php?https://...bGs&cad=rjt


На 900 сняты с производства.
На 2.4 близкие по конструкции:
https://www.digi.com/products/xbee-rf-solut.../xstream-module

Я Милливольта спросил о табличке, не вас.