А можно оценить точность этого косвенного метода измерения и дрифт со временем? Пользователь готов смириться с меньшей точностью измерений, если оговорена максимальная погрешность. Если макс. погрешность не оговорена, видеть вместо фактических показателей показатели "температуры на Марсе" нет никакого желания.
Да, но тот же СО2, который он как бы меряет, его же надо периодически калибровать, вынося на свежий воздух с 400 ppm, иначе показатели уезжают, и прибор показывает, что всё хорошо, когда всё уже не хорошо (и никакая статистика замеров без этого не поможет). BME680 работает на иных физических принципах, чем обычные датчики CO2 (от SenseAir, Winsen etc)?
Всегда интересовало насколько адекватную информацию показывают подобные датчики. С одним лишь специализированным датчиком СО2 куча маеты с постоянной калибровкой и пр., а тут 4-в-1 за небольшую сумму.
Далеко не все датчики (исключительно засчет исполнения) выдержат испытание кипящей водой и погружение в галлий.
Плюс, температура закипания воды сильно зависит от высоты, и даже на незначительных высотах ощутимо ниже 100°С. Съездить на Балтику и производить замеры там на уровне моря довольно проблематично.
Чтобы откалибровать какой-то датчик, скажем DS18B20, до точности 0,1°С, нужен датчик с еще большей точностью, чтобы фиксировать отклонения от фактической температуры рассматриваемого датчика в точках измерения, нет?
Ну вообще на вашем же графике ошибка DS18B20 составляет примерно +/-0.3°C, а не +/-0.5. Для измерения что температуры воздуха, что температуры электронных компонентов и других бытовых применений этого хватает за глаза.
На самом деле использование всяческих IDE - это признак Junior разработчиков.
Крайне спорное утверждение, как раз отдающее junior'скими холиварами "что лучше". Использовать IDE или использовать скрипты - вопрос лишь итоговой эффективности. Современные IDE включают в себя практически весь инструментарий для эффективной сборки без использования левых скриптов, а для совсем уж особых запросов позволяют писать дополнительные сборочные скрипты прямо в себе для разных этапов компиляции/сборки. Скрипты могут быть эффективны только в случае выбора неэффективной/неоптимальной для выбранной архитектуры и задачи IDE, в противном случае при равном фукнционале они всегда будут существенно проигрывать.
Пошаговая нужна редко, но посмотреть значение регистров и памяти - уже почаще.
Ну и самое главное: каковы плюсы распыляться по нескольким тулзам, в сравнении с комбайнами всё-в-одном? (AtmelStudio+AtmelICE, STM32CubeIDE+STLink etc).
Практически во всех доступных датчиках влажности итоговый результат измерения Rh% есть функция двух переменных: собственно, сырых данных с датчика влажности и данных текущей температуры (может быть, поэтому, by design, датчиков влажности без датчиков температуры не существует, по крайней мере я таких не знаю). Поэтому при разной температуре воздуха (и разной величине ошибки датчика температуры), величина ошибки влажности тоже будет разной (и это при одном и том же значении Rh%), и величину поправок поэтому нужно получать, строя не кривую по точкам, а строя поверхность по двумерному массиву температур и влажностей.
PS А почему за эталон взяли не SHT85, он вроде поточнее будет?
Развитие платформы, стандартных библиотек, среды разработки, сервисных функций, конфигураций общего назначения и отраслевых решений тесно связанно друг с другом, и по очевидным причинам. Есть фирма 1С. У нее есть определенный объем выручки от продаж и сопровождения. Часть которой она тратит на оплату труда ВСЕЙ своей команды разработчиков. Поскольку львиная доля ресурсов идет на поддержание конфигураций в актуальном состоянии в части соответствия законодательству, развитие других направлений (в т.ч. платформы) вынуждено идти по остаточному принципу.
Хех, результаты голосований по ссылке говорят сами за себя.
Зачем?
А можно оценить точность этого косвенного метода измерения и дрифт со временем? Пользователь готов смириться с меньшей точностью измерений, если оговорена максимальная погрешность. Если макс. погрешность не оговорена, видеть вместо фактических показателей показатели "температуры на Марсе" нет никакого желания.
Да, но тот же СО2, который он как бы меряет, его же надо периодически калибровать, вынося на свежий воздух с 400 ppm, иначе показатели уезжают, и прибор показывает, что всё хорошо, когда всё уже не хорошо (и никакая статистика замеров без этого не поможет). BME680 работает на иных физических принципах, чем обычные датчики CO2 (от SenseAir, Winsen etc)?
Всегда интересовало насколько адекватную информацию показывают подобные датчики. С одним лишь специализированным датчиком СО2 куча маеты с постоянной калибровкой и пр., а тут 4-в-1 за небольшую сумму.
Почему остановились на 10-й итерации, где 10-тысячная? (или дальше прогресс не пошел?)
Далеко не все датчики (исключительно засчет исполнения) выдержат испытание кипящей водой и погружение в галлий.
Плюс, температура закипания воды сильно зависит от высоты, и даже на незначительных высотах ощутимо ниже 100°С. Съездить на Балтику и производить замеры там на уровне моря довольно проблематично.
Чтобы откалибровать какой-то датчик, скажем DS18B20, до точности 0,1°С, нужен датчик с еще большей точностью, чтобы фиксировать отклонения от фактической температуры рассматриваемого датчика в точках измерения, нет?
Для такой точности в +/-0.1°С какова тогда должна быть точность (и модель) эталонного датчика?
Ну вообще на вашем же графике ошибка DS18B20 составляет примерно +/-0.3°C, а не +/-0.5. Для измерения что температуры воздуха, что температуры электронных компонентов и других бытовых применений этого хватает за глаза.
Какие, например? Только не надо пож-ста опять про DS18B20
Крайне спорное утверждение, как раз отдающее junior'скими холиварами "что лучше". Использовать IDE или использовать скрипты - вопрос лишь итоговой эффективности. Современные IDE включают в себя практически весь инструментарий для эффективной сборки без использования левых скриптов, а для совсем уж особых запросов позволяют писать дополнительные сборочные скрипты прямо в себе для разных этапов компиляции/сборки. Скрипты могут быть эффективны только в случае выбора неэффективной/неоптимальной для выбранной архитектуры и задачи IDE, в противном случае при равном фукнционале они всегда будут существенно проигрывать.
Пошаговая нужна редко, но посмотреть значение регистров и памяти - уже почаще.
Ну и самое главное: каковы плюсы распыляться по нескольким тулзам, в сравнении с комбайнами всё-в-одном? (AtmelStudio+AtmelICE, STM32CubeIDE+STLink etc).
Практически во всех доступных датчиках влажности итоговый результат измерения Rh% есть функция двух переменных: собственно, сырых данных с датчика влажности и данных текущей температуры (может быть, поэтому, by design, датчиков влажности без датчиков температуры не существует, по крайней мере я таких не знаю). Поэтому при разной температуре воздуха (и разной величине ошибки датчика температуры), величина ошибки влажности тоже будет разной (и это при одном и том же значении Rh%), и величину поправок поэтому нужно получать, строя не кривую по точкам, а строя поверхность по двумерному массиву температур и влажностей.
PS А почему за эталон взяли не SHT85, он вроде поточнее будет?
Хотите сказать, Eclipse-GUI отладчик менее эффективен, чем консольный? А код вы тоже в консоли пишете?
С 5В МК, работающим с 3.3В периферией в режиме открытого коллектора, такая эквилибристика с подтяжками просто пожжет периферию.
Не сдвинула, а сделала их шире, что не одно и то же
"Понял" не значит "принял". Лучше б запилили опрос, кому-то это вообще нужно?
Там около 5000mAh, обычное дело на сегодняшний день, просто сам телефон прост как три рубля, и кроме GSM-тракта там никакого потребления нет.
Развитие платформы, стандартных библиотек, среды разработки, сервисных функций, конфигураций общего назначения и отраслевых решений тесно связанно друг с другом, и по очевидным причинам. Есть фирма 1С. У нее есть определенный объем выручки от продаж и сопровождения. Часть которой она тратит на оплату труда ВСЕЙ своей команды разработчиков. Поскольку львиная доля ресурсов идет на поддержание конфигураций в актуальном состоянии в части соответствия законодательству, развитие других направлений (в т.ч. платформы) вынуждено идти по остаточному принципу.