А фольгой обклеить?
Не?
Кого их? 300к?
1 лайк
Ну вообще то радар сделали. И даже видит, вот только сердце без обвязки 300к стоит и не рублей. Так что к сожалению индивидуальный предприниматель не потянет.
CAN . В морском варианте тянут по всему кораблю от мостика до машины и 250 килобит и шина. Это профессиональное решение.
Обёртка данных в CAN-фрейме может дать такой оверхед, что никакая компрессия не спасёт.
Зачем? Чтоб его обнаружили?)
А вообще, думаю эта технологическая борьба на ближайшие лет 20-30. Будут искать способы противодействия.
Чтобы его обнаружить.
ТС использует сейчас RS485, как и в судовой электронике предыдущий стандарт NMEA0183, который сменился NMEA2000 на основе CAN, так что я просто советую повторить ход мысли судовых инженеров. 
Ничего нового.
Не знаю как там в судовой электронике, но в промышленности CAN распространён намного меньше чем RS485. Большинство ПЛК, сенсорных панелей, частотных приводов имеет RS485 в базе.
Скорости тот же Modbus RTU тоже может поддерживать высокие, но здесь скорее ограничение кабеля, его длины, наличие помех.
Собственно оба протокола заточены под управление, а у меня чистой воды передача информации.
Сжатие здесь тоже типовое решение - те же камеры не передают информацию в сыром виде а используют различные кодеки.
К чему приложен этот аргумент?
В CAN накладные расходы на пересылку байта относительно модбаса выше за счет служебных данных.
Те же - какие? В тех же, поди, стоит чип специально сконструированный чип, который жмёт всё на лету.
ну и подскажи как на ардуино сделать такое, чего ты жмешься, не умеешь небось?
1 лайк
Не совсем так. На мощных камерах даже две платы стоят - сама камера и чип сжатия
Та же OV2640 которая используется в ESP32 CAM модуле выдает несжатые данные в формате RGB565 (собственно сырые данные с матрицы)
ESP32 сжимает каждый кадр в JPG и выдает поток в MJPEG
Мне такой метод не подходит, так как JPEG это сжатие с потерей качества.
1 лайк
Тогда неплохо было бы определится какой подходит: чтобы картинка была сжата вдвое, втрое, впятеро… До трех бит или до одного? Лимит какой?
1 лайк
Ну я писал выше - сжатие должно быть без потери данных
Данные бинарные, то есть алгоритмы со словарями не годятся
Неверное замечание. Разделение на бинарные и не бинарные данные искусственно. На самом деле алгоритмы применимы и там и там.
В любой реальной картинке сжатие основано на поиске близких или повторяющихся элементов. Для таких данных можно построить словарик.
Если же у вас в данных вовсе нет системы - то это будет белый шум, а он, по определению, не сжимаем.
Почему? В классическом ZIP словарь составляется для всех 256 возможных значений байта, а также дополнительно для частых комбинаций – какие проблемы?
Такое впечатление, что вы ответили кому-то другому. Я не об этом предлагал подумать.
если ты хочешь жать RGB lossless, то начать придется со следуюзего:
Разделить данные на три массива: R, G и B. Пройтись по массивам фильтрами low-pass, по каждому цветовому компоненту отдельно. Потом сжать Хаффманом или Арифметической компрессией каждый канал отдельно.
А чем тебя JPG не устраивает? Ну, lossy, ну и что? Ты на глаз все равно не заметишь.
PS: low pass , конечно, что-то потеряет, но в масштабах одного канала это будет незаметно.
PPS: продвинутый вариант:
Вычисляется разница, между исходной картинкой и той-же самой картинкой, по которой прошлись gaussian blur. Разница - это будет высокочастотные компоненты. За счет этого шага можно таки здорово будет разблурить (low pass) цветовые компоненты.
Для декомпрессии, после того, как восстановятся цветовые компоненты, наложишь свою карту резкости (полученную на первом шаге).
Я такое делал давным давно, лет 20 назад. Тогда были слабые компы, а нам надо было сделать проигрывание видео в игрушке. На Bink денек не было, пришлось извращаться самим.
Боюсь быстрей несжатое отправить Морзянкой вручную) не думаю что у каждой камеры размещать супер-пупер мощную систему хороший вариант.
Идея в изначальном виде нерешаема без BABOSа) так что…продолжаем трёп как всегда)
Варианты:
- Уменьшить количество полезной информации
- Увеличить скорость передачи(да хоть 2-3-10 в параллель линий связи, либо другой тип линии связи)
- Уменьшить требования к скорости передачи.
А вот эти вот все сжатия лишь на 10-20-40% бесполезны, т.к. “хотелки” завышены в разы. Тут никакой архиватор не поможет ни по скорости, ни по требуемым вычислительным ресурсам, ни по степени сжатия.
Отправлять неслабый поток данных через ModBus изначально неправильная затея. Не для того он, как правильно тут заметили.
1 лайк