Technical decision guide · Wearable device

How to plan battery life and BLE connectivity for wearable devices

The battery life of a wearable device does not depend solely on battery capacity or BLE processor selection. When the sensor operates, how the data is transferred, how the connection is maintained, and the physical layout of the product should be evaluated together. The design goal is established over the full use cycle and measured in the prototype.

Product development guide · · Publication:

Describe your project Read the guide
Technical illustration of the combined battery, BLE radio, sensor and enclosure design of a wearable device
Conceptual technical demonstration · Technical decision guide · Wearable device
CalculationCurrent × duration × frequency of use
ConnectionBLE selected for data and response requirements
ControlMeasuring consumption in the actual enclosure

VOMRO engineering approach

Define the usage profile before asking how many days the device will run.

The device's occasional reporting of an event and its continuous transfer of sensor data do not create the same energy demand. Functions such as display, vibration, light, local recording and reconnection may change the total consumption. When the user wears the product and how they charge it also affects the decision between battery volume and ergonomics.

The initial document should define operating phases, data frequency, acceptable response time and expected charging arrangements together. Battery life begins as a target. Initial calculations from component specifications are updated using actual hardware and software measurements. The following decisions explain the inputs to that calculation and how the BLE connection will be assessed.

01

1. Calculate consumption with all operating phases

Divide the duty cycle into phases such as sleep, wake-up, sensor reading, data processing, radio activity and user notification. Average current can be estimated by summing each phase's current multiplied by its duration, then dividing by the total duration. Measure the board's total current for components operating together in the same phase. This allows the brief consumption of a sensor and the effect of a continuously powered auxiliary circuit to be assessed on the same basis.

Dividing the capacity by the average current gives approximate operating time; Available capacity, temperature and aging allowances should be considered separately. Voltage drop due to instantaneous radio current or reporting load is also checked. If the frequency of use varies, basic and intensive usage profiles can be prepared instead of a single result. These profiles are not a promise of battery life; They are design inputs that explain what conditions the measurements correspond to.

  • Current and duration of all stages, including sleep
  • Usable capacity of the battery and instantaneous loads
  • Basic and heavy use profiles
02

2. Select sleep mode according to connection need

A processor's low-power modes retain different functions. Examine which memory contents are retained, which peripherals remain active and which event wakes the device. Sensor-triggered wake-up on motion and periodic timer wake-up are different architectures. Continuously powered regulators, indicators and sensors also contribute to total sleep current.

The deepest sleep mode may be unsuitable when a connection must remain active. For example, Espressif's ESP32 documentation states that explicitly entered Light-sleep and Deep-sleep modes do not preserve wireless connections, and discusses modem sleep and automatic power management for maintaining them. Check this behaviour for the processor family. Once wake-up, sensor preparation and reconnection energy are included, the lowest instantaneous current does not always give the lowest consumption per cycle.

  • Wake-up source and memory contents to retain
  • Sleep consumption of sensors and auxiliary circuits
  • Decision to maintain or re-establish the connection
03

3. Match BLE parameters to data and response requirements

BLE advertising can make a device discoverable or broadcast information without a connection. A connection may be used when two-way data exchange and configuration are required. Bluetooth SIG's explanation describes this distinction. Fast discovery during setup and low consumption in everyday use are different needs, so advertising behaviour can change with device state.

Connected operation tests data volume, packet frequency, connection parameters and the target phone's behaviour together. If frequent transmission is unnecessary, buffering samples locally may be an option, though it can increase latency and memory needs. Define sensor sampling and radio transmission rates separately. Include reconnection, the phone moving out of range and update scenarios in the usage profile. Pairing and access permissions must be considered alongside energy decisions.

  • Discoverability, advertising and connected operation
  • Balancing data frequency, latency and local logging
  • Pairing, access and reconnection flow
04

4. Evaluate the battery and antenna in the actual enclosure

