[repstosw 18]

Дано:   поток H264 - cжатые фреймы видео.   Они посылаются цифровым трансивером относительно короткими пакетами - к примеру - по 64+ байта (полезная нагрузка).

Линия связи: трасса средней городской застройки (малый город, посёлок).

Мобильный терминал с четвертьволновой антенной (противовес - корпус терминала), диапазон 430-470 МГц.

Высота антенн над землёй - 1,5 - 2 м (рост человека).

Устройства перемещаются человеческим шагом или на автомобиле (скорость 1 -  50 км/ч).

Скорость потока 96 - 128 кбит/с.  Модуляция - возможна 2FSK, 4FSK, MSK, GMSK, GFSK.

 

Вопрос: какие методы защиты пакета можно использовать?   Коды Рида-Соломона, Коды Хемминга, Файра, Витерби,  Турбо-коды?  Отбеливание? Манчестер? Что здесь будет эффективным?

 

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

Интересует программная коррекция ошибок.

 

Пакеты линейные - 1D, не 2D.  Так как видео сжимается кодеком (аппаратно).

Изменено 21 августа, 2022 пользователем repstosw

[ASN 0]

Как я понял, для Вас коды с мягким декодированием не подойдут, т.к. передатчик цифровой.

Тогда самое эффективное, наверное, алгебраические (RS, БЧХ). Классические сверхточные коды (алгоритм Витерби и Турбо-колы), а так же LDPC будут уступать.

Хотя, для более-менее полезного ответа на вопрос, IMHO, мало данных: надо знать допустимую задержку трафика, наличие обратного канала и вычислительную мощность МПС на приеме.

[des00 25]

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

[repstosw 18]

52 minutes ago, ASN said:

Как я понял, для Вас коды с мягким декодированием не подойдут, т.к. передатчик цифровой.

Чип трансивера CMT2300A.  В интернете видел упоминания, что он может дать "сырые" данные.  Относится ли это к "мягкому" декодированию - я не знаю.

По большей части я программист, схемотехнику ПРД/ПРМ знаю только на уровне аналоговых приемников-передатчиков. Цифровые не собирал, а использовал готовые модули.

52 minutes ago, ASN said:

Тогда самое эффективное, наверное, алгебраические (RS, БЧХ). Классические сверхточные коды (алгоритм Витерби и Турбо-колы), а так же LDPC будут уступать.

А вообще, легко ли программно реализовать сверточное кодирование или БЧХ? Я делал только Рида-Соломона и Турбо-коды для 2D-массива.

Нашёл тут статью, читаю:

http://lib.tssonline.ru/articles2/podv/peredach-izobr-v-sist-prof-mobiln-svyazi

27 minutes ago, des00 said:

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

Матлаб я не знаю. Знаю С/C++, могу на нём сделать моделирование - подсовывать биты ошибки с определённым интервалом. И прямо на отладочной плате смотреть, что будет с изображением при декодировании или наблюдать ошибку отказа декодера.

Правда, в реальности думаю, что картина помех будет отличаться от модели.  Меня больше волнует вопрос интерференционных наложений и замираний, которые будут возникать при движении. В трансиверах LoRa это обыгрывалось их модуляцией с широким спредом и мощным FEC до +50% к пакету. Я бы и дальше использовал LoRa, но на видео(QQVGA, QCIF @ 25 FPS) не хватит скорости (37,5 кбит/с - предел)

Изменено 21 августа, 2022 пользователем repstosw

[ASN 0]

Сделать несложно и то и другое: если на ЯВУ (пример, C) - то не более недели.

Уважаемый des00 правильно указал, что самое первое - сделать модель системы в Matlab, где есть уже готовые модули.

Но, повторюсь, я бы исходил , в первую очередь, из доступной вычислительной мощности: объема памяти и MIPS.

При наличие достаточных ресурсов и на "жестких" решениях можно получить неплохой результат (в целом).

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

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

