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

enjoynering

Well-known member
Пять лет сенсоры 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

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

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

enjoynering

Well-known member
Мне 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

Well-known member
про "куку" и "ну типа младший байт и старший от разных значений" согласен. Бит готовности данных проверяю в библиотеке - если 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) говорит только о том, что пройдет не менее n.

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

pvvx

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

enjoynering

Well-known member
delay(n) говорит только о том, что пройдет не менее 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

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

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

pvvx

Активный участник сообщества
AHT15:
upload_2020-1-22_1-44-35.pngupload_2020-1-22_1-44-41.png
upload_2020-1-22_1-44-51.png
В режиме измерения потребление описано как: 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 сек вы этого никогда не заметите.
 
Сверху Снизу