A wearable's display dominates its power budget far more than a phone's, because the screen is the only subsystem active nearly 100% of the time. This model separates two operating modes, each with its own duty cycle:
P_display = P_base + n_lit · p_pixel · brightness
Ambient: sparse monochrome digits, 1–60 Hz redraw, dim
Active: full-color face, 60 Hz, bright — n_lit and p_pixel both jump
P_total = P_display + P_complication + P_radio_sync
P_complication ∝ (updates/min) · E_cpu_wake (CPU wake to redraw a tile)
P_radio_sync ∝ (syncs/min) · E_ble_packet (BLE connection event, phone↔watch)
Raise-to-wake blends in a fraction of full Active power equal to the
share of each minute actually spent bursting bright:
f_wake = min(1, (raises/min · 3 s) / 60 s)
P_display(ambient) = P_dim·(1−f_wake) + P_active_full·f_wake
battery(t) = battery(0) − ∫ P_total(t) dt / (V · C_mAh)
- Ambient vs Active — AOD keeps most AMOLED pixels off (true blacks cost ~0 power per-pixel) and redraws only the digits/hands at a low rate; Active lights the whole panel at full brightness every frame, which is why raising your wrist for even a few seconds costs disproportionately more energy than an hour of ambient ticking.
- Complications — each watch-face tile (heart rate, weather, steps) that refreshes wakes the CPU briefly even in ambient mode; more tiles/minute directly raises baseline draw.
- Phone sync — WatchConnectivity / Wearable Data Layer transfers happen over a low-energy BLE connection; every additional sync per minute adds one radio connection event's worth of energy.
- Raise-to-wake — each gesture triggers a full-brightness Active burst before the display times back out to ambient, so its per-event cost is set by the Active power level, not the Ambient one. Fixed here: the original 3D engine computed this burst's contribution to average power as "active-hours accrued per minute" and used that number directly as a 0–1 fraction without ever converting it back to a fraction of that minute (missing a ×60), so raising your wrist 15×/min moved instantaneous draw by only ~1% instead of the ~75%-active-fraction it should. This 2D model uses the corrected fraction — verified numerically against the original formula before shipping.
Real-world relevance: this is exactly the trade-off Apple Watch's watchOS and Wear OS scheduler tune automatically — capping complication budgets and coalescing BLE syncs — to hit their advertised 18–36 hour battery life.