- Mon Oct 20, 2014 5:29 am
#1785
wow... 300 bytes less... very good
- Tue Oct 21, 2014 10:47 am
#1807
Nice project, I myself have built a bunch of DHT22 arduino compatible nodes. I only use RFM12b as method of wireless data transportation. These last years on a single AAA battery (with boost converter).
I am not sure it will ever be practical to run the ESP8266 on battery, it is a power hog. I plan to use these for mains powered project only, they seem unbeatable there.
Few comments on the code:
* you can use sleeping rather than delay while waiting to the ESP8266 to do something
* I have noticed that once configured for the network, the ESP8266 will automatically connect to WiFi without any further intervention. You may use that to set it only once and not every time you wake it. That will also save you few seconds of "awake" run time.
*I haven't tested that, but it could be possible to set up a pin change interrupt on serial RX to wake up the MCU when the esp8266 starts talking back
I am not sure it will ever be practical to run the ESP8266 on battery, it is a power hog. I plan to use these for mains powered project only, they seem unbeatable there.
Few comments on the code:
* you can use sleeping rather than delay while waiting to the ESP8266 to do something
* I have noticed that once configured for the network, the ESP8266 will automatically connect to WiFi without any further intervention. You may use that to set it only once and not every time you wake it. That will also save you few seconds of "awake" run time.
*I haven't tested that, but it could be possible to set up a pin change interrupt on serial RX to wake up the MCU when the esp8266 starts talking back
- Wed Oct 22, 2014 7:51 am
#1829
Even 30uA are not that bad, or make them 40 with additional 8. With 300mAh battery, e.g. Li-Ion rechargable, it will give close to one year (if not counting active current during transmittion, e.e. when update rate is long enough, say 30 minutes?).
In fact there are a lot of things to do to optimize it:
- use larger battery (e.g. 3000mAh?)
- use some source or energy harvestion - e.g. solar cell if module is close to strong light source or outdoor
- in software, when waking up, check if the sensor measurements had changed since last one - don't send if no change (e.g. temperature is not changed with more that 0.5 degrees)
If you want to make faster reading, with update rates below 1 minute, it might be better to keep the module in "connected" (associated) state using DTIM divider on the AP. According to Espressif (and other wifi IoT vendors) you can go below 1mA (600-900uA) in this case. This should be compared with let's say 8 seconds of active transmitting every 40 seconds, and might prove better for the batteries.
Using long DTIM is bad for normal network speed but I don't mind having secondary AP (or multi-SSID AP) to have sensor network with long DTIM.
Sure WIFI is not the best candidate for battery powered devices, but has a lot of other benefits - like cheap access points and ready-made coverage in almost any house. Having notification on your smartphone that "battery of node 3 at basement is almost drained" is not a bad solution. Well, I would not like to get notifications like this every day, but once every month is acceptable (just size the battery according to your habits/lazyness).
In fact there are a lot of things to do to optimize it:
- use larger battery (e.g. 3000mAh?)
- use some source or energy harvestion - e.g. solar cell if module is close to strong light source or outdoor
- in software, when waking up, check if the sensor measurements had changed since last one - don't send if no change (e.g. temperature is not changed with more that 0.5 degrees)
If you want to make faster reading, with update rates below 1 minute, it might be better to keep the module in "connected" (associated) state using DTIM divider on the AP. According to Espressif (and other wifi IoT vendors) you can go below 1mA (600-900uA) in this case. This should be compared with let's say 8 seconds of active transmitting every 40 seconds, and might prove better for the batteries.
Using long DTIM is bad for normal network speed but I don't mind having secondary AP (or multi-SSID AP) to have sensor network with long DTIM.
Sure WIFI is not the best candidate for battery powered devices, but has a lot of other benefits - like cheap access points and ready-made coverage in almost any house. Having notification on your smartphone that "battery of node 3 at basement is almost drained" is not a bad solution. Well, I would not like to get notifications like this every day, but once every month is acceptable (just size the battery according to your habits/lazyness).
- Wed Oct 22, 2014 8:00 am
#1830
Is deep sleep really working in the ESP8266 yet? I don't think anyone has the 32Khz crystal hooked up yet.
So there may be a lot more power savings possible.
But... I'd recommend something like a nRF51 for the sensor. Then make another PCB with the ESP8266 and another nRF51 and run it off from the mains.
I have a nRF51 device here that is still running for over two years on a coin cell.
So there may be a lot more power savings possible.
But... I'd recommend something like a nRF51 for the sensor. Then make another PCB with the ESP8266 and another nRF51 and run it off from the mains.
I have a nRF51 device here that is still running for over two years on a coin cell.
