=AK=

К вопросу о влиянии температуры. SHT45 в коробке с влажностью примерно 43%, влажность - зеленая линия. HTE301 в коробке с влажностью 43%, влажность - зеленая линия. Короткие всплески вверх - это когда коробку открывали и она "наглатывалась" наружного воздуха.

Сенсор ENS210 фирмы ScioSense. 1. В коробке с 23% влажности. 2. В коробке с 43% влажности. Черная линия - при переходе от 23% к 43%, зеленая - при переходе от 75% к 43%. Графики еще раз демонстрирует условность параметра "гистерезис", который для этого сенсора заявлен +-0.55% через 2 часа. Лучше бы аппроксимирующий полином приводили. От "гистерезиса" могла бы быть какая-то польза при сравнении датчиков разных производителей. Однако каждый определяет "гистерезис" по-своему, так что пользы от него ноль. 3. В коробке с 75% влажности. Через 18 часов показания выросли до 75.7%

Для иллюстрации, график влажности с логгера, отправленного в аккредитованную тестовую лабораторию на калибровку. К сожалению, перед отправкой я его неверно откалибровал на малой влажности, однако при 45% и при 75% он показал неплохой результат. Из графиков можно понять, что тестирующие не ограничились обычным профилем 45%-25%-45%-75%-45%, а погоняли логгер больше, чем обычно положено по регламенту. При 45% у него погрешность оказалась всего лишь порядка 0.6% RH. Надо только отдавать себе отчет, что намерянная лабораторией погрешность - это филькина грамота. Ведь они меряют при фиксированной температуре, а у всех интегральных датчиков показания заметно "плавают" от температуры, где-то на 0.5...1% RH. Подозреваю, что логгер гоняли больше положенного, пытаясь обнаружить у него так называемый "гистерезис", абсолютно липовый параметр, который торжественно прописан во всех даташитах и аппнотах. Но не обнаружили. А вот пример сенсора SHT35, тоже протестированного в аккредитованной тестовой лаборатории. Вместо 25% он через час выдавал 23.5%, вместо 75% - 75.9%, а вместо 45% - 48.6% или 49.3% в зависимости от того, менялась влажность от низкой к высокой или от высокой к низкой. Вот эта разность 49.3-48.6 = 0.7% RH и есть тот самый липовый "гистерезис". Ежу понятно, что если сенсор подержать в камере подольше, то никакого "гистерезиса" и в помине не будет. В любом случае, в районе 45% сенсор SHT35 врет больше, чем обещано Сенсирионом. По даташиту погрешность 2%, плюс 0.8% "гистерезис", в сумме максимум 2.8% RH. А в реальности он врал примерно на 4% RH. Наверное они или в Сенсирионе, или в аккредитованной лаборатории получили "неправильные результаты" из-за того что "не понимают как датчики влажности устроены". 😎 А тот, кто "понимает", тот способен даже у соли запах учуять. 😂

ДСмысл этого сертификата в том, что д Вопрос точности датчиков влажности очень скользский. Вот, к примеру, все те же два датчика SHT45, которые я переместил из коробки с влажностью 23% в коробку 43%. Температура в коробках стабильная с колебаниями 0.1С, атмосферное давление за сутки упало с 1022 до 1016 мбар. Вентилятор в коробке по моему недосмотру оказался выключен, поэтому все намного медленнее, чем должно было быть. "Загогулина" в начале графика возникла за счет того, что пока я перекладывал датчики из одной коробки в другую, они несколько секунд побыли в комнатном воздухе с влажностью 55% Казалось бы, датчик, показанный зеленой линией, - более точный? Не тут-то было. Аккредитованные лаборатории не держат аттестуемые устройства сутками в камерах с фиксированной влажностью. Oни их держат всего час, после этого снимают показания, пишут отчеты и выдают сертификаты. Через час "черный" датчик показывал 42.5%, а "зеленый" - 42%. Поэтому с точки зрения тестовой лаборатории у "черного" при такой влажности погрешность 0.5% RH, а у "зеленого" 1% RH. Хотя через сутки "зеленый" был раза в три точнее "черного". На сайте Сенсириона есть некий документ "Calibration Certification", общий для всех их датчиков влажности, который гласит: The above mentioned products are calibrated to meet the specifications according to the corresponding Sensirion data sheet. Each device is individually tested after its calibration. Sensirion uses transfer standards for the calibration. These transfer standards are themselves subject to a scheduled calibration procedure. The calibration of the reference itself used for the calibration of the transfer standards is performed by an ISO/IEC 17025 accredited laboratory. После чего перечисляются всякие регалии их тестовой лаборатории. Однако вменяемого описания что и как они в действительности тестировали нет нигде. Смысл этого документа состоит в том, что "джентльменам надо верить на слово, что их даташиты не врут", ибо на них где сядешь, там и слезешь. Пара баек про аккредитованные тестовые лаборатории, куда мы время от времени сдаем свои устройства (даталоггеры) на поверку. Лаборатории разные, но все они по каким-то причинам стирали логи. Долгое время мы не знали, что они проделывают с нашими устройствами - устройства возвращались "пустыми" и мы получали только бумажный результат. В какой-то момент мы добавили в логгеры секьюрити и стали отправлять в лаборатории залоченные логгеры, которые были нами заранее настроны на логгирование с определенным интервалом. Сразу же выяснилось, что одна из лабораторий не выдерживает сенсоры в камере даже один час, а держат всего по 20 минут при каждом значении влажности. За 20 минут у них у самих влажность в камере только-только успевает стабилизироваться. "А чо такова?", ведь в даташитах написано, что сенсор всего за несколко секунд устанавливается до 63% от конечного значения. С этими хмырями мы дело иметь перестали. Другая лаборатория честно держала по одному часу. Но только до тех пор, пока мы им не отправили на калибровку логгер с точным и быстрым сенсором. В конечном отчете у него во всех трех точках точность оказалась не хуже 0.6%. Вот только ждали мы этот отчет больше 3-х месяцев: они выжидали, пока память логгера не заполнится и новые логи не затрут старые, чтобы не было видно как его тестировали. Да, не ожидали мы такой подлянки, впредь будем отдавать на тестирование логгеры настроенные на одиночный лог, без перезаписи.

