ubuntu-phone team mailing list archive

[Matthias Apitz <guru@xxxxxxxxxxx>]

Hello Selene,

This is, I think, the most profound statement about all this problem.
Thank you for this!

El día Monday, January 16, 2017 a las 11:04:31AM -0700, Selene Scriven escribió:

> > What 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.

What is the name of this process and does it have some log file (maybe
to avtivate) which would log the actual voltage and the derived
estimated percentage?

> 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.

Then we are lost, if already the kernel lags behind the real actual
voltage. :-(

> ... 
> 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.

Thanks for the light on this.

	matthias

-- 
Matthias Apitz, ✉ guru@xxxxxxxxxxx, ⌂ http://www.unixarea.de/  ☎ +49-176-38902045
"Wo ist der antiimperialistische Schutzwall, wenn man ihn braucht? US-Panzertransport durch ex-DDR"
"Where is the anti-imperialistic  wall, if it's needed? Transport of US-tanks through the ex-GDR"
https://deutsch.rt.com/kurzclips/45282-us-panzertransporte-durch-ex-ddr/