Power Profiling a Smartwatch¶

Power profiling turns expected daily use into a battery-life estimate and, more importantly, a ranked list of the loads worth optimizing. This article uses the supplied English Smartwatch Power Profile Data workbook as a worked example. It shows how to convert user behavior into mAh per day, identify the loads that dominate the budget, and turn a spreadsheet model into a measurement plan.

Use this page with the Low-Power Overview for architecture and firmware guidance, and Power Measurement and Validation for the measurement workflow that validates the model.

Smartwatch System Overview¶

Start by defining the model boundary. This workbook represents a battery-powered smartwatch with an MCU, AMOLED display, haptic motor, and an unallocated Other load bucket. It does not identify the panel size, resolution, brightness setting, radio architecture, or individual sensors. Treat the display-current entries below as measured or assumed AMOLED operating points, not as a specification for a particular panel. Treat Other as a modelling boundary, not as one physical component.

Power Consumption by Scenario¶

A scenario is a complete user or system event, rather than one isolated part. A message notification can wake the MCU, light the AMOLED display, drive the haptic motor, and keep background loads active. In the source matrix, every Display row refers to the AMOLED display. The matrix keeps each scenario's component rows together and retains calculated daily values for traceability. The daily frequency and duration assumptions that drive those values appear in the next section.

*The workbook labels this factor as power efficiency, but it is a voltage-ratio helper rather than a measured regulator efficiency. The following section explains the consequence for battery-life estimates. Daily-charge and percentage values in this table are rounded from the workbook; use the downloadable file for the exact formulas and values. Use the ranked tables below to set priorities, then return to this matrix when you need to inspect the current or voltage assumption behind a contribution.

flowchart LR
    A["Define daily user behavior"] --> B["Assign current and active time to each load"]
    B --> C["Sum battery-side mAh per day"]
    C --> D["Rank scenario and component contributions"]
    D --> E["Measure the largest contributors on hardware"]
    E --> F["Update assumptions and repeat"]
    F --> B

Convert a Scenario Into Daily Charge¶

For a load whose current is already expressed at the battery, its daily charge is straightforward:

daily_charge_mAh = current_mA x active_time_seconds_per_day / 3600

For a load supplied through a regulator, calculate battery-side current before applying the time term:

battery_current_mA = (load_voltage_V x load_current_mA) /
                     (battery_voltage_V x regulator_efficiency)

Use measured regulator efficiency at the intended load current. A regulator's peak-efficiency headline is rarely useful for a watch that spends much of its day at light load.

Check the Workbook's Conversion Assumption¶

The workbook labels one helper column as supply efficiency, but calculates it as load voltage / battery voltage. Its subsequent energy formula divides by that helper and then divides by battery voltage again, which cancels the voltage terms. In effect, the baseline calculation assumes ideal power conversion.

The ranking remains useful as a first-pass view of the declared current and time assumptions, but it is not a final battery budget: real regulator losses can change close comparisons and make the absolute battery-life estimate optimistic. For a production budget, replace that helper with the measured regulator efficiency for each rail and load range, include quiescent current, and account for battery-protection and charger-path losses in the finished product.

Calculate Daily Consumption from Product Usage¶

The same scenario can be negligible or dominant depending on how the product is used. The workbook enables a representative day: baseline standby, notifications, incoming-call alerts, raise-to-wake, heart-rate and SpO2 checks, exercise recording, alarms, sleep monitoring, and app synchronization. It sets NFC, Bluetooth calling, and both AOD scenarios to zero, so those features are not included in the 13.15-day result.

The blank scenario cells in the source matrix are intentional: each named scenario is followed by its display, haptic-motor, and Other component-load rows. Those rows inherit the daily occurrence and duration from the scenario row above, so the source names each scenario only once.

The model's scenario ranking is more actionable than its final battery-life number. The largest contributors are the first places to test an optimization hypothesis.

pie showData
    title Daily Charge by Enabled Scenario
    "Raise-to-wake" : 4.9020
    "Notifications" : 3.9996
    "Sleep monitoring" : 2.3040
    "Exercise" : 2.1839
    "Standby" : 2.0679
    "Incoming calls" : 0.7999
    "Alarm" : 0.6910
    "Manual SpO2" : 0.3929
    "Automatic HR" : 0.2616
    "App sync" : 0.0800

The first two screen-on interactions account for about half of the modelled daily charge. That is a testable result, not simply a generic claim that displays use power. Before spending effort on smaller loads, confirm the true raise-to-wake count, display-on duration, brightness, refresh behavior, and notification policy.

pie showData
    title Daily Charge by Explicit Workbook Category
    "AMOLED display (9.56 mAh/day)" : 9.5595
    "MCU (4.62 mAh/day)" : 4.6163
    "Haptic motor (2.22 mAh/day)" : 2.2203
    "Other / unallocated (1.29 mAh/day)" : 1.2866

