ESP8266 Community Forum

- Thu Jan 30, 2020 11:22 pm #85507 I'm curious about how you get the chip in 'zombie mode' with Deep Sleep. I've never seen it. I've hit Deep Sleep a few hundred times in the last few weeks without a single failure using the current Arduino git.

Most of the time I have a germanium or Schottky between GPIO16 and RST, sometimes a 330 ohm resistor, every now and then a 2 inch wire. All worked, depending on whether I wanted an external RESET switch.

I've never used a delay() after Deep Sleep. It shouldn't need it, as it's a different mechanism / Sleep mode than the others that DO absolutely need at least delay(1) before activating.

You don't need to do Serial.flush() before Deep Sleep. Trust me, it'll cut off in mid-byte during a printf.

The maximum theoretical deep sleep is ~ 71.58 minutes, and due to the calculation for time it's something less than that. The longest I think I got was 68 minutes and change, not 3.5 hours. How do you get 3.5 hours from 2^32 microseconds? Are you travelling near the speed of light or near the event horizon of a black hole?

I'd really like to see zombie mode, but alas my code and hardware have always worked. It's almost not worth keeping the shotgun next to my work bench.

- Fri Jan 31, 2020 4:26 am #85511 For max deep sleep check out viewtopic.php?f=160&t=20784&start=12

The variable was changed to 64 bit from 32. However, this is just an internal representation of microseconds which then seems to be transformed into a count referencing the RTC clock. The count length and the slower RTC clock then gives the real limit of around 3.4 hours. This longer interval has been verified as achievable in one of the links in that thread.

- Sat Feb 01, 2020 1:43 am #85518 StanJ - I'm using the NONOS SDK, not Arduino - that would explain why you don't need a delay as there's a lot more going on in the Arduino code before the sleep.

- Thu Feb 13, 2020 8:35 pm #85657 Here some time later, I'm flat wrong on the maximum Deep Sleep. Looks like it's around 3.5 hours, give or take. It's a fuzzy number as it's based on the RTC calibration, which wanders with temperature. I'd based the earlier number off of the wrong version of the SDK API Reference. Oops. I have 3 or 4 different versions here.

One guy had limited success hitting numbers well beyond that 3.5 hours (up to 24 hours), but got erratic results for most of them. If it works for you, great. If not, don't be wildly surprised.

The RTC speeds up when it cools down in Sleep, so the actual interval will be less than what you program.