The Internet of Things is eating everything alive, and the world wants to know: how do you make a small, battery-powered, WiFi-enabled microcontroller device? This is a surprisingly difficult problem. WiFi is not optimized for low-power operations. It’s power-hungry, and there’s a lot of overhead. That said, there are microcontrollers out there with WiFi capability, but how do they hold up to running off of a battery for days, or weeks? That’s what [TvE] is exploring in a fantastic multi-part series of posts delving into low-power WiFi microcontrollers.
The idea for these experiments is set up in the first post in the series. Basically, the goal is to measure how long the ESP8266 and ESP32 will run on a battery, using various sleep modes. Both the ESP8266 and ESP32 have deep-sleep modes, a ‘sleep’ mode where the state is preserved, a ‘CPU only’ mode that turns the RF off, and various measures for sending and receiving a packet.
The takeaway from these experiments is that a battery-powered ESP8266 can’t be used for more than a week without a seriously beefy battery or a solar panel. Run times are much longer with an open network as compared to a secured network, and that security eats up a ton of power: connecting to a secure network every now and again means your ESP might only run for a day, instead of a week.
There is another option, though: the ESP32. While the ’32 is vastly more powerful and more capable than the ESP8266, it also has a few improved features that help with power consumption. Importantly, there’s a bug in the ESP8266 where it drops into modem sleep instead of light sleep about half the time. This error was fixed in the ESP32, but all that power does come at a cost. On the whole, if you’re concerned about security, the ESP32 is slightly better, simply because it does the ‘security’ part of connecting to a WiFi network faster. This is really a remarkable amount of testing that’s gone into this write-up, so if you’re developing something battery-powered with any ESP, it’s well worth the read.
I recall a reference design with TI CC3220 which had an estimated battery life of 1 1/4 year on four AA batteries. WiFi was always connected and even a motor was driven 24 times per day! Here’s the link: http://www.ti.com/lit/pdf/tidue59
thanks for that info, i just wanted to suggest texas instruments here also
Thanks for that link! I’ll have to check it out, somehow it didn’t cross my radar, probably too much aliexpress browsing :-)
I’m trying to decipher what to expect from the CC3220 from the docs. It definitely looks interesting.
I noticed that for the measurements they state “the system was in the idle connected mode
(connected to the AP and only receiving AP beacons or broadcast and multicast traffic) with an LSI of 400
milliseconds, was measured to be 377 µA on average, over multiple DTIM receptions.” (page 44 of http://www.ti.com/lit/ug/tidue59/tidue59.pdf). One of my findings is that it’s difficult to make the power consumption independent of the background broadcast traffic on the network, so they are presenting a very best case here and one cannot extrapolate what would happen on a real network.
The chart on that page shows RX power levels of 50mA and TX power levels of just under 300mA, so very much in line with the other microcontrollers. The biggest difference seems to be that the CC3220 powers down to ~100uA between Wifi activity, which is less than the “light sleep” modes I’ve seen. Now I’m off looking where I can order one :-).
Just wanted to comment from personal experience – I developed a commercial product based on a TI BLE (cc2640r2f) microcontroller. TI’s hardware touts amazing features for the price, but unless you’re a nihilist, avoid them at all costs. Their software, documentation, and support are the worst in the industry. I’d rather use a microcontroller that had community based, third party libraries than what TI offers.
Their IDE is Eclipse based, but the SDK and documentation are a complete nightmare. Not to mention you can’t run 95% of the code in a debugger. In order for the wireless support to work, the software has to be running in release mode. It’s insanity. I quit that job over the use of TI’s hardware…just a heads up to fellow embedded folks.
Vivid description! I instinctively looked for my first aid kit to come and rescue you! :-) :-)
Whoa, that’s dark O_o
As someone who had the opportunity to work with the cc2640rf in a medium sized project: this is an accurate description. Especially the TIRTOS will crush your soul.
Hey Ben!
Thanks for the hint! That is very weird … I want to drop of the ESP8266/ESP32 train precisely for the same problems (I had to make a 2xAA rechargable enellops (1800mAh) operated wifi controller + BME280 … it works for more than an year on 5 min measure interval … but the time investment making the stupid ESP work and the gazzilion of undocumented things I had to discover in order to make it work was insane – not to mention finding a reliable supplier …) and I was thinking to jump precisely the TI world … what has stopped me so far is the inability to find the chip in a form factor like the esp – e.g. minimalist power + oscillator etc. on a small pcb … now I am blocked :D But I guess I will give the TI a try … at least I can find reliable supplier :)
Best Regards
Ivan
“The CC2640R2F is used in the TIDC-01005 to enable the system to be provisioned to a Wi-Fi network over a Bluetooth low energy connection.”
“how do you make a small, battery-powered, WiFi-enabled microcontroller device?”
My gut, knee-jerk reaction to this question… “YOU DON’T!”.
There are so many low power networking options for embedded work and WiFi just wasn’t designed for that! Just do yourself a favor, pick one and make a single “embedded device network” to WiFi gateway device that they all talk to.
Then I consider what if I wanted to share my creations with others. Almost everyone has WiFi. Ok.. maybe WiFi does have a place in embedded devices.
Then I consider how WiFi changes. My WiFi cards were old Orinoccos that didn’t even support any encryption. I’ve had 802.11 A, B, G, N and I just recently installed whatever the new one is. I have drawers full of devices that can’t connect anymore because they only support WEP.
I imagine a home full of custom, homemade “smart-house” and now none of them work because I just brought home my next router and it isn’t safe to turn on ‘legacy’ encryption methods because they are all broken.
So… back to that gateway device! And one other thing, it no longer goes from “embedded network” to WiFi MY BABY RUNS ETHERNET!
Or.. maybe I should just run twisted pair everywhere and go RS485/Modbus.
I wholeheartedly agree in general and that’s why the series intro has specific use-cases mentioned. I use rf69 FSK radios (among others) and it has now happened several times to me that I have technical difficulties when I deploy a device and so I’d like to attach a wifi-connected debug probe so I can remotely troubleshoot and monitor what is going wrong. Often that has to be battery powered ’cause there is no power in reach.
The other motivation for the investigation was to really get to the bottom of what’s possible and what not. I tried a few times before and always wondered whether there isn’t another mode/option/setting that would get me closer.
There is a part of the world who wonders why any of their appliances need to be part of the internet. Can’t a toaster just make toast? A washer just wash clothes or the refrigerator just keep things cold?
Adding complexity to simple tools can be fun but in most realities simple is better.
I think there can be value to getting devices on the LAN.
For example, I am planning on building dampers and assist fans for the windows and HVAC registers in my house. I would like each room to have it’s own thermostat. I would also like this to be controlled by a central unit that is also aware of things such as the weather outside including temperature, precipitation, humidity and even air quality.
Networking appliances could be somewhat useful as well. I dream of an alarm on my phone telling me when my microwave, clothes washer or drier are finished or warning me that I left my stove on. Toaster? Meh… toasting bread is a little too quick for me to be likely to get THAT far away before it is done. That can stay offline and I am ok with that.
So why Internet and not just LAN? On that I agree with you. I don’t think this stuff SHOULD be in the internet. Well.. that “oven is still on” alert might go to my phone via Internet if I should get so far as to drive away with it on. Other than that… privacy and security please!
People are using cloud based solutions for a shortcut. That’s why they need Internet on appliances. Personally I don’t want that kind of stuff on any cloud that I don’t fully own and control! Unfortunately that seems to be a minority opinion.
Yes, but is more difficult for manufacturers to “monitor” the appliance (i.e users) after the sale, if it is not connected.
I can see a benefit to some connectivity for many devices – even toasters & washers – for reporting status or problems…but defaulting to wifi, LAN and the cloud for IoT devices is like requiring a 6-lane divided highway to every house. It’s overkill and insecure. It seems we need to find or create a lower-speed, limited, secure wired/wireless “LAN of Things” for a house or building, with a firewalled hub that connects to the Internet. There should be no way to hack a connected device into a bot or DDOS attacker.
Of course, wifi is just so damn easy to use these days…
When my toaster stops working I can tell without the internet, the same for a washing machine. It just doesn’t work anymore.
Adding electronics makes it fun for some, it adds cost, complexity and for the marketing people it’s “Modern”! The same could be said for adding the internet to a hammer…
Yes please, combine it with a hammer.
When using a hammer, I loose so much time in finding it again.
Mine is yellow and I still can’t find it when building/repairing stuff.
Fridges only need to keep things cold, sure. Having them reorder your groceries is a little silly.
But if my freezer stops working, I have 12 hours before it gets above -40 and ruins inventory, plus more money lost waiting for resupply. It doesn’t need to have wifi, but for about $10, now it can email me if the compressor dies.
And with a bit more data, I could predict when the compressor needs replacement instead of having to pay the same-day replacement fee.
And I don’t have to have a vendor account with the fridge manufacturer that they’ll end of life when the next model comes out.
Back when I had a freezer I had it for over 20 years & it never stopped keeping food cold. It just worked. My daughter has been using it for the last 6 years. Yes if it stopped knowing about it would be good but how often does that actually happen?
Adding electronics makes anything more complex & adds cost, to do it because you can is just marketing…
I find that Samsung (IIRC) commercial where the guy is busy with his kid and needs to set the oven to “warm” as the most absolutely ludicrous thing I can think of. And with a buddy who is an appliance repairman, I get to hear regular horror stories about the cost of replacing controllers in ovens, refrigerators, etc.
Whereas my 25 year old Whirlpool heavy duty washer and dryer has needed ONE repair in those 25 years, and that was replacing the lid safety switch on the washer (yeah, I could have bypassed it, but I’m a purist). Cost me about $4 and 10 minutes to fix it. Thank Dog it wasn’t one of those Neptune washers.
Didn’t watch the series yet (looks great), but my DIY ESP8266 + BME280 sensor node has been running for a month now and is still at 3.85v on a 300mAh li-po. So I wouldn’t say it can’t be run for more than a week :) Depends on your duty cycle.
You are correct and you most likely have it in deep-sleep mode, waking up relatively infrequently. There are many examples of doing that successfully. The article series is about devices that remain connected at all times, i.e. that you can talk to within a few seconds at most.
Been reading it since I found this article. It’s great stuff, found some new things I couldn’t explain during my own poking.
Awesome – got a write up? I’m interested in the sleep approach for this exact combo of micro and sensor. Thanks!
There are a lot of these kinds of articles on the Internet, but I can’t recall a single one of them ever mentioning the different RF-calibration flags one can use in conjuction with deep-sleep: by default, when the ESP wakes up from sleep, it does a full RF-calibration cycle, which means quite a bit of power-consumption for a brief moment. You can, however, supply e.g. the WAKE_NO_RFCAL – flag (using the Arduino-core for the ESP8266), which means it won’t run the calibration-cycle on wake-up, saving you quite a bit of power in the long run.
The downside to using WAKE_NO_RFCAL is that it may fail to connect to WiFi, depending on how far away the access-point is, but one can count the number of failed connection-attempts, store the value in RTC-memory and then add some smarts to determine if it should switch back to doing full calibration or not — this is what I do with my ESP8266-based projects and it works fine in my use.
Thanks for mentioning the RF calibration ’cause I didn’t in the posts… In the esp8266 case I did use WAKE_NO_RFCAL (see https://github.com/tve/low-power-wifi/blob/master/esp8266-deep-sleep/src/main.ino#L157) and I do not believe that there is such an option for the esp32 (please correct me if I’m wrong).
The RF-calibration is depending on the supplied power voltage.
So make sure to use some kind of capacitor or at least a power supply with low internal resistance and then you can do the RF-calibration a lot less often.
This also means the RF calibration must be repeated every now and then to compensate for depleting battery.
So, whatever happened to 802.15.4?
Are we going to get the same ESP8266-style of critical mass around people in the community using it and sharing their experience?
XBee never really took off… expensive, proprietary, requires Windows-only software tools, and the XBee modules are quite bulky (compare the real estate to something like an ESP-12).
There is already silicon out there from Microchip/Atmel/TI and others.
Is it just ease of the software tools and higher network stack that we’re missing?
Or it could be some new innovative Chinese upstart with nice products we’ve never heard of before, instead of the well known Western silicon names. There’s certainly precedent for that.
ESP32 is really less hungry than an ESP8266 in standby. As far I can remember , the ESP32 goes as low as 5µA when the ESP8266 only goes 20µA.
That seems to be a small difference, but while in standby, that’s 4 more lifetime !
Of course, this is far from the “bare radio” modules such as his cousins NRF24, NRF52 and RFM69 … But comparing to an NRF24 or RFM69, there is a big footprint difference: the ESP32 does contains the CPU, as you have to provide one for NRF24 and RFM69…
One of the biggest issues in deep-sleep mode is the voltage regulator. If you’re using LiFePO4 batteries you can get away without regulator if you’re careful, but otherwise it’s quite difficult to find a 300mA+ regulator that doesn’t have a quiescent current around 20uA minimum (and much more if you’re not careful).
Also, if you look at the table in https://blog.voneicken.com/2018/lp-wifi-esp8266-2/#power-calculations you see that until you reach sleep times of an hour the active portion of the cycle dominates the power consumption, so reducing sleep consumption doesn’t make much of a difference unless the thing spends very long times asleep (which works for certain use-cases).
Ummm … batteries self-discharge as well, you know …
try the nRF24LE1; it has an 8081 compatible uC in addition to the nRF24 radio. pretty slick. i used it for a while but i couldn’t get the range to be reliable for my purposes. it even has an external antenna variant that gives a lot of range.
Ironically, light sleep on the ESP8266 can give a longer life in some situations than deep sleep. That’s because light sleep wakes every router DTIM interval and checks for new packets. From the router’s perspective it is always awake and the connection does not drop. It thus skips all of the overhead of building up a new connection that deep sleep requires, and finishes it’s work much more quickly. A few dozen milliseconds vs several seconds for deep sleep to wake and connect.
The trade-off is the DTIM interval is usually 100ms, so light sleep wakes approximately ten times per second. Still, that can in some situations use less battery.
For applications where your duty cycle is moderate, say less than two minutes, give light sleep a try.
Sounds like you didn’t read the series of posts ;-). I compare light-sleep with deep-sleep in quite some detail…
I have played around with ESP8266 running on battery, and able to run some sensors on a single 18650 battery for more than a year. Based on my measurement, it should keep going without charge for a few years. The most important thing is what kind of esp8266 boards to use, none of the existing esp8266 breakout with built in USB serial port would work. I used a modified esp01, or you can use a esp12 if you need more pins (use an adapter if necessary). Then in the code, the esp8266 wake up once a minute to do measurement (RF_DISABLED when enter deep sleep mode), write the value to RTC memory, which can store 512 bytes, I do not need 1 byte for each recording so I compressed my data. Every hour, it wakes up with RF_CAL and send data to my MQTT server. Make sure to take care of the exception if your wifi server is down. Here is my code: https://github.com/qisun1/furnace_sensor
Yup, waking up once an hour makes it relatively easy. The series of posts focuses on use cases that require mostly staying connected to WiFi.
Check out MySensors.org. They have been putting together a system of DIY battery powered sensors for a while now.
Ok, so I haven’t tried this myself do could be wrong, but if the RF cal flag yields results this implies that there is significant potential to manage the radio power in some other ways.
First easy thing seems fixing the transmit power very low and using improved antennas.
If battery power is so important, then also maybe a “local” wifi repeater (that is powered).
Finally, the power draws seem to near low enough some basic energy harvesting could keep the battery topped up, eg like the amorphous solar cells in calculators that generate power under florescent lights.
I know this all adds significant cost to a mass manufactured device, but for hobbyist and niche markets I would have thought was doable.