Sensirion много чего пишет для того, чтобы снять с себя ответственность. Я не собираюсь подавать на них в суд, поэтому все их отбрехивания не представляют для меня никакого интереса. Меня интересуют только технические аспекты, а вовсе не легальные. Это очень может быть, и это один из аспектов проблем, за которыми я наблюдаю. Вентиляторы сделаны из нейлона, а он очень даже неплохо всасывает влагу. Коробки сделаны из полипропилена, которыый влагу всасывает не так хорошо, но все же влияет. Решение состоит в том, что каждая коробка с солью работает только со своей конкретной солью. После выдержки примерно в неделю, и материал коробок, и материал вентиляторов по идее должны придти в равновесие с влажностью, задаваемой солью. К сожалению, этот документ не дает никаких намеков на то, почему "загрязнение" может вдруг случиться, что называется, "на ровном месте", когда никаких таких химикалиев, вроде ацетона, нигде нет и в помине. А уж как избавиться от "загрязнения" я, в общем-то, в курсе, в том числе и без встроенного нагревателя. Я не в курсе, откуда это "загрязнение" вдруг возникает.

Несомненно, слежу. Даже барометр купил, плюс отслеживаю показания по барометрическим логам от бюро метеорологии. Пришел к выводу, что в довольно широком диапазоне изменений атмосферного давления, в диапазоне примерно 1000-1025 мбар, показания SHT45 меняются примерно на 0.1%, от силы на 0.2%. Тому порукой приведенные выше графики, за это время атмосферное давление изменилось примерно на 20 мбар.

Производители датчиков ничего об этом не говорят ни в даташитах, ни в аппнотах. Если принять на веру сказанное вами, значит, они врут своим умолчанием на сей счет. Или вы врете. Фирмы, производящие датчики, предлагают свои тестовые системы на основе солей. И никто из них, насколько мне известно, в описаниях этих систем не упоминает ничего подобного тому, что вы сказали. Так что скорей всего врете вы. Конечно, возможно, что и вы врете, и производители: какие-то соли оказывают влияние, какие-то нет, но объективная информация об этом скрыта. Но вы, как за вами уже было замечено, свое высказывание не подкрепили ничем, налицо чистый голословный высер. Мое "понимание" или "непонимание" того, как работают датчики влажности, не оказывает никакого влияния на результаты, которые они выдают и которые я привожу на графиках. С тем успехом можете упрекать меня в том, что я молюсь "не тем богам". Ваши голословные инсинуации накак не объясняют тот факт, что при заявленном Сенсирионом для SHT45 времени установления 4 сек до 63% от конечного значения, время установления до 1% до конечного составляет вовсе не 20 сек, как следует из заявлений Сенсириона, а более получаса, что хорошо видно из приведенных выше графиков. В силу этого у меня есть твердые основания утверждать, что производители сенсоров врут, и, как следствие, вы тоже врете, защищая их.

Конечно, совершенства нет. Вопрос лишь в том, что значит слово "подходит". Большинству пользователей вполне "подходит" точность порядка 1...2% RH, которая в принципе вполне достигается современными емкостными датчиками. Меня лично сейчас более всего напрягает вопрос стабильности их показаний. Я наблюдал необъяснимый уход результатов на несколько процентов. Довольно трудно понять, что было тому причиной. Конечно, оптические датчики и более точны, и менее подвержены таким странностям. Но хотелось бы получше понимать свойства обычных интегральных датчиков влажности. К сожалению, даташиты и аппноты датчиков влажности в общем-то врут, причем, фундаментально врут.

