MLX90640: продолжение

[eddy_em]

Я уже писал, что на какое-то время забил на работу с этими датчиками, т.к. было их всего два, оба некалиброванные на отрицательные температуры и не понятно вообще было: это в моем коде косяк, или же датчики таковы.
Запланировали в конце прошлого года покупку настоящих пяти. Вышел облом: несколько поставщиков отвалилось, последний подождал с неделю и вернул деньги, мол, сорян, товарищи, но у нас ссанкции - не могëм. ОК, на ту же сумму купили на алике 10 датчиков (по 5 у разных продавцов) + парочку готовых устройств (правда, на основе менее широкоугольного). Их я надеялся для сравнения использовать, но вышел казус: там не напрямую датчики подключаются к МК, а через UART! Т.е. они взяли "модули", где уже температура вычисляется, и лишь забирают ее другим МК, да рисуют красивую картинку (на это хватило бы и STM32F103, но они F401 воткнули, а на борту "модуля" - GD32F401; ну, хоть Cortex-M4, а то реально смешно было смотреть на первые такие показометры, где F103 стояла, которая элементарно не потянет несколько тысяч квадратных корней за секунду).
Ну, да ОК, сегодня вышел погулять днем с этим показометром. Под катом - картинки. Заодно, коль уж торчу на горе, а погоды нет, сел причесывать код и проверять купленные датчики (увы, модуль CP2112 на ноуте отсутствовал, а чтобы собрать, нужно систему обновить; поэтому датчики я воткнул в одноплатник и по сети связываюсь). Сразу сказу: увы, они тоже ни хрена не калиброваны на отрицательные температуры. Однако, судя по тому, что выдает "показометр", должно получиться. Как немного рассеются облака, положу на подоконник и посмотрю. Немного картинок с них - тоже под катом.

Ноутбук адски тупит: хоть там и калька стоит, но часть (причем, особо жирных) пакетов почему-то собирается из исходников, средняя загрузка процессора - 1000%, температура около 75-80°C. Причем, я, рукожоп эдакий, чуть не обломал себе удобное проведение наблюдений: стандартным cl-update, естественно, не получилось, поэтому пришлось насильственным методом через emerge. И сначала вручную поставить базовые зависимости, удалить 13-й gcc, а потом уже пошло-поехало. Надо таки было за неделю до наблюдений обновить, а то если б угробил систему, пришлось бы работать с чужого компьютера, а это жутко неудобно.

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

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

А здесь опять слабая облачность как будто ясное небо:

Основная проблема с такой визуализацией - в алгоритме самой железки. Как там фиксировать концы диапазона, чтобы постоянную цветовую гамму получить на одни и те же температуры, я не понял. Там есть какие-то непонятные настройки, но только методом тыка их постигать (хотя, возможно, к этой штуке и есть где-то мануал). Я лишь в конце съемки нашел, как отключить эту убогую интерполяцию и оставить прямое отображение данных с датчика.
А здесь плохо видно (очень тяжело через черные очки разглядывать экранчик + одновременно экран лопаты + как-то нажимать на экран, чтобы фотографию сделать), но вот это бурое пятно достаточно мощным было, когда я непосредственно на устройство смотрел:

Через не очень толстый слой облаков солнечный свет просто заливает все! А я-то думал, что на длинах 10-15мкм от Солнца вообще почти ничего не будет по сравнению с фоном. Ну, и ладно: все равно IR-allsky camera в дневное время не нужна, т.к. телескопы только по ночам работают!
Отверстие в облаках:

и оно же на кадре ИК:

Ну и просто красивый вид:

Ну и я, сидящий за ноутбуком:

Попробовал разную битность АЦП — вообще разницы не увидел. Думал, что, возможно, на разных временах экспозиции будет разница (по шумам, например), однако, тоже между 2 и 0.5 секунд экспозиции особой разницы не заметил, а скорость выше не получилась:

медленный алгоритм сбора данных (пришлось каждый байт поштучно читать вместо того, чтобы это "скопом" сделать; надо попробовать разобраться, вдруг получится) не успевает считывать вторую страницу, в итоге мы видим только одну часть "шахматки".
Собрал у себя siv - simple image viewer, который умеет в inotify, но обломался: при монтировании по ssh не посылаются сигналы! Пришлось в фоне каждые 0.1с делать touch file.jpg. С feh'ом не получилось: не умеет он такого, а посылка SIGUSR1 хоть и заставляет перечитать изображение, но почему-то оно "порченым" бывает (mv хоть и атомарная, но, похоже, монтирование по ssh всю атомарность ломает).
Поэкспериментирую еще с другими режимами (про некоторые в библиотеке от MLX вообще забыли), ну и надо бы все же откопать свой код и посмотреть, не будет ли лучше (т.к. я писал по даташиту, а в библиотеке разработчика некоторые вещи делаются вообще не так, как в документации должны быть).
А потом можно будет из десятка имеющихся датчиков отобрать наиболее чувствительные в минуса. Правда, я бы на эту задачу посадил какого-нибудь молодого сотрудника. Все равно они там 90% рабочего времени дурью маются!