Connected medical devices increasingly run on batteries. Implants, continuous monitors, infusion pumps, and portable oxygen concentrators all share the same constraint. Every feature and performance decision trades against battery life.
Building a long-lasting battery-powered medical device starts with thoughtful hardware selection and design. That foundation matters, but it’s only part of the picture. Power-conscious choices in the firmware architecture matter just as much.
This piece walks through the firmware decisions that determine whether a connected medical device meets its battery and performance targets.
Where Does Battery Power Go?
Before diving into optimization strategies, let’s look at the different pieces of an embedded system that use battery energy. For each, we’ll cover the smart decision driving the optimization and the architectural approach for handling it in firmware.
1. Processors: The Brain’s Energy Appetite
The central processing unit (CPU) or microcontroller unit (MCU) is often the biggest constant power draw. It’s not just about whether it’s on or off; its power consumption varies significantly depending on its state:
- Active/Running: The processor is executing instructions at full speed. This is the most power-hungry state.
- Idle: The processor is powered up and ready to execute immediately but isn’t currently processing tasks. While less than active, idle still consumes significant power.
- Sleep Mode: A reduced power state where the processor stops executing, but maintains its memory state (like RAM contents) allowing it to wake up and resume operation relatively quickly.
- Deep Sleep/Hibernation: An even lower power state, often requiring more time to wake up fully. This is typically the lowest power mode achievable while the device is still technically “on”.
- Off: Everything is powered down, consuming virtually no power.
The core principle is simple: spend as much time as possible in the lowest feasible sleep state, and enter sleep immediately when the device doesn’t need to be active.
Making that practical in firmware means centralizing control. A dedicated power module lets different firmware components request the performance level they need and release it when they’re done. The module then handles transitioning the system to the lowest power state current conditions allow, rather than leaving that logic scattered across the codebase.
2. System Clocks: The Power of Time
Processors and peripherals need clocks to synchronize their operations. However, clocks aren’t free:
- Speed Costs Power: Faster, more precise clocks generally require more power to operate. Different operations might require different clock speeds.
The goal is to use clocks only when necessary. A high-speed clock running a peripheral that isn’t active is pure waste. Designing clock sources so they default to off and activate only when triggered keeps that waste from accumulating invisibly across the system. Clock control integrates naturally into your power management module, so the same centralized logic governing processor states can govern clock states as well.
One practical note: some vendor SDKs abstract away direct clock control at the application layer. When that’s the case, follow the SDK’s guidance for maintaining low power rather than trying to work around it.
3. Peripherals: Presence Has a Price
Embedded systems interact with the world (and other components) via peripherals – sensors, radios, displays, memory interfaces, etc. Examples include accelerometers, speakers, radios (Bluetooth, Wi-Fi), and DACs.
- Staying On Costs Power: Simply keeping a peripheral powered consumes energy, even if it’s not actively performing a task.
- Using Costs Power: Sending data to or receiving data from a peripheral requires energy.
The simple answer here is to turn off any unused peripherals. If a sensor or radio isn’t needed, power it down completely. Also, use peripherals efficiently. Don’t poll for data excessively if the information isn’t needed that frequently.
Integrate peripheral power control into your power management module. Implement checks (like timers) to ensure a peripheral is fully powered on before trying to interact with it, avoiding issues with half-powered components. Be mindful of polling frequency; use interrupt-driven or event-based mechanisms where possible instead of constant polling.
4. Wireless Communication: Talking Isn’t Cheap
For connected devices, wireless communication (like Bluetooth, Wi-Fi, and Cellular) is a considerable source of power usage. Key factors include:
- Sending/Receiving Data: Transmitting and receiving data costs power; more data generally means more power.
- Responsiveness (Latency): Maintaining a connection state that allows for quick responses often requires more power than allowing longer delays.
- Scanning/Discovery: Searching for other devices to connect to is an energy-intensive operation. While advertising also uses power, it is not as consuming as scanning typically is.
The key here is to communicate wisely. Scan for other devices only when necessary, perhaps triggered by a user action or specific event, and implement timeouts to prevent indefinite scanning. Optimize data transfers and package data efficiently to make the most of each transmission.
The highest-performing wireless devices are quick to connect and respond. They scan often, use short connection intervals, and transfer large amounts of data. While this creates a seamless user experience, it heavily impacts battery life compared to a balanced design. Let’s look at real-world firmware strategies for optimizing BLE power usage.
Smart Scanning Strategies
If your embedded device acts as a central, reducing scan frequency is imperative. Scanning has the largest power impact by far, costing 2 to 10 times more power than advertising or maintaining an idle connection.
Instead of scanning continuously, implement smart firmware strategies like scanning timeouts or event-triggered scanning via user actions. For example, a BLE-connected insulin pump controller can reasonably expect to find its partner pump within a minute of booting up. Rather than wasting power scanning indefinitely for a pump that might not be present, the controller should time out and wait for another trigger. (Note: Scanning power scales linearly with the scanning window against the scanning interval.)
Low-Powered Advertising
While Bluetooth 5.0 introduced power-saving extended advertising, optimizing your advertising interval is often a more reliable way to fend off drain if extended advertising doesn’t fit your product requirements. A standard firmware strategy is to implement fast advertising on boot or after an event trigger, followed by a switch to slow advertising. This guarantees the device connects quickly most of the time without constant battery drain.
Efficient Data Packaging
Sending large amounts of data uses significant power. If the insulin controller in the earlier example needs to send a firmware update image, or the pump needs to transmit bulk sensor data back to the controller, packaging that data efficiently can reduce required power by a factor of 2 to 4.
To maximize data per packet, enable data length extension and increase the maximum transmission unit so the ATT payload equals the maximum data length payload (244 octets). The best way to guarantee efficient transfer is to verify the application-level data size against the over-the-air packet size. (Check out our blog post on Data Length Extension for more specifics on data length extension and link layer packet structure.)
Selecting the Optimal PHY
BLE offers different physical layer (PHY) modulations. While the 2M PHY theoretically transmits more data in less time without linearly increasing transmission power, real-world application experience shows this efficiency isn’t always guaranteed.
Because unique device settings, negotiated parameters, and environmental noise heavily impact transfer efficiency, the best firmware strategy to select the optimal PHY is to conduct performance throughput testing of the application with compatible devices.
Check out our blog post on Bluetooth PHY for more information about the types of physical layer transmissions available with BLE.
You Cannot Optimize What You Cannot Measure
At a fundamental level, doing anything costs power; the trick is knowing when and how to do things efficiently.
By understanding these primary power consumers—the processor, clocks, peripherals, and communication interfaces—we can start making informed firmware architecture and design decisions. The key is to be conscious of the power cost associated with every operation and actively manage system resources to stay in low-power states as much as possible. However, optimization doesn’t stop at the code level. Once these firmware strategies are in place, it’s critical to validate and measure actual power consumption to ensure the system successfully meets your design goals. You cannot optimize what you cannot measure.
Navigating Low Power and High Performance
With the different embedded design power levers defined and outlined, the next step in the energy conservation process is to understand how to measure the power a device consumes for a specific operation or configuration. Application of low-power embedded design decisions requires using the right tools, designing dynamic firmware hooks for low effort changes, and implementing performance tests for continuous integration refinement.
Power Profilers and Sniffers
Power profilers are measurement devices that typically measure current draw from a load with a variable or fixed voltage supply. Because power is equal to current multiplied by voltage, the energy draw of a specific device can be calculated by integrating the measured current voltage against time. There are many ways to integrate or approximate the integral of power over time, and thankfully energy consumption from a fixed DC voltage supply can safely be approximated by simply measuring the average power draw.
Energy = Average Power x Time = Average Current x Supply Voltage x Time
Using a power profile to measure current and then calculate the average current over a specific operation will result in a good approximation of the energy used. Energy consumption of a device can be weighed against the capacity of a device’s battery to determine effective battery life. Depending on budget and required accuracy, there are different types of power profilers to consider for estimating an embedded device’s energy:
1. Development & Debugging Profiling
For day-to-day development, debugging, and integration testing, more accessible tools should be employed. The Nordic Semiconductor Power Profiler Kit II (PPK2) is a prime example. It provides a cost-effective (~$100) solution for measuring currents from sub-µA up to 1A, integrating directly with Nordic development kits and the nRF Connect for Desktop software. Its ease of use allows developers to quickly assess the impact of code changes and test variations in configuration. The Power Profiler’s ability to act as a source meter with gipo inputs as a low price positions this profiler (or similar profilers) to be an essential tool in an embedded development kit.
When increased sample bandwidth and accuracy are of interest, similar profilers like the Joulescope or Qoitech Otii Arc or may also be considered, offering potentially wider dynamic ranges or additional features compared to basic kits.
2. High-End Profiling (Benchmarking & Characterization)
For detailed analysis and establishing ground truths, high-precision Source Measure Units (SMUs) from manufacturers like Keysight can be used. These instruments offer wide dynamic ranges (nA to A, or even pA/fA resolution), high accuracy, and the ability to source voltage accurately, allowing precise characterization of different subsystems and sleep modes. This is crucial for understanding baseline power draw and verifying component datasheets.
For estimating battery life and energy usage, these high end tools are overkill. Most lower cost power profilers will achieve the accuracy needed to capture a realistic picture.
When adjusting the power levers related to wireless connectivity, sniffers are an effective tool for analysing timing and debugging issues related to changed connection parameters. Bluetooth sniffers in particular allow visual inspection of advertising and connection intervals, peripheral latency, and throughput measurements. When sniffers are used in combination with current spikes from a power profiler, most connection related behavior can be observed and diagnosed if problematic.
Dynamic Firmware
Implementing dynamic firmware hooks early in the development process facilitates rapid iteration during power optimization. As a foundational strategy, designing firmware to allow for easy runtime adjustments not only speeds development but also supports long-term maintainability and easier regulatory validation.
Runtime Configuration
Incorporate mechanisms (e.g., via an application protocol command, debug UART command-line interface, a dedicated BLE characteristic, or other debug protocols) to adjust key power-related parameters at runtime without requiring firmware recompilation. Examples include:
- BLE Advertising Interval/Power
- BLE Connection Interval/Latency/Timeout
- Sensor sampling rates and modes
- CPU clock management (on/off/scaling)
- Peripheral enable/disable states
Benefits During Development
This allows developers and testers to easily experiment with different parameter combinations and immediately measure the impact on power consumption and performance using tools like power profilers. This significantly accelerates the process of identifying optimal trade-offs.
Potential Post-Release Flexibility
When coupled with a strict security paradigm, these application protocol commands can be designed as production-level mechanisms that only certain roles in a system have authorization to send. While requiring rigorous validation and careful consideration of security implications for a medical device, these hooks could potentially allow for limited, validated adjustments in the field to optimize performance based on specific usage patterns, environmental conditions, or updated device compatibility. Any such capability would be subject to strict design controls and regulatory review.
Performance Tests
Power consumption characteristics can inadvertently change as firmware evolves. A robust testing strategy is required to ensure performance requirements are met consistently and power optimizations remain effective.
Continuous Integration (CI) Power Regression Tests
Given the frequent nature of code changes during development, integrating power measurements into a CI pipeline is a good way to track performance requirements against new code. Automated test scripts can execute specific operational scenarios on target hardware (Hardware-in-the-Loop testing). These scenarios include:
- Idle/Sleep States
- BLE Advertising (different intervals)
- BLE Connected States (different intervals, data loads)
- Sensor Sampling and Processing
- Specific product functions (including user input triggered functions)
During these tests, an automated power profiler can capture current consumption. Key metrics (average sleep current, peak current, total charge per operation) could be extracted and compared against established power budgets.
Simultaneously, functional performance metrics (e.g., data throughput, command latency) will be verified. This approach allows for early detection of power consumption regressions or performance degradation caused by code modifications, significantly reducing the cost and effort of debugging issues later in the development cycle or post-release. Test results, potentially synchronized with device logs (e.g., UART output), provide direct feedback to developers.
Checklist for Estimating Battery Life
Once you’ve got a sense of the levers associated with maximizing battery life, walk through this checklist to establish your baseline power budget:
☐ Capture the common operations from different system interactions. Examples: button press triggers therapy/wireless communication/sensor sampling with LED, accelerometer triggers speakers or vibration haptics.
☐ Estimate the frequency of each operation based on different applicable cases (default, worst case).
☐ Write prescriptive steps to exercise each operation within the system.
☐ Using a power profiler, record the amount of current required for each operation.
☐ Record the amount of current required when the device is idle or in sleep (default no activity state).
☐ Estimate the energy consumption for each operation using the current measurements.
☐ Calculate the total energy consumption over a time period (daily, weekly, etc).
☐ Determine the device’s battery capacity. (The average capacity of an AA battery is ~2500 mAh.)
☐ Divide the device’s battery capacity by the energy consumption to estimate the battery life for each case. Default/nominal battery life and worst-case battery life in a number of days or weeks.
Conclusion
Every engineering decision in a battery-powered medical device comes down to a tradeoff between performance and power conservation. For medical devices, that tradeoff isn’t just a technical specification. It’s a matter of clinical safety and usability, and the right balance depends entirely on your device’s specific clinical demands.
Some devices must prioritize immediate connectivity and rapid reaction times because patient safety depends on it. Others must prioritize months or years of uninterrupted battery life to be viable in the field at all. Defining those requirements early is what allows you to architect a firmware strategy that actually fits the device you’re building, rather than one you retrofit later under schedule pressure.
At Punch Through, these tradeoffs show up in every connected device and connected medical device program we run. When the firmware decisions start carrying more weight than your team has had to architect for before, we can help.
