* Matthias Apitz <guru@xxxxxxxxxxx> wrote:
Yes, exactly like this, with meters in addition.
Although not shown in the picture, I have the phones instrumented
with meters along the path for primary power and USB, and use it
to check power consumption on each new build.
For example, here is a summary of one type of krillin power usage
for 50 builds during a time when a relevant bug was introduced:
http://toykeeper.net/tmp/phablet/power/krillin-rc-proposed,en-power_usage_display_on-287-336-smooth.png
Toward the right side, it spikes for several builds until we had
the bug isolated and fixed. The red columns indicate when it
thinks there is a new bug, and green is when it thinks something
was improved. The blue area is where it expects the result to be
based on recent measurements. So, bug found and fixed. If I
recall correctly, this particular bug was the reason an OTA
release got delayed.
Then a few builds later, in r335, it noticed an unusually high
variation between individual measurements, and marked that build
for inspection. For context, here is a more detailed graph for
r334, when everything was behaving:
http://toykeeper.net/tmp/phablet/power/krillin.334.display.png
The green section is the part of the measurement it "counts" for
the test. Red sections mean USB was plugged in so those values
aren't relevant. In this case, it's just letting the phone idle
with the screen on right after booting. Five measurements, and
they're all pretty consistent.
Then in the next build it had one measurement which didn't look
quite right:
http://toykeeper.net/tmp/phablet/power/krillin.335.display.png
So it marked that build for inspection, with detailed logs
available to help identify what happened.
This is how we've been detecting and fixing power consumption
bugs, making sure each new OTA is the same or better than the
ones before it. But that's mostly for userspace bits. Kernel
and firmware issues are trickier.
hat I do not understand is the issue my wife sees from time to
time: her device shows 50% or 60% of remaining capacity, for
longer time (due to nearly no use of the device), and within
minutes the capacity goes to zero and the BQ E4.5 is a brick in
her pocket. I understand what you say, Selene, about
discrepancies in the layers an error in interpreting the
voltage, but I do no see, how can lead this to 50%-to-0% in a
few minutes. Have you found something, which explains this?
Yes. Especially when a device spends a lot of time in standby.
The daemon which generates that percentage estimate can sometimes
go a long time between updates... and when it does update it has
a tendency to lag.
For example, one day I was testing by manually changing the input
voltage and recording how the phone responded. What I found was
that the kernel's reported voltage lagged behind the actual
voltage when the actual voltage decreased quickly, but it tracked
closely when voltage increased. Additionally, it sometimes took
a while for the reported percent (and built-in charge graph) to
catch up.
In this graph comparison, the green line is what the power supply
voltage was set to, the blue line is what the kernel reported,
and the rainbow graph is a screenshot of what the phone reports
to its user. After manually dropping the voltage to "almost
empty", it took about 40 minutes for the UI to catch up and it
did the thing where it went suddenly from like 60% to 0%.
http://toykeeper.net/tmp/phablet/power/battgraphs.png
Then a bit later (I let it keep measuring), I noticed some other
odd behavior. Although it hadn't noticed earlier that the
voltage went back up, when it finally updated again it changed
the UI's rainbow graph retroactively:
http://toykeeper.net/tmp/phablet/power/battgraphs.2.png
After the kernel noticed the increased voltage, the UI took over
an hour to update.
If it drops suddenly to zero, that usually means the battery
itself has been dropping for quite a while and the capacity
estimation software simply took a long time to catch up.
The kernel's reported voltage level isn't perfect, but it's a lot
closer to reality than the percent shown in the UI.
Of course, there are other factors which make it a bit awkward...
like the way battery voltage sags under load then recovers later.
Play an intensive game and the cell voltage might sag to 3.4V...
but turn the game and screen off and voltage may recover to 3.8V
within a couple minutes. So it can be tricky to convert a
measurable trait (voltage) into an un-measurable trait (percent
charge remaining). And the effective capacity isn't a simple
graph from volts to percent; it changes with the discharge load
so it's more of a 3-dimensional graph. And as the cell ages, the
3D mapping from voltage+amperage to percent changes, so it needs
recalibration once in a while.
-- Selene
