You can’t stress it often enough: a low-power mindset is the key when developing IoT devices. For the past three years we have been devoting our time to support and learn from our customers, developers and teams in introducing, evolving and maintaining a #lowpower mindset in everyday development tasks. Ok, but let’s go back for a second: What do we mean by a ‘low-power mindset’?
A low-power mindset is understanding that making something energy efficient may be a complex and sometimes a tedious task, yet it is both rewarding and extremely crucial for your business. It is about understanding that you can achieve this by implementing a few important practices that are utilized by the developers as well as the team.
Let that sink in.
Getting into the #lowpower mindset means continuously measuring and optimizing the energy consumption throughout and even after the development project.
Sounds simple, right? Especially since most of us are testing continuously for many other purposes. In reality, measuring power consumption and energy optimizing has been rather a quick-check in the beginning of the development and then a reoccurring firefighting task.
If you haven’t found the perfect design for long battery life yet, you are most likely struggling with its complexity. It’s fine we’ve all been there.
It is not enough to only have ultra-low power chipsets and sensors, you need to understand your user scenarios, write smart software for those, match both the hardware and battery that you have chosen, and of course, understand how all this will work in the network, in different environments, and in the hand of the user.
Yet, it is understandable that both you and your customer want long-lived devices and preferably not a long and expensive development time to reach that.
For simplification, let’s divide that process into three phases – the Prototyping Phase, the Development Phase and the Production Phase.
You are entering the Prototyping Phase with hopefully well documented use cases, scenarios and requirements on the energy efficiency of your product. You most likely have a formfactor in mind and also a physical size of a battery to fit that form factor. And, you probably also have decided to try one or few different low power technologies and hardware to build your case on.
Early on, especially with no access to a prototype or dev kit, you base it on your use case and requirements. Saft has a useful tool for this purpose, the IoT battery selector. You can go back and edit the parameters and play to find the solution that works for you. There are also simulation tools available for this purpose, like Wisebatt or our partner Deutsche Telekom’s IoT solution optimizer. When you have something to measure, start measuring.
You are perhaps considering a cellular fall back for your LoRaWAN device, if you have dev kit for it, this is the time to test it and see what it would mean for the power consumption of that corner case. Ask your hardware supplier for an Otii file, showcasing the energy consumption profile of the chipset, module or sensor for a couple of duty cycles. Real measurements beat ppt. performance any day and it is a great insight in addition to the data sheet. It also gives you and the supplier a reference for discussing the hardware that you are using and behaviors you are seeing.
Be aware that the performance changes when you apply your scenarios and your software on top of the hardware. So, measure for every change that you do to track and to learn the behaviors in your hardware.
The goal is not to get that absolute value but rather to learn what impact different power profiles have on the battery life. You can use the Otii Battery Life Estimator when measuring power with Otii by picking the information from the power profiles, and estimate it with the battery that you have preliminary chosen. When practicing this, what you bring into the Development Phase is the idea on how to optimize your design, what key parameters to follow up on top of that and how to make it all more efficient.
Development is an iterative process and your energy optimization will depend on whether you have included power measurements for each of the iterations made – hardware, firmware and software.
This is no different than having automated tests to find firmware and software bugs, to detect performance degradation, high memory usage or memory leaks. And now that there are tools to enable this, like Otii and the Otii Automation Toolbox it is easy to add energy consumption tests to the existing test environments like Jenkins, with tests written in popular languages like Python and Java. If you have a continuous integration setup running already, integrate power consumption measurements as part of it.
There is much to gain from every developer testing prior to committing to a new firmware or software release. And to minimize the tedious and manual work of connecting and disconnecting between a debugger and a power measuring unit, you can use a simple switchboard. We have created one at Qoitech, and our customer Irnas have one available on their Github, that is worth checking out.
In this phase you need to step up your battery game. You have picked a preliminary battery or preferably a few from different brands as a second source/benchmark. If you know that perhaps your customer will be replacing the battery at some point, you need to have checked that also those potential choices work in your device and for your purpose.
By profiling batteries, we mean measuring discharge performance over time for these batteries based on your device power performance that you now have been perfecting since the Prototyping phase. This way you will gain a realistic insight into whether these batteries have the capacity and the right behavior to support a number of scenarios that your device will be in. And yes, you need to do this for the normal usage and for as many scenarios you believe are relevant. If it is relevant for your use case, also profile these in different temperatures, since battery performance are very temperature depended.
You can use the more realistic battery capacity from the profiling in the Otii Battery Life Estimator since you should continue to estimate battery life for every change made during the development.
You can further improve the accuracy of the estimation by applying the profiled battery discharge to the device (instead of powering it with a power supply) to find out what the actual usable capacity would be. We call this Battery emulation and trust us, you may in some cases see only 10-20% of capacity being usable. With the Otii Battery Toolbox this can be manually done, by applying and changing the used capacity to your device and observing when the device shuts down or reboots. Of course, you can also automate this process with the Otii Automation tool.
Now that you are practicing automated testing in development, it is a small step to introduce this in production and of course even smaller one in the maintenance. By using an affordable and easy-to-use set-up, like Otii, it is easy to have the same methodologies applied at your suppliers as well as your manufacturers. This allows for the same reference point when discussing requirements and deliverables and minimizes the risk of error in testing,
And in the production phase, it is as important as during the development phase, to make sure that any fixes in the firmware or software don’t cause irreparable damage to the already installed base of devices when distributing updates. You don’t want all your hard and smart work during the development to vanish, by draining the batteries in your deployment, with a line of code, meant to fix something else.
So, a low-power mindset is achievable, and that rather quickly!
It is mostly based on continuously measuring and already practiced automated testing. So, with having the right tools, comprehensive for the task yet affordable and easy to use, to be scaled across the teams and development chain, this is a no-brainer.
Embrace it and contact us to show you what can be done with our products.
And yes, #measureeverydamnday!