A wearable that needs charging every night is a wearable people stop wearing. Most of the battery blame lands on the sensor, but on a typical band or patch the radio consumes more energy than the accelerometer, the microcontroller, and the display combined. The reason is rarely the volume of data — a full day of thirty-second heart-rate samples is a few kilobytes — it is how long the radio stays awake to move it.

Radio On-Time, Not Data Volume

A Bluetooth Low Energy transceiver draws roughly 5 to 15 milliamps while transmitting or receiving and under a microamp while asleep. That is a ratio of ten thousand to one. A coin-cell wearable with a 220 mAh battery targeting three weeks of life has about 0.4 mAh per hour to spend on everything, so radio duty cycle is the entire design problem.

Moving one kilobyte in a single tight burst costs a fraction of what the same kilobyte costs dribbled out over an hour, because each connection event carries fixed wake-up, synchronization, and teardown overhead regardless of payload. Every optimization below is a variation on the same idea: fewer, denser radio events.

Connection Parameters Are the Main Dial

A BLE connection wakes on a fixed interval whether or not there is anything to send. The spec allows 7.5 milliseconds to 4 seconds, and the difference between the ends of that range is roughly two orders of magnitude in idle radio current.

  • Connection interval — use a short interval only while actively transferring, then renegotiate to something long. A device that holds 30 ms permanently because it was convenient during development is burning most of its battery on empty connection events.
  • Peripheral latency — lets the wearable skip a set number of connection events when it has nothing to say, keeping the link alive at a fraction of the cost while preserving fast response when the phone initiates.
  • Supervision timeout — must exceed the interval multiplied by latency with margin, or the link drops and you pay the far larger cost of reconnecting.
  • MTU and data length extension — negotiate the largest packet both sides support. Moving 244 bytes per event instead of 20 cuts the number of events by an order of magnitude for the same payload.

Both platforms constrain what a peripheral may request, and iOS in particular enforces its own accepted ranges regardless of what your firmware asks for. Design the power budget against what the phone will actually grant, not what the specification permits. The firmware side of this — GATT structure, notification versus indication, and connection event handling — is covered in BLE firmware development.

Batch on the Device, Never Stream

The single largest saving available is refusing to send data as it is produced. Buffer readings in flash or RAM, then transfer the accumulated block when a sync opportunity arrives.

Store timestamped records in a compact binary format rather than JSON — a struct of a few bytes per sample instead of eighty characters of text. Apply delta encoding, since consecutive sensor readings differ by small amounts and the differences pack into far fewer bits than the absolute values. Downsample on the device when the application does not need full resolution: an activity tracker rarely needs raw accelerometer data off the wrist when step counts and activity classification can be computed on the microcontroller. That decision drives how much storage the part needs, which is worth settling early using the reasoning in how much flash and RAM your microcontroller needs.

A day of data compressed to eight kilobytes transfers in a handful of connection events. The same day streamed live costs a persistent short-interval connection for twenty-four hours, and that is the difference between three weeks and three days of runtime.

What iOS Will and Will Not Let You Do

The phone side imposes limits that no firmware trick evades. An iOS app cannot wake itself on a schedule to poll a peripheral. What it can do is declare the central background mode, which lets the system relaunch the app when a known peripheral connects or sends a notification, and use state preservation and restoration so the app resumes its connection after a termination.

The practical pattern is to invert the initiative: the wearable advertises or notifies when it has data, iOS wakes the app briefly, the app pulls the block and returns to suspension. Background execution windows are short, on the order of seconds, so the transfer must be resumable and idempotent across interruptions. Scanning for peripherals in the background is also slower and filtered by service UUID, which means your advertising packet has to carry the right service identifier to be found at all.

Android is more permissive but less consistent: Doze mode batches background work, manufacturer battery managers kill long-lived connections without warning, and background BLE scanning requires location permission with the consent implications explained in Bluetooth and location permissions. A foreground service with a persistent notification is the reliable path when continuous connection genuinely matters, at the cost of a visible notification the user may resent.

Sync on Charge, and Other Free Opportunities

The cheapest sync is one that happens while the device is on a charger, where battery cost is exactly zero. Detect charging in firmware, raise the connection interval, and flush everything buffered. For a wearable charged nightly this alone can carry the entire data pipeline.

Layer opportunistic syncs on top: transfer when the user opens the app, when the device detects it has been stationary for a while, or when buffered data approaches a storage threshold. Add one guaranteed low-frequency sync — every six or twelve hours — so a device that never gets opened still reports in. If you push data onward to Apple Health or Google Fit, do it from the phone after the block arrives rather than record by record.

Two design factors sit underneath all of this: encryption adds a small but real per-packet cost that belongs in the budget rather than as an afterthought, as discussed in securing the BLE connection, and the physical form factor caps the battery you can carry in the first place, which is where the wearable design constraints meet the electronics.

Building the Sync Architecture

Projects House designs wearable firmware, BLE profiles, and companion apps as one power budget rather than three separate projects. Send your target battery life, sensor set, and data resolution through our contact form.