Делюсь опытом Датчик температуры и влажности AHT10/AHT15

[enjoynering]

Пять лет сенсоры HTU21D/SHT21/Si7021 были королями Arduino среди бюджетных термометров/гирометров, но всему приходит конец. Китайцам удалось сделать не хуже и на $1 дешевле.

Сенсор AHT10 общается по I2C шине, имеет два адреса и заводскую калибровку. Если верить тестам от Oleksandr Liutyi новый король даже немножко выигрывает по кучности результатов.

TTX сенсора AHT10 и AHT15 следующие:

- Напряжение питания: 1.8 В .. 3.6 В
- Диапазон измерения температуры: -40°C .. + 80°C
- Разрешающая способность по температуре: 0.01°C
- Точность измерения температуры: ± 0,3°C
- Диапазон измерения относительной влажности: 0% .. 100%
- Разрешающая способность по влажности: 0.024%
- Точность измерения относительной влажности: ± 2%
- Скорость шины I²C: 0Гц - 400КГц
- Рекомендуемая частота опроса: 8 сек .. 30 сек

Длительное воздействие на сенсор в течение 60 часов при влажности > 80% может привести к временному дрейфу относительной влажности на + 3%. Датчик медленно вернется к паспортной точности ± 2 при нормальных условиях эксплуатации.

Официального datasheet на английском нет. В кустарном переводе куча неясностей. Но тем не менее мне удалось кое-что разобрать и написать библиотеку.

Как всегда забирать тут.

 

[pvvx]

Пять лет сенсоры HTU21D/SHT21/Si7021 были королями Arduino среди бюджетных термометров/гирометров, но всему приходит конец. Китайцам удалось сделать не хуже и на $1 дешевле.

SHT85 так и остался, но снят с производства.
AHT10 и AHT15 и близко не подошли к нему.

Официального datasheet на английском нет. В кустарном переводе куча неясностей. Но тем не менее мне удалось кое-что разобрать и написать библиотеку.

Каково время преобразования у данных датчиков?
Th - время от запроса влажности до получения результата и Tt - время от запроса температуры до получения результата. Или если в них по другому, то сколько точек в сек?

 

[enjoynering]

По datasheet время преобразования для t и rh (одновременно измеряет оба) - 75 millisecond

Еще есть какой-то мистический режим cyc (я предполагаю что это cycle - continuous measurement), но информации по нему нет.

 

[enjoynering]

Мне HTU21D больше нравился чем ваш SHT85. Теперь мой фаворит AHT10. Цена за плату с датчиком, преобразователеем уровня 5-3.3 и LDO-3.3 всего $1.5

 

[pvvx]

Мне HTU21D больше нравился чем ваш SHT85. Теперь мой фаворит AHT10. Цена за плату с датчиком, преобразователеем уровня 5-3.3 и LDO-3.3 всего $1.5

А у нас больше нет SHT85..87. Перешли на другие, поновее...
----
Китайская дока на AHT15 всё правильно описывает:

Примечание: Время, необходимое для обработки замера, после выдачи хостом команды измерения (0xAC), более чем 75 мс.
Задержка повторного чтения преобразованных данных определяется битом 7 регистра “состояния”.
Если бит 7 регистра “состояния” равен “0” - данные регистров содержат правильное значения.
Если бит 7 регистра “состояния” равен “1” - датчик находится в состоянии занятости.

 

[pvvx]

Еще есть какой-то мистический режим cyc (я предполагаю что это cycle - continuous measurement), но информации по нему нет.

Скорее всего по команде 0xAC он и читает подряд. Когда наступает новый цикл, а вы в этот момент ещё читаете его данные (т.к. вы не можете остановить WiFi), то показания куку. Ну типа младший байт и старший от разных значений.
Для Arduino это не критично - там всё так...

 

[enjoynering]

про "куку" и "ну типа младший байт и старший от разных значений" согласен. Бит готовности данных проверяю в библиотеке - если busy жду 75 milliseconds

if (getBusyBit() != 0x00) delay(AHT10_MEASURMENT_DELAY); //measurement delay

там есть еще два режима (в обще-то 3 но не суть): norm (я предполагаю что это normal - one measurement & power down) и cyc (я предполагаю что это cycle - continuous measurement). Но о них информации нет даже в китайской версии datasheet

 

[pvvx]

Перепутал, SHT7x сняты, SHT85 есть, но у них ноги не гибкие и не вставляются в контакты герметичного разъема...

 

[pvvx]

про "куку" и "ну типа младший байт и старший от разных значений" согласен. Бит готовности данных проверяю в библиотеке - если busy жду 75 milliseconds

if (getBusyBit() != 0x00) delay(AHT10_MEASURMENT_DELAY); //measurement delay

Угу, запрещаете все прерывания, даете команду старта и полингом бита состояния в более 75 мс читаете... Потом опять... Иначе как китайский датчик читать? Да и когда WiFi работать будет?
delay говорит только о том, что пройдет не менее n.

