TinyML at the Edge: Battery-Friendly AI for Wearables

Wearables are becoming continuous health monitors. They track heart rate, motion, sleep, temperature, and more. Sending all that data to the cloud is expensive, slow, and often unnecessary. TinyML brings machine learning directly to microcontrollers and sensor hubs. The result is lower latency, better privacy, and longer battery life. But running AI on a device with kilobytes of RAM and milliwatts of power requires careful co-design. This article explains how to build, deploy, and operate TinyML models for wearable health applications.

Why Edge AI Matters for Wearables

A wearable that depends on the cloud for every inference faces three hard problems. First, latency: a fall, arrhythmia, or seizure needs a response in milliseconds or seconds, not after a network round trip. Second, connectivity: Bluetooth Low Energy and Wi-Fi are not always available, and radios consume significant power. Third, privacy: continuous physiological data is sensitive, and moving it off device expands the attack surface and regulatory burden.

Edge inference solves these problems by keeping raw data local. The device can detect an event, then send only a summary or alert. This reduces bandwidth and power. It also enables new features that work offline, such as gesture recognition, sleep staging, and abnormal heart rhythm detection.

• Latency: deterministic response without network jitter.
• Power: avoid radio transmissions for every sample.
• Privacy: raw biosignals never leave the device by default.
• Reliability: inference continues when connectivity drops.

The Hardware Reality: MCUs, NPUs, and Sensor Hubs

Wearable hardware is not a data center. It often uses an ARM Cortex-M or RISC-V microcontroller running at tens to hundreds of megahertz. SRAM may be 64 KB to 1 MB, and flash may be 256 KB to 2 MB. Some devices include a small neural processing unit or DSP extensions such as ARM Helium, CMSIS-NN, or a dedicated NPU. Sensor hubs can run simple inference while the main application processor sleeps.

Power sources are tiny batteries, often 100 to 300 mAh. Energy harvesting from motion or body heat is emerging but limited. Every microjoule matters. The hardware choice determines what models are possible. A Cortex-M0 without FPU will struggle with floating point math, while a Cortex-M55 with Helium can run quantized neural networks efficiently.

• MCU class: Cortex-M0+, M4, M7, M33, M55, or RISC-V.
• Memory: model weights, activations, and input buffers share SRAM.
• Accelerators: CMSIS-NN, Ethos-U, or vendor NPUs reduce energy per inference.
• Sensors: accelerometer, gyroscope, PPG, ECG, temperature, microphone.
• Radios: BLE, Zigbee, Thread, or Wi-Fi for alerts and updates.

Model Design Under Tight Constraints

Start with the clinical or user problem, not the model. Define the event, required latency, acceptable false positive rate, and power budget. For health monitoring, false negatives can be dangerous, but false positives erode trust. The model must be evaluated against those costs.

Choose the simplest architecture that meets the budget. For accelerometer data, a one-dimensional convolutional neural network or depthwise separable CNN often works well. For ECG or PPG, temporal convolutional networks and small recurrent networks can capture timing. Transformers are usually too large unless heavily pruned or distilled, but tiny attention variants are emerging.

Quantization

Quantization converts float32 weights and activations to int8 or int16. It reduces model size by up to four times and speeds up inference on integer hardware. Quantization-aware training simulates quantization during training so the model learns to be robust. Always validate on target hardware because operator support and rounding behavior can vary.

Pruning and Sparsity

Pruning removes weights that contribute little to accuracy. Unstructured pruning creates sparse matrices that need special runtimes. Structured pruning removes entire filters or channels and is easier to accelerate. Combine pruning with quantization for maximum compression, but measure accuracy after each step.

Knowledge Distillation

A large teacher model in the cloud can train a small student model on the device. The student learns from soft probabilities, not just hard labels. This often improves generalization when labeled data is limited, which is common in health applications.

Hardware-Aware Neural Architecture Search

NAS can search for models that optimize accuracy under latency, memory, and energy constraints. However, it is computationally expensive. Many teams get better results by manually designing a compact model and then tuning quantization and input features.

Data Pipelines for Edge Health AI

Data quality determines model quality. Wearable data is noisy, imbalanced, and highly personal. A model trained on one person may fail on another because of sensor placement, skin tone, motion patterns, or health conditions. Collect data from diverse subjects and include different activities and body types.

Labeling is a major bottleneck. Clinical labels may come from polysomnography, ECG patches, or expert annotation. Weak labels from user reports are cheaper but noisier. Use a clear label hierarchy and document labeling rules.

Preprocessing must match between training and deployment. If you filter, normalize, or window data differently on the device, accuracy will drop. Implement preprocessing in a shared library or test it with golden vectors.

• Windowing: use overlapping windows for continuous signals.
• Augmentation: time shift, scaling, noise injection, and channel dropout.
• Class imbalance: use weighted loss, focal loss, or resampling.
• Subject split: never split windows from the same subject across train and test.
• Privacy: anonymize data, minimize collection, and consider on-device learning.

Deployment Runtime and Toolchain

Several runtimes support TinyML on microcontrollers. TensorFlow Lite for Microcontrollers is widely used and supports many operators. CMSIS-NN provides optimized kernels for ARM Cortex-M. Edge Impulse offers an end-to-end pipeline for data collection, training, and deployment. STM32Cube.AI and ONNX Runtime can also target embedded devices.