Мировым лидером в системах измерении погоды считается Viasalla. Они датчики влажности делают сами, называются HUMICAP, но, насколько я вижу, отдельно свои датчики не продают. Судя по описанию, их датчики аналогичны датчикам TE/MEAS, Sensirion, E&E Elektronik, и т.д. Например, похожий на HUMCAP "голый" емкостной датчик фирмы TE называется HS1101LF. Современные емкостные датчики влажности как правило интегральные, с ними намного проще работать.

Собираюсь постить в эту тему данные, собранные с различных датчиков влажности. Для тех, кто захочет их проанализировать самостоятельно. Два датчика SHT45 в среде со стабильной влажностью примерно 23% RH при температуре 25С. Среда - это небольшая герметичная коробка, в ней кювета с влажной солью CH3CO2K, в коробке работает вентилятор. Датчики более-менее откалиброваны. График демонстрирует время прихода в установившееся значение после выдержки в среде с комнатной влажностью порядка 45% RH. Почему у одного датчика в установившемся режиме показания скачут на 0.1%, а у другого на 0.2% - честно говоря, понятия не имею. Уж такие датчики, наверное.

Берите любой доступный вам конденсатор класса Х2 (а лучше - Х1) на 275 VAC нужного номинала. Например, дешевые китайские посмотрите в LCSC

Именно это я и имел ввиду, говоря о том, что прочие узлы узнают о коллизии разве что по косвенным признакам. А в случае когда CRC остался неизменным - вообще не узнают. И не надо мне парить мозги мнимым "детерминизмом". Реальным доводом может быть "низкая вероятность", но желательно с цифрами, а не "на арапа".

Есть большая разница между "на практике убедиться" и "теоретически невозможно". Вам жизни не хватит, чтобы на практике убедиться, что стая обезьян, хаотически стучащая по клавишам пишущей машинки, способна или неспособна рано или поздно напечатать "Войну и мир".

А как борются с сумасшедшим узлом, который посылает Error Frame на все сообщения? Правильно ли я понял, что CAN полагается робастным за счет того, что пользователь отделен от реально происходящего на шине некой аппаратно реализованной прослойкой CAN? Она делает bit-stuffing и следит на нестыковками. Поэтому если пользователь и "сошел с ума" и посылает все биты доминантными, на шине не все биты не будут доминантнми, эта прослойка вставит рецессивный бит посля каждых 5 доминантных. Если есть второй узел, который не проиграл арбитраж, чем гарантируется наличие коллизий? Ведь может так совпасть, что второй узел тоже транслирует рецессивный уровень данных в тот момент, когда первый узел транслирует рецессивный бит по причине байт-стаффинга? Для меня неочевиден ответ на вопрос, можно ли одновременно передать два кадра с одинаковыми приоритетами и разными данными, но при этом коллизия не будет обнаружена никем кроме передающих узлов.

Если бы арбитраж происходил по всему кадру, узлы должны были бы ждать завершения передачи каждого кадра, чтобы определить, кто выигрывает арбитраж. Это увеличило бы задержки в сети, особенно в случаях, когда длина кадра велика. Все-таки чего-то я в CAN не понимаю. О каких "задержках" идет речь? Арбитраж ведь ведется в реальном времени. Определился победитель в начале кадра, в середине или в конце, это ни на что не влияет и никаких задержек не создает. Наоборот, если арбитраж идет только в начале и при равных приоритетах два узла портят друг другу данные, вот это создаст задержку - эту ошибку надо обработать и потратить время на две повторных передачи, плюс, вероятно, на две рандомные задержки, чтобы избежать повторной коллизии. Единственное разумное объяснение, какое я смог придуматъ, состоит в том, что при помощи коллизий на поле данных CAN дает знатъ каждому узлу, что у него естъ "коллега" с тем же приоритетом, который пытается вещать одновременно с ним. Побочным эффектом является то, что узлы, испортившие друг другу поля данных, знают об этом, а вот все остальные узлы - вообще говоря нет, только по косвенным признакам. И если так неудачно сложится, что результирующее сообщение окажется валидным CAN сообщением (назовем его "монстр"), то последствия могут быть плачевными. Это можно было бы сделать и другим способом. Например, вести арбитраж CSMA/CA на всем кадре, но сделать его "двухступенчатым". В начале кадра узлы, проигравшие арбитраж, затыкаются и молчат до самого конца кадра. А узлы, проигравшие арбитраж в оставшейся части кадра, помалкивают до самого последнего бита кадра (или до первого бит-интервала за пределами кадра), в котором они устанавливают доминантный уровень. Этот бит - "жалоба". Узел, выгравший арбитраж, обязан выставить рецессивный уровень в этом бите. Таким образом все узлы смогут узнать о "коллизии", но при этом самой коллизии не будет и передавать повторно ничего не требуется. Никаких "монстров" тоже не возникнет. Если узел передает одни доминантные уровни, его фрейм не будет испорчен, он ничего не узнает о коллизии. В случае реальных данных всегда есть вероятность, что один из узлов передаст свой фрейм неиспорченным и не узнает о коллизии. Соответственно, педалировать на некий "детерминизм" не приходится.