Part 3 - The tools which Espressif hath provided

So we’re still chasing power savings at this point, the next logical step is to reduce the TX power of the ESP8266 because we don’t need much range in this application, unfortunately NodeMCU does not expose the TXPower API…

Looks like we need to write a patch against NodeMCU… Or not…

Something of a diversion;

Around about this time I decided I needed the rtc API for the software which necessitated a new build, off to the NodeMCU Build service we go; build a new image, flash to ESP8266, ESP8266 crashes…

Turns out some time between when I initially started playing with NodeMCU and now, there’d been several SDK updates, and with new versions of the ESP8266 SDK it is frequently necessary to flash a new “init data block” to the ESP, so I dug up the appropriate “init data block” (in the latest SDK package) and attempted to flash it using esptool.py and also NodeMCU Flasher, but in no case was I able to get a working ESP at the end.

Further research lead me to the Espressif “Flash Download Tool v3.3.6” which can be downloaded from Espressif’s Other Tools page, with that and the latest SDK package I was able to get the updated init data block installed (I also reinstalled the “AT” firmware, probably wasn’t necessary to flash that as well, but I was being paranoid).

Espressif Flash Download Tool

Then flashed the new NodeMCU image using the normal process.

End diversion.

The upshot of having to go through this process was the discovery of the RFConfig tab in the Flash Download Tool.

Espressif Flash Download Tool RFConfig Tab

The “LowPowerEn” checkbox here piqued my interest, turns out, it does pretty much what it says on the box, it hard-codes a limitation on the TX Power. Checked the “LowPowerEn” checkbox, dialed it down to 0dBm (1mW), generated a new init data block, flashed it to the ESP, and re-tested.

Now, on a 5 min wake/1 min sleep cycle (I think, might have been 3 min wake/2 min sleep), I was seeing in excess of 48 hours of battery life, which was “good enough”. Out of interest I ran it up with NO sleep, and it was still good for 8+ hours, so a pretty good outcome all in all.

Turns out, the way we built the scenario for the competition meant that the ESP only needed to be (and indeed COULD ONLY be) deployed for about 6 hours, so I tweaked things to switch it to a 10min wake/10sec sleep cycle, just to give it the occasional kick in the head to make sure all ran smoothly, I also dropped two separate units in the alleyway for extra redundancy.

I’ll write another quick post in this series around “packaging” and that will cover the hardware, I’ll write up another post or maybe two about the software for it as well.

But for now, that’s your lot.