touch-packages team mailing list archive

[Jean-Baptiste Lallement <jean-baptiste.lallement@xxxxxxxxxx>]

** Also affects: upower (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: upower (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upower in Ubuntu.
https://bugs.launchpad.net/bugs/1476476

Title:
  battery indicator only sort of reflects actual battery charge

Status in Canonical System Image:
  New
Status in upower package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1476476/+subscriptions