Как оптимально, с точки зрения продолжительности работы, запитывать модуль от батареек?

[SkyN]

Теоретический расчёт работы от двух пальчиковых батареек для термометра показывает что устройство может прожить 3 месяца от двух пальчиковых батареек (пол года от четырех!!!). Но если подключать напрямую, то как только напряжение на батарейках немного упадет, то устройство перестанет работать. Если же подключать через dc-dc преобразователь, то основным потребляющим устройством станет именно преобразователь.

Как проработать от 4х батарейках полгода?

Сам расчет для термометра
0,00001 А потребление в спящем режиме 35 минут (это 2100 секунд)
0,2 А потребление в режиме передачи (считаем что все 7 секунд такое потребление)
Итого, за цикл 2107 секунд среднее потребление будет 0,000674 A (674 мкА)

судя по исследованию пальчикавая батарейка содержит в себе 2,5 ватт часа
получается, что если высаживать батарейки полностью, то от четырех батареек при проживет 4493 часа, а это пол года.

 

[pvvx]

судя по исследованию пальчикавая батарейка содержит в себе 2,5 ватт часа
получается, что если высаживать батарейки полностью, то от четырех батареек при проживет 4493 часа, а это пол года.

Там не учитывается саморазряд. Итого, в реале, раза в два-три меньше. Берите CR123A (CR17345) и проверяйте. Они, нормальные, как раз стоят в дцать раз дороже самого модуля

 

[SkyN]

Берите CR123A (CR17345) и проверяйте

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

Итак, я собрал вместе esp8266 (ESP-12), DHT11, и две пальчиковые щелочные батарейки (GP Super). Эта братия просыпается раз в 35 минут и отправляет данные о температуре, влажности, времени потребовавшемся на включение wifi, и НАПРЯЖЕНИИ НА БАТАРЕЙКАХ на https://thingspeak.com/channels/29707

За два дня нечего сказать нельзя, подождем на каком напряжении девайс откажется работать. И интересно, кто первым esp8266 или DHT11.
Пока напряжение выше 3х вольт.

Если будут желающие повторить мой опыт, может быть добавив конденцатор, резисторы, а может быть и какой нибудь dc-dc, пишите! Интересно посмотреть на большую выборку.

 

[pvvx]

Минимальное напряжение при котором модуль ESP2866 + flash (даже запись) полностью работает определено давно и равно 1.71В.
Ставьте SHT71 - он по спецификации до 2.4 В (это самый точный цифровой из бытовушных). SHT10. С меньшей разрядностью и дешевле FOST02 и ещё много клонов...
Supply current:
measuring 0.55...1 mA
average 2..28 µA
sleep 0.3..1.5 µA

 

[Alex_S]

Я сделал похожую штуку. Но есть и отличия:
- датчик температуры DHT22
- добавлен датчик давления и температуры BMP180
- длительность сна 300сек.
- датчики запитаны от порта есп. Включаются за полсекунды до измерения.
Вот показания: https://thingspeak.com/channels/29335
От двух батареек проработал около недели. Потребление еще не изучал и не оптимизировал.
Где-то около 2.7в перестал работать датчик dht. ESP пока работает.
Теперь надо придумать как вычислить потребление и придумать как его уменьшить. А так же стоит тоже добавить логгирование времени подключения и отправки данных.
В общем тема мне тоже интересна.

 

[pvvx]

Теперь надо придумать как вычислить потребление и придумать как его уменьшить. А так же стоит тоже добавить логгирование времени подключения и отправки данных.

Чем меньше грузится при старте модуля и чем оптимальнее написана передача данных - тем меньше общее потребление. Lua тут вообще не катит, т.к. кушает просто так.

В общем тема мне тоже интересна.

Время соединения после просыпания исчисляется в порядках 0,2 сек. Передача блока в 100 килобайт = 0,1 сек. В с остальных "просыпаниях " WiFi модуль вообще не включают и все ожидания данных с датчиков делают на deep-sleep (перехватывая вход в SDK) или постоянно выполняя sleep(xx). WiFi отключается вроде при записи в 0x60000710 = 0x00000000.
При постоянно включенном WiFi, при разных опциях WiFi-sleep, потребление описал тут http://esp8266.ru/forum/threads/raz...go-webservera-na-esp8266.56/page-14#post-2745 При передаче ток прыгает за 250 mA и чем оптимальнее написано соединение и отсылка данных, тем будет меньше ИТОГО.

 

[Alex_S]

Я только в начале пути... Оптимизации еще вообще никакой не делал.
А есть возможность в ESP получить timestamp из модуля? Не хочется для этого таймер заводить...

В с остальных "просыпаниях "

В остальных - это в каких? Если я правильно понял - при входе в deepSleep модуль просто "умирает", и воскресить его может только ресет (через GPIO16 он произойдет автоматически). И далее при старте - происходит просто обычный старт. Или это не так?
И еще я не понял - зачем глушить WiFi, если наша задача тут - просто собрать данные из датчиков и тут же передать их. А это выходит довольно таки быстро.

 

[JustACat]

Alex_S, если речь идет о NodeMCU, то есть разные режимы ухода-просыпания.
Посмотрите тут: http://esp8266.ru/forum/threads/ne-rabotaet-wifi-posle-vyxoda-iz-deep-sleep.148/#post-2715
И само описание команды dsleep https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en#nodedsleep
Там же можете и остальные функции посмотреть, заодно и про работу со временем (time).

зачем глушить WiFi, если наша задача тут - просто собрать данные из датчиков и тут же передать их. А это выходит довольно таки быстро.