Memory planning is critical. Most TinyML runtimes use a static memory arena for activations. If the arena is too small, inference fails; if it is too large, you waste SRAM. Profile the model on the target and tune the arena size. Avoid dynamic allocation in the inference loop.

Power Budgeting: The Real Constraint

Battery life is often the limiting factor. Estimate energy per inference as average power multiplied by inference time. Then add sensor sampling, preprocessing, and radio transmission. A model that is fast but keeps the CPU awake may use more energy than a slower model that sleeps between events.

Use duty cycling. Sample sensors at the minimum rate needed. Use a low-power wake-up trigger, such as a motion threshold or a tiny always-on classifier, to activate the larger model only when necessary. Batch sensor reads. Keep the radio off unless an alert or sync is required.

• Active power: CPU and accelerators at operating voltage and frequency.
• Sleep power: deep sleep current of MCU, sensors, and power management IC.
• Duty cycle: percentage of time the system is active.
• Radio cost: BLE connection intervals and payload size dominate.

For example, if an inference takes 10 ms at 20 mW and runs once per second, the average compute power is about 0.2 mW. If the MCU sleeps at 5 microwatts for the rest of the second, the total is still dominated by compute. Reducing inference frequency or using a wake-up trigger can cut power dramatically.

Security and Privacy at the Edge

Edge devices are physically accessible, so assume an attacker can probe them. Protect model weights and raw health data with secure boot, encrypted flash, and debug lockout. Use signed firmware updates and rollback protection. Never store long-term secrets in plaintext.

Privacy is both a legal and ethical requirement. Health data is regulated by laws such as HIPAA, GDPR, and local medical device rules. Minimize data collection. Process raw signals on device. If data must leave, aggregate or anonymize it. Consider differential privacy for any shared model updates.

• Threat model: device theft, malicious firmware, adversarial sensor input.
• Model protection: encryption at rest and secure key storage.
• Data protection: on-device inference, no raw data by default.
• Update security: signed images, version checks, rollback support.

Testing, Validation, and Monitoring

Testing TinyML is harder than testing cloud models. You must verify preprocessing, inference, and postprocessing on the actual device. Build a hardware-in-the-loop test bench that feeds recorded sensor data and compares outputs against a reference implementation.

Track metrics that matter: accuracy, sensitivity, specificity, false positives per day, latency, peak RAM, flash size, and energy per inference. Test across temperatures, battery voltages, and sensor placements. Use shadow mode to run a new model alongside the current one without affecting users.

After deployment, monitor for drift. Sensor aging, firmware changes, and population shifts can degrade performance. Collect anonymized performance statistics and user feedback. Plan a rollback path if a model causes problems.

Case Study: Real-Time Fall Detection on a Smartwatch

Consider a smartwatch that detects falls using a 3-axis accelerometer and gyroscope at 50 Hz. The goal is to detect a fall within one second while minimizing false alarms during hand washing, sitting down, or dropping the watch.

The pipeline uses a 2.5-second sliding window with 50 percent overlap. Preprocessing computes magnitude, applies a low-pass filter, and normalizes per window. The model is a depthwise separable 1D CNN with three blocks, followed by global average pooling and a small dense layer. It is quantized to int8 for a Cortex-M4F at 64 MHz.

The model uses about 28 KB of RAM and 74 KB of flash. Inference takes 12 ms and consumes roughly 0.25 mJ. A low-power motion threshold wakes the system only when acceleration exceeds a baseline. Heart rate and posture features confirm the event before an alert is sent over BLE. In this illustrative example, sensitivity is 96 percent and false positives are reduced by 60 percent compared with a threshold-only detector.

Implementation Checklist

• Define the event, latency, power, memory, and accuracy budgets.
• Collect diverse, well-labeled data and split by subject.
• Keep preprocessing identical between training and deployment.
• Choose a compact architecture and quantize with validation.
• Profile on target hardware, not just on a desktop.
• Use static memory and avoid dynamic allocation in the inference loop.
• Protect model weights and health data with secure boot and encryption.
• Test with hardware-in-the-loop and golden vectors.
• Plan for secure updates, monitoring, and rollback.

Common Pitfalls

• Training on filtered data but deploying raw data, or the reverse.
• Leaking windows from the same subject into both training and test sets.
• Ignoring sensor power, which can dominate the total energy budget.
• Assuming a model that fits flash also fits SRAM.
• Forgetting thermal limits and battery voltage drop under load.
• Overfitting to lab conditions and failing in real-world motion.
• Treating privacy as an afterthought instead of a design constraint.

The Road Ahead

TinyML for wearables is advancing quickly. RISC-V vector extensions, analog in-memory computing, and spiking neural networks promise lower energy per inference. Federated learning can personalize models without sharing raw data. Tiny transformers and event-based sensors may enable richer health monitoring while staying within power budgets.

The biggest gains will come from co-design. Hardware, model, firmware, data, and clinical validation must be developed together. Teams that treat battery life and privacy as first-class requirements will build wearables that users trust and wear every day.

Conclusion

Running AI on wearables is not simply shrinking a cloud model. It is an engineering discipline that balances latency, power, memory, privacy, and accuracy. Start with a clear problem and strict budgets. Choose simple models, quantize carefully, and measure on the real device. With the right pipeline, TinyML can deliver immediate, private, and battery-friendly health insights at the edge.