We’ve been testing low-power behavior on an STM32N6-based camera board, and I keep coming back to one number that is easy to misread: 6.1 uA in deep sleep.
That is not the NPU “running at 6.1 uA”.
In that state, the vision side is basically out of the picture. The STM32N6 is not doing inference, the camera rail is off, Wi-Fi is off, and storage is off. What stays alive is the low-power controller and the wake path.
The rough setup is:
- STM32N6 for image capture and on-device inference
- STM32U0 for low-power control / wake management
- PIR, button, external IO, or scheduled wake as possible triggers
- camera, Wi-Fi, storage, and other rails powered only when needed
The part I find interesting is that the sleep number only matters if the system is actually allowed to stay asleep.
For a battery-powered camera, it feels like the real problem is not just “how efficient is the NPU?”
It is more like:
sleep -> trigger -> power camera -> capture -> maybe run inference -> store/upload -> shut rails back down
If that loop runs too often for useless events, the deep sleep number stops being the thing that matters.
A few tradeoffs we are thinking through:
- False wakeups can cost more than shaving a little time off inference
- Wi-Fi / Cat-1 upload time can dominate if every event gets sent out
- PIR-first triggering is cheap, but it can miss some visual events
- Image-first triggering gives better control, but keeps more of the system awake
- Scheduled wake is great for things like metering or environmental monitoring, but not for fast events
So the question I’m trying to frame is:
How do you avoid waking the full vision pipeline unless the event is actually worth it?
For people who have built battery-powered cameras, sensors, or other embedded vision prototypes, what trigger strategy has worked best in practice?
Do you usually start with PIR/external triggers, or do you keep the image sensor active enough to do visual pre-filtering?
Context: I work with CamThink, and this comes from testing on our STM32N6 edge camera hardware. Sharing here because the power-state tradeoff seems more useful to discuss than the headline sleep-current number.