Смотря что понимать под "довольно таки быстро". Опрос DS18B20, к примеру, может занять несколько миллисекунд. Ну, не сам опрос, а ожидание преобразования температуры.
750 мс, емнип, точно не помню, ДШ открывать сейчас не стану.
И вот если представить, что мы включаемся, и все эти 750 мс у нас зря молотит WiFi - то потери получаются огромные. Ну, это в случае с батарейным питанием и просыпанием раз в пол-часа.
Так что в идеале я вижу так:
- проснулись (без рабочего WiFi-модуля вообще)
- подключили все датчики и пнули их, чтобы они замеряли что они там меряют
- уснули на время измерения датчиков
- проснулись когда датчики все замерили
- получили с них результаты замеров
- отключили датчики от питания
- подготовили данные к отправке
- включили WiFi
- как только есть подключение - послали данные
- отключили все и уснули надолго до следующего замера
Не уверен, что именно в таком виде это возможно на ESP, но нужно подумать.

Вообще вопросы оптимизации очень обширные: там чуть-чуть, тут чуть-чуть и получаем много.

 

[pvvx]

Я только в начале пути... Оптимизации еще вообще никакой не делал.
А есть возможность в ESP получить timestamp из модуля? Не хочется для этого таймер заводить...

В остальных - это в каких? Если я правильно понял - при входе в deepSleep модуль просто "умирает", и воскресить его может только ресет (через GPIO16 он произойдет автоматически). И далее при старте - происходит просто обычный старт. Или это не так?
И еще я не понял - зачем глушить WiFi, если наша задача тут - просто собрать данные из датчиков и тут же передать их. А это выходит довольно таки быстро.

Датчик инициализируется по включению на него питания очень долго. Это обычно от 0.1 сек. После подачи команды измерения он тоже тупит ещё от 0,3 сек. Всё это время модуль может спать и не включать WiFi. Для нормальных измерений всегда применяют осреднение нескольких замеров. Т.е. модуль просыпается каждый возможный замер с датчика и делает сумму с фильтрацией, а передают уже накопленную итого. Просыпание после deep-sleep до входа в процедуру инициализации какие-то микросекунды. Считывание данных с датчика и новое засыпание = до пары миллисекунд.
Все I/O ESP8266 имеют функцию "enable GPIO wakeup CPU". Процедура инициализации доступна в SDK - берите хоть user_init(). После неё уже инициализируется всё остальное. В неё и пишите свой код - опрос датчика и если надо, то новое засыпание с вкл/выкл WiFi.

Взять к примеру SHT71:
Инициализация всего 85us:

           s_connectionreset(); // 26t
           s_transstart();      // 8t transmission start
           if(hmioerr) break;
           s_write_byte(HTD_WS);// 18t Status Register Write  [0x06]
           if(hmioerr) break;
           s_write_byte(0x00);  // 18t
           if(hmioerr) break;
           hmioerr=0; // сбросить флаг ошибки (см. InitHMS())
           hmcnt=1; // далее на запрос температуры датчика
           break; // 26+8+16+18 = 68t -> 68*1.25=85 us

Запрос на измерение всего 26 тактов I2C, потом пауза ожидания в 0.2128 s выставления "0" на I/O с аппаратным "подъёмом" CPU:

           s_transstart(); // 8t transmission start
           s_write_byte(HTD_MT); // 18t Read Measure Temperature  [0x03] ... 0.2128 s

Прием температуры и запрос влажности - 75 тактов I2C, и ожидание 0.06133 s:

           Dp.uc[1]=s_read_byte(); // 19t
           Dp.uc[0]=s_read_byte(); // 19t
           if (s_read_crc()) // 19t
           {
             hmioerr++;
             break;
           };
           s_transstart(); // 8t transmission start
           s_write_byte(HTD_MH); // 18t Read Measure Humidity [0x05] ... 0.06133 s
           hmcnt++; // след. функция

Далее чтение влажности 57 тактов I2C на 400кГц:

           Dp.uc[3]=s_read_byte(); // 19t
           Dp.uc[2]=s_read_byte(); // 19t
           if (s_read_crc()) // 19t  // ~75us
           {
             hmioerr++;
             break;
           };
           hmcnt++;
           break;

Затем повтор "Запрос на измерение" и расчет с записью промежуточных значений в flash или RTC RAM... А когда накопится, то уже передача значений. Но запас на сохранение замеров всё равно нужен, т.к. связь - дело тонкое...
В итоге цикл опроса где-то 0.2744 s. Я обычно собираю кратное 2-м кол-во замеров и это и передаю. Выходит ещё большее разрешение у датчика

 

[Alex_S]

А где тогда хранить промежуточные данные? Во флеше - продырявим. В памяти RTC - ты же сам говорил, что криво реализовано...

 

[pvvx]

А где тогда хранить промежуточные данные? Во флеше - продырявим.

Считайте - сборка 4-х опросов с суммой и записью в RTC RAM = более 1 секунды. Размер итоговых значений = 4 байта.
Исходя из PDF на гарантированное кол-во записей (лень смотреть - возьмем 5 000 раз в одну ячейку - типа у нас не flash, а туалетная бумажка )
Значит для 10 лет записи надо: 10*365*24*60*60=315360000 сек или всего записей за 10 лет, 315360000/5000 = 63072 раз для "туалетная бумажка" -> необходимо 63072*4 = 252288 байта для буфера записи в flash. Стирание пока не учитываем (кол-во стираний зависит от размера буфера и это можно тоже сосчитать).
Сократив это дело за счет RTC RAM, накапливать там будем, пусть, по 32 сек - это в 32 раза реже, значит буфер нужен всего в 7884 байт = менее 2-х секторов flash. Берем хоть 10 секторов и не паримся.
Пересчитайте - считал кое как и мог оБшибитЬся

В памяти RTC - ты же сам говорил, что криво реализовано...

Не трогайте CH_PD и не снимайте питания. Пробуйте внешнее питание на RTC_VDD...