Нормально ли, что сенсор прилично нагревается при работе за короткий промежуток времени? Использую его вместе с платой Raspberry Pi, подключил по схеме, указанной в даташите. Кто юзал этот датчик - отпишитесь пожалуйста.

Использовал две разных модификации - 90614-BCI и 90614DCI. Обе с питанием 3,3в. Никакого нагрева замечено не было, даже при многочасовой работе.
Есть и модификации на 5в - Вы с питанием не промахнулись? Резисторы подтяжки на шине i2c какого номинала?

Аналогичная ситуация. Работал датчик отлично. Во время сборки проекта стал греться до 35 градусов. И стал кушать 35 мА даже в режиме сна. Что я сделал не так не знаю, как решить проблему тоже.

Год уже стоят 2 датчика 3,3 В на установке. Подключены к Raspberry Pi через оптическую развязку.Не греются. Работают.

Собрал несколько пирометров на этих датчиках. Аномальчого токопотребления и разогрева никогда не наблюдалось. В частности, со времени публикации статьи батарейку в этом экземпляре устройства не менял.

А как Вы 90614 читаете? И можно ли его вообще посредством ардуиновской библиотеки Wire.h читать? Чего-то у меня только нули выдает... Может чего подскажите?

А на дату глянуть? Последний разговор на этой теме был > 5 лет назад.
"Помогу. Лет через 5" © Мимино

Глядел я на дату конечно. Более свежих тем в поиске не нашел.

Могу посоветовать изучить даташит и написать свой код.
Это самое лучшее решение вашего вопроса.
Или попробуйте разобраться в моем коде.
Могу выслать вам программу для смены слейв адреса MLX90614.

Программа для смены слей адреса была бы тоже полезна. Там не ясно как вычислить контрольную сумму и записать ее вместе с новым слейв адресом? Без нее менять адрес не хочет. Прочесть показания уже удалось.

Адрес ему я не менял, у меня этот датчик сидит на отдельной шине, поэтому с адресацией у меня проблем нет и подсказать про адрес не смогу. Вот резисторы на шине я поставил разные: на клок 10 килоом, а на данные - 4.7 килоома, чтобы данные подтягивались пошустрее, на осциллографе хорошо видно, как чтение стало более стабильным. В остальном этот SMBus почти один в один всем известная I2C, разве что зависать в постоянку не умеет. Во всяком случае я этот датчик читаю именно библиотекой для I2C. Но у меня не атмеловский процессор.
Про контрольную сумму не понял: там же не сумма, а циклический контрольный код. Который, кстати, не защищает от ошибок на 100%: бывает, что показания правильные, а CRC не сходится (там обычно нули). А бывает и наоборот, CRC сходится, а в показаниях температуры одни нули. Но это редко, а в 99.99% случаев если CRC сошёлся, то и показания температуры правильные. В интернете есть онлайн-калькуляторы для вычисления этого (именно этого) CRC.

Прикрепляю программу для смены слейв адреса.
Разбирайтесь. Тут есть вычисление CRC8.

