Работа с ИК матрицей MLX90640

[A_I]

Раздел-то вроде аппаратный, то есть, по-идее, практический, но как-то маловато тут этой самой "практики"..

Получил матрицу, разбираюсь потихоньку..
Китайцы приделали обвязку на базе контроллера ат32 (их клона стм32), и назвали это устройство GY-MCU90640. Это дало возможность работать с матрицей не только по i2c, но и по rs в соответствие с прикладным протоколом. Чтобы задействовать первый вариант, имея описание апи и длл от мелексис (производителя матрицы), надо кинуть перемычку - на фото видно (подписано SET I2C):


Так как тип объектива 55 град., матрица - 32х24 пикселя, то нехитрые подсчеты дают более-менее приемлемое качество определения человека (из расчета минимум 5 пикселей для человека среднего роста), примерно 20 метров расстояния и менее.

А план такой:
1. Использовать оба метода обмена (по i2c и rs). Понять, что проще при одинаковых показателях (пока для меня не до конца ясно, можно ли общаться по rs с той же частотой и актуальностью данных что и по i2c - всё же "лишнее" преобразование. Как минимум, - будет ли отставание на цикл или нет?)
2. Попробовать за счет контролируемой динамической смены ракурса (положения относительно объекта) и специальной программной обработки увеличить разрешение в разы при приемлемой частоте обновления, скажем, 1 Гц. Больше 10 лет назад немецкие студенты на практике показали что это вполне возможно, используя датчик на условно 1 пиксель:
https://spectrum.ieee.org/ir-eye

[A_I]

По послед. порту соединился и запустил какой-то пример под питон с гитхаба. В принципе, показывает наверное правильно. На фото - в правом верхнем углу, рядом с языковой панелью, выведены показания внутреннего темп. датчика процессора. Как видно, датчик показывает темп-ру проца 55 град. ИК-датчик направлен на процессор малины. Показывает 48-49 град на радиаторе с частотой обновления 4 Гц.

Однако пример какой-то корявенький (а может и руки - еле установился opencv), но после перезапуска примера датчик начинает показывать какую-то хрень. Нужно перед запуском обязательно сначала снять с него питание, чтобы стало все корректно.. Возможно с послед. портом как-то не правильно налажена работа. Нужно поразбираться с примером..
В примере, кстати, экстраполяция в 10х10 раз (то есть, преобразуется в 320х240)

-- 04.02.2024, 20:42 --

Кстати, используется тип интерполяции opencv кубический, то есть, изначально более тормозной чем линейный. Вроде пишут на визуальное восприятие картинки сильно влияет (кубический более "качественный"). Для нашей задачи вряд ли это важно, и расходовать ресурсы на различные украшательства точно смысла нет. (Вообще, скорее всего будет работа с исходной матрицей - 32х24).

[A_I]

Протокол обмена по серийному порту как и ожидалось достаточно простой с классическим обрамлением части с данными - 1544 байта, из которых 2 первых - заголовочные, 3 и 4 - размер данных всего фрейма (всегда 32х24х2=1538), 4-1542 - пары байт данных попиксельно (темп-ра пикселя умнож. на 100). Предпоследняя пара байт - собственная т-ра матрицы, а последние два байта фрейма - чек-сумма.


При этом обмен предусматривает 3 возможных скорости - 9600, 115200 и 460800 б/с.
Даже прикидочными расчетами (учитывая, что 1544 байта это ~16000 бит с учетом, понятно, 8 бит данных и всех старт- стоп- бит и бит четности) видно, что на самой низкой скорости возможно обмениваться с частотой не более 0,5 Гц. Тогда как на самой высокой теоретически возможна частота 16 Гц.
Но протоколом предусмотрены частоты обмена 0.5, 4 и 8 Гц.
В то время как по i2c напрямую возможно обмениваться на макс. частоте в 64 Гц (что, кстати, говорит, о том, что частота самой шины i2c никак не меньше нескольких МГц - это для "знаек-зазнаек ").
Но, как оказалось, сильные шумы не то что на высоких частотах, а уже на 8 Гц картинка выглядит как поверхность солнца в специальных солнечных телескопах - переливается кучей градиентов .
Так что работаем по послед. порту и не паримся...

[A_I]

Мне тут в личке посоветовали "научиться читать и считать" и только после этого "бочку катить" .
В личках не люблю переписываться, поэтому здесь отвечу.
Да, каюсь, прикидывал в уме без калькулятора и слишком допуски завысил.
Однако, на мой взгляд, "несколько МГц" всё же ближе к одному МГц, чем 400 Гц..
(а по поводу "бочек" - мне нравится также поговорка "на воре шапка горит" )

[EUgeneUS]

Не знаю, что Вам написали в ЛС (и знать не хочу, так как это нарушение правил)

Однако:

A_I в сообщении #1629120 писал(а):

(учитывая, что 1544 байта это ~16000 бит с учетом, понятно, 8 бит данных и всех старт- стоп- бит и бит четности)

Для общеупотребительного 8-N-1, формула простая - скорость в байтах равна скорости в битах умножить на 10.
16000 бит на кадр - хорошее приближение.

A_I в сообщении #1629120 писал(а):

Тогда как на самой высокой теоретически возможна частота 16 Гц.

$460800 / 16000 = 28.8$ тут значительно промахнулись.

A_I в сообщении #1629120 писал(а):

В то время как по i2c напрямую возможно обмениваться на макс. частоте в 64 Гц (что, кстати, говорит, о том, что частота самой шины i2c никак не меньше нескольких МГц - это для "знаек-зазнаек ").

А тут Вы не прочитали даташит на MLX90640.

Читаем там в разделе "8. General Electrical Specifications":

Цитата:

I2C clock frequency FI2C 0.4 (Typ.) 1 (Мах.) MHz

