Comments 49
1. C# != C.
2. Если сделаете синхронизацию устройств, то не нужно будет ждать 65 секунд во время приема. Достаточно сделать период отправки сигнала датчиком более-менее фиксированный, а на базе запоминать время приема предыдущего пакета и включать приемник как раз к моменту следущего пакета. Это здорово сэкономит энергию.
2. Если сделаете синхронизацию устройств, то не нужно будет ждать 65 секунд во время приема. Достаточно сделать период отправки сигнала датчиком более-менее фиксированный, а на базе запоминать время приема предыдущего пакета и включать приемник как раз к моменту следущего пакета. Это здорово сэкономит энергию.
Спасибо!
Но для синхронизации надо ввести в оба узла часы, которые будут потреблять постоянно. Еще не факт, что общее потребление уменьшится. Надо считать.
Но для синхронизации надо ввести в оба узла часы, которые будут потреблять постоянно. Еще не факт, что общее потребление уменьшится. Надо считать.
Не надо никакие часы. Нужна просто общая виртуальная шкала времени, которую станция создаст для датчиков.
В своё первое включение станция ожидает данных от датчика и держит приёмник включенным. Первый корректный пакет данных синхронизирует обмен и приёмник отключается. Затем станция включает приёмник через 60 секунд на 10 секунд — открывается «окно приёма». Понятное дело, что кварцевые генераторы на станции и датчике тикают по разному и время будет разбегаться, поэтому каждый принятый пакет должен калибровать внутренний счётчик таймаута приёма. Если станция не получила подряд три пакета — нужна полная ресинхронизация (аналог первого включения).
Однако всё усложняется, если датчиков несколько и они могут быть включены в совершенно произвольное время — станции придётся дожидаться первой посылки от каждого датчика и каждому выделять персональное «окно», за которым и следить. Понятно, что это чисто алгоритмическая нагрузка, которая тем не менее энергопотребление может тоже снизить, но тут уже зависит от количества датчиков и порядка их включения. Хотя, конечно, это не очень красиво, когда время жизни устройства зависит от того в какой последовательности я почесал за ухом и включил тот или иной датчик) Эти проблемы просто решаются введением в систему двунаправленного обмена данными станции с датчиками (введение просто часов не поможет, т.к. всё равно возникнет вопрос их синхронизации), но это повышает сложность и стоимость самих датчиков.
В своё первое включение станция ожидает данных от датчика и держит приёмник включенным. Первый корректный пакет данных синхронизирует обмен и приёмник отключается. Затем станция включает приёмник через 60 секунд на 10 секунд — открывается «окно приёма». Понятное дело, что кварцевые генераторы на станции и датчике тикают по разному и время будет разбегаться, поэтому каждый принятый пакет должен калибровать внутренний счётчик таймаута приёма. Если станция не получила подряд три пакета — нужна полная ресинхронизация (аналог первого включения).
Однако всё усложняется, если датчиков несколько и они могут быть включены в совершенно произвольное время — станции придётся дожидаться первой посылки от каждого датчика и каждому выделять персональное «окно», за которым и следить. Понятно, что это чисто алгоритмическая нагрузка, которая тем не менее энергопотребление может тоже снизить, но тут уже зависит от количества датчиков и порядка их включения. Хотя, конечно, это не очень красиво, когда время жизни устройства зависит от того в какой последовательности я почесал за ухом и включил тот или иной датчик) Эти проблемы просто решаются введением в систему двунаправленного обмена данными станции с датчиками (введение просто часов не поможет, т.к. всё равно возникнет вопрос их синхронизации), но это повышает сложность и стоимость самих датчиков.
Не надо никакие часы. Нужна просто общая виртуальная шкала времени, которую станция создаст для датчиков.
Свежий, неожиданный для меня подход! Обязательно займусь им, не откладывая на будущее.
Возможно, он присутствует в технологии iT+? Описание технологии мне не удалось найти, но производители ее рекламируют.
Я просто предложил решение, которое в голову пришло. Вам же как таковое абсолютное время не нужно — можно и относительным, ни к чему не привязанным обойтись. Решение простое, изменений в аппаратной части не требует — надо только накодить. Вряд ли я изобрёл что-то новое)
Надо заметить, что синхронизировать моменты приёмо-передачи можно по источнику из вне. Это может быть время GPS (просто опрос модуля GPS), GSM (запрос времени AT+ командами от модуля GSM модема), WiFi (модули на базе ESP, который сам бы подключался к сети, внутри крутился бы опрос по NTP какого-нибудь stratum сервера + ответы на запросы от атмеги) или вообще по радиосигналам точного времени (но не везде они «долетают»). Конечно, всё это будет жрать энергию, но тут зависит от концепции — все эти «обвески» могут включаться, например, только раз в сутки для точной синхронизации. При этом вы получите очень точное время. Окно приемо-передачи можно реально сузить до полсекунды. Однако, с моей точки зрения, если уж заниматься чем-то своими руками и ради хобби, то гораздо интереснее построить именно автономную систему, которая бы минимально зависела от внешних условий. В принципе, сама станция может периодически излучать синхросигнал, по которому будут синхронизироваться датчики. Причём можно его хоть как-то закодировать, чтобы помехоустойчивость поднять.
Надо заметить, что синхронизировать моменты приёмо-передачи можно по источнику из вне. Это может быть время GPS (просто опрос модуля GPS), GSM (запрос времени AT+ командами от модуля GSM модема), WiFi (модули на базе ESP, который сам бы подключался к сети, внутри крутился бы опрос по NTP какого-нибудь stratum сервера + ответы на запросы от атмеги) или вообще по радиосигналам точного времени (но не везде они «долетают»). Конечно, всё это будет жрать энергию, но тут зависит от концепции — все эти «обвески» могут включаться, например, только раз в сутки для точной синхронизации. При этом вы получите очень точное время. Окно приемо-передачи можно реально сузить до полсекунды. Однако, с моей точки зрения, если уж заниматься чем-то своими руками и ради хобби, то гораздо интереснее построить именно автономную систему, которая бы минимально зависела от внешних условий. В принципе, сама станция может периодически излучать синхросигнал, по которому будут синхронизироваться датчики. Причём можно его хоть как-то закодировать, чтобы помехоустойчивость поднять.
Попробуйте вот так отключать нагрузку habr.com/ru/post/386735
Модуль TIDA-00484 TI Design — фантастика! Обязательно посмотрю этот модуль.
Там фокус в TPL5111 таймере и выключателе нагрузки TPS22860. Они сами потребляют микроскопический ток и с фиксированной частотой включают прожорливое устройство для передачи данных, а потом отключают.
Там фокус в TPL5111 таймере и выключателе нагрузки TPS22860. Они сами потребляют микроскопический ток и с фиксированной частотой включают прожорливое устройство для передачи данных, а потом отключают.
Спасибо за уточнения! Но, собственно, неважно что вводит модули в режим сна: таймер контроллера или внешний таймер. К тому же многие модули управляются по нескольким проводам (протокол SPI). Справится с их включением/выключением выключатель нагрузки TPS22860?
200 mA Maximum Continuous Switch Current
В копилку идей:
Вотериус: Передача показаний воды на телефон по Wi-Fi (4 года от батареек) — 3 батарейки АА
Метеостанция на Arduino от А до Я. Часть 4. Заоконный датчик — используется солнечная батарея.
Схема питания от батарей с повышающим стабилизатором NCP1400
В копилку идей:
Вотериус: Передача показаний воды на телефон по Wi-Fi (4 года от батареек) — 3 батарейки АА
Метеостанция на Arduino от А до Я. Часть 4. Заоконный датчик — используется солнечная батарея.
Схема питания от батарей с повышающим стабилизатором NCP1400
Такое разительное отличие в операционном потреблении объясняется, на мой взгляд, тем, что контроллеры в любительских схемах запрограммированы на языке Arduino IDE
Дело не в Arduino, а в опыте и квалификации проектировщика. В Arduino никто не мешает в критических местах использовать низкоуровневый код, программирование регистров и т. д. А также никто не мешает использовать здравый смысл и смекалку для минимизации потребления датчика.
Например, на модифицированной Pro Mini и nRF24L01 прекрасно делаются датчики со временем жизни от 1 года до 10 лет от одного комплекта батареек, в зависимости от типа датчика и режима его работы.
Анекдот на эту тему из жизни. Во время беседы с представителем «Стрижа», я задал ему вопрос: «Скажите, а как вам удалось добиться времени работы датчика 10 лет?». Ответ: «А наши датчики выходят на связь 1 раз в сутки». :)
В Arduino никто не мешает в критических местах использовать низкоуровневый код, программирование регистров и т. д.
Это полумеры и шараханье из одной крайности в другую. Хотя, не спорю — вторая крайность требует соответствующей квалификации. Код на языке С — мне кажется оптимальным решением.
… на модифицированной Pro Mini и nRF24L01 прекрасно делаются датчики со временем жизни от 1 года до 10 лет от одного комплекта батареек, в зависимости от типа датчика и режима его работы.
Сначала надо победить nRF24L01. Посмотрите как мучаются люди с nRF24L01 — 114 страниц форума за несколько лет! Я тоже возился с этим радиомодулем. Возможно, в будущем дополню эту статью.
Люди может и мучаются, но если понимать, что делаешь, то nRF24L01 работает как часы. Вот прямо сейчас делаю скриншот одного из своих работающих проектов.
Это пример работы беспроводного датчика расхода воды на Pro Mini и nRF24L01. Два канала, холодная и горячая вода, период отсылки показаний (актуализации) в системе (AMS) 5 минут.
Расчётное время работы датчика в динамическом режиме (период 5 минут) — 2 года, в тарификационном режиме (период 1 день) — 6+ лет.
Всё сделано на Wiring (нативом языке Ардуино) в Arduino IDE.
Это пример работы беспроводного датчика расхода воды на Pro Mini и nRF24L01. Два канала, холодная и горячая вода, период отсылки показаний (актуализации) в системе (AMS) 5 минут.
Расчётное время работы датчика в динамическом режиме (период 5 минут) — 2 года, в тарификационном режиме (период 1 день) — 6+ лет.
Всё сделано на Wiring (нативом языке Ардуино) в Arduino IDE.
Где можно посмотреть ваш проект? Дополню хотя бы сравнительные таблицы.
Публичные версии системы, включая (работающие) примеры nFR24 датчиков здесь:
https://hi-lab.ru/arduino-mega-server/details/download
Частные проекты и разработка здесь:
https://hi-lab.ru/arduino-mega-server/ams-pro
https://hi-lab.ru/arduino-mega-server/details/download
Частные проекты и разработка здесь:
https://hi-lab.ru/arduino-mega-server/ams-pro
UFO just landed and posted this here
мучаются птому, что изобретают велосипед. Я использую либу MySensors и получаю удовольствие. Сейчас правда перешел на nrf52
UFO just landed and posted this here
Давно-давно повторял(не моя придумка) проджект температурного датчика на MSP430 в качестве передатчика был контур на 200Кгц ударно возбуждаемый с ножки микроконтролера — никаких радиомодулей ;). Приёмник такой же контур + усилитель и на компаратор встроенный в МК. Дальность была около 20..25 метров на одной не новой солевой батарейке датчик продержался больше года, потом механически был повреждён сосулькой…
Такое разительное отличие в операционном потреблении объясняется, на мой взгляд, тем, что контроллеры в любительских схемах запрограммированы на языке Arduino IDE
Вот не нужно валить все с больной головы на здоровую!
Моя "ардуинка"(голый микроконтроллер) от двух батареек потребляет 0.5 мА в активном режиме(отрабатывая скетч из Arduino IDE), и знаете почему?
Она работает на 1МГц!
Удивляет то, что коль уж зацепились с фьюзами, не перешли хотя-бы на 8МГц (внутренний генератор)
А впрочем, не удивляет — сам столкнулся со следующей вещью — многие библиотеки заточены именно под частоту Атмеги 16МГц!
Пример — библиотека того-же DHT11/DHT22 — прекрасно работает на быстрой версии Arduino,
на версии Pro Mini 8Mhz 3.3В приходится править саму библиотеку, и дело не в напряжении — проверял, но даже с правками — работа нестабильна.
AM2320 — аналогичная картина.
А вообще автор-молодец!
UFO just landed and posted this here
Вы хотите сказать, что для микроконтроллеров есть библиотеки, одинаково работающие и на Atmega328, и на STM32, и на ESP8266???
Вот хотя-бы для DHT22
UFO just landed and posted this here
Наверное, есть библиотеки, пихающие данные в регистры напрямую, но не умеющие в F_CPU.
рамках одной модели микроконтроллера не способны нормально работать.
да как бы:
Atmega328, и на STM32, и на ESP8266
все разные мк, с абсолютно разной архитектурой и ядрами.
все разные мк, с абсолютно разной архитектурой и ядрами.
Как минимум на Atmega328 и на ESP8266 ардуиновский код вполне работает. Так что ардуиновские либы могут работать на разных архитектурах, если под ту архитектуру есть ардуиновское ядро. П — платформонезависимость, ага ;)
Как минимум на Atmega328 и на ESP8266 ардуиновский код вполне работает.
ага. а как реализовано?
ifdef esp8266
//шмат кода для есп
...
ifdef atmega
//шмат кода для атмеги
...
Так что ардуиновские либы могут работать на разных архитектурах, если под ту архитектуру есть ардуиновское ядро.
Адуриновская обертка единственное что может организовать универсально — программный ногодрыг с уартом. Остальная периферия esp8266/32 фактически не задействуется, собственно понятно почему, иначе универсальности не будет.
П — платформонезависимость, ага ;)
Как бы абсолютно не нужная вещь получатся не находите? Уж ногами подрыгать по таймеру / байты по уарту послать это надо страниц 40-20 любого datasheet-а осилить (заодно узнаете архитектуру). Ну или открыть пример из sdk аля gpio / hello world / uart, там и на страницу не наберется.
а как реализовано?
ifdef esp8266
//шмат кода для есп
…
ifdef atmega
//шмат кода для атмеги
…
Если библиотеку писали правильные программисты — то да. Разница в архитектуре будет закодирована на #ifdef'ах, а интерфейсная часть будет одинаковая для любой поддерживаемой платформы.
Адуриновская обертка единственное что может организовать универсально — программный ногодрыг с уартом. Остальная периферия esp8266/32 фактически не задействуется, собственно понятно почему, иначе универсальности не будет.
Дисплей 1602 по I2C подключается одинаково что к ардуине что к 8266. Никакая периферия вроде не страдает ;)
Дисплей 1602 по I2C подключается одинаково что к ардуине что к 8266.
Учитывая что у 8266 i2c софтварный то разницы особо нет. Подцепите sd-карточку, или spi-дисплей. Чую на адурине что для 8266 что для avr все через digitalread/write написано.
Никакая периферия вроде не страдает ;)
А чего ей страдать? Речь о том что она не используется :)
П — переносимость. О — оптимальность. П != О.
В ардуиновском ядре для 8266 своя реализация SPI, софтовая, да. А для тех контроллеров, что умеют поддержку SPI — аппаратная. SPI.h внутри разные, а интерфейсы одинаковые.
Учитывая что у 8266 i2c софтварный то разницы особо нет.
В ардуиновском ядре для 8266 своя реализация SPI, софтовая, да. А для тех контроллеров, что умеют поддержку SPI — аппаратная. SPI.h внутри разные, а интерфейсы одинаковые.
П — переносимость. О — оптимальность. П != О.
Ну собственно об этом и речь если надо уже не просто мигать лампочкой а делать что то серьезное где требуется Оптимальность то адурина с ее П нафиг не сплющилась.
В ардуиновском ядре для 8266 своя реализация SPI, софтовая, да. А для тех контроллеров, что умеют поддержку SPI — аппаратная.
У esp8266 есть два аппаратных контроллера spi, а программная реализация spi для адурины — софтовая. Собственно для esp32 где аппаратных контроллеров spi уже три (вобще 4 но юзить можно три) — аналогичная ситуация. Как то это неправильно, особенно если учитывать то что вектор развития современных микроконтроллеров это именно обогачивание периферии (таймеры, шины, дма, итд) и разгрузка программной части от софтварного ногодрыга.
поставил (+) «за старание». но честно говоря, в конце 2019 года хотелось бы видеть какие-то прорывные статьи, а не очередную погодную станцию на античном DHT22
поставил (+) «за старание». но честно говоря, в конце 2019 года хотелось бы видеть какие-то прорывные статьи, а не очередную погодную станцию на античном DHT22
У каждого свое понимание прорыва. В общем-то, в избитой теме метеостанции я не нашел в Инете решений с питанием базы метеостанции от батареек. Как правило, речь идет о аккумуляторах, солнечных батареях и т.п.
Осознаю — мое решение не идеальное, но с чего-то надо начинать.
А что касается DHT22, то это техническая работа — заменить один датчик на другой.
Успехов!
те «прорыв» — использование батареек? Разочарую, это не прорыв. Большинство ПС как раз сделано на батарейках, тк у них низкий саморазряд.
328p далеко не лидер по энергоэффективности, и опять же, странно пользоваться им в 2019 году
328p далеко не лидер по энергоэффективности, и опять же, странно пользоваться им в 2019 году
Большинство ПС как раз сделано на батарейках, тк у них низкий саморазряд.
Относительно низкого саморазряда батареек — в этом не надо никого переубеждать. По поводу большинства — хотелось бы хоть один пример, чтобы дополнить сравнительную таблицу приемного узла в статье конкретными результатами из других проектов. Повторюсь, мне таких примеров найти не удалось. Возможно не там искал.
328p далеко не лидер по энергоэффективности, и опять же, странно пользоваться им в 2019 году
Учту на будущее.
А почему не использовали прерывание — wake on radio, встроенное в чип? Как только SX1278 словил сигнал, он выставляет высокий уровень на DIO4. Atmega328 просыпается делает дела и засыпает до следующего прерывания.
If a Preamble signal is detected, the Sequencer is switched off. The PreambleDetect signal can be mapped to DIO4, in
order to request the user's attention. The user can then take appropriate action.
А почему не использовали прерывание — wake on radio, встроенное в чип? Как только SX1278 словил сигнал, он выставляет высокий уровень на DIO4. Atmega328 просыпается делает дела и засыпает до следующего прерывания.
Да, но приемник LoRa при этом должен быть все время включен. Потребление работающего приемника вряд ли ниже потребления сторожевого таймера контроллера, поэтому я не смотрел в сторону прерывания. Возможно ошибался.
Если батарейки в комнате, сам датчик снаружи, и между ними провод, непонятно, зачем в этой схеме ещё и радио ?
Вставлю свои 5 копеек, т.к. делал аналогичное решение на esp8266-esp01, которое уже несколько лет работает. Только на улицу у меня «пошел» dht-22.
Так вот. Зимой датчик замерзает, его едят птицы, он нагревается на солнце, нагревается от стены дома. Чтобы этого не происходило он был погружен в отрезанную горловину пластиковой бутылки, закутанную в фольгу. Кроме того, из-за длины питающих датчик проводов(более метра), он ловит помехи извне, а также на показания влияет сопротивление длины проводов. Немного помогла скрутка проводов в косичку.
Так вот. Зимой датчик замерзает, его едят птицы, он нагревается на солнце, нагревается от стены дома. Чтобы этого не происходило он был погружен в отрезанную горловину пластиковой бутылки, закутанную в фольгу. Кроме того, из-за длины питающих датчик проводов(более метра), он ловит помехи извне, а также на показания влияет сопротивление длины проводов. Немного помогла скрутка проводов в косичку.
@Cadil
- Неплохо-бы добавить на линии питания конденсатор микрофарад на 100 для облегчения работы батареек.
- Контроль питания. С такими сопротивлениями делителя — надо зашунтировать "нижний" конденсатором (10..100 нФ), чтобы данные соответствовали действительности.
А лучше — измерять напряжение питания полностью встроенными средствами МК. Сконфигурировать опорное напряжение АЦП как напряжение питания и измерять относительно него внутреннее опорное напряжение 1,1 В.
igrushkin
"328p далеко не лидер по энергоэффективности, и опять же, странно пользоваться им в 2019 году"
Правда?
Неплохо-бы добавить на линии питания конденсатор микрофарад на 100 для облегчения работы батареек.
Для батареек с током короткого замыкания больше 2А (точнее не позволяет измерить шкала моего амперметра) вряд ли нужна помощь при работе с нагрузкой около 10-ти мА.
Контроль питания. С такими сопротивлениями делителя — надо зашунтировать «нижний» конденсатором (10..100 нФ), чтобы данные соответствовали действительности.
Я думал над этим и проверял — ставил конденсатор 470 нФ, но изменений в десятых вольта не заметил. Конденсатор, по-моему, важен при подключении к блоку питания — для сглаживания пульсаций напряжения. Для страховки — поставлю.
А лучше — измерять напряжение питания полностью встроенными средствами МК. Сконфигурировать опорное напряжение АЦП как напряжение питания и измерять относительно него внутреннее опорное напряжение 1,1 В.
Обязательно реализую этот подход.
"Для батареек с током короткого замыкания больше 2А (точнее не позволяет измерить шкала моего амперметра) вряд ли нужна помощь при работе с нагрузкой около 10-ти мА."
Это для новых. А когда они разрядятся и внутреннее сопротивление вырастет — будет помогать.
"470 нФ"
Возможно, эффект маскируется analog_read'ом?
Nrf52 в любом режиме, выкинуть DS18b20 штука абсолютно бестолковая в батарейных термометрах, поставить хотя бы sht2x — 3x и будет работать от пары АА а лучше от одной LisoCi2 пару лет в режиме шлем инфу каждую минуту. Количество компонентов в разы меньше, стабильность выше.
Sign up to leave a comment.
Автономная метеостанция на контроллере ATMEGA328P и питанием от батареек с беспроводным выносным датчиком