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. -- You received this bug notification because you are a member of Desktop 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
