Перейти к содержанию
Поиск
    

repstosw

Участник
 Профиль  Обзор контента

  • Постов

    2 582

  • Зарегистрирован

  • Победитель дней

    2

 Тип контента 

Сообщения, опубликованные repstosw

  1. Опубликовано · Изменено пользователем repstosw · Пожаловаться

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

    В буфер длиной 5952 байт (1 пакет Si4463) записывался образец: последовательность байт от 0 до 255 с периодичностью. Число пакетов - 2160 (это ровно 3 минуты на 12 FPS).

    Полученный лог преобразовался в 8-битный PNG с градациями серого с размером: 5952 x 2160 пикселов.

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

    Вот что вышло: 

    wood.thumb.png.23f2f9d24069fe5f45de396525e062ce.png

    Фрагмент увеличенный в 2 раза:

    1.thumb.png.0a41a6e484429e6991c1f06999b83e1d.png

     

    Картинку лучше скачать, потому что она сжимается в браузере. Прямая ссылка на файл:   wood.zip

     

    Что можно предпринять с таким характером ошибок?  Какой код тут оптимален?  Хемминг? Голей? Рид-Маллер? Файр? БЧХ?  Рид-Соломон?

    Решения жесткие (Hard Decision).

  2. Опубликовано · Пожаловаться

    1 hour ago, des00 said:

    Вам конечно виднее, но еще лет 10 назад, знакомые ребята приносили модуль с 264 для БПЛА, который на CIF ЕМНП требовал порядка 100кб/с. 

    Какой фреймрейт?

    Какой фактор квантования Y и CbCr кодера?

    Используются ли Predict- и Back- фреймы в потоке?

  3. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    10 hours ago, des00 said:

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

    У вас сильно приукрашенное представление о работе данной игрушки (Spy Gear Walkie Talkie) :acute:

    Начнём с того, что в рекламном видео, снятым производителем, не показываются критические моменты:

    1. Что будет со связью, когда происходит движение в помещении

    2. Качество изображения (обратите внимание, что в ролике видео-поток выглядит очень реалистично для кадра 160x128)

     Скорость не может быть выше 1 мбит/c (с включенным Хеммингом), или 2 мбит/c (без Хемминга).  Марку RFIC  уже называл.

     

    Quote

    ИМХО потому что всем нужна скорость) если бы хватало 50-100кбит/с на толпу, как той игрушке, то все было бы намного проще)

    100 кбит/c не хватит, чтобы передать JPEG 160x128 приемлемого качества на 10-15 FPS (из видео видно, что фреймрейт не ниже 10 FPS).

    Как минимум, нужно 250-300 кбит/c (как показали мои ранние эксперименты на CMT2300A).

    На FPS ниже 10, анимация перестаёт быть приемлемой и превращается в стробоскопирование.

  4. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    3 hours ago, des00 said:

    зачем? чтобы все промышленное г..о собрать? да и дальность всего 50 метров.

    На 2,4 ГГц г..о от Wi-Fi роутеров.   И затухание в свободном пространстве выше.  Поэтому для меня этот диапазон неинтересен.

     

    3 hours ago, des00 said:

    вот как раз на FSK этого хватает, это не камы енти ваши, синус попробуй прибей точечно, его и усиливать в ограничение можно, и по выходу и перед демодуляцией)

    Кому хватает?  Не думаю, что этого кода хватит для подвижной наземки.

     

    2 hours ago, _4afc_ said:

    Если новый "каждый кадр - ключевой" пришёл битым - надо вставлять серое поле, а не вводить в заблуждение заказчика и себя - демонстрацией устойчивой связи в виде протухшей информации.

    Кому надо?

    Что-то я не вижу подобного решения в видео-звонках Скайп, Вацап, телеграм и им подобных. Везде заморозка кадра.

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

     

    2 hours ago, _4afc_ said:

    Странно, вы тут столько рассказывали нам, что освоили перемежение в пакетах данных, и даже слово "транспонирование" привели, но не можете сделать того же с изображением?

     Учитесь понятнее излагать свои мысли, если хотите быть понятым.

     

    2 hours ago, _4afc_ said:

    При отсутствии связи, постепенно, через 7 битых кадров, на восьмом -  весь экран станет серым.

    Не вижу смысла таким образом нянькаться с кадром,  мой корректирующий код восстанавливает до 25% информации.  Всё что выше, уже нет смысла вытягивать.  К тому же ещё и без звука, который как JPEG не порежешь. :biggrin:

     

  5. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    13 minutes ago, _4afc_ said:

    Нам так часто показывали какой H264 хороший, пока не повернёшm камеру на меняющееся изображение 🙂

    Использовал H264  в режиме "каждый кадр - ключевой".  Из потока можно выкусывать отдельные его фреймы - на ПК они тоже смотрятся. И выглядят лучше чем JPEG.

    Использовать P- и B- фреймы нет смысла, так как придётся ждать время всего GOP в худшем случае, если ключевой кадр битый.

    2 minutes ago, _4afc_ said:

    Шахматная доска разбита с шагом 2.

    Всёравно непонятно.

     

  6. Опубликовано · Пожаловаться

    2 minutes ago, _4afc_ said:

    Если скормить пару битых байт декодеру что будет?

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

    4 minutes ago, _4afc_ said:

    А буфер заполнит мусором при ошибке?

    Не проверял.

    6 minutes ago, _4afc_ said:

    В любом случае скормить 25 кадров 32х48 полученных из кваратов 8х8 взятых с шагом 25 из изображения, а на приёмнике выводить только не битые, а на битых затухать старые в 2 раза в серый будет красивее...

    Не совсем понял как разбивать.

    Если 160x240 разбить на куски 32x48, то это будет 5x5 = 25 мелких картинок.    Что значит шаг 25 из изображения ?

  7. Опубликовано · Пожаловаться

    4 minutes ago, _4afc_ said:

    Отсутствие изображение лучше частичного отсутствия?

    Там не отсутствие, а заморозка на предыдущем кадре.

    5 minutes ago, _4afc_ said:

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

    Аудио жёстко сжато, кодек CELT.  1 аудио-фрейм 50 байт (16,6 мс).

    5 minutes ago, _4afc_ said:

    Процессор повиснет на битом JPEG?

    Декодер вернёт ошибку декодирования. Если сбросить, то готов к декодированию нового фрейма. В регистрах задаётся максимальный размер для разжатого буфера.

    Процессору всёравно.

  8. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    Есть интересный девайсик под названием Spy Gear Video Walkie Talkie.

    Удалось найти кое-какую информацию о его внутренностях.

    Дисплей там 1,8 дюйма  (разрешение скорее всего 160x128),  камеру опознать не удалось.

     

    Трансивер там- модуль на AMICCOM A7137 - это 2,4 ГГц. Лучше бы сделали 430-440 МГц.

    С наличием аппаратной FEC - Хемминг (7,4). Как-то ни о чём:  исправляет 1/7 всех данных и строго 1 бит на 1 байт.   Он как мёртвому припарки на Релеевских/Райсовских каналах.  Модуляция FSK, не OFDM.

     

    Но девайсик сам забавный.  Дальность 50 метров по прямой, питание 3 ААА.

     

    Внутренности:  int-photos-2619495.pdf

     

  9. Опубликовано · Пожаловаться

    Касаемо темы ECC,CIRC и прочего.

    Удалось "пощупать" CIRC через elbyecc.dll

    Данный ECC меня разочаровал.  Слишком малая ээфективность для моих целей: из  2352  байт (сектор диска+ остальное) допустимы 52 ошибочных байта.  А проверочные байты (P,Q) вообще сильно чувствительные.

    Приложил рабочий бенчмарк для тестирования CIRC:

    diskecc.zip

  10. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    16 minutes ago, _4afc_ said:

    Разбейте картинку на 4. Сожмите отдельно. Передайте восстановите - всёравно кодирование 8х8 идёт.

    Смысл?  Увидеть пол-морды собеседника?

    16 minutes ago, _4afc_ said:

    Декодирование тоже аппаратное? Или libjpeg8?

    Тоже аппаратное.

    libjpeg там только для заголовка и расчёт Хаффманов всяких. Причём всё просчитано заранее для качества от 5% до 95% с шагом +5%

    16 minutes ago, _4afc_ said:

    Как декодируются битые JPEG с восстановленным заголовком?

    Никак.  Пропуск фрейма.

    Там ещё сжатые аудио-данные в конце супер-фрейма. Они тоже пропускаются.

    Работаю на уровне данных в буфере, никакой специфики вытащить разрушенный JPEG или CELT-аудио - нет.

     

    JPEG кадр 160x240 (портретный) режим.   Дисплей 320x240:  поделён на две половины - слева собеседник, справа - я (камера).

    Изначально был H264, но с переходом на Allwinner T113-s3 пришлось отказаться от H264. Потому что он не умеет кодировать H264, а Allwinner V3s умеет.

    JPEG очень сильно даёт артефакты на резких переходах или токих линиях в картинке, что бросается в глаза даже при качестве 90%. H264 такого недостатка не имеет.

    Может я слишком привередлив.  Whatsapp видео-звонок тоже даёт картинку, которая мне не нравится.

  11. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    6 minutes ago, petrov said:

    CRC8 - очень мало, на шуме в среднем каждый 2^8 блок будет давать ложную верную сумму.

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

    2 hours ago, repstosw said:

    CRC8 - на столбцы блоков RS (длина столбца 28 байт)

     

    4 minutes ago, _4afc_ said:

    Но самое главное заголовок не передавать.

    Заголовок не передаётся. И кое-какие постоянные данные тоже.

    Использую libjpeg8 для восстановления заголовка.

    Передаётся только тело и байт качества сжатия(в %)

  13. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, _4afc_ said:

    Забыл, вы переписали MJPEG чтобы при потере части суперфрейма - весь кадр не сыпался?

    Это можно как-то согласовать с аппаратным кодированием и декодированием?   Использую аппараный кодек JPEG.

    54 minutes ago, des00 said:

    тогда врядли что-то будет лучше, все сверточники идут лесом, только брутфорс, только хардкор: большой блок, низкая скорость кодирования и размазывание ошибки на бОльшее количество блоков

    Сильно большая латентность тоже ни к чему, не очень приятно когда голос собеседника и мой голос идут в разницу 1 секунда. (Full Duplex)

    Блоков сейчас 29.  Один блок RS 255 байт.   Скорость одного супер-фрейма 100 мс.   Исправляющая способность на пакетной ошибке :  64 * 28 = 1792 байт,   всего в суперфрейме 7395 байт.

    Этого хватает на исправление ошибки длительностью до 24 мс.

  14. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, des00 said:

    похоже понял в чем была неясность. Этож теория кодирования, если ошибок в канале больше чем способность кода обнаружить ошибки, то код просто напросто возьмет соседнее кодовое слово. Но и CRC не панацея, где то же в сети есть рассчеты эффективности CRC разных размеров под определенные длины блоков. Тот же CRC32 в Ethernet не просто так появился. Но да, соглашусь, сигнал отсутствия отказа от декодирования кода РС, в общем случае не является индикатором того, что ошибок нет. Но и тот же CRC32 прилично так отьест от блока {32,28}, который обсуждался выше) Получается классический размен: скорость кодирования vs исправляющая способность

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

    У меня несколько CRC.   CRC8 - на столбцы блоков RS (длина столбца 28 байт),  и CRC64 - на декодированный супер-фрейм (длина ~6 кБ).  Финальная проверка по CRC64 - если проверка супер-фрейма проходит, значит данные подаются на декодеры (фреймы MJPEG и CELT). Если проверка неудачна, супер-фрейм отбрасывается.

     

    1 hour ago, des00 said:

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

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

    Перепробовал перемежители:  Zig-Zag("змейка") и шаблон случайной перетасовки.   На пакетных ошибках - перемежение "транспонирование" выигрывает.

     

  15. Опубликовано · Пожаловаться

    19 hours ago, petrov said:

    Можно попробовать сделать второй код просто CRC для определения стираний, после деперемежения RSом исправляете стирания.

    Смоделировал.  Взял 28 блоков по 255 байт. Посчитал CRC.

    Действительно, исправляющая сила возрасла в 2 раза на пакетной ошибке.

    Перемежение - простое транспонирование.

    image.png.f17cd08a2a30035f02dcee39b4565015.png

     

    Какие есть более эффективные перемежения?   Исправляющая способность сильно зависит от характера ошибок: на случайных одиночных ошибках исправляющая эффективность данной конструкции падает до 40%   (40%  от половины числа исправляющих символов одного RS-блока)

  16. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    13 hours ago, V_G said:

    Осталось проверить, как это работает в условиях городской застройки. И сравнить с OFDM.

    После как усовершенствую коррекцию ошибок.

    Вариант с OFDM получился слишком громоздким - чтобы получить 1 Вт средней мощности ВЧ, пришлось дополнительно рассеивать в тепло 14 Вт (RFPD3580, D10040230PH1 ).  И повышать напряжение до 24-28 В. И городить коммутацию на нескольких ключах SPDT (потому что у AT86RF215  общий вход на передачу и приём).

     

    C 4FSK таких проблем нет,  раскачать до 1-1,5 Вт можно одним RF-MOSFET'ом (2SK3078 , 2SK3756 ).  Как это сделано в модулях RF4463F30.

    Можно сделать ещё 7/ 17/ 30 Вт , применив модуль RF4463PRO (+20 дБм) и модули УВЧ: RA07H4047M, M57716,  RA30H4047M

     

    Кстати, кто-нибудь знает, какие требования к линейности усилителя должны быть на модуляции 4FSK?

    Понятно, что не сильно высокие, как для OFDM(BPSK, QPSK, QAM-16,...), но всё-же.

  17. Опубликовано · Пожаловаться

    56 minutes ago, petrov said:

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

    Мне нужно интегральное решение на одном чипе.

    P.S.  Однако же, я разогнал Si4463 на 20% (кварц 36 МГц вмето 30) и уменьшил уровень своих амбиций.   Результат устраивает.

    • Upvote 1

  18. Опубликовано · Пожаловаться

    24 minutes ago, des00 said:

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

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

    Сделал 2D кодирование RS.  Взял квадрат 255x255.   Промоделировал:  позиции ошибок случайные,  пакетная ошибка.

    Всё только хуже.  Я ожидал что эта конструкция исправит   число ошибок равное числу проверочных символов.  На деле оказалось меньше.

    Выходит лучше  проверочные символы по второму измерению закинуть в первое - эффекта даст больше.

    Приложил проект бенчмарк моделирования.

    RS_Quad.zip

  19. Опубликовано · Пожаловаться

    3 hours ago, des00 said:

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

    Я правильно понял, что в случае если RS не может исправить ошибки (если их много), то он не может вернуть, что пакет неисправляем?  Это городить отдельно CRC надо?

  20. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    56 minutes ago, Самурай said:

    логично предположить, что и девиация должна быть больше на 20%. Ну это при условии, что все аналоговые и аналого-цифровые блоки трансивера такое повышения частоты вытерпят:)

    Впаял кварцы на 36 МГц.  Трансивер работает.  Проверил, что пакеты принимаются корректно, без коррекции ошибок и на минимальной мощности.

    Увеличил размер пакета на 20%. Тоже работает.   Разместил там проверочный код Рида-Соломона для коррекции ошибок.

     

    Так как фильтры в Si4463 цифровые, значит их полоса тоже увеличивается на 20%.

    Частоту несущей пришлось скорректировать в программе настройки - уменьшить на 20%, чтобы осталась той, которая нужна.

     

    P.S. Чипы SX1278 LoRa тоже гонятся.  До 35%.  Выше уже не работали.

  21. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, des00 said:

    ЕМНП в лоб там не выводится корректирующая способность, все вероятностное.

    Я так и думал.  Что это зависит от расположения ошибок.  Ну а если минимум и максимум вывести? Мне интересно это оценить с одиночным RS+перемежение.

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

     

    1 hour ago, des00 said:

    Лучше всего этот код работает, когда код может вернуть мягкую метрику, чтобы передавать ее между итерациями. Решения для БЧХ я видел, но решений для РС кодов не находил. Не совсем понимаю как в РС посчитать мягкую метрику символа. Но и без мягкой метрики, за счет перемежения и корректной обработки отказа от декодирования, полагаю что код даст выигрыш. Подобная схема кстати в высокоскоростном Ethernet используется. Есть варианты для РС, есть для ММПЧ кодов. 

    Что-то в последнее время многие говорят об этих мягких решениях, но кроме как в LDPC кодах я не видел эти решения вживую.

    У меня твердый массив байт, работа с буфером.  Нету мягких решений.

     

    1 hour ago, des00 said:

    Самый простой вариант прочитать главу 8 Морелоса Сарагосы "Итеративно декодируемые коды"(страниц 10 вроде). На примере обычного кода проверки на четность, который не может исправлять ошибки, показано что подобная схема может корректировать ошибки. ЕМНП в лоб там не выводится корректирующая способность, все вероятностное.

     

    1 hour ago, des00 said:

    Подобная схема кстати в высокоскоростном Ethernet используется. Есть варианты для РС, есть для ММПЧ кодов. 

    Видел такое.   Там в столбцах считается остаток от деления на 256 и вычитается из 255.  А по строкам Рид-Соломон.

     

    Однако в своём приложении, я могу позволить только до 25% проверочных символов от общего числа.   Хотел использоватать каскадный код (RS + cверточный), но у него оверхед 67% (CR=1/3).    В моём случае оверхед не должен превышать 25% (CR>=3/4).  

     

    Пока использую РС + перемежение. Оно работает и даже лучше, чем без него, но хочется бОльшего.

    Использую RS(255,191).  Это 64 байта каждого блока на проверочные символы, что исправит максимум 32 ошибки в каждом блоке.  Число блоков: от 24 до 30. (зависит от FPS видео).    Хочется получить бОльшую исправляющую способность, при этом её увеличение должно быть больше, чем рост оверхеда.

  22. Опубликовано · Пожаловаться

    9 hours ago, des00 said:

    Для характерных ошибок CD это правомерно, ведь код разрабатывался именно для этой физической среды передачи данных, а не на все случаи жизни. Стирание не панацея, просто вы говорите коду "ошибка вероятно тут", даже если ошибки там могло и не быть. Ему от этого не жарко не холодно, что жесткому, что мягкому. Про то как определяется эта ситуация "ошибка вероятно тут", выше уже писал.

    Ладно.  CIRC отставить...

     

    Нашёл статью с имплементацией блочного кода на базе Рида-Соломона:

    https://we.easyelectronics.ru/Soft/2d-reed-solomon-block-turbo-codes-rs-btc.html

     

    В чём эффективность такого кода по сравнению с Ридом-Соломоном + перемежение?

    Проверочные символы добавляются и по вертикали и по горизонтали: общее число проверочных символов увеличивается.

    Но что происходит с исправляющей способностью блочного 2Д-кода?

     

    Допустим полезное сообщение: M x M байт.   Всё сообщение:  N x N байт.   Число проверочных:  N*N - M*M.

    Как вывести максимальное число ошибок которые могут быть исправлены в таком коде?  Формула.

     

     

  23. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    15 hours ago, petrov said:

    FPGA с квадратурным трансивером.

    И жирные АЦП и ЦАП. Итого: уже 3 чипа как минимум.

    Мне даже даром такое решение НЕ НУЖНО!

  24. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, des00 said:

    неужели стандарт из 5 строки гугла не помог? https://www.ecma-international.org/wp-content/uploads/ECMA-130_2nd_edition_june_1996.pdf

    Не помог вообще.  Я узнал из него не больше, чем в википедии.

     

    И всётаки... Как перевести ошибки в разряд стираний?

    image.png.b7e7006de55b97773990d7eb15835e2c.png

     

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

     

  25. Опубликовано · Пожаловаться

    17 minutes ago, des00 said:

    Относительно CIRC в википедии же написано

    Я этот текст тоже читал, забавно что в англоязычной версии приводится другая исправляющая способность - до 3500  бит на блок.  А не 4000 бит, как в русскоязычной версии.

    Мне нужна точная имплементация данного алгоритма. Википедиям я не верю.

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

     

    P.S. Рида-Соломона с перемежением научился уже делать, работает.  Но хочется не только ошибки, но и стирания.

×
×
  • Создать...