battery indicator only sort of reflects actual battery charge

Bug #1476476 reported by Selene ToyKeeper
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
High
John McAleely
upower (Ubuntu)
Confirmed
High
Unassigned

Bug Description

On Ubuntu Touch devices, the battery indicator and graph behave in strange ways which do not accurately represent the state of the phone's battery or power supply. This may be several bugs, but more than one of those can probably be fixed in a single straightforward way.

Attached is a graph showing, at the top, what the battery indicator and graph show. Below, the blue line shows the kernel's voltage value from /sys/class/power_supply/battery/voltage_now , and the green line shows the actual voltage going in to the phone from a power supply.

To help make sense of the graph, here are the events which happened during the measurement period:
- I tested bug 1476468, but this part of the graph is cut off to the left.
- I turned the power supply up to 4.2X V and turned the phone back on. It was not plugged in to USB.
- At about 0.1 hours I turned the power supply down to 3.1V and waited.
- At about 0.35 hours the phone turned itself off; I guess I set the input power too low.
- At about 0.45 hours I noticed, turned the power up to 4.3V, and turned the phone back on. After it booted, I turned the power down to 3.3V and waited again.
- Time passed; I was working on other things.
- At ~2.7 hours, I turned up the power supply to 4.3 V.
- At ~2.8 hours, I plugged in USB.
- At ~3.8 hours, the battery indicator noticed, jumped to 85%, and retroactively changed the graph from a horizontal line to a diagonal rising line.

One issue is that the user-visible graph lags way behind the power supply. It took about 35 to 60 minutes to notice that the power had dropped to a very low level, then plummeted all at once. Before this, it merely declined a few percent. The kernel's reading also lags a bit, but it looks like it may simply have a lowpass filter or something on it. Regardless, the kernel's raw value is much closer to reality.

A second issue is that the user-visible graph and percent do not go up when the battery voltage increases. It refuses to increase the estimated charge, ever, unless USB is plugged in. However, li-ion batteries normally recover some voltage after a high-amperage drain stops. So, if you watch videos for half an hour and stop, the charge actually recovers and the battery indicator should reflect this. Letting the percent go up while it's not plugged in is not an error, it's just how the battery works.

A third (and fourth) issue is that it took about an hour for the indicator to show an increased charge even after the USB cable was plugged in. ... and then despite jumping suddenly from 1% to 85% it *retroactively* changed the graph to make it look like the level had been increasing the whole time.

I notice that the kernel sees voltage increases immediately, but decreases take a while to settle. Not ideal, but probably not bad either.

What I propose as a solution: Instead of using the current code to estimate a charge percent, we should perhaps translate the kernel's voltage value into a percent directly. At least while unplugged. While plugged in, I'm not sure if the kernel has an accurate value anywhere. Using the kernel data directly would give a more accurate representation of the battery state, and is not prone to the bizarre behaviors reported on the mailing lists (or the corner cases I've observed in testing on a modified phone).

As for translating the kernel voltage into a percent, it simply needs to go through a curve correction function. It should look approximately like one of these, depending on the exact battery type:
http://www.lygte-info.dk/pic/Batteries2011/All18650/Capacity-0.2A.png

Tags: power-bugs
Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

First graph comparison, taken about an hour after plugging the phone in.

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

Second graph comparison, in which the graph changed retroactively to indicate it had been "charging" the whole time.

Revision history for this message
Robie Basak (racb) wrote :

It might be worth looking at gnome-power-settings to see what it does on a laptop. I think the GNOME infrastructure applies a curve correction.

Changed in upower (Ubuntu):
importance: Undecided → High
Revision history for this message
Julia Palandri (julia-palandri) wrote :

Among strange "updates" backwards in the graphic, the other day I witnessed this with Arale:
- Phone plugged for 7+ hours, says battery 100%
- Unplugged phone, battery % starts to decrease. First value is oddly enough 98%
- Plugged it again (plugged to wall, btw, not computer)
- Battery starts to "drain" really quickly: within minutes (literally, less than two minutes) battery says 1%
- Phone turns off *for real*
- I turned it on again, while still plugged. Battery says 100%

I've also seen it plugged for several hours, but when disconnected show strange values such as 44%, 20%, etc.

Have some screenshots of the battery graphics, if useful.

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

Yes, please attach those screenshots, along with a description of what happened in each. :)

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

@John we have a number of similar reports of incorrect battery status readings, some attributed to actual drainage but seemingly they are actually false readings

Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
importance: Undecided → High
milestone: none → ww40-2015
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upower (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.