[repstosw 18]

24 minutes ago, ASN said:

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

CPU Allwinner V3s,  Cortex-A7,  1 ГГц.   Память DDR2, 456 МГц.  64 мегабайта.

Ресурсов хоть отбаляй...  Кодек H264 у него аппаратный - время кодирования фрейма 0,5 - 1,2  мс.

 

Трансивер - до 300 кбит/c.

Видео:  положим 176x144 @ 25 FPS.

 

Связь  симплексная - один передаёт, другой принимает.  И наоборот.

Изменено 21 августа, 2022 пользователем repstosw

[ASN 0]

Попробуйте RS + CRC32 на пакет. Самое простое.

Встречал  реализации на свёрточном кодере с K > 11, где анализировался список наиболее вероятных путей с выбором по CRC. Эдакая реализация "мягкости" по выходу за счет большой величины веса путей.

Поищите по форуму посты уважаемых des00, yes, petrov, работы П.В. Трифонова и В.Д. Милославской (есть лекции на youtube).

[des00 25]

2 hours ago, repstosw said:

Матлаб я не знаю. Знаю С/C++, могу на нём сделать моделирование - подсовывать биты ошибки с определённым интервалом. И прямо на отладочной плате смотреть, что будет с изображением при декодировании или наблюдать ошибку отказа декодера.

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

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

Quote

Линия связи: трасса средней городской застройки (малый город, посёлок). диапазон 430-470 МГц.

Устройства перемещаются человеческим шагом или на автомобиле (скорость 1 -  50 км/ч).

Скорость потока 96 - 128 кбит/с.  Модуляция - возможна 2FSK, 4FSK, MSK, GMSK, GFSK.

подобный канал не описывается обычным AWGN, там есть многолучевка, есть замирания, есть промышленные помехи (то за что не любят этот диапазон). Доплером полагаю можно пренебречь. Подобный профиль канала реализован в библиотеке квадрига для матлаба. С использованием нее можно задать профиль радиотрассы и даже движение приемников/передатчиков друг относительно друга. Затем изучить характер и структуру ваших ошибок. 

Можно все это сделать без матлаба, если сделать логгер который запишет полностью ваш сигнал на испытаниях и вы потом можете дорабатывать ваш демодулятор для оптимизации. Можно без логера если долго собирать статистику канала: ошибки, замирания и т.д. Как я понимаю демодулятор вы не делаете, вы не знаете как работает система эквалайзирования, синхронизации, ару и т.д. По хорошему остается тогда только натурный эксперимент. 

Только после этого можно предложить какую то систему кодирования и защиты. Так в лоб работать, не получится, ну если только вам повезет и вы попадете пальцем в небо) Например у вас есть случайные битовые ошибки, на уровне 1е-3, без групповой ошибки, тогда можно из блочных арифметических кодов что-то подобрать. 

ЗЫ. ну и может быть память мне уже изменяет, 264 не используется же для каналов с ошибками, из-за особенностей декодирования (CABAC/CAVLC), там вроде как был какой то алгоритм сжатия, устойчивый к ошибкам? 265 или SVC или как то еще он назывался

[repstosw 18]

49 minutes ago, des00 said:

Можно все это сделать без матлаба, если сделать логгер который запишет полностью ваш сигнал на испытаниях и вы потом можете дорабатывать ваш демодулятор для оптимизации. Можно без логера если долго собирать статистику канала: ошибки, замирания и т.д. Как я понимаю демодулятор вы не делаете, вы не знаете как работает система эквалайзирования, синхронизации, ару и т.д. По хорошему остается тогда только натурный эксперимент. 

Скорее всего будет эксперимент с логгером.   Образец можно тоже задать и сравнивать полученные пакеты с ним.

 

У CMT2300A есть FEC (не знаю точно какой) - как я понимаю это - свёрточное кодирование на  уровне битов.

Можно ли поверх него добавить Рида-Соломона (255, 233) и улучшить ситуацию?

 

