Designing a Battery-Powered BLE Medical Wearable: How We Hit 39 Days on a Coin-Sized Battery
Srihari Maddula • Founder & Technical Lead, Eurth Techtronics Pvt Ltd
Category: IoT Solutions
Estimated Reading Time: 9 min
A medical adherence wearable — a device that clips onto a bottle or sits on a patient's hand to detect and log a specific medication-use gesture — sounds, on paper, like a simple embedded project: an accelerometer, a Bluetooth radio, a battery. The first power budget spreadsheet we built for exactly this kind of device came back at 4 days of battery life on a 250mAh cell, against a target of six weeks. Getting from 4 days to 39 wasn't one clever trick — it was a systematic pass through every subsystem's duty cycle, and it's worth walking through in full, because the same discipline applies to almost any battery-powered BLE wearable, not just this specific device category.
Overview: What This Class of Device Actually Needs to Do
The device class here — call it a gesture-adherence wearable — needs to detect a specific physical motion (a tilt-and-hold gesture, in this case), timestamp it, store it locally if no phone is nearby, and sync that log over Bluetooth Low Energy when a paired app is in range. It needs to survive being worn continuously, charged infrequently, and — critically for the actual use case — it needs battery life measured in weeks, not days, because a device that needs daily charging defeats the purpose of unobtrusive adherence monitoring. The engineering problem is almost entirely a power budget problem wearing a firmware-architecture costume: every design decision, from MCU selection to sensor sampling rate to BLE advertising interval, is really a decision about where the device's finite energy budget gets spent.
Technical Details & Specifications: The Architecture That Got Us There
The final architecture centers on a DA14531, a Dialog Semiconductor (now Renesas) ultra-low-power BLE 5 SoC with an integrated Cortex-M0+ core, paired with an ICM-20948, a 9-axis IMU (accelerometer, gyroscope, magnetometer) from TDK InvenSense. The board is a 25mm circular PCB, powered by a 250mAh LiPo cell charged through a TP4057 or MCP73831 linear charge management IC.
Component | Part | Role | Typical current draw |
BLE SoC | DA14531 (Cortex-M0+, BLE 5) | Main controller, radio, flash logging | ~10 µA deep sleep, ~4.9 mA RX/TX peak |
IMU | ICM-20948 (9-axis) | Gesture detection (tilt + motion) | ~2.5 mA active, ~4 µA low-power accel-only mode |
Charger IC | TP4057 / MCP73831 | Li-Po charge management | Negligible in operation, active only while charging |
Battery | 250 mAh LiPo | Power source | N/A — the budget itself |
The BLE GATT layer uses a custom service (0xFFF0) with four characteristics: event data (0xFFF1, the logged gesture with timestamp), status (0xFFF2, battery level and device state), config (0xFFF3, adjustable detection thresholds), and crash log (0xFFF4, diagnostic data for field debugging). Firmware runs on the DA14531 SDK6, developed in Keil with SmartSnippets Studio for power profiling, debugged over SWD via a J-Link (P0_2 as SWDIO, P0_3 as SWCLK).
// Simplified event structure logged to flash on gesture detection --
// compact by design, since every byte written costs flash-write
// energy and every byte transmitted costs radio energy
typedef struct attribute((packed)) {
uint32_t timestamp; // seconds since epoch or device boot
uint8_t gesture_type; // detected gesture classification
int16_t peak_tilt_x; // raw IMU reading at gesture peak
int16_t peak_tilt_y;
uint8_t battery_pct; // battery level at time of event
} adherence_event_t; // 12 bytes per logged event
// FIFO flash logging -- events accumulate locally and sync in a
// batch when a BLE connection is available, rather than requiring
// an active connection for every single event
void log_event(adherence_event_t *evt) {
flash_write(next_log_addr, evt, sizeof(adherence_event_t));
next_log_addr += sizeof(adherence_event_t);
if (next_log_addr >= FLASH_LOG_END) {
next_log_addr = FLASH_LOG_START; // wrap, oldest events overwritten
}
}
Advantages: Why This Architecture, Specifically
The DA14531's specific advantage over a more general-purpose BLE SoC (an nRF52840, for instance) is that it was designed from the ground up for exactly this power envelope — its deep sleep current, on the order of 10 µA with RAM retention, is meaningfully lower than what a larger, more capable SoC achieves, precisely because it doesn't carry the silicon overhead of a more powerful core or additional peripherals this application doesn't need. For a device that spends the overwhelming majority of its life in a low-power waiting state, punctuated by brief bursts of IMU sampling and even briefer bursts of BLE activity, optimizing for sleep current rather than peak performance is the correct trade, and it's a trade a more general-purpose, more expensive, more capable SoC would make worse by default.
The ICM-20948's low-power accelerometer-only mode is the second load-bearing advantage: the IMU doesn't need its gyroscope or magnetometer running to detect a tilt gesture, and running only the accelerometer at a reduced sample rate cuts its current draw by roughly two orders of magnitude compared to full 9-axis operation. This matters because the IMU, not the BLE radio, turned out to be the dominant power consumer in the naive first-draft power budget — a lesson worth stating explicitly, because most engineers coming to a BLE wearable project assume the radio is where the power goes, and in a device that's mostly idle with occasional BLE syncs, the always-on sensor is frequently the bigger cost.
THE RULE: The radio is not always where the power goes. In a device that samples continuously but transmits rarely, the always-on sensor is frequently the dominant power draw — profile before optimizing, don't assume.
Challenges & Trade-offs: What Fighting for 39 Days Actually Cost
None of this came free. The accelerometer-only low-power mode that saves so much current also means the device can't distinguish a genuine adherence gesture from a similar-looking incidental motion (picking the device up, dropping it) using accelerometer data alone — the full 9-axis sensor fusion that would disambiguate these more reliably is too power-expensive to run continuously. The practical compromise: run accelerometer-only detection continuously as a low-power trigger, and only wake the gyroscope and magnetometer for a brief confirmation window when the accelerometer trigger fires, rather than running full sensor fusion at all times. This is a genuine accuracy-versus-power trade, and it means the device's false-positive rate is higher than a continuously-fused-sensor design would achieve — an explicit, documented compromise, not an oversight.
The FIFO flash-logging approach has its own limitation: flash write cycles are finite (typically on the order of 100,000 write/erase cycles for the flash technology used here), and a device logging frequently over a multi-year product lifetime needs wear-leveling consideration built in from the start, not retrofitted after a field unit's flash starts degrading. We under-scoped this in the first design pass — the initial FIFO implementation wrote to a fixed set of flash pages far more aggressively than necessary, and a wear-leveling revision (rotating write locations across a larger flash region rather than a tight FIFO wrap) was a genuine second-pass fix, not something we got right the first time.
BLE connection intervals present the last major trade-off: a shorter advertising interval makes the device more responsive when a phone comes into range (faster reconnection, less missed-sync risk) but costs more average current since the radio wakes more often to advertise. We settled on a tiered interval — frequent advertising for a short window after a gesture event (when a sync is most valuable), falling back to a much slower interval during idle periods — rather than a single fixed interval, which required more firmware complexity than a naive fixed-interval implementation but delivered meaningfully better battery life for the same practical responsiveness.
THE RULE: Every power-saving decision in a wearable trades against something — accuracy, responsiveness, or flash lifespan. The discipline isn't finding a free win; it's making each trade-off explicit and choosing deliberately, not by default.
Case Study: The First Power Budget Was Wrong, and Here's Why
The initial power budget spreadsheet, built before any hardware existed, estimated roughly 4 days of battery life against the 250mAh cell — nowhere close to the six-week target. The spreadsheet wasn't wrong about component-level current draws; it was wrong about duty cycle assumptions, which is a far easier mistake to make and a far more consequential one. The first draft assumed the IMU ran continuously at full 9-axis, full sample rate — a reasonable-sounding default for "the sensor needs to detect gestures reliably," and one that, on paper, looked like a minor simplification rather than a major cost.
Once actual hardware existed and current draw was measured directly (via SmartSnippets Studio's power profiling against the physical board, not just datasheet estimates), the IMU's continuous full-mode operation turned out to account for roughly 70% of total average current draw — far more than the BLE radio, which had been the team's initial focus for optimization. Switching to the tiered accelerometer-only-trigger-then-full-fusion-confirmation approach described above, combined with the tiered BLE advertising interval, took the measured average current down by a factor that translated the 4-day estimate into a genuinely field-measured 39 days on the same 250mAh cell. The lesson that generalizes past this specific device: a power budget built from datasheet numbers and assumed duty cycles is a starting hypothesis, not a design conclusion — it needs to be validated against actual measured current on real hardware before the architecture is considered settled, because duty-cycle assumptions are exactly where naive budgets go wrong, not component-level current figures.
Implementation Plan: Building This Class of Device, Step by Step
Start with a component-level power budget spreadsheet, but treat every duty-cycle assumption in it as unverified until measured on real hardware — datasheet current figures are reliable, assumed operating duty cycles are not.
Build the sensor duty-cycle architecture first, before BLE integration — identify which sensor modes are genuinely needed continuously versus which can run in a low-power trigger mode with a higher-power confirmation step, since this is typically the dominant power cost, not the radio.
Prototype on a development board with real power profiling tools (SmartSnippets Studio, or the equivalent for whichever SoC is chosen) as early as possible — don't wait for a final PCB to start measuring actual current draw against the budget.
Design the GATT profile around what actually needs to sync, not everything the device could theoretically report — a minimal characteristic set (event data, status, config, diagnostic log) keeps both firmware complexity and radio-active time down.
Implement flash wear-leveling from the first firmware revision, not as a later fix — estimate expected write frequency over the target product lifetime against the flash technology's rated write-cycle endurance before committing to a fixed FIFO scheme.
Tier BLE advertising interval against actual usage pattern — a fixed interval optimized for either responsiveness or power alone is very likely leaving battery life on the table that a context-aware tiered interval would recover.
Re-measure the full power budget on final hardware before committing to a battery capacity and enclosure size — the gap between a prototype's power draw and a production board's (different PCB layout, different component tolerances) is real and worth catching before the enclosure is tooled.
Conclusion: The Discipline That Generalizes
The specific numbers here — DA14531, ICM-20948, 39 days on 250mAh — are particular to one device, but the underlying discipline applies to essentially any battery-powered BLE wearable: build a power budget, measure it against real hardware rather than trusting datasheet-and-assumption estimates, find where the actual dominant power cost sits (which is frequently not where intuition points), and make every power-saving trade-off an explicit, documented design decision rather than a default. The gap between a 4-day first-draft estimate and a 39-day measured result wasn't one breakthrough optimization — it was systematically finding and fixing the gap between assumed and actual duty cycle across every subsystem, which is exactly the kind of unglamorous, iterative engineering work that separates a wearable that ships with a battery-life claim it can defend from one that doesn't.
EurthTech delivers AI-powered embedded systems, IoT product engineering, and smart infrastructure solutions — Hyderabad, India. www.eurthtech.com
Comments