Canonical System Image

Bug #1471913
Comment #81

Comment 81 for bug 1471913

Revision history for this message

Selene ToyKeeper (toykeeper) wrote on 2016-02-22: Re: Battery statistics are incorrect on MTK based devices

#81

On a MX4 phone with the battery removed (replaced with a bench power supply), I noticed that the reported percentage kept dropping over time despite a steady 4.35V input voltage. When it got low enough to pop up warnings (which interrupted and invalidated tests), I checked the kernel's reported power stats.

The kernel reported 10% full and 4.193V.

I then unplugged USB, disconnected a power lead, waited a moment, then reconnected everything to boot the phone fresh (hard power cycle), and checked the kernel stats again.

This time it reported 77% full and 4.356V.

I checked the input voltage both times with a separate DMM, and it measured at 4.42V.

The expected voltage range of these cells is about 4.35V for "full" and about 3.0V to 3.3V for "empty".

So, two notable things:
* The kernel's initial reported voltage was 0.23V lower than reality, but corrected itself to only 0.07V low with a power cycle.
* The reported capacity was off in both cases, but in the "10%" case it was nowhere near the truth. Instead of 10% and 77% it should have been more like 77% and 100%, going strictly by voltage.

I'm assuming there is some sort of automatic curve calibration going on, so it tries to create a voltage-to-percent curve automatically based on recent measurements and previous discharge-charge cycles. If this is true, I should be able to temporarily improve the behavior by artificially dropping the input to 3.3V, leaving it overnight, then restoring it to 4.35V and leaving it a few hours. This would hopefully reset the curve. However, it might be simpler and more reliable to drop the auto-calibration entirely and go with a fixed curve calibrated once for each phone model. It would at least be more predictable, and less prone to the weird behaviors people have reported.

So, something in hardware or firmware or the kernel seems to be getting mildly incorrect readings in some situations. However, even as-is, using data from the known-weird kernel, behavior could be improved by relying more on voltage measurements and less on clever userspace algorithms.

On a MX4 phone with the battery removed (replaced with a bench power supply), I noticed that the reported percentage kept dropping over time despite a steady 4.35V input voltage.  When it got low enough to pop up warnings (which interrupted and invalidated tests), I checked the kernel's reported power stats.

The kernel reported 10% full and 4.193V.

I then unplugged USB, disconnected a power lead, waited a moment, then reconnected everything to boot the phone fresh (hard power cycle), and checked the kernel stats again.

This time it reported 77% full and 4.356V.

I checked the input voltage both times with a separate DMM, and it measured at 4.42V.

The expected voltage range of these cells is about 4.35V for "full" and about 3.0V to 3.3V for "empty".

So, two notable things:
* The kernel's initial reported voltage was 0.23V lower than reality, but corrected itself to only 0.07V low with a power cycle.
* The reported capacity was off in both cases, but in the "10%" case it was nowhere near the truth.  Instead of 10% and 77% it should have been more like 77% and 100%, going strictly by voltage.

I'm assuming there is some sort of automatic curve calibration going on, so it tries to create a voltage-to-percent curve automatically based on recent measurements and previous discharge-charge cycles.  If this is true, I should be able to temporarily improve the behavior by artificially dropping the input to 3.3V, leaving it overnight, then restoring it to 4.35V and leaving it a few hours.  This would hopefully reset the curve.  However, it might be simpler and more reliable to drop the auto-calibration entirely and go with a fixed curve calibrated once for each phone model.  It would at least be more predictable, and less prone to the weird behaviors people have reported.

So, something in hardware or firmware or the kernel seems to be getting mildly incorrect readings in some situations.  However, even as-is, using data from the known-weird kernel, behavior could be improved by relying more on voltage measurements and less on clever userspace algorithms.