An Interesting Battery ExperimentGeneral

Last Updated:

  1. nkk

    nkk Well-Known Member

    With all of the talk of battery life on the TB, I decided to do a little experiment.

    I graphed the current coming out of the battery vs time. This gives a graph with units of mA vs seconds. If you integrate said graph (that is, take the area between it and the x axis), you get an area with units mA*seconds. Divide by 60 and you get mA*minutes. Again by 60 and you get mAh, i.e. the capacity of the battery.

    To do this, I used:
    my phone and its built in current sensors
    current widget, which measures the current and then logs it
    MicroCal Origin, a research grade data analysis software and the industry standard

    So, I used current widget to plot my current (polling every 30 seconds), and I go this scatter plot:

    NOTE: The Y axis is mA, not mAh. I was not paying attention to my units and I am too lazy to go and fix it and then recreate the image. Thanks to ilikebeer for catching that.


    Ok, so integrating that gives me a capacity of 5975120 mAs, which is about 1660 mAh. This is obviously over the rated capacity of the battery. So, I analyzed my errors:

    -Current Widget. Since this was drawing directly from the sensors, I am pretty sure it is within a fairly strict error tolerance. It did round to the nearest whole mA, so that is an error (probably a small one). The big error from this is the polling frequency. At 30 seconds, the picture I can draw is not whole and in fact has 29s worth of data missing between every poll

    -MicroCal origin. This is the industry standard. If it had logical flaws, I would be amazed. What may be the problem is the method of integration. Normally, one integrated a function (ex y=x+27). However, I had a scatter plot, not a continuous graph. So I used a thing called numeric integration, which basically splits the difference between each data point and its neighbors to find a local slop from that point to the next. It then uses that as the continuous function in that area. When it moves on the the next data point, it finds the difference of the points and this the slope there. This is inaccurate, as it cannot account from non linear behavior between two points. Since my data is obviously not going to be perfectly linear between each point, this is a source of error. The error for this (I used a more advanced method that is a bit more complex than just linearization) is not too large, and certainly not enough to account for the ~250 mAh overestimation.

    In reality I think most of the data comes from the 30s polling period. I will do this again with 1s and see what I get.

    In summary, we can see that although this method has errors, the stock battery cannot be far from the rated 1400 mAh.

    I just thought some people may find this interesting.

    I know this was somewhat technical. I tried to put the math in layman's terms, but explaining is not my strong attribute. If you have any questions at all, please PM me. I am more than happy to share.

    As an aside, I work in a Li-Ion battery lab at a world class research university. I am only a student, but I do know what I am talking about. I say this not to brag, but to give some credentials. There is a lot of misinformation out there, so verifying your source is accurate is a good thing to do. Of course, I could be lying about my credentials, but I am not willing to post my name everywhere so that they can be verified. You have to start trusting somewhere, I guess. :)


    Edit: I am working on a java program that anyone can use that will just have you point it to the log file for current widget and it will do the rest and spit out a value in mAh. The numeric integration part will not be as sophisticated as Origin, but I will also output the error so you can see what the error for it is. This is a long term (month or two) project, so do not hold your breath. However, when I am done it will work for any phone that can run current widget.

    Edit 4.8.2011:

    New graph with 1s polls:

    Note that this graph has data points at regular intervals removed so that it is clear and legible.

    Also, I used the same template and did not fix the mAh, so again the y axis should me mA, not mAh.


    This chart would imply a capacity of 1525 mAh. We are getting closer. :)

    1s polls brought some other errors to my attention. One is that I have SetCPU to put my clock at 245/356 or something like that when the screen is off. That means that sometimes there is not enough processing power to poll and write a file every second. Now, when I turn the screen on it usually jumps to 1200-ish. What happens is what should be a line that goes flat for 1 minute then jumps to a higher mA is being interpreted as (again thanks to numerical integration) a line that is flat for 30s and then somewhere and somehow between 31s and 60s goes much higher. That adds calculated capacity.

    next stop is .1s polling with the SetCPU off.

    chuck2530, magpullin, ska.t73 and 6 others like this.
  2. Nor*Cal

    Nor*Cal Well-Known Member

    Impressive research nkk.

    I would be very interested in the java program you are currently working on. I should have some aftermarket 1700mAh batteries delivered tomorrow from HTC Express and would like to test them out so I can share the results with fellow members.

    Please keep us posted and thanks for sharing your test.
  3. Skeletronix

    Skeletronix Well-Known Member

    [​IMG] this a good thing?
  4. nkk

    nkk Well-Known Member

    As I said, the program is backseat to other interests, mainly the research I am paid to do. However, getting this was easy, so if you download current widget I would be happy to use origin (licenses for it cost $$$, so I am assuming you do not have it) and then give you the results to post.

    Are you being sarcastic? Or just a troll? This is not my opinion (well...the error analysis part is), this is the result of well established mathematical processes and the observation of fairly well understood and measured physical phenomena.

    As for if it is good or not, it is what it is. The errors are too big to make any real exact claim, but it looks good. As was said in the OP, more testing is in order.

  5. Skeletronix

    Skeletronix Well-Known Member

    Just being sarcastic, no worries. I read through your post and was impressed! I just wasn't quite clear on what your final results were or what the outcome was of all of this work you put in. Are you saying that the 1400 mAh battery is performing as advertised?
  6. MikeMBau

    MikeMBau Active Member

    All of my nightmares from AP Statistics, AP BC Calculus, and AP Physics just came back.
    kcs7272 and EgoDogg like this.
  7. Diggit

    Diggit Active Member

    Your analysis is very interesting. Thanks to people like you this is an great android community.
  8. Tech Addiction

    Tech Addiction Well-Known Member

    Keep us posted and thanks for this very usefull thread.

    I have the 1500mah batteries and they seem to hold a charge fine when at idle but they "seem" to drain more quickly then the stock battery.
  9. robrecht

    robrecht Well-Known Member

    Thanks for the substantive analysis. I would not be surprised if OEM batteries are conservatively rated, while cheap knock-offs use overly optimistic estimates. Does anynone know who makes the OEM batteries for HTC?
  10. nkk

    nkk Well-Known Member

    A healthy dose of sarcasm is necessary in life, IMHO. :) My result say two things: The stock battery performs well above expected, and that there are too many errors to take that result seriously without further experimentation. So...take that for what you will.

    Well, again the offer to send me your current widget output stands. I obviously cannnot do this for everyone, but I would like a few more data points from stock batteries and extended 3rd party ones. Make sure to set polling to 1s, as 30s seems too inaccurate. I will send you the data back to you when I am done.

    Thanks all,

    PS: One second polling is coming tonight or tomorrow
    Tech Addiction and Skeletronix like this.
  11. Skeletronix

    Skeletronix Well-Known Member

    Gotcha. I can't say I fully grasp your calculations, but I've found the battery life to be more than adequate, which I think is what you're trying to say. Soooo....thanks!
  12. Jerzboi

    Jerzboi Well-Known Member

  13. ilikebeer

    ilikebeer Member

    Pretty neat approach.

    Hard to imagine the Current Widget would be rounding up for every polling instance; if not, the sample size seems way too large to have much bias either way.

    It would be interesting to use this methodology with something that was using a high number of CPU cycles; hopefully, you'd have a more consistent power draw with less variance. Combined with increased polling frequency, you'd probably be able to rule out numerical integration methodology as the source of error. Then again, maybe you didn't want to do that for specific reasons; I've always wondered whether battery capacity was somehow affected by current draw (maybe you can enlighten me if you have a moment).

    Big thumbs up (from a former ApplMath person).

    PS: the Y-axis is mis-labeled as mAh

    Edit: It would also be interesting to see the current draw from "typical"activities; it looks like the baseline power draw is low enough that standby shouldn't be an issue. But I wonder what the draw is when using 4G, for example...could be helpful in trying to assess what applications use the most power.
  14. nkk

    nkk Well-Known Member

    Glad I could make you happy?

    See, I would be weary of either current widget or even the interpretor for the sensor that CW reads from using an always round up function just so that the sensor always takes the cautious reading. In fact, that is how I would program it just to be extra safe.

    As for CPU cycles, probably. Even constantly downloading from the network should cause the increased and relatively constant drain (guess what the next study is? :) ). I did not want to do it because I am not a fan of excessive and constant over clocking (while cool, it is not good for the chip), and I also did need my phone to last (i.e. I could not just drain it then recharge). Over the weekend when I have free time I may do the total and quick drain.

    As for mA having an influence on mAh, the short and somewhat summarized answer is not for these cells because they have an over current protection chip that will stop them from giving anything that is detrimental to their health, so you are guaranteed to stay within safe and optimal tolerances. That being said, generally when we test a cell's capacity, we do it at tiny amps because without the protection chip it would change.

    EDIT: just saw your edit...I pretty much answered it. That is my project for the weekend. :) Also, first post was edited with the units.

  15. ilikebeer

    ilikebeer Member

    True enough. Still, even if the units are rounded up, the maximum error would only be 1mA times the number of seconds used, or about 11.5 mAh in your scatter plot. It seems far more likely that the polling frequency and the interpolation algorithm are the primary sources of error.

    Thanks for your explanation on current draw vs. capacity, too.
    nkk likes this.
  16. nkk

    nkk Well-Known Member

    Good point. I had not even gotten to the quantitative error analysis...I was just sort of thinking what the sources may be.

    I have my phone draining right now at 1s polls. Update tomorrow when I get a chance to analyze the data. Hopefully it will be more accurate

  17. nkk

    nkk Well-Known Member

    Bump. New data in first post.

    Summary: with 1s polling, the capacity is ~1525 mAh. However, SetCPU was found to introduce errors. Se first post for details.

  18. f_padia

    f_padia New Member


    Nice analysis. I have been doing similar investigations on my Hero battery. I am interested to know what is your current draw (approximately) when the phone is idle/sleep. The large range on the y-axis makes it difficult to read off, is it around 20mA?

Share This Page