Comments 14
Наверно лучше вместо LM2576 использовать китайский модуль на MP2307, а если устройство большую часть времени спит то LD1117.
Для питания подойдет любой китайский stepdown модуль, притом достаточно 1A выдавать, MP2307 так же жирно по максимальному току как и использованный LM2576, оба на 3А. Просто была кучка LM2576 их и взял.
Про LD1117 в статье отметил:)
Для батарейного питания линейные преобразователи слишком дорого, если и использовать, то не с кроной, а с четырмя AA/AAA батарейками, например. Ну или преобразователь в корпусе TO220 с хорошим таким радиатором:)
Отдельно замечу, что вообще-то wifi решение — не сильно про батарейку, слишком большое потребление. Обычно канал связи на низкопотребляемых протоколах, LoRa, SigFox, BLE и прочих с копеечным потреблением.
Мотивация этого мини проекта — получить готовую «вещь» на очень популярном и просто программируемом(в том числе для желающих повторить) для использования в дальнейшем
описании IIoT инфраструкуры.
Про LD1117 в статье отметил:)
Но все, что понижает линейный преобразователь — он просто рассеивает в тепло. Пиковый ток esp8622 около 0.4A, это значит с линейным преобразователем (9-3.3)*0.4 = 2.28Вт в никуда. Еще и расплавится.
Для батарейного питания линейные преобразователи слишком дорого, если и использовать, то не с кроной, а с четырмя AA/AAA батарейками, например. Ну или преобразователь в корпусе TO220 с хорошим таким радиатором:)
Отдельно замечу, что вообще-то wifi решение — не сильно про батарейку, слишком большое потребление. Обычно канал связи на низкопотребляемых протоколах, LoRa, SigFox, BLE и прочих с копеечным потреблением.
Мотивация этого мини проекта — получить готовую «вещь» на очень популярном и просто программируемом(в том числе для желающих повторить) для использования в дальнейшем
описании IIoT инфраструкуры.
Про 1117 я написал в случае большого процента сна, например 300 секунд сна 10 секунд работы, собственное потребление недорогих ШИМ достаточно велико.
Также при небольшой разнице вход — выход может оказаться выгоднее линейный стабилизатор.
Также при небольшой разнице вход — выход может оказаться выгоднее линейный стабилизатор.
С китайскими модулями step-down надо быть осторожнее. Наткнулся тут недавно на то, что модули на MP2307 при отсутствии существенной нагрузки — сами по себе жрут почти 30-40 миллиампер. Для батарейного питания не подходят совершенно.
Интересно спасибо за статью…
Каким образом при помощи BPM можно помочь GPS, для навигации в здании (определить этаж).
По относительной разнице давления при перемещении объекта пытаться предугадывать этаж?
Каким образом при помощи BPM можно помочь GPS, для навигации в здании (определить этаж).
По относительной разнице давления при перемещении объекта пытаться предугадывать этаж?
Вот их листовка
Аппноутов к сожалению нет, но судя по настройкам барометра из документации, да, по разнице давления определять этаж.
Они позиционируются как дополнительный, «улучшающий» сенсор к мобильному устройству.
Что-то типа такого алгоритма:
— акселерометр показывает постоянное вертикальное ускорение и одновременно уменьшается давление — значит поднимаемся на следующий этаж.
— акселерометер показывает вертикальное направление, давление одинаковое но изменилась влажность — перешли в другую комнату.
Цитата из датащита на эту тему:
Аппноутов к сожалению нет, но судя по настройкам барометра из документации, да, по разнице давления определять этаж.
Они позиционируются как дополнительный, «улучшающий» сенсор к мобильному устройству.
Что-то типа такого алгоритма:
— акселерометр показывает постоянное вертикальное ускорение и одновременно уменьшается давление — значит поднимаемся на следующий этаж.
— акселерометер показывает вертикальное направление, давление одинаковое но изменилась влажность — перешли в другую комнату.
Цитата из датащита на эту тему:
3.5.3 Indoor navigation
Lowest possible altitude noise is needed. A very low bandwidth is preferred. Increased power
consumption is tolerated. Humidity is measured to help detect room changes. This setting is
suggested for the Android settings ‘SENSOR_DELAY_NORMAL’ and ‘SENSOR_DELAY_UI’.
Можно и по относительной разнице давления. Но вообще, множество способов измерить высоту здания с помощью барометра описано Нильсом Бором, например.
Хочу вставить свои пять копеек по поводу mqtt topics и предложенного варианта /device_location/device_name/sensor, дабы не запутать впервые изучающих данную тему.
Во-первых, первый слеш является лишним. Такое наименование может привести случайной путанице в дальнейшем. В данном случае первый уровень топика — ветка с пустым именем. Best practice — не использовать слеш впереди.
Во-вторых, сама иерархия топиков не является чем-то зафиксированы протоколом. Каждый волен выбирать нотацию, которая удобнее всего подходит для конкретного применения. Желательно заранее продумать дальнейшее использование, деление на крупные кластеры ближе к корню. Для упрощения опроса датчиков, необходимо стандартизировать глубину вложенности данных и именование оконечных ветвей для задания wildcard подписок вроде +/sensors/+/+/temp
Третье, чем короче названия, тем лучше. Передача данных с удалённых датчиков часто не бесплатна. Особенно, если их много.
Четвёртое, идеальной структуры топиков продержаться возможно, только если делать каждый самому и с нуля. Либо заточить себя в жёсткую кабалу vendor lock-in. Большинство устройств не конфигурируются, ибо это ведёт к их удорожанию и удорожанию их внедрения. В итоге, вместо идеального соснового бора, всегда будет смешанный лес. Решается простейших способом, который сразу делает систему намного более гибкой — внедрение оркестратора-маршрутизатора, который получает данные как есть и пересылает далее как надо. Тот-же node-red прекрасно справляется с этой задачей.
Ещё много чего можно добавить, как вспомню — напишу)
Во-первых, первый слеш является лишним. Такое наименование может привести случайной путанице в дальнейшем. В данном случае первый уровень топика — ветка с пустым именем. Best practice — не использовать слеш впереди.
Во-вторых, сама иерархия топиков не является чем-то зафиксированы протоколом. Каждый волен выбирать нотацию, которая удобнее всего подходит для конкретного применения. Желательно заранее продумать дальнейшее использование, деление на крупные кластеры ближе к корню. Для упрощения опроса датчиков, необходимо стандартизировать глубину вложенности данных и именование оконечных ветвей для задания wildcard подписок вроде +/sensors/+/+/temp
Третье, чем короче названия, тем лучше. Передача данных с удалённых датчиков часто не бесплатна. Особенно, если их много.
Четвёртое, идеальной структуры топиков продержаться возможно, только если делать каждый самому и с нуля. Либо заточить себя в жёсткую кабалу vendor lock-in. Большинство устройств не конфигурируются, ибо это ведёт к их удорожанию и удорожанию их внедрения. В итоге, вместо идеального соснового бора, всегда будет смешанный лес. Решается простейших способом, который сразу делает систему намного более гибкой — внедрение оркестратора-маршрутизатора, который получает данные как есть и пересылает далее как надо. Тот-же node-red прекрасно справляется с этой задачей.
Ещё много чего можно добавить, как вспомню — напишу)
Спасибо за дельный комментарий: ) Мы подумали, что было бы интересно собрать всех, кто занимается темой — сделали группу в телеграме. Если интересно, рады будем пообщаться: t.me/justiothings
Спасибо большое за интересный материал! Совсем недавно начал заниматься данной тематикой и такой подарок!
я очень люблю тематику «интернета вещей». Но вот тут в статье я увидел термин «IIoT — индустриальный интернет вещей.» и сразу вспомнил фильм «Крепкий орешек 4», в котором, в эру кнопочных телефонов умудрялись по сюжету перенаправлять электроэнергию в определенный узел системы. И так приятно становится, что рано или поздно фантазии авторов воплощаются в жизнь.
Я не профи в схемах, но в статье написано
GPIO02 и GPIO15 используются как SDA/SDL линии шины I2Cа на схеме вижу GPIO15 подключён к «земле». И нет SDL на входах JP*.
Sign up to leave a comment.
Как построить IIoT архитектуру своими руками. Часть 2: «Вещи»