The chart deliberately leaves the final slice as Other / unallocated. The workbook does not provide independent battery-side values for Bluetooth, the accelerometer, or the gyroscope. Its disabled Bluetooth-calling scenario does not prove that Bluetooth costs zero: the app-synchronization scene may also use a radio path, but the workbook does not split that energy out. Likewise, the sensor contribution may be included in Other, but it cannot be separated into accelerometer and gyroscope values from the supplied data.

To turn this into a five-way MCU/display/haptic/Bluetooth/accelerometer-and-gyroscope chart, add separate rows for Bluetooth idle and transfer states, accelerometer modes and duty cycles, and gyroscope modes and duty cycles. Measure each row at the battery input, or apply the measured regulator efficiency before adding it to the battery-side mAh total. Then replace the Other / unallocated slice rather than adding a second, overlapping sensor or Bluetooth slice.

Separate Standby MCU, Active MCU, and Sensors¶

The workbook provides an explicit MCU bucket, but it does not isolate graphics rendering as its own code path. The most defensible split is therefore between its baseline-standby MCU entry, MCU work in display-on interaction scenarios, and other scheduled MCU work.

pie showData
    title Daily MCU Charge by Activity Group
    "Baseline standby" : 1.4854
    "Display-on interaction" : 1.3013
    "Sleep monitoring" : 1.6640
    "Automatic heart-rate check" : 0.1656

Two comparisons prevent a misleading conclusion:

• Standby MCU versus display-on MCU: baseline standby contributes 1.49 mAh/day, slightly more than the 1.30 mAh/day MCU contribution from all display-on interaction scenarios combined. In this baseline, reducing standby current is at least as important as making individual graphics bursts shorter.
• Standby MCU versus all active MCU work: all non-standby MCU entries total 3.13 mAh/day, or 2.11 times the baseline-standby MCU entry. The largest opportunity is not graphics alone: the 8-hour sleep-monitoring scene dominates the active MCU portion.

The workbook provides no dedicated sensor category. Its Other bucket is the only place that could include sensor consumption, but it may also include PMIC, radio, leakage, or other background loads. It totals 1.29 mAh/day (7.28%). Therefore, even under the conservative assumption that all Other consumption belongs to sensors, the explicit MCU bucket is more dominant: 4.62 mAh/day versus 1.29 mAh/day, or 3.59 times higher. The true sensor-only share can only be determined after the model separates sensor rails from the generic Other entry.

Turn the Ranking Into Design Work¶

Work from the largest modelled contributor downward, then validate the order with measurements. In this model, a sensible sequence is:

1. Display policy: Measure the full raise-to-wake trace. Reduce false gesture triggers, screen-on duration, brightness, full-screen redraws, and unnecessary animation before chasing MCU microamps.
2. Notification policy: Coalesce non-urgent notifications where the product experience permits. Review whether every event needs both display and haptic feedback.
3. Connected standby: Confirm that the MCU reaches the intended sleep mode after each event. Audit periodic timers, polling loops, Bluetooth callbacks, and power-management votes.
4. Haptic patterns: Tune amplitude and duration using perceptual tests. A shorter or softer pattern can reduce energy without making alerts less usable.
5. Long-running sensing: Profile sleep monitoring and exercise recording as complete scenes, including sensor duty cycle, processing, memory traffic, and radio behavior.

Do not optimize an isolated spreadsheet number. An apparently efficient change can increase wake frequency, reduce user satisfaction, or extend active time enough to erase the expected energy saving.

Validate the Model on Hardware¶

The model becomes useful when it is continuously calibrated against measurements. For every top contributor, record the battery or supply voltage, temperature, board revision, firmware revision, enabled radios, display mode, and measurement range.

Keep the Profile Honest¶

• Treat disabled scenarios as unbudgeted, not free. The workbook currently assigns zero charge to NFC, Bluetooth calling, and AOD scenarios.
• Keep separate scenarios for user-visible features and background work. This makes product trade-offs visible during reviews.
• Measure at the battery input when possible. Rail-level measurements are still valuable, but they need regulator losses and quiescent current added before they become battery-life numbers.
• Change one assumption at a time, then compare mAh per day rather than only instantaneous current.
• Re-run the profile whenever a display policy, Bluetooth setting, sensor cadence, PM policy, or major firmware feature changes.

Key Takeaways¶

• Battery life is the effective battery capacity divided by daily charge consumption; this model projects 13.15 days from 232.5 mAh of usable capacity and 17.68 mAh/day of enabled load.
• In the supplied baseline, display behavior dominates the budget. Raise-to-wake and message notifications alone account for about half of daily charge.
• Scenario ranking tells you where to measure and optimize first; it is more useful than a single average-current number.
• Use actual converter efficiency and quiescent current before treating a workbook forecast as a production battery-life claim.
• Repeat the loop: model realistic behavior, measure the dominant scenes, update the assumptions, and then optimize.