Welcome to part 3 of this series on reducing WiFi power consumption on ESP8266 chips.
This time, I’ll take it a step further by showing how to make sure the radio is needed for a shorter period of time.
In the first part I showed that in my case, where the ESP8266 wakes up every 5 minutes to read some sensors and transmit the results to the server. This whole process takes 8.3 seconds, and a whole 6.45 seconds of this is taken up by the ESP8266 establishing a connection to the WiFi network and configuring itself by DHCP.
Disabling network persistence
I mentioned before that the ESP8266 will persist the network connection information to flash, and then read this back when it next starts the WiFi function. It does this every time, and in my experiments I have found that this takes at least 1.2 seconds. There are cases where the WiFi function would crash the chip, and the WiFi would never connect.
The chip also does this even when you pass connection information to WiFi.begin(), i.e. even in the case below:
WiFi.begin( WLAN_SSID, WLAN_PASSWD );
This will actually load the connection information from flash, promptly ignore it and use the values you specify instead, connect to the WiFi and then finally write your values back to flash.
This starts wearing out the flash memory after a while. Exactly how quickly or slowly will depend on the quality of the flash memory connected to your ESP8266 chip.
The good news is that we can disable or enable this persistence by calling WiFi.persistent(). Our code to enable the WiFi network will then look like this:
WiFi.forceSleepWake(); delay( 1 ); // Disable the WiFi persistence. The ESP8266 will not load and save WiFi settings in the flash memory. WiFi.persistent( false ); WiFi.mode( WIFI_STA ); WiFi.begin( WLAN_SSID, WLAN_PASSWD );
Let’s see how this affects the power consumption:
The cycle has become longer, but on closer inspection of the graph and network packets the main reason for that is that DHCP took longer this time. Unfortunately, the DHCP time is quite variable on my network, probably something I need to look into at some stage but not today. (Ah, the noble art of procrastination…)
What is missing this time, though, is the 1.2 seconds between AP association and the start of DHCP negotiation. That’s 1200 ms at 71 mA, or 0.023 mAh saved. Combined with the 0.024 mAh saved so far, we’ve saved 0.047 mAh in total. And we’ve most likely increased the life time of the flash chip as well.
Configuring static IP
As the DHCP negotiation is taking quite a while, the next step will be to disable DHCP and configure the WiFi connection statically instead.
Of course, depending on your network setup this may not be a practical solution, but if your goal is to reduce the power consumption as far as we can go, it’s worth looking at this as well.
Assuming that the sensor network operates with an IP range of 192.168.0.1 – 192.168.0.255, network mask 255.255.255.0 and 192.168.0.254 as a gateway, we can configure it as follows:
IPAddress ip( 192, 168, 0, 1 ); IPAddress gateway( 192, 168, 0, 254 ); IPAddress subnet( 255, 255, 255, 0 ); WiFi.forceSleepWake(); delay( 1 ); WiFi.persistent( false ); WiFi.mode( WIFI_STA ); WiFi.config( ip, gateway, subnet ); WiFi.begin( WLAN_SSID, WLAN_PASSWD );
The time taken to negotiate a DHCP lease is now completely gone, and along with it the variability in the wake/sleep cycle.
The total power consumption is now down to 0.07 mAh per cycle, less than half of the 0.164 mAh we started with before optimising.
There may be other areas to target, so I will continue researching the impact different access points and interleaving operations.