Always Worn Wearable Battery Reality for Procurement
Duty Cycle Is Not Fixed — It Is Negotiated
An always worn wearable does not operate on a fixed duty cycle. Its power draw shifts with ambient temperature, skin conductivity, sensor activation frequency and how often the host app pushes notifications. For example, the health smart ring draws more current during sustained heart-rate sampling than during passive motion tracking — and both modes are triggered by firmware logic, not user input. That means duty cycle must be defined per hardware revision and validated against the intended use pattern: eight hours of sleep tracking plus four daytime syncs is not equivalent to twelve hours of continuous pulse-ox logging. Procurement teams must align firmware scope with battery test conditions before finalising the build.Charging Habit Determines Real-World Uptime
“Always worn” implies no daily removal — but it does not imply no charging. The difference between a weekly and a bi-weekly charge interval changes thermal stress on the cell, impacts long-term capacity retention, and alters the required safety margin in the battery management IC. For devices like the smart ring with charging case, the case itself becomes part of the power system: its internal battery must be rated, tested and documented alongside the wearable’s cell. Charging habit also affects importer obligations — under EU BattG and UK EPR rules, the charger and wearable are treated as one functional unit for reporting. That makes charger certification scope part of the procurement checklist, not an afterthought.Notification Load Is a Silent Power Drain
Each push notification triggers Bluetooth LE reconnection, sensor wake-up, local processing and display or haptic feedback. In a device worn 24/7, even low-frequency alerts compound over time. Unlike a smartwatch where users disable notifications manually, an always worn ring or patch relies on firmware-level filtering — which must be validated per revision. There is no universal “low power mode”: it is defined by how many sensors remain active, how often the MCU wakes, and whether BLE remains in advertising or connected state. That definition belongs in the firmware white-label agreement, not the datasheet.What This Process Cannot Do
This process does not produce a certified battery life claim for clinical or regulatory submission. No report exists that validates “seven days of continuous wear” under EN 62368-1 or IEC 62304 — those standards govern safety and software lifecycle, not runtime duration. Nor does any test simulate real-world variation in skin impedance, sweat composition or ambient RF noise. If a supplier presents a “7-day battery life” figure without stating the exact test conditions (temperature, notification frequency, sensor set enabled, firmware version), the importer should decline the quote. Runtime is a function of configuration, not hardware alone.Compliance Documentation Follows Hardware Revision
Battery compliance is not static. Each hardware revision requires fresh UN38.3 testing and SDS issuance — even if the cell manufacturer and chemistry remain unchanged. That is why the CE RED document checklist lists battery test summary as mandatory per revision, not per model family. Likewise, EN 1811 nickel release applies only to the skin-contact build, meaning plating, coating and assembly method must be confirmed before testing. These documents are supplied with production, not samples — and they cannot be backdated.Procurement Checklist: Battery-Related Decision Points
| Decision Point | Factory Policy Reference | Procurement Action |
|---|---|---|
| Battery datasheet availability | No capacity or Wh figure published before revision-specific datasheet exists | Require signed datasheet before PO confirmation |
| UN38.3 and SDS delivery | Supplied with every battery order, Wh rating printed on each unit | Verify print legibility and alignment with SDS value |
| Charging case certification | Treated as integral part of power system for BattG/DEEE | Confirm CE RED and RoHS apply to case + wearable as one unit |
| Firmware-defined power states | Validated per hardware revision, not model family | Require firmware test log showing sensor enable/disable sequence |
| Ring size exchange | Unopened wrong sizes exchanged within same run only | Order size kit before production start via MOQ, sampling and lead times |
| Warranty coverage | 12 months, 2 % free replacement parts shipped with order | Include spare battery units in initial shipment calculation |
| Health metric scope | Wellness guidance only, never diagnosis or monitoring | Validate packaging and app copy against Health & Wellness line policy |
- Review firmware scope before finalising battery test conditions — OEM/ODM services include firmware white-label from 2,000 units
- Book EN 1811 nickel release testing early for skin-contact builds — it applies to plating and coating, not just base metal
- Confirm charger and wearable are submitted together for CE RED — refer to the CE RED document checklist
- Use the how we build and test page to align your QC team with our IQC/IPQC/FQC/OQC gates
- Check MOQ thresholds: rings require 1,000 units, service robots 50 units quoted per project — see full list at MOQ, sampling and lead times
Questions buyers ask
Why does “always worn” make battery life harder to specify than for a smartwatch?
Because continuous wear demands stable performance across variable skin contact, movement, temperature and daily notification load — not just lab-rated capacity. Duty cycle becomes a function of user habit, not just firmware.
How do I verify battery claims when the device ships with no published cycle count or watt-hour rating?
Every battery order carries UN38.3 test summary and SDS, with watt-hour rating printed on each unit; no figure is quoted until the datasheet exists for that hardware revision.
What happens if a sample fails during field testing in Germany?
Unopened wrong ring sizes may be exchanged within the same run; all other failures are assessed at FQC/OQC gates using AQL 2.5 major / 4.0 minor, with 2 % free replacement parts shipped with the order.
What is not covered by the factory’s health metrics statement?
Health metrics are wellness guidance only — they do not constitute diagnosis, monitoring, fall detection, emergency response or clinical-grade output.
Related: more on ai health monitoring · buyer guides · customisation tiers