Open Bug 703689 Opened 13 years ago Updated 2 years ago

Increase battery charging/discharging time precision on Android by guessing the curve with the battery type

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Platform:
All
Android
Type:
defect

Tracking

()

People

(Reporter: mounir, Unassigned)

References

Details

In a nutshell, nowadays batteries take 20% of the time to charge 80% of the battery so 'chargingTime' might be very optimistic because the curve is going to be nearly vertical at the beginning and nearly flat at the end.
We could likely increase our precision by adding that parameter to our algorithm.
I grep 'chargingTime' and found some references under /mozilla-central/dom/battery component. Are there more information to assist in my understanding of how the battery charging/discharging is used, so I can try and address the issue properly?

Thanks!
(In reply to Charles Chan from comment #1)
> I grep 'chargingTime' and found some references under
> /mozilla-central/dom/battery component. Are there more information to assist
> in my understanding of how the battery charging/discharging is used, so I
> can try and address the issue properly?

What you found is correct but is for the DOM API.
What you want to change is the Android backend which can be found here:
/mozilla-central/mobile/android/base/GeckoBatteryManager.java
Thanks Mounir, I have a quick look at GeckoBatteryManager.java -- and this is definitely interesting. Will read up on the source and Android backend and battery tech in general before proposing something ...
Mounir, I think the change would be in the following block in /mozilla-central/mobile/android/base/GeckoBatteryManager.java:

          if (sCharging) {
            if (dLevel < 0) {
              Log.w(LOGTAG, "When charging, level should increase!");
              sRemainingTime = kUnknownRemainingTime;
            } else {
              sRemainingTime = Math.round(dt / dLevel * (1.0 - sLevel));
            }
          } else {
            if (dLevel > 0) {
              Log.w(LOGTAG, "When discharging, level should decrease!");
              sRemainingTime = kUnknownRemainingTime;
            } else {
              sRemainingTime = Math.round(dt / -dLevel * sLevel);
            }
          }

Based on the description, your expecting: 
Time	        10.00%	20.00%	30.00%	40.00%	50.00%	60.00%	70.00%	80.00%	90.00%	100.00%
Battery Level	50.00%	80.00%	82.50%	85.00%	87.50%	90.00%	92.50%	95.00%	97.50%	100.00%

Am I on the right track?

---------

I don't have an Android device for test, where does the charging time show up? Under Android OS settings? Or is it somewhere like 'about:config'?
So, my description was over-simplified. I don't know how long it takes usually to charge 50% of a battery. It very likely depends on the battery's type (chemicals inside) and the battery's age (but you could probably ignore that parameter).

If you have no Android device, I think you should try to find documentation about battery life depending on its type, write a patch and then someone could try it.

To show the charging time on an Android device, you have to use Nightly or Aurora (maybe Beta too) and load a webpage that shows |navigator.mozBattery.chargingTime|. Android doesn't provide that information.
Can this work?

if (sCharging) {
            if (dLevel < 0) {
              Log.w(LOGTAG, "When charging, level should increase!");
              sRemainingTime = kUnknownRemainingTime;
            } else {
              sRemainingTime = Math.round(dt / dLevel * (1.0 - sLevel)* Math.round((8/10)*(max/sLevel));
            }
          }
This is assuming that the curve is almost vertical till 80%
(In reply to Rishabh from comment #7)
> This is assuming that the curve is almost vertical till 80%

On what do you base this approximation?
8/10 * max = 80% battery charged
thus, the value of the expression Math.round((8/10)*(max/sLevel)) decreases as the battery level increases. After 80% of the battery is charged this expression yields a value of 1 and therefore, ceases to affect the equation. 

The remaining time is least accurate at lower battery levels and is significantly higher than obtained by the current calculations.
I was just thinking that the amount of the battery getting charged would closer to the function -e^-t , where t is the time elapsed since it began to charge. If it is so then it can be implemented in the program and I would like to help in it.
Why -e^-t? Is there any paper/documentation explaining that this is the right approximation?
(In reply to Mounir Lamouri (:mounir) from comment #11)
> Why -e^-t? Is there any paper/documentation explaining that this is the
> right approximation?

Yes, I found a few pages on the web that gives a graph between cell voltage and time:
http://batteryuniversity.com/learn/article/charging_lithium_ion_batteries
http://www.ibt-power.com/Battery_packs/Li_Ion/Lithium_ion_tech.html

Here the curves are steep at first and then becomes almost flat, something similar to the -e^(-x) function here: http://www.wolframalpha.com/input/?i=-e^-x . This is not really an exact one and I didn't find any sources stating this to be the formula. This could be a rough estimate, that I thought so I just discussed it here.
IEEE 1725 includes information that we can use to make these estimates more precise.  We should reference that spec.
IEEE 1725: http://standards.ieee.org/findstds/standard/1725-2011.html

I'm new but I'm going to look into this.
Access costs over $100 even for IEEE members. I left them a voicemail about free access for this purpose. I'll follow up if/when I hear back from them.
IEEE 1725 has no indication of battery charging curves.

I understand that the charging curve can be modeled with a function of one variable that increases monotonically, passes through the points (0,0) and (0.2, 0.8), and has a horizontal asymptote at 1. I think at this point it is Mounir's decision what function to use. I found that Sankha's suggestion of y=-e^-bt+1 is appropriate because it satisfies all these constraints.

I solved for the b that satisfies the points above, and found that y=-e^(-8.04719*x)+1 is a good model. Mounir, would you like me to implement this?
John we are happy to cover the cost for accessing that document. Please email me at gal@mozilla.com
Hi Andreas, I'm going to email you right after this comment. I have just verified in the IEEE document 1725-2011 that there is no mention of "curve" or "model", and the only 2 mentions of "equation" are irrelevant to this issue.
Whiteboard: [mentor=mounir][lang=java]
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.