То есть те же самые 400 kHz, максимум, но не гарантируется - 1 Мбит.
Никаких "нескольких мегагерц" там нет.
Но откуда там рефреш-рейт 64 Hz? А оттуда, что он считается в виде "подстраниц" в секунду, а не полных кадров в секунду. "Подстранца" по объему это половина кадра.

[A_I]

EUgeneUS в сообщении #1629139 писал(а):

Не знаю, что Вам написали в ЛС (и знать не хочу, так как это нарушение правил)

(Оффтоп)

Посмешили, спасибо.
Это тоже не понял :
"То есть те же самые 400 kHz, максимум, но не гарантируется - 1 Мбит."

Кстати, в режиме "запрос - ответ" (а есть и такой) все ваши "детальные" расчеты ломаются, как это не прискорбно..
В общем не понятно, для чего затеяна эта игра в диапазоны чисел, не имеющих особого смысла в рассматриваемых контекстах, и выводы первоначальные всё равно верны..

[Dmitriy40]

EUgeneUS в сообщении #1629139 писал(а):

То есть те же самые 400 kHz, максимум, но не гарантируется - 1 Мбит.

Не соглашусь: раз это не в разделе "7. Absolute Maximum Ratings", то указанный максимум 1МГц вполне себе гарантируется. Как и например работа при Vdd=3.6В выше в той же таблице.

[A_I]

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

[EUgeneUS]

Dmitriy40
Согласен.

A_I в сообщении #1629140 писал(а):

В общем не понятно, для чего затеяна эта игра в диапазоны чисел, не имеющих особого смысла в рассматриваемых контекстах, и выводы первоначальные всё равно верны..

Если Вы не видите смысла, то не значит, что его нет.

Вы сначала ошиблись в два раза, не разобравшись, что такое рефреш-рейт, назвав его частотой обмена, почему-то. (Да, в даташите на GYMCU90640 это называется "Module update frequency", но причем тут "частота обмена"?)
Потом насчитали откуда-то несколько мегагерц. Хотя гарантируется ровно один.

И потом делаете вывод, что будете работать через UART, а не через I2C. Хотя все эти Ваши расчеты не имеют никакого отношения в принятому решению, соответственно, и ошибки в Ваших расчетах на решение не повлияли.

[A_I]

EUgeneUS в сообщении #1629149 писал(а):

Вы сначала ошиблись в два раза, не разобравшись, что такое рефреш-рейт, назвав его частотой обмена, почему-то. (Да, в даташите на GYMCU90640 это называется "Module update frequency", но причем тут "частота обмена"?)

И потом делаете вывод, что будете работать через UART, а не через I2C. Хотя все эти Ваши расчеты не имеют никакого отношения в принятому решению, соответственно, и ошибки в Ваших расчетах на решение не повлияли.

Да, насчет обмена - опыт работы всегда с несколькими устройствами на одной шине. Соответственно, по запросу от мастера. И спецификации всегда назывались что-то типа "протокол" или "интерфейс" информационного взаимодействия или "обмена". Так как если даже, как Вы говорите только "Module update", то всё равно есть какие-то разовые настроечные или калибровочные и проч. команды от мастера в сети. То есть, в классическом понимании - это "обмен", как Вам бы не нравилось это слово.
Но, в общем-то соглашусь, что с цифрами надо поаккуратнее...

[EUgeneUS]

A_I

A_I в сообщении #1629151 писал(а):

И спецификации всегда назывались что-то типа "протокол" или "интерфейс" информационного взаимодействия или "обмена".

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

[A_I]

EUgeneUS в сообщении #1629265 писал(а):

б) но само понятие "рефреш-рейт" - это про внутренности девайса, про его потроха. И к обмену, протоколу и скорости, отношения не имеет никакого.

Ух, как жёстко и безапелляционно!

(Оффтоп)

и мамой поклянетесь?

А то что весь этот "рефреш..." находится в разделе с communication protocol, так то как бы пустой звук?

[EUgeneUS]

(Оффтоп)

A_I в сообщении #1629292 писал(а):

и мамой поклянетесь?

Это последний пикабушный закидон, который пропустил мимо ушей

A_I в сообщении #1629292 писал(а):

А то что весь этот "рефреш..." находится в разделе с communication protocol, так то как бы пустой звук?

Так читать надо не только заголовки, но и что написано между заголовками.
Особенно имеет отношение к communication protocol раздел "10.6. Reading patterns", где описывается, будет ли камера формировать подстраницы в шахматном порядке пикселей или черезстрочно

(Оффтоп)

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

[A_I]

Заказал Орандж пи 5. Интересно поюзать их восьмиядернвй рокчип с поддержкой нейроаычислений и сравнить с распи + ncs2 и нвидиа джетсон нано. Между собой джетсон и распи плюс нейросеьевая флешка я сравнивал - примерно одинаково (учитывая то что совсем одинаковые сети на них я не запускал/...

[A_I]

Повозился в праздники со "сгребанием в кучу" реалтаймовой ос linuxcnc, opencv, picamera, thermo, serial, pwm, gpio и т.д., ну и кучу зависимостей для всего этого с многократной переустановкой, пока не заработало..
Сейчас имеем - спарку из обычной камеры и термо- матрицы.

(Оффтоп)

И наложение видеозахвата от обеих камер с полупрозрачностью обоих видеопотоков и приведением картинки к 640х480:
https://youtu.be/RGw6_mOyaVE
Однако углы у камер разные - 55 и 65 град. Видимо накладывая, нужно ещё и масштабировать что-то одно под что-то другое..
Дальше - очередные танцы с бубнами с тензорфло, opencv dnn, нейрофлэшкой, ну в общем, со встраиванием всего нейросетевого в общий проект.