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

[Mister_DSP]

Добрый день.

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

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

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

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

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

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

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

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

[MrYuran]

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

[Mister_DSP]

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

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

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

[litv]

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

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

[Mister_DSP]

Для кода Хэмминга : эффективность кода растет при увеличении информационных блоков. Так, для кодирования 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, оно эффективнее Голея и Хемминга будет

[_4afc_]

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

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

Допустим ваш код (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мС

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

[andyp]

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

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

[Mister_DSP]

_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 фреймов потеряны.

[Maverick]

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

Код 8B/10B
Используется та же схема для кодирования, т.е. 8 бит кодируются 10-битным символом. Здесь 4-кратная избыточность (28=256; 210=1024), т.к. 256 возможных входных значений кодируются 1024 выходными.
Этот код обеспечивает стабильное соотношение 0 и 1 в выходном потоке, не зависящем от входных данных. Это свойство актуально для лазерных оптических передатчиков. От данного соотношения зависит их нагрев и при колебании степени нагрева увеличивается количество ошибок приема. Применяется в гигабитной сети на оптоволокне.

[Mister_DSP]

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

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

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

Сообщение отредактировал Mister_DSP - Jan 20 2017, 13:15

[petrov]

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

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

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

[MrYuran]

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

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

[Maverick]

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

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

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

[Mister_DSP]

Создатель 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 бит/с
 325bit_from_700C.wav ( 255.67 килобайт ) Кол-во скачиваний: 47


Код:

Код

codec2=codec2_create(CODEC2_MODE_700C);

while(fread(buf,sizeof(short),320,f_in)==320)
{
  codec2_encode(codec2,bits,buf);

//bits[3]^=0x08; //01234567 (!не влияют89_10_11_12_13_14) 15_16(pitch)_17(pitch) (не влияет: 18_19) 20(усиление)_21 (не влияет: 22_23_24_25_26_27)

bits[1]&=0x80; //зануляем биты 8...14
bits[2]&=0x33; //зануляем биты 18..19, 22..23

  fwrite(bits,sizeof(char),4,f_out);
}

codec2_destroy(codec2);

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

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

Сообщение отредактировал Mister_DSP - Jan 20 2017, 15:28

[Dr.Alex]

Блочные коды не предлагать.

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

Существуют ли другие алгоритмы коррекции битовых ошибок в коротких пакетах, которые исправляют 1/4 - 1/2 числа бит от общего потока?
К примеру, из общего кодового слова длиной 24 бита исправить 6... 12 бит?
Каков предел эффективности?

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

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

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

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

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

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

[Mister_DSP]

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

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

Хорошие коды подразумевают мягенькое декодирование,
поэтому там вообще-то нет понятия "ошибки".

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

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

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]

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




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

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



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



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

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

[Dr.Alex]

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]

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

[Mister_DSP]

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

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

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

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

------

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

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

Сообщение отредактировал Mister_DSP - Jan 22 2017, 11:18

[petrov]

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

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

[Serg76]

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

[Mister_DSP]

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

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

[Mister_DSP]

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

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

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

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

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

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

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

Сообщение отредактировал Mister_DSP - Jan 23 2017, 11:42

[petrov]

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

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

[Mister_DSP]

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

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

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

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

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

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

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

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

[petrov]

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

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

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

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

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

АБГШ.

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

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

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

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

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

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

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

Вникать.

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

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

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

Сообщение отредактировал Милливольт - Jan 23 2017, 19:40

[Mister_DSP]

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

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

Цель другая - исправлять пакеты от передатчика, когда приёмник на грани чувствительности.

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

Если абонент не дурак, то поймёт что это предел возможности аппаратуры

Вопрос: эффективно ли на этот ПАКЕТ навернуть что-то

Бог в помощь!

[Mister_DSP]

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

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

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

вот теперь реалия: есть RFM96 у которого данные аппаратно кодируется сверточным кодером FEC с опциями 4/5 4/6 4/7 4/8 для программиста это невидно.
Имеем декодированый FEC-декодером поток уже с жеским решением: ПАКЕТ.

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

Сообщение отредактировал Mister_DSP - Jan 24 2017, 08:06

[sergvks]

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

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

[Aner]

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

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

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

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

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

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

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

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

[Mister_DSP]

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

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

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

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

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

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

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

[Aner]

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

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

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

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

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

[Mister_DSP]

Да, уважаемые Милливольт и 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

[arhiv6]

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

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

[stealth-coder]

приёмник на грани чувствительности ... ну вот нет такого понятия в цифровой радиосвязи.

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

[GeGeL]

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

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

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

PS:

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

[Aner]

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

[stealth-coder]

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

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

Так кто же не хочет "мягкого" Голея в готовой С-реализации.

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




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

Сообщение отредактировал Милливольт - Feb 17 2017, 20:20

[MrAlex]

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

Реально существуют с 2006.

https://www.google.com/url?sa=t&rct=j&a...bGs&cad=rjt

[Aner]

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




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

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

[Dr.Alex]

Реально существуют с 2006.

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

[Aner]

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

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

[MrAlex]

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

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


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

[Aner]

Ссылка под табличкой.
http%3A%2F%2Fftp1.digi.com%2Fsupport%2Fdocumentation%2Fproductmanual_xstream_pkgr_rs232rs485rfmodem_v5.x00.pdf&usg=AFQjCNFZj_drF5EDT6iOQQBeytJicCmQ8Q&sig2=gOs0iIt1oxUhQl7CeE80OA&bvm=bv.147448319,d.bGs&cad=rjt

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

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

[MrAlex]

Табличка то откуда? ... источник дайте.

Цифровая связь, Скляр
стр.393