Building an IoT Product — Continuous Battery Lifetime Testing
--
This story points out the learnings we gathered from building battery powered IoT consumer products over a multiple year timeframe from the perspective of engineers working on firmware and the related CI/CD processes.
It’s relatively straightforward to build a functional MVP for electronic products and for sure that’s the right way to find out what your customers need. But after the discovery phase of your product, it can be quite a journey to build custom IoT hardware and firmware that satisfies all your customer needs. Where one of them is not changing batteries too often.
We are continuously releasing firmware updates to all our customers with the risk of increasing power consumption of our embedded devices. In this article, I want to share our ongoing challenge to prevent regressions in battery lifetime while delivering new features to our products.
The products
Our team builds a range of different products with different requirements regarding power consumption. We have products powered by mains, USB, and different types of batteries.
The most tricky one, when it comes to battery consumption, is our Smart Radiator Thermostat. It controls physical valves with a stepper motor. The current draw of a moving motor is manyfold higher than the device being in standby waiting for user input or receiving commands over the air. This high dynamic range from a couple of μA to hundreds of mA range makes it hard to measure.
As we were a team of engineers in a startup environment, we started off building our own equipment to measure these high dynamic ranges but see our journey on equipment below.
The equipment
Our path to correct measurement led us across multiple tools from multimeters to top notch lab equipment and back to some modern lightweight home-office suitable solutions that didn’t exist back in the day, when we started our power journey. Here is our excerpt…
- We started measuring our current with a multitude of multimeters and shunt resistors. Unfortunately, I don’t have any pictures of these solutions any more, they looked adventurous.
- We soon switched over to the X-NUCLEO-LPM01A. It could supply up to 50 mA of current, and that was also where we started running into restrictions. Our devices usually go beyond this when turning on multiple LEDs or ramping up the motor. When the device drains more than 50mA the measurement is automatically stopped. This and similar “development shields” from other vendors work well for devices that don’t have a dynamic range of current draw, but didn’t work well for our use cases, so we ditched that.
- After different approaches (e.g. switching shunt resistors dynamically to different ranges) we decided to buy the big gun. The N6705C is a small box at the price of a mid class car that could do exactly what we wanted: Know very precisely what our baseline current consumption is. It gave us some peace of mind as it is pretty accurate and we didn’t feel the need to question our measurement equipment any more. It was a relief for any developer in the team. We could integrate it well with Python to set up a nightly power measurement test for our recurring releases. Yay! We had the first continuous feedback loop running!
- However, solution 3 didn’t scale very well. As we built multiple different PCB variants of our devices and had to evaluate alternative parts of the power stage of our devices (hey, component shortage, I’m looking at you ;), we had to make sure, the power consumption of all of these devices is guaranteed and we didn’t want to buy 5 cars to scale up our measurement setup. Then the Joulsescope came around, it’s an 800$ device that fit’s on the developers desk without problems. It comes with a great open source Python library to evaluate collected data, thus it also became our first choice for the integration in our daily CI/CD process.
- Finally nordicsemi launched the Power Profiler Kit 2, this is the new recommendation for home office usage, it’s not as accurate as the Joulescope, but a great tool for sanity checking below 100$.
To get as much as possible out of our equipment we added relay boards with 4 relays to the Joulescope, this allows us to test different devices sequentially for multiple hours with one measurement device during the night.
The Process — CI/CD
As we strive towards delivering firmware to our customers on a daily basis, we also want to make sure that we don’t accidentally increase power consumption at any point in time. So we eventually extended our CI/CD pipeline with Continuous Battery Consumption Measurement.
Our CI/CD workflows are fully automated with the use of Jenkins, Elasticsearch and internal Python libraries.
When our engineers go to sleep, our test system starts its tedious work to measure the power consumption of a multitude of our devices over multiple hours. When the well rested developers start working, they will receive a report as below in their inbox to start the day.
Each line represents the current consumption of one of the tested devices overnight. In case power consumption is too high, the developer can check critical commits of the previous day(s), fix and rerun the test case for a particular device immediately through self service.
The example below shows an unwanted power increase when we tried to introduce atomic operators to lock the threads in our operating system and the revert one day after.
As you can see, this setup allows us to iterate on battery related issues on a daily basis.
We assume many engineers in different IoT companies struggle with this problem, and we would be curious to hear and learn what different approaches you took to keep up battery life while continuously delivering features to your customers. Let us know in the comments below, or reach out directly.
The Learnings
- Having daily measurements makes it way easier to debug and fix power related issues timely, it makes the team more confident and happier.
- The Joulescope is your friend for automated setups, it’s worth every penny
- Create a fixed setup for your tests, and have a dedicated place with ideally low RF noise. We chose the basement of our office.
- Make your test results visible daily and try to avoid having flaky test results, hunting ghosts can really can waste time and effort here.
Working at tado°
At tado°, we’re passionate about bringing the best user experience to our customers. We’re looking for engineers with a mindset to solve great technical challenges like this, to deliver best in class products. If you think alike, join us on our way here: Open positions