Мда... Тут разбираться надо неделю с моими познаниями. Вы не могли бы просто пояснить что есть полином Х8+Х2+Х1+1. Везде поясняется так, что при записи нового адреса следует сложить десятичные значение адреса слейва, команду, мл.байт и старший байт соответственно. В моем случае 5А (90),2Е (46)-адрес регистра где шинный адрес храниться, то что будем записывать(к примеру новый адрес 0х5В (91). Это 227 в сумме.
При попытке чтения дефолтного адреса на шине, датчик шлет мне контрольную сумму 190. Могу я 191 ему отослать, чтобы он адрес поменял на следующий по списку? Или там алгоритмы разные?

Добавлено after 13 minutes 26 seconds:
Да. Спасибо конечно за программу.
Насколько я понял, это какой то общий случай работы с шиной. У ардуинщиков библиотечные команды в основном.

После 9-го числа. Уж извините, подождите немножко...
Не надо складывать десятичные! Процессор считает в двоичной, в ней и складывайте. Точнее, вообще не заботьтесь об основании системы счисления. Это забота компилятора.

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

Начну с того, что в интернете есть онлайн-калькулятор для вычисления этого кода. Я только что ввёл туда пример из PDFa по записи в EEPROM: b42207c8, указав Content Type = HEX и получил ответ Hex Result = 48. В ПДФе приведено тоже 48, так что всё сходится.
А вообще циклический контрольный код отличается от простой контрольной суммы тем, что вычисления делаются несколько раз в цикле, но со сдвигами. В выражении Х8+Х2+Х1+1 пропущены знаки возведения в степень. Вместе с ними должно быть x^8 + x^2 + x^1 + 1. Опять же, считать это всё вручную не надо. Для обсуждаемого датчика подходит вот такая подпрограммка (я её не сам написал, а нашёл в интернете да адаптировал для этого датчика, выкинув из неё всё лишнее):

Спойлер

Код:

/*
 * Name  : CRC-8
 * Poly  : 0x07    x^8 + x^2 + x^1 + 1
 * Init  : 0x00
 * Revert: false
 * XorOut: 0x00
 * Check : 0xF7 ("123456789")
 * MaxLen: 15 байт(127 бит) - обнаружение одинарных,
 *           двойных, тройных и всех нечётных ошибок
 */
unsigned char crc8(unsigned char *pcBlock, unsigned int len) {
#define poly 0x07 // порождающий многочлен
#define init 0x00 // начальное значение
    unsigned char crc = init;
    while (len--) { crc ^= *pcBlock++;
        for (unsigned int i = 0; i < 8; i++) crc = crc & 0x80 ? (crc << 1) ^ poly : crc << 1;
    }
    return crc;
}

Там, собственно, после выкидывания осталось всего 5 строчек, не считая пары дефайнов, но в алгоритмах CRC есть две фишки: это начальное значение CRC и значение порождающего многочлена. Для этого датчика начальное значение CRC должно быть равно нулю, а порождающий многочлен — 7. Где я это вычитал, уже не помню, а вот так прямо щас в ПДФе этих данных не нашёл. Может, просто подобрал их в своё время в ходе экспериментов. И не надо самому вычислять никаких сумм: надо лишь в вызывающей программе объявить массив подходящей длины (для измерения температуры достаточно 5 элементов, для изменения адреса может хватить и 4, но я сделал для себя 6 во избежание выхода за границы массива) да скормить подпрограмме CRC8 этот массив и его длину. Когда я измеряю температуру, то там всё делаю по книжке:

Спойлер

Код:

#define ADDR_TS       0x5A // Address for SMBus temperature sensor
#define size_of_cmd   1
#define size_of_data  3
    int short temp;             // температура
    uint8_t read_tr[1]={0x07}; // команда чтения температуры объекта
    uint8_t buf_crc[6]={ADDR_TS<<1, 0, (ADDR_TS<<1)+1, 0, 0, 0}, buf_t[3];
    smbus_res_t result;
            SMBus.write(ADDR_TS, read_tr, size_of_cmd, no_stop_bit);
            result = SMBus.read(ADDR_TS, buf_t, size_of_data, with_stop_bit);
            temp = ((buf_t[1] << 8) + buf_t[0]) / 5 - 2731;
            buf_crc[1] = read_tr[0];
            buf_crc[3] = buf_t[0];
            buf_crc[4] = buf_t[1];
            crc = crc8(buf_crc, 5);

Заметьте, что я читаю с шины SMBus в массив buf_t, а затем вручную переношу два байта в массив buf_crc. На ассемблере я бы сразу читал в buf_crc и не делал бы промежуточного массива. Но в С я слаб, поэтому мне проще сделать промежуточный массив. Если я правильно понял книжку, то для смены адреса надо сделать наоборот, сначала заполнить четырьмя нужными значениями массив buf_crc, затем вычислить CRC8, после чего записать этот пакет в датчик. То есть должно получиться что-то вроде этого:
Но я не проверял, поэтому гарантии дать не могу. И там ещё указано, что прежде чем писать что-то в EEPROM, надо сначала стереть старое значение, записав в эту ячейку ноль, так что эту процедуру надо сначала выполнить с нулём, потом подождать 5-10 мс, потом выполнить сию процедуру уже с нужным значением, снова подождать 5-10 мс, после чего уже можно будет считать записанное значение, чтобы убедиться, что оно действительно записалось.
Ну и я не привожу текстов библиотеки SMBus, поскольку у меня процессор не Атмега, так что они будут не очень полезны. Просто надо понимать, что обе функции (как Read, так и Write) посылают адрес, указанный первым аргументом, затем Write посылает, а Read принимает массив, указанный вторым аргументом, длина которого указана третьим аргументом. Четвёртым аргументом указано наличие или отсутствие заключительного стоп-бита. В принципе, функция записи заливает весь пакет в датчик на одном дыхании, так что её можно было бы заставить просто заливать массив buf_crc без использования промежуточного массива write_tr. Но изначально это была библиотека I2C, она была написана (не мной) именно так, и я не стал её сильно переделывать. Работает — и ладно!
Нет. Там циклическая сумма, её надо считать той подпрограммой CRC8. И если честно, то я пока не уверен, сколько байт надо записывать при смене адреса: один или два. Ведь в описалове про команду 0x2E сказано "LSByte only". Может статься, эта команда будет трёхбайтовой 5A2E5B, и тогда PEC будет 5D, пятая строчка незаспойлеренного кода будет лишней, а шестая превратится в buf_crc[3] = crc8(buf_crc, 3);, ну и в седьмой будет тройка вместо четвёрки. Но что-то я плохо понимаю смысл написанного в ПДФе на 18-й странице: для того, чтобы обеспечить доступ к любому устройству или назначить адресс слейву перед подключением его в систему, связь надо начать с нулевым адресом, за которым подать нулевой R/W бит. Когда мастер подаёт эту команду, MLX90614 всегда отвечает, игнорируя свою внутреннюю информацию. Может статься, что правильная команда будет начинаться с нулевого адреса 002E5B, и тогда PEC будет FE, но это всё надо проверять на реальном датчике.
Нет. При смене адреса на единицу CRC8 съедет на несколько единиц. Это не контрольная сумма.

Вы в серьез считаете, что следует СА датчика возвести в восьмую степень, сложить с квадратом адреса регистра и у меня получиться число меньше 255, чтобы я мог его отправить байтом PEC ? Быть может члены полинома это условная запись разрядности двоичных чисел? (Что более похоже на истину.) И следует брать для суммирования 2 младших разряда в случае Х2 и 1 в случае Х1? А может старшие? Или через 1? Я не знаю. Потому и спросил. Я на ассемблере не работаю. Что конкретно надо вводить в онлайн калькулятор не знаю. Уже возведенное, как Вы предлагаете в степень значение или он сам возведет. Если уж взялись помочь и знакомы с названным калькулятором, введите необходимые для смены СА значения на 0х5В к примеру, и сообщите искомый PEC. Это проще чем писать текст на страницу. Без обид.

Нет-нет, я не берусь помочь пассивным людям, которые ничего не хотят делать. Я помогаю только активным, которые ничего не умеют делать, но хотят научиться. Вот научить их могу. Когда-то ведь и я ничего не умел, но потом меня всему научили. Пришло время, когда уже я могу поделиться своими знаниями с тем, кому они нужны.

В мои годы поздно уже бинарную алгебру изучать. Для меня как для инженера возведение в степень это оно и есть. Откуда мне знать, что на бинарном языке - это инвертирование соответствующих разрядов? Мне надо температуру мерить двух вращающихся роликов и как то её стабилизировать.
Пробовали уже и затирать регистр с РЕС (DB) c DELAY(100), и с РЕС (5D) новый адрес - (5В) писать. Ничего не стирает и не записывает. Ни с 4 ни с 3 битовыми словами.
Вообщем мое мнение - необходимость проверки контрольной суммы для MLX 90614 разработчиком надумана. По факту без CRC его не настроить. На основе каких байтов его считать в мануале прямо не указано. Вывод - переключатель на линию.

Вот век живи - век учись. Более 40 лет в этом ремесле, а о существовании "бинарного языка" слышу впервые. Вот такой?

А уж такой способ возведения в степень - не к ночи будь сказан, кошмары будут сниться. А чтоб бошку не забивать лишними знаниями - в поисковике набрать "crc8 online calculator" - и пользоваться готовым.