Creating the DropBot9k (AKA; ESP8266 throwies) Part 3

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

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.

Flash Download Tool RFConfig tab

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.

Morgan / 2016-11-09 / Uncategorized / 0 Comments

Creating the DropBot9k (AKA; ESP8266 throwies) Part 2

Part 2 – ESP8266’s do HORRIBLE things to batteries

So initially I went with the naive approach, I stuck a pair of CR2032’s in parallel and strapped them to the ESP8266, I was rather disappointed to discover that that only got me about 20 mins of life, repeated the test with a pair of AAA’s for interests sake, I think I got about an hour out of them, time to do some ACTUAL research…

In doing some fishing around online I found some YouTube video around powering ESP8266’s from batteries or somesuch, which alerted me to the horrific power draw behaviours of the ESP8266, turns out a bare module pulls bugger all current, EXCEPT every 100ms or so where when it’s in AP mode, where it suddenly draws 400+mA to beacon, which the CR2032’s (being that their nominal rated current draw is 15mA) were VERY unhappy with, I did a quick lash up on my electronics bench to validate that that was, in fact, what was happening here, the scope confirmed the findings.

Fortunately there exists a simple solution for this, “strap a big-ass capacitor across the power rails”, 1000uF is a good choice, it doesn’t completely eliminate the spikes, but it reduces them to manageable levels and doesn’t add excessive bulk.

So I went and strapped a 1000uF cap across the module and repeated the test with a fresh pair of AAA’s, sadly that was still only good for 6 hours or so (even after I dropped the beacon interval back to 2 sec).

Back down the rabbit hole then.

The ESP8266 supports various “sleep” modes, reading the doco, the only thing that would really work for me is “deep sleep”, next problem, the way deep sleep works is;

  • GPIO16 is connected to RESET.
  • Sets a timer to fire GPIO16.
  • Powers down everything except the timer.
  • Timer expires, GPIO16 fires, chip is reset.

Problem is that the ESP-01 doesn’t have GPIO16 broken out… Time for some microsurgery!

ESP-01 Modified for Deep Sleep

ESP-01 Modified for Deep Sleep

Note the jumper wire between the Reset pin and pin 8 on the ESP8266, also note that the power LED has been removed, that alone pulls ~10mA.

Bada bing, bada boom, deep sleep, did some testing managed to get 60 hours out of a 5min sleep 1min wake cycle, this was less than optimal but at least it showed that there was a way forward.

More in part 3 whence we dig into the tools Espressif hath provided.

Morgan / 2016-11-04 / Uncategorized / 0 Comments

Creating the DropBot9k (AKA; ESP8266 throwies) Part 1

Part 1 – The Inspiration

For Ruxcon 12 this year it was decided to expand the Black Bag competition into two phases, the first being on the Saturday which was the “standard” Black Bag fare, get into a hotel room, acquire intel, don’t set off alarms and such, Sunday however was a bit different.

We decided to send the top three teams on something of a “scavenger hunt”, basically we’d send them to a few locations across the Melbourne CBD to find clues which would eventually lead them back to the conference venue where they would find a (blatantly fake) “bomb” (I’ll write up another post on the construction of that some time later), which they’d have to “disarm” for extra points.

The first stop for this “scavenger hunt” was to be a Wireless hotspot stashed in one of Melbourne’s many alleyways, to which they would connect for instructions for the next step.

Because things were very much “up in the air” as far as how we were actually going to achieve this one of the design goals was that the hotspot should be capable of being deployed on the Friday night and collected on the Sunday, necessitating at least 48 hours of battery life.

WRT703N with Internal LiPo battery

WRT703N with Internal LiPo battery

I did some testing of a Linksys WRT703N platform I’d modified with an internal battery pack, unfortunately the battery life was rather woeful, next attempt was to just strap the WRT to a USB Power Bank and use that, turns out the 703N is actually really power hungry, the ~4000mAh power bank I tested with gave only a bit over 2 hours of life, even with TX Power down at 0dBm (1mW), and obviously the equation around the amount of battery capacity required just wasn’t going to work out.

Clearly it was time to go back to the drawing board, at some point on Slack somebody had suggested we might be able to do it with an ESP8266, I’d initially discarded the suggestion because I didn’t want to have to deal with building webservers and suchlike on a platform like that. But needs must, so I dug in, more on that in part 2.

Morgan / 2016-11-03 / Uncategorized / 0 Comments