We’ve been tuned into coin cell designs lately given the coin cell challenge, so we were interested in [CNLohr]’s latest video about pushing the ESP8266 into the lowest-possible battery drain with coin cells. The result is a series of hacks, based on a reverse-engineered library and depends on a modified router, but that gets the power consumption down by more than a factor of ten!
Although the ESP8266 has a deep sleep mode that draws only 20 microamps or so, that isn’t as rosy as it seems. If you could go to sleep for a while, wake up for just a moment, send your data, and then go back to sleep, that might be one thing. But when you use conventional techniques, the device wakes up and has to do about ten seconds of work (at high power) to connect to a nearby access point. Then it can do what you want and go back to sleep. That ten-second hit is a killer on small batteries.
Since that’s all you can do with the standard libraries, the next step was to find [pvvx] who has reverse engineered a great deal of the libraries and provides a library with no WiFi capability. That’s a two-edged sword. The pro is you get a 30 ms startup from a deep sleep. The downside is — well — you don’t have WiFi.
Because that’s not a great thing if you need the network, [pvvx] also has a minimal version of the SDK that can wake up and do a transaction in about 100 milliseconds. What’s more is, the power drain isn’t 100% for that entire 100 ms. The library uses a different TCP/IP stack (lwip) to make this possible.
This in turn requires a special bit of firmware on the wireless router since there isn’t enough time to do the entire WiFi transaction. Luckily, a router with OpenWRT is very easy to hack to work as required. [CNLohr] sends the data from the router to a Google form. Unusual but effective.
[CNLohr] is no stranger to the pages of Hackaday and he has done a good bit with the ESP8266 among other things. We liked his USB hack, for example. He also added wired ethernet to the ubiquitous device.
…or go with client – server way and go down order of mag. 0.8uA sleep and ~2mA full throttle
* per node of course
What do you mean by “client-server way”?
I guess the whole appeal of ESP8266 is that it can connect to any WiFi out there – and this hack needs router modification, nullifying this advantage. At this point, you could just as well use some low power radio with some base station acting as gateway to the Internet.
It’s still a nice hack, though.
How much do the “low power radios” cost? How much more effort is involved in building the infrastructure around them instead of re-using what you already have?
Whatever you do, wifi is going to be power hungry compared to dedicated radios. Either using this, or ESPnow or dedicated radio, something in your network must be special and do the translation to normal IP.
Low power radios like the NRF24L01 can be even below $0.5 and you can fit a micro next to it for the $1.5 you still have left up to the cost of an ESP. If you really want to built something serious, low power radios are worth the price when you take into account energy cost and the hassle of replacing batteries.
You can get arbitrarily low power usage by dropping your duty cycle. Also, the 8266 might use more power in that 100ms, but you get 400m+ range out of it without doing anything special.
CNLohr is sitting on a big pile of 8266’s already, buying any new hardware is automatically more expensive regardless of price. You’re also completely ignore all the NRE costs involved with setting up those ‘cheap’ nrf24l01 boards.
It’s fine to use the BLE solution if you want, but it’s a mistake to write off other people’s implementations as pointless.
why would you think I “write off other people’s implementations as pointless” ?
All I was trying to point out is that WiFi as it is is not very low power, comparable to other solutions. This is a huge improvement, has some applications, but like ESP now it requires a custom setup.
Whatever option you choose in the end depends of course on many factors.
Reverse engineer?
Espressiv has their own library for this nowadays, called “esp-now”.
http://espressif.com/en/products/software/esp-now/overview
But, as said before without WiFi there is not much use in using the ESP8266.
But if you are already farmilar with it, then why not stick with it?
Also:
A small uC with separate radio can probably do a complete transaction in 2ms or less.
Single chip solutions:
Bit of a bummer the CC25xx uC’s +bluetooth chips don’t have a cross compiler for Linux.
The broadcom uC/Bluetoot chips seem to be supported by flatformio.
I’d like to try using ESP-NOW to built something like a walkie-talkie with two ESP32s.Would you say its suitable for that?
I haven’t done much with these critters myself.
Look at the basics.
Bandwith is enough, and ESPxx has enouth horsepower for some audio compression if needed.
Range is going to be low, just like WiFi.
ESP8266 can’t do A2D while operating the WiFi, so just the ESP32 option is practical for digital 2 way radio, or even digital party line/room radio. Embed your geolocation in the audio stream and the receiver could spacialise the mix too, so that people would sound like they were in different directions and even at different distances.
I hadn’t tested ESP-NOW on an ESP32, but, on the ESP8266, the walkie talkie mode was rather… busted. It is trivial to send broadcast packets with ESP-NOW, but receiving those packets doesn’t seem to work at all. It’s easy for routers to receive those packets, but still the return path is kind of critical.
Re: Other hardware: I want to be able to use my home router for this (or in MAGFest’s case a mountain of existing wireless APs). I’ve actually tried a few brands and so far every one supports reading the ESP8266 raw packets!
Thanks. ESP8266s not being a able to receive broadcast packets is… weird? I’ve never used ESP-NOW before, the website says I have to pair two devices, which in my case would be ok. Got any experience with that mode, which I assume is different from the broadcast one?
Of course it can, broadcast is a staple of IP networks. Getting the right incantations can be tricky, but I am 100% sure it can be done. (I’ve implemented a broadcast need servants’ bell myself).
The NRF51822 does BTLE with an ARM Cortex-M0, but has no WiFi and only comes in a hard-to-hand-solder QFN48 package.
Why does it even take that long to connect to an AP anyway? The round trip time should be microseconds, several seconds is an eternity for a controller, it would seem it’s waiting for timeouts several times during the handshake or something.
It’s got something to do with authentication, encryption key exthange or such.
But don’t ask me, I’m an alsmost total WiFi noob.
It’s highly variant on the hardware, but even when I was ricing it (with my wifi cup) I could never get power-on to connect to network to less than about 1.6, 1.8 seconds. That’s an order of magnitude longer than this solution.
Maybe air-fairness have something to do with airtime fairness?
“10 seconds of work (at high power) to connect to a nearby access point.”
10 seconds ? I have a few of those “Adafruit Feather HUZZAH with ESP8266 WiFi” boards with a 800mAh / 3.7V battery that do some data logging. They wake up every minute, take sensor readings and post them to a server on the LAN. Waking up, connecting to wifi, and posting the data lasts less than 2 seconds. Sitting in deep sleep for the rest of the time. In this scenario, the battery lasts just under 100 hours, giving me an average power consumption of 8mA at 3.7V, or 30mW (including sensors), which is acceptable for my application, but i’m sure there’s room for improvements while still adhering to standards.
With or without DHCP?
Bingo. If you use custom DHCP systems you can sometimes work it down to as little as 1.8 seconds, but you’re really not going to get the scan-find-negotiate-connect-talk-to-internet-and-everything operation below that mark. This is 100ms.
I’m wondering if “ad-hoc” would improve performance–for that matter sending datagrams rather than going all the way up to IP/UDP would avoid having to deal with DHCP…
static IP yes, I should have mentioned that.
The usual DHCP lease time is 24 hours and most home networks are classed IP blocks. If you can keep about 6 bytes of state you shouldn’t need to do DHCP if the library is written intelligently. I’m not sure about WPA2 and other wifi handshakes though. Google isn’t helping me find out how long a WPA2 session is usually valid, but maybe 30 minutes? The security handshake looks like it’s 4 frames, and the wifi association another 7. It looks like wifi association tends to timeout after 5 minutes.
So let’s assume even just sending a UDP packet is going to probably take at least a 7-way handshake worth of amplification most of the time and that’s on top of any ARP. I guess wifi is kinda crap for this. Doing an actual HTTP transaction if you want to save power is just lunacy though. You can cram easily a kilobyte of data into a UDP datagram and probably send it in triplicate in the time it takes to just handshake TCP.
Yeah, nice well-behaved internet access that uses DNS and certificates and such looks increasingly like a bad idea for extreme low power.
Look up the details of apple osx network quick stay, essentially the Dick is asynchronous and they assume the lease is still valid to get super fast reconnect. It’s quite near.
DIsable all “safety” features of DHCP and you can bring the IP init time down a lot.
I don’t think those are even safety features. If you have a proper DHCP implementation that remembers it’s own lease you should only need to do it once a day. It’s non-compliant firmwares that just restart and store no memory that make this a problem.
If you have to go with option that doesn’t work on normal router then WiFi is probably not a way to go. WiFi was not designed for ultra-low power applications, so BLE or NRF24L01+ modules would be much more suitable for task.
Or esp32, which has ble built in
please write this same but using pine stamp (pine64)
While it can’t run on coin cells, I am testing a design to use Auto Light Sleep, so the Wifi stays connected:
https://github.com/leon-v/ESP8266-MQTT-Auto-Light-Sleep
Better and faster than hacking a router, is using another dedicated esp8266, who as a wire electrical powered, to do the transaction betwin TCP/ip stack and full wifi communication.
Somewhere in the datasheet of the ESP8266 there is mentioning of DTIM. Anyone made that work? It should allow a permanent connection to the wifi with less than 1mA average current.
I did.. I too couldn’t find any source to get those DITM modes working, so I got out my scope and did it my self. I have a post above somewhere in this thread with looks to my github.
https://github.com/leon-v/ESP8266-MQTT-Auto-Light-Sleep
Cool stuff actually!
Maybe there is another way– at least for some of the cases– for instance, consider the case where you want to make door or window sensors and have them last a long, long time on batteries… instead of firing up an expensive radio (wifi) for each status report– why not make some proxy units to put around that do have power– whether larger batteries or plugged-in power somewhere or both– and then have the remote sensors wake up and flash an led to communicate status to the proxy. The proxies could be scattered around to collect the status from the various units it can see– probably whatever is in the same room with it or some such– and then it, in turn, can use wifi or whatever to relay the info to a collection point. Since it has power, the expense is less of a concern.
10 secs ‘to connect’ ??????
ESP8266 can do that in a fraction https://wp.me/p2ffrb-10h