Optimizing Your IoT Device Energy Consumption
Here is a word, and many engineers are not going to like this word: Batteries.
Yes, these things that make our lives so simple by not connecting every device to a wall outlet as consumers makes our lives hard as engineers.
Imagine how the world would look if we had to plug pacemakers into an outlet. Contrarily, how would it feel if we had to change batteries every week?
This is where trade-off engineering turns into an art — how do we design a device that consumes less energy without compromising on functionality.
The pacemaker example is an extreme yet clear representation of this trade-off — this device that must operate without any quality compromises over a period of 5–10 years.
So how is it related to our work? Well, IoT devices are all around us— monitoring your beer freshness, counting people within a store or even helping your local grocery store never run out of milk — all of this magic, on batteries.
So how can one reduce a device’s battery consumption? In the following article, we’ll review several techniques to reduce battery consumption in “on” states — all of this was done with the Otii Arc — an engineer’s multitool that serves as a power supply and analyzer.
Frequency Matters
CPU/MCU tend to consume more energy when they run at higher frequencies, but higher frequencies do not guarantee better or faster operation for your IoT device.
Lets take a concrete example: here is my base profile and the improved one with a lower frequency:
And if we dive deeper, we can see that the average current in similar tasks is 4~7mA lower while maintaining the original operation time, meaning, no additional compute was needed to conduct the operation.
Just a side note — in my specific example, the application does not conduct heavy compute, so there is no effect on timing at all when frequency is raised or reduced — I would recommend to test both options (raising and lowering) just to see what parts of your states machine benefit from this change.
Cut Connections
Or at least reduce your packet transmission. If you have a WiFi enabled device and you need to keep a socket open, try to reduce the keep alive packet transmission to minimum.
For BLE — depending on your chosen topology, you can strategize how you send your data in bigger intervals and still maintain full functionality.
And the key takeout — if you don’t need to keep a connection open or send data — turn of your emitter immediately or put it to standby if you’re going to retransmit within a period of time shorter than your cold start.
Turn Things Off — Immediately
This may be very obvious, but turn off your peripherals as soon as you don’t need them anymore, don’t wait the extra milliseconds. Sometimes we forget to turn off things as soon as possible (boiler, oven, AC) just because we turn them on a few moments later, but due to the fact that we need to save each and every joul, it matters.
Idle - The Silent Killer
Let's say you have an I2C operation, and you’re sleeping 10ms in between operations, even though I2C operations should take micro-seconds . You are adding up (10-x)*NumberOfOperations ms to your idleness, this could sum up to quite a lot of energy in case your base profile is quite high.
Another common mistake that is related to idleness is using pre-defined waits for operations that send a notification when they are done. By waiting extra time for the confirmation, we waste extra Joules on nothing. This can be improved by using interrupts instead of polling for signal.
Your Engineers’ Artifacts
So your engineers made it and released this amazing product, but they didn’t clean up their debugging components, such as blinking LEDs, printing messages, enabling debug tools (UART) — these all sum up to quite a lot of energy.
Assuming you are using a LED at full brightness, it could potentially drain to 10–20mA per LED.
You’d be amazed how much you can save just by cleaning before deploying to production.
Restructuring The State Machine
A similar example planning a multi-stop commute plan — you can organize your trip by multiple methods:
- Priority -opening/closing time for destinations, I must arrive when something is still open.
- Distance between points —the travelling salesperson problem.
- Logical order — I can drop off the pizza only after I pick it up from the restaurant.
The same thing applies to your device — if we are focused on functionality and energy efficiency, we can do some non-trivial ordering to reduce cold start penalties.
Summary
By following these simple guideline, I was able to reduce the overall energy consumption in on state by 66% (7.5mWh to 2.5mWh per iteration), which is the major part of the energy consumption throughout the day.
To conclude, these guidelines could significantly help you reduce your overall energy consumption when developing a battery based IoT product.
Of course we can explore the deep-sleep realm, but this is something that would be more board specific or related more to the selected architecture.
If you are interested in deep sleep techniques, I highly recommend that you check out Kevin Darrah and his Youtube channel.
TL;DR
- Reduce your MCU/CPU core frequency to minimum.
- Reduce the WiFi/BLE transmit interval for socket keepalive.
- Turn off any unused peripherals as soon as possible.
- Avoid predefined idle time frames, use interrupts instead.
- Remove any “debug in release” code — debug LEDs, prints, UART access.
- Reconsider your state machine design, sometimes you’d be surprised how much you can save with a different sequence — cold start vs warm standby.