Нашёл реализацию сверточного кодера (133,171) K=7 R=1/2 на Си. Его используют вместе с RS (255,233) - доупускается ли двойное свёрточное кодирование(штатный аппаратный FEC + 133,171) + RS ?  Или второй свёрточный лишний и лучше положиться на аппаратный FEC?

Изменено 21 августа, 2022 пользователем repstosw

[ASN 0]

Декодер свёрточного кода даст пакеты ошибок. Код RS с этим прекрасно справляется, так что лучше будет.

У (133,171) низкий ЭВК при "жестком" декодировании, при этом низкая скорость кода. Если хотите получить приемлемый результат от свёрточного кода на "жестких" решениях, то надо увеличить K (ЕМНИП, до 14) и использовать списочное декодирование (анализировать набор наиболее вероятных путей с выбором по CRC). Однако, рост сложности ML-декодера с ростом K экспоненциальный, а это вычислительная мощность. Или использовать модификации Фано. IMHO, следует попробовать самый проростей вариант: RS с повторение части битов кадра. Если не получится, то тогда уже думать дальше. . Так же обратите внимание на замечание уважаемого des00 о видеокодеке, там тоже есть что подкрутить.

[thermit 1]

Может быть имеет смысл посмотреть готовые решения? Например транки? В p25fdma речь используется хэмминг+ rs. p25 tdma - rs. Всякие crc имеют смысл только тогда, когда есть возможность перезапроса. В потоковом видео в низко скоростном канале это смысла не имеет.

[ASN 0]

2 минуты назад, thermit сказал:

Всякие crc имеют смысл только тогда, когда есть возможность перезапроса

Это не так. CRC используется для проверки правильности декодирования кадра (пакета). Яркий пример - турбокоды: принятие решения об окончании итеративного процесса декодирования. Для HARQ  - это только одно из использований. Более того, я встречал реализации, где CRC использовалось даже для снижения сложности демодулятора (но это уже экзотика).

[thermit 1]

5 минут назад, ASN сказал:

Это не так. CRC используется для проверки правильности декодирования кадра (пакета). Яркий пример - турбокоды: принятие решения об окончании итеративного процесса декодирования. Для HARQ  - это только одно из использований. Более того, я встречал реализации, где CRC использовалось даже для снижения сложности демодулятора (но это уже экзотика).

И? Кадр кривой. Что дальше? В случае х264 картинка развалится до следующего i-фрейма.

Да. Кроме всего прочего мягкий декодер тут не але. Вход-выход жесткий.

Изменено 21 августа, 2022 пользователем thermit

[ASN 0]

14 минут назад, thermit сказал:

И? Кадр кривой

Так в том-то и дело, что вариантов выхода декодера может быть много (списочный декодер). Тут CRC и подскажет, который из вариантов верный. И если кадра от данных "развалился", то это можно обнаружить иначе . И скомпенсировать другими средствами (например, CNN). Это же не данные в чистом виде.

P.S. По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы чиатем не кдаужю бкуву по отдльенотси, а все солво цликеом

[thermit 1]

13 минут назад, ASN сказал:

Так в том-то и дело, что вариантов выхода декодера может быть много (списочный декодер). Тут CRC и подскажет, который из вариантов верный. И если кадра от данных "развалился", то это можно обнаружить иначе . И скомпенсировать другими средствами (например, CNN). Это же не данные в чистом виде.

P.S. По рзелульаттам илссеовадний одонго анлигйсокго унвиертисета, не иеемт занчнеия, в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы преавя и пслоендяя бквуы блыи на мсете. Осатьлыне бкувы мгоут селдовтаь в плоонм бсепордяке, все-рвано ткест чтаитсея без побрелм. Пичрионй эгото ялвятеся то, что мы чиатем не кдаужю бкуву по отдльенотси, а все солво цликеом

Это все прекрасно. Только в действительности все не так, как на самом деле.