Google Invites Selected Devs to Buy Project Tango Development Kit

Just about a month ago, the curious Project Tango development kit was … more

Micromax Yureka: Indian Handset with CyanogenMod

Thesoap opera involving Cyanogen Inc., OnePlus, and Micromax is one of the most talked about … more

Chainfire Turns Your Bootanimation into a Logging Center

Having a nice boot animation certainly adds a little bit of aesthetic polish to your … more

Android TV Launcher Pushed to Google Play

Over the past decade, the tech universe has seen two drastic and widely contrasting changes with … more

Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

Measure and compare your battery capacity - easy, foolproof, comparable - any WM dev

OP tobbbie

6th February 2010, 11:32 PM   |  #1  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Hi all,

...since I could not find a program to achieve this, I had to write one myself. Well, it is not a program, but just a MortScript to do the job of data collection while the battery is discharged.
As MortScript runs on all WM platforms from WM2k3 onwards and on both: Smartphone (standard) and PocketPC (professional), you can use this concept for all devices that MortScript runs on.

You have to take care yourself that the battery is full before you start and that the discharge is constant over time. Both is easy however :)

The job to discharge your battery while measured is done by the display lit to the maximum brightness and all other big current drains should be off to get comparable data. The script runs in the background and whenever the Battery% goes down is writes to a file remembering the timestamp for this.

For my devices the time to drain the batteries from full to zero was 1-16 hours, depending on how much the fully lit display draws off the battery and capacity and health of the battery.

Evaluation is done off-line with a spreadsheet program.

Usage:
  1. install MortScript
  2. unzip the attached file to your PC
  3. put the battery-rundown.mscr file to the folder \My Documents\Battery or \Storage\My Documents\Battery for WM2K3 on your device
  4. put the battery-rundown.lnk (*-wm2k3.* for WM2k3) file on your device to the \windows\startup folder. This makes sure that the script starts as soon as your device starts. It will not do any harm there and can even stay there for a longer time if you want to learn about your battery charge cycles. You can also copy it to any other place you like in the startmenu for easy access.
  5. make sure all radio access is off (GSM/UMTS, BT, WLAN)
  6. adjust the display and backlight on battery to stay on forever as well as backlight brightness for battery use to maximum
  7. switch off the device
  8. charge it until the battery is full (green light). Optionally leave it like this for another 1-3 hours to get the trickle charge squeeze the last electrons to the battery. Impact of this should not be more than 10% capacity - skip it if you are impatient.
  9. switch on, the script starts automatically and measurement has created a file where the mortscript resides. It will continue to write to this file until the battery goes to 0% and device switches off.
  10. disconnect from the charger (but you did this already, or?)
  11. You can check from time to time the content of the log-file to see the progress if you like.
  12. leave the device alone until is is off - this will take several hours, best is to do this over night. Put it at a place where the battery warning is not disturbing you at night.
  13. after the device is off due to the empty battery, reconnect the charger and switch on after a few seconds of recovery
  14. now you can look at the log-file and examine or post-process it in a spreadsheet program - the timestamp should tell you which file it was.
The resulting file "bd_<date-time-started>.csv can be loaded to a spreadsheet and evaluated, so you can compare your own batteries to see which is the best.

Even better, for the same device type the standardized method of measurement, where the current drain by the fully lit display should be reasonably identical for all devices, makes it possible to share battery quality data for 3rd party suppliers. A reasonable point of comparison for one device type is the time it takes until the battery is drained down to 10% - despite the discharge is not at all linear (usually).

I did all this and supply you all my data as an example to depict what you can do yourself now.

I hope you find the script useful.

For device specific discussions, please open a thread in the relevant device forum - pointing to this thread for the method - and not here. This thread is only to discuss the scripts or the method of measurement.

Note:
Please also read post 2 (device specific links) and post 3 (general hints on batteries) of this thread. I will update them from time to time when new info is available.

20100225 added:
If you want to find out how much drain happens to your battery in the test-setup, you can ask the battery driver, e.g. by using HomeScreen++ or BattClock. Mind that this data is not immediately reliable, especially when you change conditions (e.g. dim the light) the change is often reflected only minutes later. The true value can only be found by measuring the drain with an Ampere-meter. This is harder than you may think as the impedance of the meter must be very low to get the device started up properly.

