Of all the ways a wireless product can quietly degrade between firmware releases, none is more insidious than a power regression.
Functional bugs fail tests. Performance regressions show up as slower operations. Crashes are unmissable. But a firmware change that increases the device’s idle current consumption by ten percent will pass every functional test you have, run every protocol procedure correctly, and ship to customers — where it will manifest six months later as a halving of battery life, an embarrassing review, and a support escalation that traces back through several firmware revisions before someone realises which release introduced the regression.
This article is about why power regressions are uniquely difficult to catch with conventional testing, what it takes to measure power consumption automatically and reliably, and what changes when you treat battery life as a continuously-tracked property of your firmware rather than a release-time benchmark.
Why functional tests cannot catch power regressions
Start with the structural reason this problem is so hard to address with the testing techniques you already have. Functional tests are pass-or-fail. The device either responds correctly to the protocol exchange or it does not. The connection either succeeds within the expected timeout or it does not. The notification either arrives within its supervision window or it does not. Functional tests are designed to detect events — specifically, events where something has gone wrong.
Power consumption is not an event. It is a continuous quantity, and a regression in it is not a wrong outcome but a slightly worse one. A device that drew an average of eight microamps in idle now draws nine microamps. Every protocol operation completes correctly. Every state transition happens on schedule. Every test passes. The only thing that has changed is a number, and the number is not exposed by any functional test because functional tests are not designed to measure it.
This is not a deficiency you can fix by writing more functional tests. The information simply is not in the protocol behaviour. To detect a power regression you need to be measuring power directly, with instruments designed for the purpose, and you need to be measuring it precisely enough that a ten-percent drift is statistically distinguishable from measurement noise. That is a different kind of test infrastructure entirely from the kind that runs your protocol regression suite.
The consequence is that most teams do not have power testing in their CI pipeline at all. They run a power benchmark once before a major release, compare the result to a previous benchmark, and trust that nothing significant has changed in between. This works only as long as the assumption holds — and the assumption frequently does not hold, because firmware changes that look harmless in code review can have surprising effects on power consumption. A new logging statement that runs in a hot path. A timer that fires more often than it needs to. A peripheral that gets clocked higher than required. An interrupt handler that takes longer to complete than the previous version. None of these will be flagged by code review or by functional testing, but each can produce a noticeable power regression that ships invisibly to the field.
What automated power measurement actually requires
To measure power consumption with the precision needed to catch regressions, you need three things: a precision current measurement instrument, a controlled test environment, and a deterministic test workload. Each of these is worth understanding individually because each contributes its own kind of difficulty.
The instrument is the most obvious piece. A typical wireless device’s current consumption ranges from a few microamps in deep sleep to tens or hundreds of milliamps during transmission, with sharp transitions between the two. A precision power analyser captures this with sub-microamp resolution at sample rates fast enough to resolve individual transmit and receive bursts. Several commercial instruments are designed specifically for this — the Otii Arc and Joulescope are common choices, though there are others — and they cost in the low thousands of dollars per unit. The instrument connects between the device and its power supply, measures the current flowing through, and streams the data to a PC for analysis.
The controlled environment is less obvious but equally important. Power consumption in wireless devices depends sensitively on RF conditions. A device transmitting in a strong signal environment uses less power than the same device transmitting in a weak signal environment, because the link layer succeeds with fewer retransmissions. A device whose advertising is being responded to quickly enters a connection sooner than one whose advertising goes unanswered, and the connection state has different power characteristics from the advertising state. If you want measurements that are comparable across firmware versions, the RF environment must be the same in every measurement run.
This is why serious power measurement happens inside a shielded enclosure — typically a metal box that isolates the device from ambient RF — with a controlled signal path to a programmable peer. The signal level is set by a programmable attenuator. The peer’s behaviour is scripted. The sequence of operations the device performs is identical between runs. Under these conditions, the only thing that varies between measurements is the firmware itself, which is exactly the property you need for regression detection.
The deterministic workload is the third piece. A power measurement is only as meaningful as the operations it covers. Measuring “average current over an hour” tells you something, but it conflates the device’s behaviour across many different states and obscures the specific regressions that matter most. The useful measurements are state-specific: average current during idle advertising, average current during a connected interval, peak current during transmission, energy per round-trip notification, energy per connection establishment. Each of these is a separate measurement, with its own protocol sequence to drive the device into the right state, its own measurement window, and its own regression threshold.
A mature power test setup automates all of this: the test orchestrator drives the device through a defined sequence of states using its serial API, the programmable peer responds in scripted ways, the measurement instrument captures the current trace, and a post-processing step extracts the relevant per-state metrics. The output is not a single number but a structured set of measurements that together characterise the device’s energy profile across all the operating states that matter for battery life.
What a power-trend dashboard reveals
Once power measurements are running automatically — typically nightly, against the latest firmware build, in a controlled test fixture — the per-state metrics get logged to a time-series database. The most valuable artifact this produces is the power-trend dashboard: a chart for each metric showing how it has evolved across firmware versions over time.
The patterns this surfaces are illuminating. A clean firmware project shows mostly flat lines, with occasional step changes that correspond to deliberate optimisation work. A project with creeping regressions shows a slow upward drift in idle current, often imperceptible on a per-release basis but obvious over a year of accumulated changes. A project with intermittent regressions shows spikes that get walked back in subsequent releases, often without anyone noticing the pattern at the time.
The dashboard turns power consumption from an abstract specification into a continuously-monitored property. Engineers can see their changes’ effect on power immediately, the same way they can see their changes’ effect on test results. A regression that appears in tonight’s measurement gets investigated tomorrow, when the responsible commit is recent and the context is fresh. This is exactly the same dynamic that makes per-commit functional testing valuable — fast feedback compresses the time-to-fix dramatically — except applied to a metric that conventional testing cannot reach.
The dashboard also produces an important secondary artifact: high-confidence battery life estimates. With per-state power measurements taken under defined conditions, and with a model of how the device divides its time across those states in a deployment, you can compute expected battery life with much more accuracy than back-of-envelope estimation. This data feeds directly into product specifications, customer commitments, and competitive positioning. It is the difference between “we estimate the battery lasts about three years” and “based on measured per-state energy and the deployment model in spec section 4.3, the expected battery life is 3.4 years with a 95% confidence interval of 3.1 to 3.7 years.” The latter is a different kind of claim, and it is enabled by the same infrastructure that catches regressions.
The economics of catching regressions early
To see why this infrastructure is worth building, it helps to think through the economics of when a power regression is detected and what that costs.
If the regression is detected in CI on the night it is introduced, the cost is one engineer-hour the next day, spent reviewing the offending commit and deciding whether to fix or accept the regression. The change is fresh, the engineer who made it is available, and the fix is usually obvious once the cause is identified.
If the regression is detected in pre-release benchmarking — typically weeks after introduction — the cost rises. The regression has been built upon by other changes, and disentangling them takes engineer time. The release schedule is now affected. Other work may need to be deferred while the fix is investigated.
If the regression ships, the cost rises again, dramatically. Customers eventually report shortened battery life. The support team has to triage the reports and escalate them. Engineering investigates, often without a clear hypothesis because the change was many releases ago. A hotfix release is prepared, qualified, and shipped. Customers must update. Reviews of the product reflect the regression for some period afterward, and competitive comparisons during that period are damaging. The full cost is genuinely orders of magnitude higher than catching the same regression in CI.
This is the standard economic argument for fast feedback applied to power consumption, and it is just as valid here as for any other category of regression. The reason it gets less attention in power than in functional testing is not that the economics are different but that the test infrastructure is harder to build. The instruments are more expensive than CI compute. The test fixture is more involved than a containerised test runner. The expertise to design the measurement methodology is rarer than the expertise to write functional tests. The investment is larger, and so the threshold to make the investment is higher.
But the return is correspondingly large. A team that catches power regressions on the night they are introduced spends a fraction of the engineering time on power management compared to a team that catches them after release. The product ships with better battery life because the cumulative drift over the development cycle has been minimised. Customer trust in the product’s specifications is grounded in measured data rather than estimation. And the team can make optimisation choices with confidence, knowing that any improvement will be visible in the next nightly measurement.
What this implies for how you build the pipeline
The practical question is what an automated power-measurement layer in a CI/CD pipeline actually looks like, and the answer depends on the cadence the team chooses. The most common pattern is to run a defined power test suite nightly, against the most recent firmware build, in a dedicated power-measurement fixture. The fixture is one of several specialised test stations the team operates, separate from the per-commit functional test rigs but using the same general orchestration framework.
The output of each nightly run is a set of per-state power measurements, logged to a database with the firmware version, timestamp, and test conditions as metadata. A trend dashboard reads from this database and shows the team where each metric stands relative to recent history. An alert fires when any metric drifts outside its established range, triggering investigation the same way a functional test failure would.
For teams operating at scale, the fixture itself is duplicated for parallel measurement of multiple firmware variants — different products, different hardware revisions, different feature configurations. The fixed cost of building the first power-measurement station is largely a one-time investment; the marginal cost of adding additional stations to expand coverage is much lower. A team that has solved the methodology problem can extend it across the product portfolio with relatively modest incremental investment.
The discipline that makes this work is treating power as a first-class metric rather than a secondary one. Power measurements get their own dashboards, their own alerts, their own review cadence in engineering meetings. Power regressions are bugs, and they are tracked the same way functional bugs are tracked. The team’s culture comes to include power as part of what “the build is working” means, alongside the functional test results and the build itself. Once that cultural shift happens, power consumption stops being a periodic concern and becomes part of how the team thinks about firmware quality continuously.
Battery life as a property of the codebase
The deeper consequence of automated power measurement is that battery life stops being an attribute the marketing team measures occasionally and starts being a property of the codebase. It is something that exists at every commit, that changes with every change, and that can be reasoned about with the same precision as any other metric the team tracks.
This is a meaningful shift. It means battery life specifications can be defended with measured evidence. It means optimisation work has immediate, visible impact. It means the team can make engineering decisions — whether to accept a feature that costs ten microamps, whether to invest in a low-power redesign of a particular subsystem — with quantitative inputs rather than estimates. And it means customers receive a product whose battery life claims are backed by the same engineering rigour as its functional behaviour, which over time becomes a meaningful competitive differentiator in markets where battery life is the primary purchase criterion.
For wireless products that compete on battery life, this is not optional infrastructure. It is the foundation of the product’s most important specification, and treating it with anything less than the seriousness applied to functional testing is a strategic mistake that the market eventually punishes.
needCode designs and delivers automated power-measurement infrastructure for battery-powered wireless products, including precision instrumentation, controlled RF test environments, and CI/CD integration. We have implemented automated power testing across BLE mesh, LTE-connected IoT, and multi-protocol embedded engagements. If your battery-life specifications are based on estimates rather than measurements, we are happy to talk about what changing that would involve.
Book a free discovery call or get in touch
Further reading
- Bluetooth Low Energy Power Optimization — the direct companion: this piece explains how to catch power regressions, that piece explains how to avoid them by design
- Anatomy of a Production OTA Pipeline — the release pipeline that runs the nightly power suite as a release gate
- Semantic Versioning Isn’t Enough for Embedded SDKs — version-to-version trend dashboards depend on meaningful version semantics, the discipline that makes power trends interpretable across releases
- Documentation as a Product: How Good SDKs Treat Docs as Code — “battery life claims backed by measured evidence” mirrors “docs as code” — both treat supporting evidence as a first-class engineering output
