In my prior post I implied it was OK to start building the Gate Monitor using an ESP-01 and 3 AA batteries. I was wrong.
I had neglected to include the difficulty of disabling all the handshakes and timeouts inherent with WiFi and TCP. While it is certainly possible, it would take lots of work to figure out, implement, and debug. In fact, I found no evidence that anyone has ever done it! To me, this means the project could be much more complex than just wiring up a switch and batteries, then writing a few lines of code.
A possible halfway position would be to place the AP in RTS-CTS mode and set the AP DTIM value to 3, then deep sleep between DTIM intervals. While this would work well for the node, it would wreak havoc with other WiFi users, possibly reducing overall throughput by up to 80%
This would be practical only if the ESP-01 nodes were all on their own private WiFi network, separate from all other traffic. While cheap $20 b/g/n APs are available, it would still be overkill if all we want is a single simple gate monitor.
So, let's say the ESP-01 is most easily used when it's WiFi is operating normally, which means an average ~70 ma consumption with minimal transmission. Which means disposable batteries just became a greater cost.
There is an alternative: Piggyback the ESP-01 on a much larger battery-powered host. In my case, I have some PIR-activated 60-LED solar security flood lights. Adding the ESP-01 should not significantly affect flood light activation. And I've been thinking about improving the lighting at the gate, so moving a solar flood there makes sense.
We'd need to add a $5 switching regulator for the ESP-01, since the LEDs are connected directly to the battery. The PIR sensor is powered separately, but it's supply couldn't also power the ESP-01.
This would have the added benefit that the PIR sensor could also be monitored, permitting a message to be sent whenever someone approached the gate. And we could also monitor the battery voltage, to warn of a dying system (solar floods have a habit of dying young).
So, for quick and easy ESP-01 nodes, either use a wall wart, or piggyback them onto larger systems that won't notice a 60ma load.
Thursday, August 20, 2015
Saturday, August 15, 2015
Powering Wireless IoT Nodes
Many hobbyists entering the IoT arena assume they can write an application for an RF development board then "just add a battery" to magically permit it to run for months or years before a recharge or replacement is needed. They are shocked when they see the batteries die in hours or days.
Supplying power to an IoT board requires understanding the big picture of power management. Power management affects all aspects of system development, from design to deployment.
Let's start by reviewing the basic system design and development process.
1. Overall design:
- What must the system do?
- What are the minimum required features?
- What are the "nice to have" features?
- What is our development budget?
- What is our per-node deployment budget?
2. Identify physical/hardware constraints.
- Does the system have to fit in a specified volume or have a specific shape?
- What hardware features are requiired? (RTC? UART? Radio? PWM? ADC?)
- Does the system have to use existing hardware, or is a new hardware design permitted?
- What is the power budget?
- Does the system have to use existing power sources?
3. Identify logical/software constraints.
- How much ROM/flash is available for application code storage?
- For use cases that require remote firmware update: How many copies of the application must be retained?
- How much RAM is available for application use?
4. Create a system design.
- Identify dependent requirements (requirements that depend on other requirements or specifications).
- Determine which requirements/specifications impose the greatest constraints (are the most difficult to meet).
5. Analyze the design.
- Identify and address any additional dependent (or inferred) requirements.
- Does the design meet all requirements?
6. Acquire hardware and write software.
That's only the most basic list. Let's go through the process of designing a simple system, then calculate an estimate of power consumption, then evaluate one power option in detail.
Goal: Monitor a remote fence gate.
Target Hardware: ESP-01 ($5 ESP8266EX-based WiFi module)
Industrial/commercial projects typically will first specify the application in detail, then identify the most appropriate hardware to meet the needs of the application and the budget. Hobbyists tend to already have some hardware, and want to do something useful with it.
Minimum Required Features:
1. Send a message when the gate opens.
2. Send an "I'm Still Here!" message at least once an hour.
3. The node is remote: No wired power, no wired communications.
4. If disposable batteries are used, they must last at least 3 months.
"Nice to Have" Features:
1. Send a message when a problem is detected (e.g., the batteries get low).
2. Send a message when the gate closes.
3. Send a message if the gate fails to close withing 10 minutes after being opened.
4. Provide doorbell support (switch and message)
5. Support OTA (Over The Air) firmware updates.
That's enough detail for now. Notice that nothing much has been said about the power source. That's because the power supply is a "dependent requirement", whose details depend on other system features. There are other dependent requirements that will arise as we perform our analysis.
We will also ignore all "Nice to Have" features: They can be added after we show that all the minimum system requirements can be met. However, the design of the minimal system should not exclude or prevent adding any of the optional features.
Let's look at ESP8266EX power use in detail. Which means looking at the ESP8266EX 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 ESP-01 values are higher for several reasons, including PCB layout choices and the overall circuit design (what loads are present on which pins).
In particular, we won't see a 10 ua current draw when in Deep Sleep. We may be able to get down close to 100 ua (0.1 ma) absolute minimum power drain.
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 understand 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 ESP-01 may not buy you much overall power savings unless you have an extremely efficient wall wart.
That leaves non-mains (battery) power as the primary reason to try to minimize ESP-01 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: While the specification says transmit takes up to 170 ma, a quick online search will show that the ESP-01 actually uses 300ma. So it would make great sense to bend over backwards to minimize the transmissions that are needed.
Transmitting more during each awake period will impact battery life, which means compromises will be needed in other parts of the system to regain satisfactory battery life, primarily by a) reducing the number of awake periods (increase the time between "I'm Here!" packets), and b) using the deepest available sleep mode.
Minimizing WiFi transmissions 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 ESP-01 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 ESP-01 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.
The only external input device connected to the ESP-01 is a switch that opens when the gate is opened. When the gate opens, the ESP-01 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 ESP-01 will send an "I'm Still Here!" packet and wait for a reply. In either case, when the ACK is received, the ESP-01 immediately goes back to "sleep" (the kind of sleep isn't yet defined).
To keep things as simple as possible, let's use 3 AA alkaline batteries in series, connected to a 3.3v LDO regulator. Our batteries will be Eveready Energizer AA, which have this datasheet and a nominal 2500 mah rating.
Let's now let's define 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 an average of 4 times each day. We can view each "open" event as an interruption (and restart) of the one hour "I'm Here!" cycle. Skipping the basic statistics, this means our typical day will see 26 packets sent. And let's assume our transmissions never fail, and that we always get an ACK 100 ms after the packet is sent.
When the ESP-01 wakes (either due to the gate switch or the timeout), it first 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 ESP-01 listens for the reply, which it sees 100 ms later. After verifying the ACK, the ESP-01 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 @ 70 ma (radio warmup, packet prep), 3 ms @ 300 ma (send packet), 100 ms @ 70 ma (wait for reply). Our average current consumption during our 106 ms awake time is: (3*70 + 3*300 + 100 * 70)/106 = 77 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 77 ma * 106 ms = 8162 mas (milliamp-seconds), which we divide by 3600 to get 2.3 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 ESP-01 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 = 360 mah
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 (can't do better than a single packet).
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 = 2.3 mah + 2.4 mah = 4.7 mah/day
Light Sleep = 2.3 mah + 24 mah = 26.3 mah/day
Modem Sleep = 2.3 mah + 360 mah = 362.3 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 feeling lazy, so 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.7 mah/day = 532 days (A year and a half!)
Light Sleep = 2500 mah / 26.3 mah/day = 95 days (About 3 months)
Modem Sleep = 2500 mah / 362.3 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 ESP-01 application I can think of. (It gets worse, perhaps much worse, if your ESP-01 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 ESP-01 applications should plan on at least using Light Sleep, which should be easy to program (SRAM stays powered).
Now. imagine that you had 10 ESP-01s 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 (since the CPU RAM is powered off), and restoring them upon waking. And our 10 ESP-01s would use just 20 AA batteries in a year, much more affordable.
Bottom line? Deep Sleep is a Win. We need the ESP-01 to fully support it, including a safe interface to the RTC SRAM. Otherwise, the ESP-01 is truly useful ONLY when plugged in, or when connected to a battery system that costs much more than the ESP-01 itself.
The above analysis shows it is fairly difficult to use the ESP-01 with battery power for even the simplest wireless nodes. Such applications should consider using a lower-power radio, such as BTLE, ZigBee, Z-Wave, ANT or 6LowPAN.
If cost is not an issue, we can improve the power supply. Each of the following alternatives comes with its own issues to resolve:
- Use a switching regulator instead of an LDO linear regulator (more complex power analysis).
- Use rechargeable batteries (limited number of charge/discharge cycles, self-discharge and thermal issues).
- Use solar power (needs batteries at night, which also means a battery charger).
- Use an ultracapacitor (nearly infinite cycles, but large and expensive).
Of course, we also could try to eliminate the remote node itself, which would in turn eliminate all battery life issues. For example, we could point a webcam at the gate and use video analysis software to detect gate position and movement. But doing so would make it impossible to add some of the "Nice to Have" features, such as the remote doorbell.
Given that the above does meet all our mandatory requirements, our next step would be to design the circuits to interface the gate switch to the ESP-01 and add the LDO regulator, after which we'd build an instance of the hardware.
Next, we'd develop the software (using whatever ESP8266 development environment you prefer) and make it work!
Finally, after all the mandatory features work, and we verify the system power use is very close to what we estimated, we'd next consider which optional features to add.
Supplying power to an IoT board requires understanding the big picture of power management. Power management affects all aspects of system development, from design to deployment.
System Design Overview
Let's start by reviewing the basic system design and development process.
1. Overall design:
- What must the system do?
- What are the minimum required features?
- What are the "nice to have" features?
- What is our development budget?
- What is our per-node deployment budget?
2. Identify physical/hardware constraints.
- Does the system have to fit in a specified volume or have a specific shape?
- What hardware features are requiired? (RTC? UART? Radio? PWM? ADC?)
- Does the system have to use existing hardware, or is a new hardware design permitted?
- What is the power budget?
- Does the system have to use existing power sources?
3. Identify logical/software constraints.
- How much ROM/flash is available for application code storage?
- For use cases that require remote firmware update: How many copies of the application must be retained?
- How much RAM is available for application use?
4. Create a system design.
- Identify dependent requirements (requirements that depend on other requirements or specifications).
- Determine which requirements/specifications impose the greatest constraints (are the most difficult to meet).
5. Analyze the design.
- Identify and address any additional dependent (or inferred) requirements.
- Does the design meet all requirements?
6. Acquire hardware and write software.
That's only the most basic list. Let's go through the process of designing a simple system, then calculate an estimate of power consumption, then evaluate one power option in detail.
Our Example System
Goal: Monitor a remote fence gate.
Target Hardware: ESP-01 ($5 ESP8266EX-based WiFi module)
Industrial/commercial projects typically will first specify the application in detail, then identify the most appropriate hardware to meet the needs of the application and the budget. Hobbyists tend to already have some hardware, and want to do something useful with it.
Minimum Required Features:
1. Send a message when the gate opens.
2. Send an "I'm Still Here!" message at least once an hour.
3. The node is remote: No wired power, no wired communications.
4. If disposable batteries are used, they must last at least 3 months.
"Nice to Have" Features:
1. Send a message when a problem is detected (e.g., the batteries get low).
2. Send a message when the gate closes.
3. Send a message if the gate fails to close withing 10 minutes after being opened.
4. Provide doorbell support (switch and message)
5. Support OTA (Over The Air) firmware updates.
That's enough detail for now. Notice that nothing much has been said about the power source. That's because the power supply is a "dependent requirement", whose details depend on other system features. There are other dependent requirements that will arise as we perform our analysis.
We will also ignore all "Nice to Have" features: They can be added after we show that all the minimum system requirements can be met. However, the design of the minimal system should not exclude or prevent adding any of the optional features.
ESP-01 Power Consumption
Let's look at ESP8266EX power use in detail. Which means looking at the ESP8266EX 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 ESP-01 values are higher for several reasons, including PCB layout choices and the overall circuit design (what loads are present on which pins).
In particular, we won't see a 10 ua current draw when in Deep Sleep. We may be able to get down close to 100 ua (0.1 ma) absolute minimum power drain.
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 understand 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 ESP-01 may not buy you much overall power savings unless you have an extremely efficient wall wart.
That leaves non-mains (battery) power as the primary reason to try to minimize ESP-01 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: While the specification says transmit takes up to 170 ma, a quick online search will show that the ESP-01 actually uses 300ma. So it would make great sense to bend over backwards to minimize the transmissions that are needed.
Transmitting more during each awake period will impact battery life, which means compromises will be needed in other parts of the system to regain satisfactory battery life, primarily by a) reducing the number of awake periods (increase the time between "I'm Here!" packets), and b) using the deepest available sleep mode.
WiFi Transmission
Minimizing WiFi transmissions 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 ESP-01 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 ESP-01 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.
The Gate Monitor
The only external input device connected to the ESP-01 is a switch that opens when the gate is opened. When the gate opens, the ESP-01 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 ESP-01 will send an "I'm Still Here!" packet and wait for a reply. In either case, when the ACK is received, the ESP-01 immediately goes back to "sleep" (the kind of sleep isn't yet defined).
To keep things as simple as possible, let's use 3 AA alkaline batteries in series, connected to a 3.3v LDO regulator. Our batteries will be Eveready Energizer AA, which have this datasheet and a nominal 2500 mah rating.
Let's now let's define 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 an average of 4 times each day. We can view each "open" event as an interruption (and restart) of the one hour "I'm Here!" cycle. Skipping the basic statistics, this means our typical day will see 26 packets sent. And let's assume our transmissions never fail, and that we always get an ACK 100 ms after the packet is sent.
Estimating Power Use
When the ESP-01 wakes (either due to the gate switch or the timeout), it first 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 ESP-01 listens for the reply, which it sees 100 ms later. After verifying the ACK, the ESP-01 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 @ 70 ma (radio warmup, packet prep), 3 ms @ 300 ma (send packet), 100 ms @ 70 ma (wait for reply). Our average current consumption during our 106 ms awake time is: (3*70 + 3*300 + 100 * 70)/106 = 77 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 77 ma * 106 ms = 8162 mas (milliamp-seconds), which we divide by 3600 to get 2.3 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 ESP-01 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 = 360 mah
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 (can't do better than a single packet).
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 = 2.3 mah + 2.4 mah = 4.7 mah/day
Light Sleep = 2.3 mah + 24 mah = 26.3 mah/day
Modem Sleep = 2.3 mah + 360 mah = 362.3 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 feeling lazy, so 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.7 mah/day = 532 days (A year and a half!)
Light Sleep = 2500 mah / 26.3 mah/day = 95 days (About 3 months)
Modem Sleep = 2500 mah / 362.3 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 ESP-01 application I can think of. (It gets worse, perhaps much worse, if your ESP-01 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 ESP-01 applications should plan on at least using Light Sleep, which should be easy to program (SRAM stays powered).
Now. imagine that you had 10 ESP-01s 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 (since the CPU RAM is powered off), and restoring them upon waking. And our 10 ESP-01s would use just 20 AA batteries in a year, much more affordable.
Bottom line? Deep Sleep is a Win. We need the ESP-01 to fully support it, including a safe interface to the RTC SRAM. Otherwise, the ESP-01 is truly useful ONLY when plugged in, or when connected to a battery system that costs much more than the ESP-01 itself.
Other Ways to Manage Power
The above analysis shows it is fairly difficult to use the ESP-01 with battery power for even the simplest wireless nodes. Such applications should consider using a lower-power radio, such as BTLE, ZigBee, Z-Wave, ANT or 6LowPAN.
If cost is not an issue, we can improve the power supply. Each of the following alternatives comes with its own issues to resolve:
- Use a switching regulator instead of an LDO linear regulator (more complex power analysis).
- Use rechargeable batteries (limited number of charge/discharge cycles, self-discharge and thermal issues).
- Use solar power (needs batteries at night, which also means a battery charger).
- Use an ultracapacitor (nearly infinite cycles, but large and expensive).
Of course, we also could try to eliminate the remote node itself, which would in turn eliminate all battery life issues. For example, we could point a webcam at the gate and use video analysis software to detect gate position and movement. But doing so would make it impossible to add some of the "Nice to Have" features, such as the remote doorbell.
Next Steps
Given that the above does meet all our mandatory requirements, our next step would be to design the circuits to interface the gate switch to the ESP-01 and add the LDO regulator, after which we'd build an instance of the hardware.
Next, we'd develop the software (using whatever ESP8266 development environment you prefer) and make it work!
Finally, after all the mandatory features work, and we verify the system power use is very close to what we estimated, we'd next consider which optional features to add.
Subscribe to:
Posts (Atom)