To understand the available low power modes, it's time to look at ESP8266EX power use in detail. Which means looking at
the datasheet, specifically Table 4 in Section 2.3 on Page 13.
First, it is important to realize the numbers in Table 4 should be viewed as "best case" values. The Oak values will likely be higher (possibly MUCH higher) for several reasons, including PCB layout choices and the overall circuit design (what loads are present on which ESP8266EX pins).
In particular, I would not expect to ever see a 10 ua current draw when in Deep Sleep. The 5V-to-3.3V LDO linear regulator will have some additional minimal current drain even if the ESP8266 itself is drawing only 10 ua. And a power LED could draw 20 ma, or 2000 times more than the processor. So assuming you disconnect the LED, and tristate all ESP8266EX GPIO pins (except the RTC pin), I'd expect you may be able to get down close to 100 ua (0.1 ma) absolute minimum power drain (perhaps a bit less).
Also, Deep Sleep is a PITA, since it requires a full reboot to recover. Which means when the CPU wakes, it has no idea what it was doing just prior to going to sleep. The work-around is to save the program state prior to entering Deep Sleep, and restoring it upon waking. The RTC (Real-Time Clock) module (which stays awake during Deep Sleep) appears to have some SRAM in it we can use for this purpose.
Before looking at the other low-power modes, it is important to know why and when they are needed. If you are operating from a wall wart, the wall wart itself could be wasting a fair amount of power anyway, so restricting the power use of a mains-powered Oak may not buy you much overall power savings unless you have an extremely efficient wall wart.
That leaves non-mains (battery) power as the main reason to try to minimize Oak power use. But before even thinking about using any particular sleep mode, it is critically important that the application itself isn't wasting any power whatsoever. Let's look at Table 4 again. The biggest use of power is transmitting (up to 170 ma, which again is not a worst-case value), so it would make great sense to bend over backwards to minimize the transmissions that are needed. Basically, the more you transmit, the deeper and longer you'll have to sleep to get good battery life.
But minimizing transmission is tough: When a node boots, it must do a few handshakes with the AP (WiFi Access Point) before it is allowed to send data to the local network. These handshakes involve basic access (SSID and Password), configuring encryption, using DHCP to get an IP address lease, and there may be more I'm not remembering at the moment.
So a good transmission conservation goal is to prevent having to repeat any part of the boot-up handshake when an Oak wakes up to send data. Fortunately, there are ways to do this! But it isn't well documented, and I haven't yet done it myself with any of my ESP boards.
Next comes sending the data itself. Pretty much the entire Internet uses TCP/IP, which is a Good Thing, since TCP provides "guaranteed delivery" (every packet sent is eventually received). But that guarantee comes with some connection timeouts and overhead, which our battery-powered Oak nodes should avoid. Which means using UDP. But that has its own problems: UDP is a "connectionless" protocol that has no packet delivery guarantees, so we must add our own minimal ACK protocol to let the node know it's data has been received and it can go back to sleep.
But for Home Automation and Security, we'd want our protocol to do a bit more than just "ACK". Since WiFi encryption isn't all that secure, we should consider adding our own encryption layer (Highly Recommended!). And the protocol should also protect against MITM (Man In The Middle) attacks as well as Packet Injection attacks. Fortunately, once the link is encrypted, adding a pseudo-random packet serial number can provide these safeguards. (I've just described some of the key features in the Thread and CoAP protocols, which both use DTLS.)
The last thing the protocol must do is support "NAK", which means the recipient got a packet, but it may have been corrupted in some way (possibly due to an attack), so a NAK tells the sender to do a retry. After sending a packet, the sending node must wait some pre-determined time for the ACK or NAK to arrive. This wait is done in Receive mode, which uses much less power than Transmit mode (~60 ma, vs ~200 ma).
Whew! Clearly, the CPU is going to be busy. Fortunately, when the radio is off ("Modem Sleep") the CPU is still running, and it uses "only" 15ma. So when there is lots of computation to do, it is best to do it with the radio off. Or, conversely, turn the radio on only when needed, but be sure to wait the 3ms radio wakeup/warmup time before sending data.
OK, now we can discuss a simple but realistic minimal battery-powered Oak scenario: A gate monitor. The only thing connected to the Oak is a switch that opens when the gate is opened. When the gate opens, the Oak wakes up to send a single packet, then waits up to 1 second for a reply. If the gate isn't opened for 1 hour, the Oak will send an "I'm Still Here!" packet and wait for a reply. In either case, when the ACK is received, the Oak immediately goes back to "sleep" (the kind of sleep isn't yet defined).
Yes, the above description is just a sketch, and omits many important things: How the switch can wake up the Oak, what to do when no reply arrives, what to do if a NAK arrives, what to do when the gate closes (or if it doesn't). These are left as exercises for the Reader. ;^)
One important detail must be defined now: The power source. To keep things as simple as possible, let's use 3 AA alkaline batteries in series, connected to the USB power pins. Any other power source would be more complex and require its own analysis. Our batteries will be Eveready Energizer AA, which have
this datasheet and a nominal 2500 mah rating.
Let's now pick a "typical day" for our gate: If nothing at all happens, it will wake up 24 times to send "I'm Here!" packets. Let's say the gate is opened 4 times each day. We can view each "open" event as an interruption of the one hour "I'm Here!" packet timeout cycle. Skipping the basic statistics, this means our typical day will see 26 packets sent. And let's say our transmissions never fail, and that we always get an ACK 100 ms after the packet is sent.
So when the Oak wakes (either due to the gate switch or the timeout), it will power on the radio, and during the 3ms warmup period it will prepare the packet to be sent. Then the packet will be transmitted, which may take 3 ms. Then the Oak listens for the reply, which it sees 100 ms later. After verifying the ACK, the Oak powers off the radio and goes back to "sleep".
How long does this take? Assuming the CPU wakes in zero time (which may not be the case), we have 3ms radio power up, then 3 ms transmit, then 100 ms listening. We'll also assume it takes zero time to go to "sleep". That's a total of 106 ms awake. This happens 26 times a day (on average, for our scenario), which is 16 * 106 ms = 2756 ms. That's less than 3 seconds awake for the entire day to monitor a gate! Not bad.
But how much power does the awake time consume?
We need to calculate this from the perspective of the battery, not the ESP8266EX. It is important to understand that the batteries start out at 1.5v*3 = 4.5v, and that value will decrease until the LDO cuts out at about 3.4v. But how do we account for the LDO that sits between the batteries and the ESP8266EX? I don't want to get into the details of linear regulator operation here, but suffice it to say that the LDO "wastes" the difference between the battery voltage and 3.3v, meaning the current is the same at the battery.
So, each wakeup has 3ms @ 60 ma (radio warmup, packet prep), 3 ms @ 200 ma (send packet), 100 ms @ 60 ma (wait for reply). Our average current consumption during our 106 ms awake time is: (3*60 + 3*170 + 100 * 60)/106 = 63 ma. Since we're measuring our battery capacity in mah (milliamp-hours), let's see how much of our battery we're consuming each day while awake: It's simply 63 ma * 106 ms = 6678 mas (milliamp-seconds), which we divide by 3600 to get
1.855 mah.
Now, let's figure out how much current we'd consume for each of our 3 sleep modes for the rest of the day. First, how long will the Oak be sleeping each day? That would be: 24 hours - awake time = 24 hours - 2756 ms = 23 hours, 59 minutes, and 57.244 seconds, or 23.9992 hours. To keep it simple, we'll just round to an even 24 hours. (No, that's not cheating!)
Deep Sleep: 100 ua * 24 hrs = 2400 uah = 2.4 mah
Light Sleep: 1 ma * 24 hrs = 24 mah
Modem Sleep: 15 ma * 24 hrs = 360mah
Notice that even Deep Sleep mode uses more power than the awake power. That's not to say that Deep Sleep is expensive, but rather it says that we have done a good job minimizing the power used while awake.
The next step is to figure out our total daily current consumption for each of the three scenarios. We just add the awake mah to the sleep mah for each sleep mode:
Deep Sleep = 1.855 mah + 2.4 mah = 4.255 mah/day
Light Sleep = 1.855 mah + 24 mah = 25.855 mah/day
Modem Sleep = 1.855 mah + 360 mah = 361.855 mah/day
Now, let's figure out our battery life for each of the three sleep scenarios. The "right" way to do this is to use the average current for each scenario and follow the "constant current" discharge curve in the battery datasheet. But I'm up way past my bedtime, and we'll just assume a fixed battery capacity of 2500 mah. Since the batteries are in series, the current is common to all three batteries, so it's still 2500 mah for the set (but at a starting voltage of 4.5 v instead of 1.5 v).
For each of our scenarios, we'll divide 2500 by the daily mah consumed to get the battery life in days:
Deep Sleep = 2500 mah / 4.255 mah/day = 588 days (Over a year and a half!)
Light Sleep = 2500 mah / 25.855 mah/day = 97 days (About 3 months)
Modem Sleep = 2500 mah / 361.855 mah/day = 7 days (A week)
And, there, finally, at long last, you have it. The effect of sleep mode on battery life for the absolute simplest-but-realistic Oak application I can think of. (It gets worse, perhaps much worse, if your Oak needs to do anything remotely intelligent.)
What have we learned? Consuming 3 batteries each week adds up, so even if we turn off the radio (but keep the CPU awake), we'll still want to use a wall wart. Which in turn means that all battery-operated Oak applications should plan on at least using Light Sleep, which should be easy to program (SRAM stays powered).
Now. imagine that you had 10 Oaks running on batteries. Then even Light Sleep would go through 120 AA batteries each year!
Using Deep Sleep will take some work to save persistent values before sleeping (sincs SRAM is powered off), and restoring them upon waking. And our 10 Oaks would use just 20 AA batteries in a year.
Bottom line? Deep Sleep is a Win. We need the Oak to fully support it, including a safe interface to the RTC SRAM. Otherwise, the Oak is truly useful ONLY when plugged in, or when connected to a battery system that costs much more than the Oak itself.
Enjoy!
