Capacity suddenly drops to 0

[Jean-Baptiste Lallement]

current build number: 248
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en

[This report is used to gather data about the main issue reported in bug 1471913]

Test Case:
1. Charge the device to a reasonable capacity (between 30% and 50%)
2. Reboot it
3. Let it drain

Actual result
After some time (in this experiment it was 24h) the capacity suddenly drops to 0 (from 10% in this case)

The graph attached shows upower charges history over time.

From syslog the battery is the wakeup source so it suggests that the battery is really empty:
⟫ grep battery syslog.1454238636
Jan 31 10:31:24 ubuntu-phablet kernel: [ 3696.984325]active wakeup source: battery
Jan 31 10:47:41 ubuntu-phablet powerd[935]: Turning screen on, battery state changes
Jan 31 10:53:09 ubuntu-phablet kernel: [ 4215.152283]active wakeup source: battery suspend wakelock

Although on the upower graph, upower reports 28% left at exactly the same time (there is a +1h offset due to timezone)
09:38:36 29 discharging
11:31:56 28 discharging
11:32:28 27 discharging
[...]
11:46:41 1 discharging
11:47:11 0 discharging

Then starting from 10:31 UTC it goes down to zero in about 15 minutes. The powerd events correspond to the low battery notification.

The driver uses 2 counters:
- SOC: Read from battery meter
- UI_SOC: State of charge internal to the driver

The capacity attributes exposed by sysfs in /sys/class/power_supply/battery corresponds to UI_SOC.

The driver linearly decreases (or increases) the UI_SOC each time the battery status is updated i.e either called from pmic when a charger is plugged or unplugged, or from the battery kthread.

If UI SOC drifts too much, the driver triggers an adjustment algorithm until
UI SOC is back within bounds. There is a calibration mechanism to calculate the periodicity and the step to use for the adjustment.

The driver syncs the RTC SOC with the UI SOC if:
- UI_SOC - SOC >MAX_DIFF_UI_AND_SOC (2)
- SOC > MIN_SOC_FOR_ADJUST (20)

The battery graph suddenly decreasing to 0, then oscillating between 0 and 1 until the battery is completely empty (<3.4V) is the symptom of this adjustment function.

For some reason this adjustment function is not triggered when it should, the difference between the SOC in the driver and the real SOC becomes significant (> 20%) and the adjustment only starts when the battery is already below a critical level.

[Jean-Baptiste Lallement (jibel)]

Here is another graph when this issues is reproduced again.

It shows the problem with upower history (orange) not containing enough data to generate a graph corresponding to the actual capacity of the device (which confuses users a lot)

Then it shows over the last hour the effect of the adjustment function in the battery driver when the capacity (in purple) drops quickly from 21% to 0% then oscillates between 0 and 1 for 30 minutes until the device really dies (device was at 0% when voltage reached 3.4V then shutdown at 3.0V)

Now, there are the following possibilities:
1. The battery meter returns wrong data to the driver (calculation of the capacity is incorrect for example)
2. UI_SOC and SOC diverge and the adjustment is not triggered.
3. There is a battery calibration or a battery profile issue

[Jean-Baptiste Lallement (jibel)]

ods containing the data.

[Jean-Baptiste Lallement (jibel)]

Here another graph produced by reproducing the test case on arale which exposes the HW fuel gauge through sysfs.

This graph shows that the capacity returns by the battery driver and the capacity returns by the battery meter are the same. THat would eliminate the case where the battery driver and the fuel gauge are diverging.

The voltage graph shows that voltage decreases linearly for about 14 hours, then decreases faster and faster for 4 hours until it reaches the lower limit of 3.4V and the devices shuts down.

When it reaches 3.5V the percentage starts dropping to reach 0% in half an hour.

3.5V corresponds to the value of low power wakeup (and 3.6V for the normal wakeup)

The battery meter table shows that 3.6V also corresponds to a DOD of 97% at 25°C, although the percentage reported by the fuel gauge is still 20% while it should be around 3%.

[Jean-Baptiste Lallement (jibel)]

data file.

[Selene ToyKeeper (toykeeper)]

It's normal for voltage drop off to accelerate below 3.6v (or 3.7V, depending on the battery). The voltage discharge curve looks normal for lithium ion. However, the capacity graphs look like a pretty poor method of converting voltage into a percent.

I find that the kernel's reported voltage usually tracks the actual voltage pretty closely, but the capacity estimation lags way behind. This is harder to measure on krillin since its kernel doesn't report voltage.

In any case, I doubt it's hugely important for the reported percentage to be totally accurate. It's more important for the voltage to give timely and continuous feedback about the battery state, with no large sudden jumps. Being reasonably accurate likely only matters near the top and bottom of the scale.

[Jean-Baptiste Lallement (jibel)]

The description in bug 1550223 confirms the same behaviour but in power charging mode.

=====
In the last few weeks it has quite often happened that my Krillin would turn off while the battery indicator was still showing a good 15-20% battery.

Today, after the device switched off, I plugged it to a wall charger while it was off.

Here's what happened:
1) Phone switches on and goes to charging screen (showing the fullscreen charging animation), showing 26% battery
2) After one minute, the battery animation was showing 18%
3) After a few seconds, it was showing 17%
4) After a few more seconds, it was showing 15%
5) After a couple of minutes, it was showing 2%
=====

It reinforces the suspicion of a faulty PMIC Fuel gauge as YC Chen originally suggested in bug 1471913. However no one confirmed that the proposed workaround improves the situation.

For reference the workaround was:
1. set the phone to airplane mode
2. charge overnight.

[Jean-Baptiste Lallement (jibel)]

Read Bug #1550263 (not 1550223 )

[Andrea Bernabei (faenil)]

Charging with airplane mode did not help.

I had the same issue this morning. The battery was not even red, and after a few minutes I grabbed the phone and it was dead.

[Andrea Bernabei (faenil)]

More info: I went to bed with 97% battery, when I woke up it was still 97%.

It sounds a bit too good to be true :) these smartphones usually use 0.5 or 1%/hour, so it should have gone down by 3-4% at the very least

[Andrea Bernabei (faenil)]

the battery level I reported is the one I got from the UI, so power-indicator

[Jean-Baptiste Lallement (jibel)]

@Andrea, right, this is another issue and part of bug 1538470. upower doesn't update its history records when the device is suspended but the capacity reported by the kernel and the PMIC is correct.

This bug report is about the wrong capacity reported by the kernel when the battery is close to empty (~3.6V)

[Andrea Bernabei (faenil)]

Update:
After the phone died on 29th I left it charging until 100% while it was OFF.

I could not reproduce the bug this time, the

Nothing changed on my device, except I enabled a data plan (that I didn't have during the previous test). Enabling the data plan may have led to considerably faster discharge, so the conditions of the test are not exactly the same, but this time everything worked fine. It's still at 5% battery now.

[Marek Greško (mgresko8)]

I tried to completely discharge the phone and charge it while turned off twice without success. I am still observing this behaviour which was introduced by some OTA. I cannot remember which one was it.

[Matthias Apitz (gubu)]

see also https://bugs.launchpad.net/canonical-devices-system-image/+bug/1458756 (which maybe should be closed in favor of this here)

[Cousteau (war-richard)]

Same problem here. Today reported to be at app. 50 % battery, then suddenly my phone is dead.

[dinamic (dinamic6661)]

same on mx4/rc proposed, since forever X-)