|
Bogdan Timofte
authored
a month ago
|
1
|
# Charging While Off
|
|
|
2
|
|
|
|
3
|
## Definition
|
|
|
4
|
|
|
|
5
|
A device that **can charge while off** can continue charging its battery when it is powered down (screen off, OS not running).
|
|
|
6
|
|
|
|
7
|
In practice, this is the *general rule* for many battery-powered devices. The important exceptions are:
|
|
|
8
|
|
|
|
9
|
- some devices **auto-boot when power is connected**, so they do not reliably stay off while charging
|
|
|
10
|
- some devices **cannot be turned off**, so an off-state session is not possible
|
|
|
11
|
- some devices **only charge while off**, meaning they must be powered down to accept charge
|
|
|
12
|
|
|
|
13
|
## How the app should decide ON vs OFF
|
|
|
14
|
|
|
|
15
|
When information is available, the app should decide the charging mode automatically:
|
|
|
16
|
|
|
|
17
|
- If the available information clearly indicates **ON** or **OFF**, use it.
|
|
|
18
|
- If the information indicates multiple plausible variants, show a **non-intrusive hint** that the user should specify whether the session is **ON** or **OFF**.
|
|
|
19
|
- If no information is available, the app assumes **ON** for devices that support **both ON and OFF charging** (for capacity learning and confidence rules).
|
|
|
20
|
|
|
|
21
|
## Why it matters for battery capacity estimation
|
|
|
22
|
|
|
|
23
|
Off-state charging sessions tend to produce the cleanest signal for estimating battery capacity (energy stored):
|
|
|
24
|
|
|
|
25
|
- Most of the measured input energy goes into the battery, instead of being consumed by the device itself.
|
|
|
26
|
- The result is less affected by background processes, radios, thermal throttling, screen usage, and OS-level behavior.
|
|
|
27
|
|
|
|
28
|
## App implications
|
|
|
29
|
|
|
Bogdan Timofte
authored
a month ago
|
30
|
### Explicit session setup
|
|
|
31
|
|
|
|
32
|
- Starting a charge session should be **explicit**: the user picks the device, the charging type (**wired** / **wireless**), and the charging mode (**on** / **off**) whenever the device supports both.
|
|
|
33
|
- Wireless sessions also require the user to pick the **charger** that is being used.
|
|
|
34
|
- The app should ask for an **initial battery checkpoint** before the session begins.
|
|
|
35
|
- If no stop threshold is known for the selected combination of charging type + charging mode, the session should remain **open-ended** until the user pauses or stops it.
|
|
|
36
|
|
|
Bogdan Timofte
authored
a month ago
|
37
|
### Defaults
|
|
|
38
|
|
|
|
39
|
- **Default assumption (for capacity learning):** if the user does not specify otherwise, a device is treated as **on/unknown-state** while charging.
|
|
|
40
|
|
|
Bogdan Timofte
authored
a month ago
|
41
|
### Stop-threshold learning for wireless charging
|
|
|
42
|
|
|
|
43
|
- Wireless stop-threshold learning must subtract the charger's **idle current** (no-load current).
|
|
|
44
|
- Without that idle-current measurement, the app must **not** learn a wireless end-of-charge threshold from the session.
|
|
|
45
|
- The UI should warn both in the **charger detail** and in the **session view** when that idle-current measurement is missing.
|
|
|
46
|
|
|
Bogdan Timofte
authored
a month ago
|
47
|
### Capacity estimation priority (conceptual rule)
|
|
|
48
|
|
|
|
49
|
When we have both:
|
|
|
50
|
|
|
|
51
|
- high-confidence capacity determinations from **off-state** charging, and
|
|
|
52
|
- lower-confidence determinations from **on/unknown** charging,
|
|
|
53
|
|
|
|
54
|
then:
|
|
|
55
|
|
|
|
56
|
- off-state determinations are **preferred** for establishing the device’s capacity baseline
|
|
|
57
|
- on/unknown determinations **must not overwrite** off-state determinations, **except** when they imply a **smaller capacity**
|
|
|
58
|
- example: the user logs a large measured energy, but later battery-percent checkpoints indicate the battery can’t actually hold that much energy (or has degraded), so we allow the estimate to move downward
|
|
|
59
|
|
|
|
60
|
### Current implementation note
|
|
|
61
|
|
|
|
62
|
For devices that are **not** marked as chargeable while off, the app **does not accept sessions that end at “full”** as capacity inputs (near-full can hide unknown “top-off” time/energy while the OS is doing its own work). For devices marked as chargeable while off, full / near-full sessions remain eligible.
|
|
|
63
|
|
|
|
64
|
## Device-specific notes (practical guidance)
|
|
|
65
|
|
|
|
66
|
- **iPhone:** tends to auto-boot when connected to a charger. To record an off-state session, you may need to shut it down after connecting power. Some factors can still trigger a boot even if the phone was shut down.
|
|
|
67
|
- **Powerbank:** treat as “chargeable only while off” (no active output load). For capacity learning, prefer sessions where the powerbank is not simultaneously powering other devices.
|
|
|
68
|
- **AirPods case:** treat as “off” **only if the earbuds are not inside** the case while charging (otherwise the case is also charging the earbuds).
|
|
|
69
|
- **Apple Watch:** cannot be reliably powered down for charging; treat as **always on**.
|
|
|
70
|
- **Garmin Edge bike computers / some Garmin watches:** treat as **chargeable only while off** (they need to be powered down to charge).
|