20100313 added:
More programs to read the power drain:
free: acbpowermeter
cost: acbtaskman (can also export data) same provider as above.

Update to the script and few more data inserted to the spreadsheet:
  1. The script now logs several items from the registry, including the Data for CurrentDrain and BatteryTemperature that BattClock writes if it is configured to show them in display.
  2. Started to measure standby drain on all my spare devices - mileage varies. This is also not a real life measurement as the devices have everything shut off (light, radio etc..) and the only process that keeps them busy is the script waking up each 5 minutes. If you like you can change the value for MaxSleepTime in the script to much higher values to decrease the impact of drain to the measurement. I am not sure how this will behave on WM Professional with its complicated power model (standby mode) but on smartphone it runs very well. First data are available in the spreadsheet. It would be best of course to be notified by the system if the battery percentage changes instead of polling for it, but MortScript does not supply a method to achieve this.
20101123 added:
The script reads from data that the BattClock program writes to the registry if you configure it to do so. Further changes are:
  1. Also BatteryVoltage is read from BattClock Data
  2. Added log of status even if % has not changed if MaxLogWait has passed and if Battery % is below a given limit of LogForcePercent. This is needed as the last % (e.g. from 1 to 0) may take a long time (seen as 1h on an Asus P565) and the 0% will not be written because the device just switches off when 0% is reached. There is no chance for the script to write the last data to file in such case.
  3. added a delta-% column to easily detect non linear decrements
The full change history is included in the script:
Code:
# Date        ID            comments
# 20101123    tobbbie        changed script to match to a TAB alignment of 8 characters
# 20101123    tobbbie        altered the logic  for LogForcePercent and set default to 0 to not log anything by default.
# 20101010    tobbbie        Added log of status even if % has not changed if MaxLogWait has passed and if Battery % is 
#                below a given limit of LogForcePercent. This is needed as the last % (e.g. from 1 to 0) may 
#                take a long time (seen as 1h on an Asus P565) and the 0% will not be written because the 
#                device just switches off when 0% is reached. There is no chance for the script to write the 
#                last data to file in such case.
#                added a delta-% column to easily detect non linear decrements
# 20100425    tobbbie        added Registry Read for BattClock BatteryVoltage, rearranged sequence of items
# 20100313    tobbbie        added evaluation of \HKLM\System\State\Battery "main" to logging
# 20100313    tobbbie        added identification of device via HKLM\Ident and IMEI in headerline
# 20100312    tobbbie        made dword registry data to be logged as "0" if no data retrieved
# 20100302    tobbbie        added registry read for data created by BattClock
# 20100205    tobbbie        added self-adjusting sleeptime (InitSleepTime to MaxSleepTime in ms)
# 20100201    tobbbie        initial version
# 20100128    tobbbie        draft versions, proof of concept
Attached Thumbnails
Click image for larger version

Name:	Amadeus.jpg
Views:	661
Size:	83.7 KB
ID:	286541   Click image for larger version

Name:	Hurricane.jpg
Views:	370
Size:	78.0 KB
ID:	286542   Click image for larger version

Name:	Tornado.jpg
Views:	250
Size:	86.2 KB
ID:	286543   Click image for larger version

Name:	Vox.jpg
Views:	229
Size:	63.6 KB
ID:	286544   Click image for larger version

Name:	LG-KS20.jpg
Views:	186
Size:	69.0 KB
ID:	286545   Click image for larger version

Name:	Standby-discharge.jpg
Views:	148
Size:	57.3 KB
ID:	293361   Click image for larger version

Name:	Charge-sample.jpg
Views:	182
Size:	63.3 KB
ID:	293362  
Attached Files
File Type: zip BatteryRundown.zip - [Click for QR Code] (30.3 KB, 137 views)
Last edited by tobbbie; 23rd November 2010 at 11:58 AM. Reason: New ZIP file with updated script
The Following User Says Thank You to tobbbie For This Useful Post: [ View ]
6th February 2010, 11:33 PM   |  #2  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Device Specific threads are available for:

...I will add more here if someone else starts other device specific threads, please PM me for this.
Last edited by tobbbie; 23rd February 2010 at 01:14 PM.
6th February 2010, 11:33 PM   |  #3  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
A lot of background information can be found at the "Battery University": http://www.batteryuniversity.com/index.htm

A specially interesting part is the one about charging: http://www.batteryuniversity.com/partone-12.htm

I have seen a strange charge curves on my Hurricane device - it goes to 68% and jumps to 100% suddenly. This device has a very bad discharge curve (% accuracy) anyway - so the charge fits to that as well. I am using the T-Mobile Germany SDA 2 standard firmware of the device - and since it is in my "museum" I will not put more effort in getting it tracked down.

At least I can confirm that the discharge for the same battery in the same device is nearly identical (I did this for the worst performing battery). I will upload some new result Excel soon.

To be on the safe side that your battery is properly charged, leave the battery charging for at least 4 hours. This should make sure that "step 2" of the charge (where the charge current goes down until charge cut-off) is sufficiently executed. In how much the "green LED" signal is linked to charge-cut-off is device dependent - it may even be different if you charge via the bootloader (device is completely "off") or with the battery driver controling the job.
Last edited by tobbbie; 21st February 2010 at 04:12 PM.
15th February 2010, 04:30 AM   |  #4  
Addicted2xda's Avatar
Senior Member
Flag Kolkata, India
Thanks Meter: 136
 
2,206 posts
Join Date:Joined: Jan 2008
More
This is really an amazing tool. Thanks
17th February 2010, 09:33 AM   |  #5  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Ooops, this thread was lifted to the front-page news (I checked there to see the new design), so I hope to see some new device threads starting up and some more comparable data on "my" devices.

The echo was quite low (as of now: null) on these threads, so I suspect that people are happy with their batteries and have no need to know (or report) the truth.
17th February 2010, 10:52 AM   |  #6  
mccune's Avatar
Senior Member
Thanks Meter: 51
 
2,677 posts
Join Date:Joined: Nov 2005
Donate to Me
More
Will post this in the Rhodium section as well. Great idea!

Don't give up on projects like these. It looks like XDA has a lot of members compared to a few years back, but the group of tech geeks (this is actually meant positive) remain about the same. :P
17th February 2010, 11:00 AM   |  #7  
Senior Member
Thanks Meter: 7
 
101 posts
Join Date:Joined: Jan 2008
More
Thanks. Works on HD with Topix rom.
21st February 2010, 04:17 PM   |  #8  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
Please get back to this thread or PM me if you have reports of the test running on other devices. I'd prefer if you can deliver data along with your reports - of course.

Mind that the script can easily be enhanced to collect more information, e.g voltage or battery drain if these can be accessed via MortScript. A good place to observe is the HKLM\System\State\Battery\ where different drivers are updating useful information. Unfortunately not for mine, so I have not included it here.
23rd February 2010, 01:06 PM   |  #9  
mccune's Avatar
Senior Member
Thanks Meter: 51
 
2,677 posts
Join Date:Joined: Nov 2005
Donate to Me
More
I've posted this in the Rhodium section as promised.
You can find it right HERE. I did copy your post to keep things more general.

concerning the images you've posted they seem to lack some quality and are a bit hard to read.
EDIT: It seems that the graphics in the attachment from the first post are just fine.

Currently I'm charging my TouchPro2 to perform the test!
23rd February 2010, 01:31 PM   |  #10  
tobbbie's Avatar
OP Senior Member
Flag Stuttgart
Thanks Meter: 240
 
1,408 posts
Join Date:Joined: Jan 2007
More
thanks, mccune!

I have added your post to the list in post 2 of this thread. I really hope that all the speculation on usage time and performance which is derived by comparing "average use" over time will fade away using this simple method.

If you like to adapt the script by adding related registry values from your device, feel free to do so. Many newer battery drivers are supplying data to the HKLM\System\State\Battery hierarchy of the registry.
If doing this, please do it conditionally on existence of the value so that the script can stay generic and still run on devices where the driver does not supply the data.

I would like to follow two real physical values when the battery runs down: battery voltage and current drain from the battery. This could put the comparison of batteries even out of the "device specific" cage - still assuming that the supplied values are sufficiently accurate though. However, since charging LiIon batteries is much depending on accurate voltage, this assumption should be valid.

Regarding the pictures: The board limits the picture size to 640x480 and resizes accordingly. As you found out the ZIP has the original pictures inside.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes