-
Notifications
You must be signed in to change notification settings - Fork 13.3k
add Low-Power demo #6989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
add Low-Power demo #6989
Changes from 1 commit
Commits
Show all changes
69 commits
Select commit
Hold shift + click to select a range
0c870ae
add Low-Power demo
Tech-TX fd1c366
add Low-Power demo
Tech-TX b912664
add Low-Power demo, remove OTA and add WiFi timeout
Tech-TX 287bc2d
add Low-Power demo
Tech-TX 7ea68d8
add Low-Power demo
Tech-TX f77a2c5
add Low-Power demo, remove OTA and add WiFi timeout
Tech-TX 387e30d
add Low-Power demo, remove OTA and add WiFi timeout
Tech-TX 0db9254
Merge branch 'master' into add_Low-Power_demo
Tech-TX 3f3ab30
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX df75200
add Low-Power demo
Tech-TX ab30950
Merge branch 'master' into add_Low-Power_demo
Tech-TX 11f1931
add Low-Power demo
Tech-TX 7d6a03b
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX 2003ef4
add Low-Power demo
Tech-TX acf3cec
add Low-Power demo
Tech-TX 2f2c508
add Low-Power demo
Tech-TX 47b73a2
add Low-Power demo
Tech-TX 36a8dbb
add Low-Power demo
Tech-TX 7178362
Merge branch 'master' into add_Low-Power_demo
Tech-TX 5d16fca
add Low-Power demo
Tech-TX 7a74da2
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX aa4feb2
add Low-Power demo
Tech-TX 8f4448d
add Low-Power demo
Tech-TX b8e42e4
add Low-Power demo
Tech-TX 068f4bd
add Low-Power demo
Tech-TX 3118de5
add Low-Power demo
Tech-TX ac40b6e
add Low-Power demo
Tech-TX 662b1f2
add Low-Power demo
Tech-TX 5695626
add Low-Power demo
Tech-TX 7627080
Merge branch 'master' into add_Low-Power_demo
Tech-TX 7b0e515
add Low-Power demo
Tech-TX a41c381
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX b93c2e3
add Low-Power demo
Tech-TX f4d00c6
add Low-Power demo
Tech-TX 841fa1b
add Low-Power demo
Tech-TX efe55a0
Merge branch 'master' into add_Low-Power_demo
Tech-TX ebc2b0a
add Low-Power demo
Tech-TX c9c073a
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX 222b9e8
add Low-Power demo
Tech-TX 9ef40f8
Merge branch 'master' into add_Low-Power_demo
Tech-TX 3ffb8ec
add Low-Power demo
Tech-TX b902ed2
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX 6ff566d
Merge branch 'master' into add_Low-Power_demo
Tech-TX c8a5955
add Low-Power demo
Tech-TX d9ea100
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX 431f5dc
add Low-Power demo
Tech-TX 9597a12
Merge branch 'master' into add_Low-Power_demo
Tech-TX 7d3ee8d
add Low-Power demo
Tech-TX 701634e
Merge branch 'add_Low-Power_demo' of https://github.com/Tech-TX/Ardui…
Tech-TX b618e6c
add Low-Power demo
Tech-TX 3292f9b
add Low-Power demo
Tech-TX 1e80279
add Low-Power demo
Tech-TX 93a527b
add Low-Power demo
Tech-TX 6018d0b
add Low-Power demo
Tech-TX 55d95e2
Merge branch 'master' into add_Low-Power_demo
Tech-TX b990e59
add Low-Power demo
Tech-TX c107c43
add Low-Power demo
Tech-TX fecacfd
add Low-Power demo
Tech-TX 601a5ae
add Low-Power demo
Tech-TX a3ddde1
8000
add Low-Power demo
Tech-TX 535d483
add Low-Power demo
Tech-TX 3775b1b
add Low-Power demo
Tech-TX 56cb239
add Low-Power demo
Tech-TX c26ce4a
add Low-Power demo
Tech-TX a76ec12
add Low-Power demo
Tech-TX a79f48c
add Low-Power demo
Tech-TX ee4c701
add Low-Power demo
Tech-TX d378102
add Low-Power demo
Tech-TX df1a494
Merge branch 'master' into add_Low-Power_demo
Tech-TX File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
add Low-Power demo
- Loading branch information
commit df7520039956c3d8fd995f5d28b18c4041b2f9a5
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,107 @@ | ||
# <center>Low-Power Demo</center> | ||
|
||
There is a lot of confusion, out-of-date information, and poor or non-working examples of how to use the 5 basic low-power modes of the ESP8266. This demo code shows you how to use them reliably. If you're here for very low power, then the 2 Light Sleep modes and Deep Sleep are what you want. | ||
|
||
The two relevant reference manuals from Espressif are the [Low-Power Solutions](https://www.espressif.com/sites/default/files/documentation/9b-esp8266-low_power_solutions__en.pdf) and the [Non-OS SDK API Reference](https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf). There is more information in the two PDFs than is presented here, so you'll want both of them for your reference. | ||
|
||
|
||
The table below is an expanded version of Table 1.1 from the Low-Power Solutions PDF. The currents listed are absolute minimums, and most people will not get that low with typical hardware and programs. | ||
|
||
| item | Automatic Modem Sleep | Forced Modem Sleep | Automatic Light Sleep | Forced Light Sleep | Forced Deep Sleep | | ||
|:---------------------:|:---------------------:|:------------------:|:---------------------:|:------------------:|:------------------:| | ||
| WiFi connectivity | Connected | Disconnected | Connected | Disconnected | Disconnected | | ||
| GPIO state | Unchanged | Unchanged | Unchanged | Unchanged | Low current (2 uA) | | ||
| WiFi | ON | OFF | ON | OFF | OFF | | ||
| System Clock | ON | ON | CYCLING | OFF | OFF | | ||
| RTC | ON | ON | ON | ON | ON (1) | | ||
| CPU | ON | ON | ON | ON | OFF | | ||
| Substrate Current | 15 mA | 15 mA | 2-15 mA (2) | 0.4 mA | 20 uA | | ||
| Avg Current DTIM = 1 | 16.2 mA | | (1.8 mA) | | | | ||
| Avg Current DTIM = 3 | 15.4 mA | | (0.9 mA) | | | | ||
| Avg Current DTIM = 10 | 15.2 mA | | (0.55 mA) | | | | ||
|
||
Notes: | ||
(1) setting a sleep time of 0 for Deep Sleep turns off the RTC, requiring an external RESET to wake it | ||
|
||
(2) due to a bug in SDK 2, the minimum current will never be less than 2 mA and is frequently 15 mA between DTIM beacons | ||
|
||
The Average Current with different DTIM settings is unverified, and will likely be higher in a real-world environment. All of the currents listed in this README are for the ESP8266 chip only. Modules that have voltage regulators, USB chips, LEDs or other hardware will draw additional current. | ||
|
||
--- | ||
|
||
## Basic Tests in the Demo | ||
|
||
1. Unconfigured modem | ||
2. Automatic Modem Sleep | ||
3. Forced Modem Sleep | ||
4. Automatic Light Sleep | ||
5. Forced Light Sleep (stop the clock, and wait for an interrupt) | ||
6. Deep Sleep for 10 seconds, wake with default modem power settings | ||
7. Deep Sleep for 10 seconds, wake with RFCAL | ||
8. Deep Sleep Instant for 10 seconds, wake with NO_RFCAL | ||
9. Deep Sleep Instant for 10 seconds, wake with RF_DISABLED | ||
|
||
--- | ||
|
||
### Test 1 - Unconfigured modem | ||
|
||
This is typical for programs that don't use WiFi, and is a high current drain of at least 67 mA continuous. | ||
|
||
### Test 2 - Automatic Modem Sleep | ||
|
||
This is the default power saving mode when you have an active WiFi connection. You don't need to add anything to your code to get it. The only time the modem sleeps is when you spend a long time in delay(), with delay times over 50mS. The LED blinks more slowly during this test as it's doing delay(350) to get the modem to sleep. While in delay() your sketch isn't doing anything worthwhile. Average current during long delay()s is 15 mA minimum. Without the delay() the average current is 67 mA with short spikes above 250 mA as transmissions occur. When the WiFi has traffic (even a couple of pings), the modem can turn on for over 2 seconds continuous at 67 mA, and it may stay on for a second after the traffic. In a high traffic environment you won't get any power savings with either of the 2 Automatic modes. Automatic Modem Sleep turns on 7-8 seconds after an active connection is established. | ||
|
||
### Test 3 - Forced Modem Sleep | ||
|
||
Turns off the modem (losing the connection), and dropping the current by 50 mA. This uses the WiFi library function. It's good if there is a long interval with no expected WiFi traffic, as you can do other things while only drawing 15 mA. | ||
|
||
### Test 4 - Automatic Light Sleep | ||
|
||
Like Automatic Modem Sleep, with the same restrictions. Once configured it's immediately active when a connection is established. During periods of long delay() the average current can drop to ~2 mA. In a network with sparse traffic you might get something near 2-5 mA average current. The LED blinks more slowly during this test as it's doing delay(350) to get the modem to sleep. | ||
|
||
### Test 5 - Forced Light Sleep | ||
|
||
Similar to Deep Sleep, but without the timer. The chip sleeps at 0.4 mA current until it is woken by an external interrupt. The only allowed interrupts are high level and low level; edge interrupts won't work. If you have a design that needs to be woken frequently (more often than every 2 seconds) then you should consider using Forced Light Sleep. For sleep periods longer than 2 seconds, Deep Sleep will be more efficient. The chip wakes after an interrupt in about 5.1mS. | ||
|
||
### Test 6 - Deep Sleep, wake with RF_DEFAULT | ||
|
||
In Deep Sleep almost everything is turned off, and the chip draws ~20 uA. If you have D0/GPIO16 connected to RST, you can use the RTC timer to wake the chip up at a timed interval. You can also wake it with an external RESET. Waking with RF_DEFAULT means it will do an RFCAL if it needs to. These first two Deep Sleep tests use the standard Deep Sleep function, so the WiFi connection is closed and the modem turned off, which takes about 270mS before Deep Sleep begins. Deep Sleep ends with a RESET, and the boot time after that is around 120mS. Any Deep Sleep less than ~2 seconds is wasting power due to the modem shut-off and boot time, and Forced Light Sleep will be a better choice as it recovers in 5.1mS from the previous state. | ||
|
||
### Test 7 - Deep Sleep, wake with RFCAL | ||
|
||
Identical to the test above, but the modem does a power calibration when booting. In normal use, most people would do WAKE_RF_DEFAULT instead to minimize the extra RFCAL power burst if it's not needed. | ||
|
||
### Test 8 - Deep Sleep Instant, wake with NO_RFCAL | ||
|
||
This variation doesn't do an automatic RF calibration, so power requirements will be slightly less. Additionally, *most* of the time it immediately goes into Deep Sleep without turning off the modem (that's the INSTANT part). There's another bug in SDK 2, and the SDK functions the WiFi-class calls occasionally do a modem shut-down before Deep Sleep; it's not always Instant. When it doesn't do the modem shut-down it saves an extra 270mS of power. | ||
|
||
### Test 9 - Deep Sleep Instant, wake with RF_DISABLED | ||
|
||
This last variation also uses Deep Sleep Instant, but it wakes up with the modem disabled so current after Deep Sleep is only 15 mA. Each of the 4 WAKE styles has their own use, depending on what you need. | ||
|
||
--- | ||
|
||
All of the Deep Sleep modes end with a RESET, so you must re-initialize everything. You can store *some* information in the RTC memory to survive a Deep Sleep reset, which was done in this demo to illustrate it. See the **RTCUserMemory** example for more on this feature. | ||
|
||
The maximum Deep Sleep interval is 71.58 minutes (2^32 -1 microseconds), although the actual interval may be something less than that. | ||
|
||
If you need a longer sleep period than 72 minutes, you can pass zero as the time variable to Deep Sleep and it turns off the RTC. The only way to wake it at that point is an external RESET; D0 can't do it. Both Forced Light Sleep and Deep Sleep(0) are woken by an external signal, so short delays under 2 seconds are more efficient with Forced Light Sleep, and longer delays are more power efficient with Deep Sleep. | ||
|
||
|
||
--- | ||
|
||
### Lower Power without the WiFi library: | ||
|
||
If all you want to do is reduce power for a sketch that doesn't need WiFi, add these SDK 2 functions to your code: | ||
```c | ||
wifi_station_disconnect(); | ||
wifi_set_opmode(NULL_MODE); | ||
wifi_fpm_set_sleep_type(MODEM_SLEEP_T); | ||
wifi_fpm_open(); | ||
wifi_fpm_do_sleep(0xFFFFFFF); | ||
delay(1); | ||
``` | ||
That allows you to shut down the modem *without* loading the WiFi library, dropping your average current by 50 mA, or around 1/5th of the initial power. You have to add it as shown preferably in setup(), although the delay() can be longer. It doesn't time out at 71 minutes, as you might think from the (0xFFFFFFF). The Forced Modem Sleep test does the same thing with a WiFi library call that essentially encapsulates the code above. | ||
|
||
You can also use the Deep Sleep modes without loading the WiFi library, as they use ESP API functions. The tests above try to bring the WiFi up to show you the differences after the 4 reset modes. | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are these functions to be added by the user? setup()? there is also preinit(), which allows doing things much earlier. I believe there is already an example included where wifi is disabled in preinit. Does doing that improve on this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see the other example (doing the same thing). I haven't looked at any examples that weren't of immediate interest. I saw several people on forums and elsewhere attempting this and failing, instead. That's why I added it to the README. You can include that chunk anywhere, all it does it turn off the modem.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no timeout on the WiFi connection, and none on the pushbutton waits. Those are the only two waits I know of offhand. If it never connects, turn on the debug option and see why the WiFi failed. As far as never pushing the button goes, ummm... how simple ARE kids nowadays? The bottom line on the serial monitor says "press the button to continue" each time it stops.
Half of the tests need an active WiFi connection, so I don't really want to fail into the code with nothing more than a warning on the monitor that all hell has broken loose on WiFi so we're running half-functional. Maybe I should be more explicit that it needs an active WiFi connection to run the tests... I never tried without here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just forced a WiFi fail and continued on into the code: both of the Automatic tests fail as there's no WiFi connection: neither one ever went into low-power mode. If I put in a timeout on WiFi, I'll need to add additional checks in to skip those two tests in the event of WiFi failure. The other tests ran OK. Aren't 99% of people buying the ESP8266 because they want WiFi?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OTA is gutted out, and a 30 second timeout on WiFi added. If it fails connection it skips the two 'Automatic' tests as they won't do anything. They won't fail or anything, but they won't work without an active connection. CRC32 integration is the last step I'm working on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, hopefully it passes the style check THIS time around. 😝