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