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:
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:
The script reads from data that the BattClock program writes to the registry if you configure it to do so. Further changes are:
...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:
- install MortScript
- unzip the attached file to your PC
- put the battery-rundown.mscr file to the folder \My Documents\Battery or \Storage\My Documents\Battery for WM2K3 on your device
- 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.
- make sure all radio access is off (GSM/UMTS, BT, WLAN)
- adjust the display and backlight on battery to stay on forever as well as backlight brightness for battery use to maximum
- switch off the device
- 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.
- 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.
- disconnect from the charger (but you did this already, or?)
- You can check from time to time the content of the log-file to see the progress if you like.
- 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.
- after the device is off due to the empty battery, reconnect the charger and switch on after a few seconds of recovery
- 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.
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:
- 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.
- 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.
The script reads from data that the BattClock program writes to the registry if you configure it to do so. Further changes are:
- Also BatteryVoltage is read from BattClock Data
- 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
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 conceptAttachments
Last edited:
