There is a number that decides whether a battery-powered sensor is a product or a prototype, and it is not the accuracy of the model. It is the average power draw while nothing is happening.
For a frame-based camera pipeline, nothing happening is still expensive. The sensor clocks out a full frame thirty times a second, the ISP processes it, the network runs a detection on it, and then the system discards the result because there was nothing in the frame. The overwhelming majority of the energy is spent confirming that the scene did not change.
Event-driven sensing inverts that. The sensor reports only the pixels whose brightness changed, asynchronously, with a timestamp. A static scene produces almost no data and therefore almost no energy. The detector runs when there is something to detect.
The energy arithmetic
Published always-on vision measurements put frame-based detection in the tens of millijoules per detection and event-driven pipelines in the low single digits. That is roughly a twenty-fold gap, and it is not a constant factor you can tune away with a better model.
The gap exists because the two designs spend energy on different things. The frame-based system spends it on data movement: sensor to ISP, ISP to memory, memory to accelerator. The event-driven system spends it on the sparse arithmetic of the events themselves, and when the scene is quiet there are no events.
This is why the interesting comparison is not accuracy. It is what happens at 3 a.m. in an empty warehouse, which is the state the device is in for most of its life.
Why the power budget is the product
A coin cell holds roughly 200 milliwatt-hours. To last two years, a device must average under about 11 microwatts. That number is not a target, it is a hard constraint that eliminates most designs before they start.
Look at where the line sits relative to the bars. A 2019 front end drawing 1.8 milliwatts misses the budget by two orders of magnitude. The designs now reaching the low tens of microwatts are the first ones where the arithmetic closes without a battery change, and that changes what the product can be.
It is the difference between a sensor you install and a sensor you commission. A device that needs a battery swap every eighteen months has an operating cost per unit that dwarfs its bill of materials, which is why so many pilots never scale past a few hundred units. A device that runs for the life of the building has no operating cost at all.
Where this lands in daily life
The application that will touch most people first is not a robot. It is hearing assistance.
A hearing aid has a brutal power budget, a strict latency requirement, and a signal-processing problem that is fundamentally about detecting events: speech onset, a door, a name. Frame-based processing forces the device to run continuously and spend its battery on silence. An event-driven front end that wakes the heavier pipeline only when there is something to process is the only architecture that fits both the battery and the latency.
The same pattern applies to warehouse safety vests that detect a reversing forklift, to pipeline monitors that listen for a pressure transient, and to agricultural sensors that report a pest visit rather than a photograph of an empty leaf.
The market arithmetic
The always-on sensing market is not one market. It is the sum of a lot of small ones, each defined by a battery constraint. My estimate is that the addressable volume for sub-100-microwatt vision front ends grows from a few million units a year today to somewhere in the hundreds of millions by 2030, with the growth concentrated in devices that currently do not exist because they cannot be powered.
The value capture will not sit in the sensor. It will sit in whoever owns the integration: the module maker that can put sensor, processor and radio in one package at one price. The sensor is a component; the module is a product.
There is a second-order effect worth pricing in. Once a device can run for five years on a coin cell, the installer stops being a technician and becomes whoever is already on site. That collapses the deployment cost, which is the line item that has killed more IoT rollouts than any technical limitation.
What breaks when you build on this
Three things, in my experience.
First, event data is not an image, and every tool in your stack assumes images. Your labelling pipeline, your augmentation, your model zoo, your debugging screenshots — all of it needs rethinking. Budget for that, because it is larger than the hardware change.
Second, sparsity is a scheduling problem. An event-driven pipeline's latency is set by the worst-case event rate, not the average, and the worst case is a scene where everything moves at once: a light switching on, a curtain moving, a person walking past a window at noon. If your scheduler assumes average rates, the device will brown out exactly when it matters.
Third, the twenty-fold energy win does not survive a careless radio. A front end at 45 microwatts paired with a radio that wakes every ten seconds to check in will draw more than the sensor ever saved. The whole device has to be designed around the constraint, or the constraint will be spent on the wrong component.
The latency budget is the other half
Energy is the constraint that gets discussed, but latency is the one that decides whether the product is usable.
An event-driven pipeline has a latency profile that looks nothing like a frame-based one. There is no fixed frame period, so the floor is the sensor's own response time plus the time to accumulate enough events to classify. In a quiet scene that is fast, because the first few events are unambiguous. In a busy scene it is slower, because the classifier has to disambiguate a crowd of simultaneous changes.
That inverted profile is actually an advantage for the applications that matter. A door opening produces a handful of events and needs a decision in milliseconds. A crowded corridor produces thousands and can tolerate tens of milliseconds. The pipeline naturally spends its time where the information is.
The trap is benchmarking on a static test set. A model evaluated on still frames will report a latency that the device never achieves, because still frames contain no event dynamics at all. The number you need is the tail latency at the ninetieth percentile of event rate, measured on the device, in the scene where it will be installed.
Teams that skip that measurement tend to discover the problem in the field, as a device that works beautifully in an empty office and stutters the moment people arrive in the morning.
What is actually transferable
The transferable idea is that sampling should be driven by change, not by a clock. A clock is a promise to spend energy at a fixed rate regardless of whether anything happened, and most sensing systems make that promise without examining it.
Anywhere you find a pipeline that processes a fixed-rate stream and discards most of it, there is a twenty-fold saving waiting, and it is usually blocked by a toolchain rather than by physics.
If this saved you time, a tip is appreciated.
HCqPmPJM3NVtS6YrmVaTZYnuP8XZ2PFgQZKT94VK1LkS
Top comments (0)