Blog · Power
Why the radio, not the sensor, sets battery life
In a connected cardiac monitor, almost nobody optimises the part that actually burns the power.
When a team designs a wearable cardiac monitor, the power conversation almost always starts at the analogue front end. That is understandable: it is the delicate part, it determines signal quality, and it gets the most attention on the datasheet.
But the power budget is rarely decided there.
Where the energy goes
In a device that transmits, consumption tends to break down by order of magnitude like this: the analogue front end and converter operate in microwatts or a few milliwatts; the processor, in intermittent active mode, somewhat above that; and the radio transceiver, when it turns on, draws tens of milliamps.
The difference is not only in instantaneous current but in the product of current and time. Every transmit window means powering up the radio, synchronising, transmitting and waiting for acknowledgement. The larger the payload, the more windows are needed and the longer the radio stays on.
The practical consequence: halving the bytes that leave the device has an effect on battery life that no front-end optimisation can match.
Why doing it in firmware is not enough
The obvious objection is that compression can already be done in software, on the microcontroller that is already there. And that is true — up to a point.
- The MCU has to wake up to compress, and waking it costs energy.
- The energy cost of compression becomes dependent on whatever else the processor is running, which makes the budget hard to bound.
- CPU time spent compressing is time not available for arrhythmia detection, link management or the rest of the application.
A dedicated hardware block inverts that relationship. Compression happens in the data path, without processor involvement, at a bounded and predictable energy cost. The MCU gets to sleep more, not less.
The design criterion that follows
From this comes the constraint that governs the design of a compression block for this class of device: the core has to consume less energy than the transmission it removes. If it fails that test, its compression ratio does not matter.
It is an uncomfortable constraint, because it sharply limits how much logic you can spend. It is also why a general-purpose algorithm, however good it is at compressing, is almost never the right answer here: it spends too much for the saving it achieves.
What to measure
If you are evaluating compression for a device like this, the useful questions are not about compression ratio in isolation. They are these:
- How many joules does it cost to compress one minute of signal?
- How many joules does that compression save in radio-on time?
- What is the net balance on your real transmission profile, not the vendor's?
- What happens to that balance when the link degrades and retransmissions kick in?
The fourth is usually the one that decides, and it is the one least often measured.