там есть еще два режима (в обще-то 3 но не суть): norm (я предполагаю что это normal - one measurement & power down) и cyc (я предполагаю что это cycle - continuous measurement). Но о них информации нет даже в китайской версии datasheet

У меня живых пока нет. Ещё их надо посмотреть на помеху. Может вообще мрут от чиха по проводкам к ним. SHTxx - сбиваются, и без контрольных сумм и прочего не стоит даже...

 

[pvvx]

Так же SHT на производстве мрут по черному... Возможно их статика в потоке убивахает или слабый поток газа (чаше простой сухой воздух) грызет, а может колебания давления и у них кристалл отваливается... фиг знает. Их постоянно меняют. Но другие ещё хуже...

 

[enjoynering]

delay говорит только о том, что пройдет не менее n.

да. а что в этом крамольного? даю команду на измерение 0xAC. проверяю 7 бит. если занят жду 75мсек (время, необходимое для обработки замера). 75мсек прошли, теперь данные точно готовы. читаем и выводим.

 

[pvvx]

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

да. а что в этом крамольного? даю команду на измерение 0xAC. проверяю 7 бит. если занят жду 75мсек (время, необходимое для обработки замера). 75мсек прошли, теперь данные точно готовы. читаем и выводим.

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

Уж что, что а китайщину надо проверять. Та же INA219 имеет такую багу в нескольких режимах - отдает разные байты при чтении двух регистров значения тока... Сбоит внутренняя защелка... TI промахнулись

 

[pvvx]

Смысл сей байки - у I2c устройства за время от старт (+ адрес) до стоп значения регистров для чтения не должны меняться. Новые значения должны быть зафиксированы или помещены в регистры чтения когда i2c свободна. Обычная атомарность.

По этому рассматривать такие статьи как Test i2c humidity sensors - Arduino - WIKI ...

 

[pvvx]

Китайская дока на AHT15 ещё гласит о том, что его незя часто опрашивать - он нагревается и типа врет.
В общем надо брать партию и проверять...

 

[enjoynering]

Они все врут. Я бы даже сказал AHT10 врет
меньше чем HTU21D/SHT21/Si7021. HTU21D у меня через 5 минут уже на 0.5С завышает. С AHT10 такого нет. Опрашиваю раз в 10сек.

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

Да может быть такое. Успокаиваю себя что я работаю только в normal - one measurement . Измерили один раз после получения команды 0xAC, положил в регистр и заснул. Я после 75мсек прочёл из регистра.

 

[pvvx]

AHT15:


В режиме измерения потребление описано как: 0.07 мВт при 3.3В.
Это 21 мкА. (0.00007Вт/3.3В = 0.000021A)
Это при условии по сноске 5: Минимальный и максимальный ток источника питания VDD = 3,3 В и Т < +60 ℃. В среднем один раз каждые две секунды при измерении значений.
Кто укажет верный ток при замере?

Необходимо обследование на применимость с BLE.
(среднее максимальное потребление BLE маяка около 3..5 мкА)

 

[pvvx]

С SHT85 всё понятно:

Supply current IDD:
Idle state (single shot mode) T= 25°C - 0.2..12.0 µA (3.3..5.5V)
Idle state (single shot mode) T= 125°C - max 6.0 µA (5.5V)
Idle state (periodic data acquisition mode) - 45 µA (3.3V)
mode Measurement – 600..1500 µA (3.3..5.5V)
Measurement duration 2.5..15.5 ms

 

[pvvx]

Гадание без чипа AHT15 по китайской доке ведет к этому:

1. Описан период в 2 сек (на один замер)
2. Замер длится от 75 мс.
3. Ток сна возьмем 80 нА.

Из 75 мс от 2000 мс – это 0.0375 от единицы времени идет на замер. Остальное время 80 нА - не будем учитывать. В итого 21 мкА надо поделить на 0.0375.
0.000021A/0.00375=0.0056A.

Т.е. что скрывают китайцы:

Ток при измерении 5.6 мА. (75 мс)

Перепроверьте.... А то для BLE уже не годен.

 

[pvvx]

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

 

[pvvx]

Да может быть такое. Успокаиваю себя что я работаю только в normal - one measurement . Измерили один раз после получения команды 0xAC, положил в регистр и заснул. Я после 75мсек прочёл из регистра.

На счет два байта на 16 бит и Arduino.

Пусть у вас температура в 16 бит (можно и меньше, во всех датчиках I2C обычно активны старшие биты (сдвигают значение к старшим), даже если значение 10 битное).
Шкала ширпотреба в этих старших 8 битах пусть в 128 градусов. Т.е. при 8-ми битах 0.5C на бит.
Ну считались у вас в Arduino старшие 8 бит от одного замера, а младшие от другого. И что – это максимальный прыжок/отклонение на 0.25С.

При вашем опросе раз в 10 сек вы этого никогда не заметите.