ESP32-CAM and lightsleep

[davefes]

Has anybody managed to successfully use lightsleep() in any ESP32-CAM Micropython distro?

[krismc]

I found an old esp32 board here dave
(sysname='esp32', nodename='esp32', release='1.18.0', version='v1.18-74-gfeeeb5ea3 on 2022-02-02', machine='ESP32-cam module (i2s) with ESP32'
It was using deepsleep & the usb ammeter showed 6.4mA asleep. I edited deepsleep to lightsleep & ran it again, worked OK except the ammeter now shows 27.9mA asleep.

[davefes]

Those are roughly the currents I get. The main problem I have is that deepsleep takes too long to get to the image capture stage, ie about 2 seconds. With lightsleep I can cut that down to about 0.5 seconds. But, the problem with lightsleep() (forever) or even lightsleep(60000) it works for a day or two then stops functioning.

Have you been able to lighsleep for long periods without the ESP32-CAM locking-up? If so, whose firmware is that?

Thanks.

[krismc]

I've haven't done much work with lightsleep reliability because I prefer deepsleep for the lower power consumption. Have you tried using deepsleep in a .mpy file for quicker wake ups?

As for programs that run for a a day or two then crash I used to use the WDT watchdog when I first started with upython back in 2016 but I haven't seen a guru meditation error for years & these days there doesn't seem to be a need to to use the WDT.

Do you know where the program is faulting? I found the early esp cam boards (the ones that had no usb port & had to be plugged into a separate usb enabled host card for dev) would lock up when wifi was powered up. I think it was because of the 117 high dropout regulator. The later esp32-cam cards with usb on board where much better.

[davefes]

For quite awhile I was lightsleeping for 1 minute, wake-up and feed the system WDT and a SW WDT, but I suspect that there are very few issues with keeping a simple script running then what goes on in the back-ground (ie RTOS).

I could put a few more try/except blocks in the code. I was logging any WDT fails, but don't recall seeing any. So, still do not know where it is failing. I have read some horror-stories of what people have tried to sort lighsleep issues in Arduino. I am not confident working at the ESP-IDF level.

I only power-up the WiFi if I want to send an image, then usually reset everything. I normally remove the 3V3 regulator and use a HT7333 from a single Li-ion cell. Also, I am convinced that a machine.reset() does NOT bring the camera back to a known state, so built a mono-stable to control a power-on reset circuit.

Good point about freezing stuff. Unfortunately, the source is in someone else's head.

I am shifting the camera location closer to the house, where I can feed power to it, rather than using a 2W solar panel. Then there will be no lighsleep issues.

Thanks for your input.

[aliarifat]

Here is an old thread about a similar issue:
https://github.com/orgs/micropython/discussions/15142
Not all MicroPython firmware versions support lightsleep() or deepsleep() functions properly, especially on ESP32-CAM boards. It’s important to ensure you are using a firmware version that supports power-saving modes.
If you want to make a PCB with the ESP32 CAM and a TFT screen, you can see here: https://www.pcbway.com/project/shareproject/ESP32_cam_with_tft_6939b8ec.html

[davefes]

I was the author. I have been battling with lightsleep on cameras for a few years now.

Not all MicroPython firmware versions support lightsleep() or deepsleep() functions properly, especially on ESP32-CAM boards.

Is this from your experience? The author of the distro I am using doesn't appear to know. Do you know how I can determine this myself? I do not have access to the source.