Beyond the use of machine.deepsleep()with the user SW button,
On the AE3, does machine.deepsleep() support wakeup from RTC, GPIO, or other interrupts?
If not, is support planned for:
• RTC wake
• GPIO wake
• HE‑core wake
• Timer wake
• Sensor wake (ToF/Audio)
I do not see an example maximizing the low power potential of the HE core and HP core.
Thanks!
Hi, a PR that fixes lightsleep wakeup and deepsleep wakeup just was merged into master of MicroPython: alif: implement wake up sources for `machine.lightsleep()` by dpgeorge · Pull Request #19210 · micropython/micropython · GitHub
We may be able to get this into the V5.0.0 release.
We support wakeup from the RTC, USER Switch on the side of the camera, and the IMU for deep sleep and light sleep.
Wakeup via the HE core is possible via OPENMV Bug: Alif lightsleep doesn't work anymore. · Issue #19190 · micropython/micropython · GitHub.
When the light sleep fixes get merged into OpenMV I’ll update the docs to include this all.
For wakeup via Audio, you’d need to have the HE core running something and waking up the HP core.
Regarding this:
• RTC wake → Yes for both light sleep and deepsleep once everything is merged.
• GPIO wake → Yes deep sleep is just the user button, light sleep may work via any pin.
• HE‑core wake → Yes for light sleep on the main core.
• Timer wake → Yes, works the same way as the RTC.
• Sensor wake (ToF/Audio) → HE Core could wake via Audio detection
As for ToF wakeup, this is wired up in hardware too and possible via light sleep. However, there’s no code yet for this. But, the signals are there in hardware.
Note that there’s not much point for ToF wakeup from deepsleep as the GPIO pins that power the ToF release when in deep sleep. However, for lightsleep this can work. The ToF draws quite a bit of power to do its low-power autonomous ranging so you wouldn’t want to try to use it in deep sleep anyway as it’s going to draw mAs.
@kwagyeman Thanks for promptly sharing the update and guidance! I read thru PR #19210, and the Alif AE3 implementation direction and your progress are encouraging.
We’ll continue to build our battery powered application architecture toward utilization of deepsleep as much as practical.
HP core application and camera recovery time from deepsleep will have to be determined for impact on power consumption while periodically awake.
I am hopeful for V5.0.0 availability.
Thanks!
Jim M
Hi Jim,
Also, some info on the AE3 battery shield. We’re still in development on it. However, the latest prototype hits this with the AE3 in deep sleep:
From the Low Voltage Interface:
About ~475uW on average.
From the LiPo Interface:
About ~500uW on average.
…
And then, when running, the system is like at 50mA at 3.0V or 45mA at 3.3V → 150mW.
…
Given ~500uW when sleeping and ~150mW when on you can estimate your battery life by looking at the percentage of time off versus on.
For example, with 5 seconds on and 15minutes off in an application, you’d be looking at an average power draw of 1.33mW. With that draw, a 3.7V 1S 30,000mAh LiPo battery gives you 9.5 years ideally, and probably closer to 4+ years in a real application.
…
Note, lightsleep on the main core barely helps low power. As for using the HE core, I can’t give estimates on its use yet. We’ll get there, but not initially. Right now, using the main core with deepsleep() has a clear path above to a multi-year app.
@kwagyeman Your average sleep power graphs and benchmark ON/OFF timing is encouraging. For our application we have been targeting an overall average power draw target of 1.5mW (based upon a computed ~2 mW theoretical limit).
Additional guidance and benchmarking is appreciated!
Our current architecture approach is to operate the camera in snapshot mode, periodically capturing an image, perform inferencing and results processing, then deepsleep until the next cycle. The HE core will handle other sensor input.
· Question: Do you have data or guidance on a tradeoff between completely powering on/off the camera versus maintaining powered idle state between snapshots. I expect that powering OFF/ON has to deal with pixel startup, focusing and other sensor related startup activities.
So as not overly limit the OFF time (i.e be able to reduce the 15 minutes window between image capture, inferencing and application analysis cycles), we want to minimize the ON time of each snapshot cycle.
In addition to the YOLO (or alternative model yet TBD with our Roboflow project) inferencing time and our application initialization and inferencing results processing, do you currently have any benchmark (or timing estimates) for.
· HP core startup from “deepsleep()” to begin our application code, including loading the model?
· Camera initialization from Power ON (after a deepsleep) to accept a snapshot trigger?
· Question: Do you have data or guidance on a tradeoff between completely powering on/off the camera versus maintaining powered idle state between snapshots. I expect that powering OFF/ON has to deal with pixel startup, focusing and other sensor related startup activities.
There would be some power savings not having it constantly sending frames all the time. However, generally, you don’t want to be on. Once triggered mode is merged, this will be the best thing to use for that as the camera will implicitly do nothing until you call snapshot. So, you just put it in triggered mode, and it will draw barely any active power.
· HP core startup from “deepsleep()” to begin our application code, including loading the model?
It’s like <2 seconds to turn on and take a pic and run inference. The bootloader imposes some additional delays, but, you can customize that to no wait for a PC to attach to boot faster.
· Camera initialization from Power ON (after a deepsleep) to accept a snapshot trigger?
Here’s the results on the N6. The AE3 is roughly the same:
Power-on to inference result (attached to PC): ~2.5s
Power-on to inference result (stand-alone): ~1.5s
Wakeup from deepsleep to inference result (attached to PC): ~2.5s
Wakeup from deepsleep to inference result (stand-alone): ~1.5s
Bypass bootloader, power-on/wakeup to inference result (attached to PC): ~1.5s
Bypass bootloader, power-on/wakeup to inference result (stand-alone): ~0.5s
Bypass bootloader, power-on/wakeup to inference/image-save (attached to PC): ~4s
(PC slows down the system while reading the mass storage)
Bypass bootloader, power-on/wakeup to inference/image-save (stand-alone): ~0.75s
@kwagyeman
Excellent! We will count on “triggered mode” becoming available and using deepsleep to the maximum. Achieving under a 1 second “ON” cycle time is viable for our application and battery life requirement.
Much appreciated!
Jim M
@kwagyeman I want to confirm my understanding.
While the AE3 HP core is in deepsleep, the camera is also not powered; the AE3 HP core GPIO is not active during deepsleep and the Camera 1.8V regulator is therefore OFF.
It is possible to have the camera ON and in Triggered Mode (once triggered mode is implemented) only while the HP core is Awake (or perhaps in lightsleep with minimal power savings).
Thanks,
Jim M
@Jim Not in deep sleep mode; just the low-power gpio pins which are connected to the IMU, ToF, and switch. However, you can do literally anything you want if you get into the weeds with compiling your own code.
Alif made a highly configurable architecture. See this: 14.4. Building, flashing, and debugging the firmware - OpenMV MicroPython 1.28 documentation
For how to set up the build system. From there, you can tweak anything. The AE3 has a secure enclave where you can store encryption keys, control power settings, etc. There are a lot of different power modes available that we don’t expose to keep the system simple.
For light sleep, the GPIOs will be on, so yes, you could do this. Note there’s a PR that we need to upstream into our code base from MicroPython for lightsleep mode.
@kwagyeman I shall explore the potential customization as you suggest. Your prompt reply and guidance is much appreciated!
Jim M
