ESP8266 Community Forum

I built a dht22 interface that posts data to thingspeak and for the first time I have it powered by 2 D cells.
A plug pack test version ran for several days happily but this one had a boot failure this morning (after 8 hours operation) but recovered after 4 hours, it dropped the battery voltage in that time however, so I suspect it was in the ubiquitous 'zombie mode'.

This one is using an ESP12e board soldered onto a http://www.banggood.com/banggood breadboard friendly board carrier, the ones with the reset and flash switch push buttons already on there along with a regulator (currently bypassed for 3v battery operation).
I have not tied GPIO2 or 15 high, from memory GPIO2 has a pullup but GPIO15 does not. Like I said, it worked for few days previously.

I am using a static IP,as I found the dhcp request crashing on occasions. I wish to have the same IP anyway.

The code ..

WiFi.begin failure .. ESP.deepSleep(SLEEPTIME, WAKE_RFRFCAL);
WiFi not connecting in 20 seconds ESP.deepSleep(SLEEPTIME, WAKE_RFRFCAL);
after successful data posts .. ESP.deepSleep(SLEEPTIME, WAKE_RF_DEFAULT);

where SLEEPTIME is 300000000 (5 minutes)

I use yield() anywhere it may take some time that is not covered by a delay(xxxx)

I did have previous version a 680uF capacitor soldered between vcc and ground, though the carrier board has an SMD electrolytic on the rail (220u .. seems a bit small for that size) I have found the esp8266 never complains about more supply bypassing. even considering adding a supercap for battery operation as it may help a flat battery 'get over the hump' for peak current times. when I start getting unreliable operation I will add a cap and see if it can still function.

I wish to somehow recover from failed boots .. I was considering adding a hardware reset device, RC network on an NPN transistor base, collector to reset line.
pullup to vcc, cap to ground, GPIO via resistor can discharge the cap and hold the transistor off. code sets the GPIO to output,low. If the code fails to initialise then the transistor can turn on within a hundred mS or so and reset the micro.

Instead of that is there either a hardware wdt I can get to function (via configuration) without running any code, I am assuming that boot failure is a complete lack of running external rom code.

Just wondering if anyone has a completely reliable low voltage operating device that can recover from any issues ..

Here is the thingspeak channel.. http://thingspeak.com/channels/36227
If you check soon you can see the dead zone this morning and the drop in battery voltage.
This channel is always going to be running if you want to know the temp and humidity in queensland

if not, here is the historical data for the period, you can see the battery drop with no reports
http://api.thingspeak.com/channels/36227/charts/3?start=2015-06-21%0500:00:00&end=2015-06-23%0000:00:00

and heres the hardware .. dead bug style except I soldered components to the top of the module to leave the pins unscathed.

just added a 4.7k pullup to GPIO 2 and also a 0.47F supercap to the supply input leads.

Looking at GPIO 15 it should be low quite happily at boot time, i am using it to both drive a LED and also to drive the top of a voltage divider for the A/D battery reading.

here is the schematic I went with ( my first fritzing attempt for documentation, I usually use kicad)

the esp12 however is also fitted to the carrier, so it has the GPIO pullup onboard and not documented.

wow, that has made it worse !

made no code changes, now it will only post once it seems then not again till the reset button is pressed.
after the second failure I brought it inside and looked at the TX line to see if anything was happening, it wasn't..

I was snoozing with the LED turned on, I have turned that off now just in case it was causing a problem.

In case anyone has not encountered this .. you need to put a delay loop after a deepsleep command or it seems the device will just punch through and continue on I have found, I have a delay(5000) after each sleep and it seems fine.

grr .. logged me out, lost post. thats annoying..

found my issue, old 1/4W resistor caused a dodgy connection between XTC pin and reset.

after deepsleep finished all I got was .. (bootloader baud rate

ets Jan 8 2013,rst cause:2, boot mode:(3,6)
ets_main.c

then nothing for evermore..

after fixing that I now get ..


load 0x40100000, len 31668, room 16
tail 4
chksum 0x23
load 0x3ffe8000, len 1516, room 4
tail 8
chksum 0x9f
load 0x3ffe85f0, len 3620, room 0
tail 4
chksum 0x44
csum 0x44


now to work out why my DHT22 is working less and less...