In compact devices, the battery, board, antenna, screen and connection parts share the same volume. Metal parts, body material, and proximity to the body can affect radio behavior. The layout around the antenna is regulated according to the design rules of the selected antenna and radio component. The connection attempt on the open board alone does not represent the use in the finished body.

Battery placement, cables or contacts and charging access must be resolved together. A physical sample is used to assess how users put on, remove and dock the device for charging. Strap or clip movement may affect sensor placement. A 3D prototype checks dimensions and assembly, while production materials and final assembly still need separate assessment. Ergonomics and electrical decisions can then be tested on the same product.

  • Placement harmony between antenna, battery and body
  • Connection testing in the actual wearing configuration
  • Charging access, installation and service evaluation
05

5. Turn the measurement into a repeatable test record

Both long sleep intervals and short radio pulses should be visible in the current recording. The measuring setup must not alter the power supply or connection behavior of the device. Test conditions include battery status, software version, connection settings, sensor activity, and number of notifications. After the first measurement on the open board, the evaluation is repeated with the real body and usage profile.

VOMRO develops electronics, embedded software, mechanics and prototypes in wearable device projects with this common test plan. The source code, design files and technical documents of the project are delivered at the end of the project. In the deliverable, power management decisions, data model, compilation information, and relevant test conditions are initially clarified; third party licenses are disclosed. The basic function of the device, data need, attachment style and charging expectation form a sufficient framework for the first meeting.

  • Current recording covering sleep and momentary loads
  • Version, connection setting and usage profile registration
  • Source files, designs and technical test documentation
Match energy decision to usage need in wearable device
Need for useApproach to be evaluatedTarget benefitTopic to check together
Infrequent event reportingEvent-triggered wake-up and brief activityReduce active timeWake-up source and reliable event detection
Regular sensor recordingPlanning sampling and transmission separatelyGrouping radio activityMemory, data loss and acceptable latency
Quick response to the phoneTesting connection and advertising parametersBalancing consumption with response timeReal behavior on target phones

How it works

Turn decisions into a project plan.

Not every project looks the same; however, the measurable requirement, controlled revision, and field verification steps remain unchanged.

  1. 01

    Define the usage profile

    Document the measurement, data transfer, notification and charging patterns.

  2. 02

    Set up an energy budget

    Evaluate all operating phases with their current and duration.

  3. 03

    Test the connection

    Test BLE behaviour against the target phone, data and latency requirements.

  4. 04

    Measure on actual product

    Record the results with the enclosure, battery and software working together.

Frequently asked questions

Before starting the project

The technical scope, deliverables and test plan are clarified together according to the requirements of your project.

Does every device using BLE offer long battery life?

The operating time depends on the consumption and usage of the entire device. The current and duration of the sensor, processor, auxiliary circuits, data transmission and notifications must be calculated and measured together.

Is a larger battery always the right solution?

Larger capacity affects size, weight and charging pattern. First, the consumption sources in the working cycle are examined; Battery selection is made in conjunction with the energy target and mechanical limits.

When is the connection and battery testing of the prototype done?

Measurements can begin on the first hardware and software sample. Results are reviewed as layout and enclosure change, then validated again on the integrated prototype using the actual wearing arrangement and defined usage profile.

Related content

Engineering for devices used on the body

Wearable technology and BLE device development

 We design the behavior of the device

Embedded software and embedded system development

 Design that makes the function visible

Industrial design for electronic products

 Physically test the model

3D prototyping and product validation

All product development services

Your project, your product

Developed confidentially and delivered with source files.

We may work with a confidentiality agreement (NDA) before sharing technical details. At the end of the project, we deliver the source codes, design files and technical documents we have developed to you.

  • NDA before sharing technical information
  • Clear deliverables agreed at the outset
  • Source and technical files at the end of the project
Our confidentiality and delivery process
Let's start with your idea

Let's talk about the product you dream of and the need you want to solve.

Submit a project request +90 534 487 98 02