Related
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:
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.
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:
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.
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:
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
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
Device Specific threads are available for:
Vox (tobbbie)
Tornado (tobbbie)
Hurricane (tobbbie)
Typhoon/Amadeus (tobbbie)
LG KS20 (tobbbie)
Rhodium/Touch Pro 2 (mccune)
...I will add more here if someone else starts other device specific threads, please PM me for this.
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.
This is really an amazing tool. Thanks
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.
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.
Thanks. Works on HD with Topix rom.
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.
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!
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.
@tobbie
I've finished the testing but I did not get the values quite correct in the Excel sheet it seems.
Can you have a look at it? You can just send me the pics and I'll post them in the Rhodium section for you.
I performed two tests.
First: just charging the battery till the LED turns green (100%) and followed the instructions from the first post to perform the test.
Second: After the first test I've removed the battery for about 30 seconds and inserted the battery but left the device turned off. After it was fully charged I removed the battery again for 30 seconds. I put back the battery and performed the test again. I've read that this is the way to calibrate your battery after flashing.
The data looks fine - you can take the sheets directly to generate an individual graph in Excel. Just mark the first 2 columns, select the "Graph" button and then the "Points(XY)" graph type.
You also have to take care that the right % values are taking the time data. It sometimes happens that the % rundown is not getting all values, so certain % values are simply never seen (like 99,98 or 24 in your data).
If you want to use one of my sheets as a sample, then you need to create a % scale first for your device (it seems it can take all % values - while for the Tornado the < 20% are stepping in larger increments).
Then the copy/paste has to use the "transpose" option of the "paste information" menu to convert the column to line data.
I have done a quick graph on your data, see attach. You can further beautify this. I am surprised to see that the device has 10 hours of rundown time with the large display. Are you sure you have set the light to the maximum value on battery?
What were the current drain readings you got from the driver?
Thanks for this I can really work with this. I realized that I could just replace your data with mine but you've already done it.
Concerning the brightness. I did set it to maximum. The ROM used however is my own custom Rhodium ROM. Maybe I'll repeat the test with a WM6.5 ROM to see if you can actually notice any difference. At the moment I'm testing a Nokia E72 so my Rhodium can be used for testing a little longer
I normally use Homescreen++ to view the current drain. Another option would be to use BattClock 1.9 which seem to support this feature as well.
What method do you use to read out the current drain?
mccune said:
The ROM used however is my own custom Rhodium ROM. Maybe I'll repeat the test with a WM6.5 ROM to see if you can actually notice any difference. At the moment I'm testing a Nokia E72 so my Rhodium can be used for testing a little longer
Click to expand...
Click to collapse
Good that you can spend some time on it. I doubt that the ROM is making a difference as the OEM drivers and settings (battery, display) are usually not changed when cooking.
You have seen in the charts that the "calibration" is actually not doing anything worth noting down. Put in a different battery (other vendor) and you will see a difference. Nice to see that the percentage rundown is nearly linear on the device
mccune said:
I normally use Homescreen++ to view the current drain. Another option would be to use BattClock 1.9 which seem to support this feature as well.
What method do you use to read out the current drain?
Click to expand...
Click to collapse
Both programs ask the same driver so they should deliver the same values.
Can you actually TELL what the value of your drain was on the Rhodium?
My "method" is to connect an Ampere-meter (an old analog one to get a clue on the average current) - a little tricky though but it works once you have managed to get the "adapter" assembled.
My current drain on the Rhodium is:
- full lit display: 134 mA
- dim display: 35 mA
- Backlight can't be turned off so can't tell what the current drain for the third measurement is.
Modified the post in the Rhodium section.
Also added this line to the post:
"(If you want to use software try HomeScreen++ or BattClock to get the readings about the current drain.)"
Updated the Rhodium section. This should be the data you were after, right?
Yes it is - actually for calculating the capacity it is now simple: roughly 10 hours with 135 mA gives 1350 mAh capacity for the battery in the Rhodium. What is the rated capacity of the battery inside?
Was it the regular battery or a spare one from a different vendor?
If you use my sheets as a template you find fields for any of the interesting data that can be listed - also battery manufacturer and serial to tell apart different batteries.
I will add the two programs to the first post so that people do not have to read the full thread. Thanks for the information.
tobbbie said:
Yes it is - actually for calculating the capacity it is now simple: roughly 10 hours with 135 mA gives 1350 mAh capacity for the battery in the Rhodium. What is the rated capacity of the battery inside?
Was it the regular battery or a spare one from a different vendor?........
Click to expand...
Click to collapse
I use the regular Rhodium battery. Age is about 6 or 7 months now.
Today I've finished the test with a WM6.5 ROM. As you've predicted it's pretty much the same so I decided not to add it.
What might be useful to know is that you only get 10% increments when using the default battery driver from HTC. On my 6.1 ROM I was using a 1% driver so the data is measured much more frequent.
Data for PURE
Hi,
I have recorded data for my PURE.
It seems to suck battery very fast. Doesn't normally last a workday.
I am running TESS LEO IV ROM.
Would love to compare with someone with a similar device but did not see a thread for the PURE/D2/Topaz
Thanks.
This video : http://www.youtube.com/watch?v=DqdHFmKq57c
Says if you drain your htc hd 2 battery full out. And then charge it full. It will work longer.
Is this right? And some pp says its bad for your battery.
106 views... no replies ;(
well.. the idea originated from laptop battery tricks and some facts about the technical side of the problem.
If i try to simply put it, a laptop battery contains (beside the actual battery) a small pcb that has a charge/discharge controller and a eeprom memory chip (among others). The point of having these is also pretty simple. The battery actively communicates with the laptop via a i2c interface, so that the laptop always knows the state of the plugged in battery. The laptop itself can't measure the current or voltage of the battery and doesn't know it's capacity or composition. Instead the chips inside the battery does all this work and reports it to the laptop. That's how the laptop knows when you plug a different capacity battery or other things. The percentage of power remaining is measured by the chip inside the battery and stored in a volatile memory also contained on the small pcm inside. This memory can be accesed by the laptop and from there, it will display you the remaining power left (in percents %). This is updated as long as there is any notable difference from what the chip measures from the battery cells and what was the last measurement made. So.. what would happen if you would charge the battery to 100% full, then disassemble it, remove the 100% charged cells and replace them with 50% charged ones.
When you would start the laptop next time, it will STILL display 100% charge, the last measurement, and will assume this state is valid for the cells. When the physical batteries will drop the charge level with 1% the laptop would display 99%. So around 50% displayed the batteries will actually be empty. When you charge them back, the laptop would start from 50% and go back to 100%. The actual batteries would get only 50% energy, so they won't get fully charged, therefore you get less battery life.
Of course, this is a very exagerated scenario, but in practice, sometimes small errors can occur, when the physical level of the batteries is a bit different to what the battery controller recorded. In this case, a full discharge then recharge can help to correct this issues (but only if you're talking about couple percents - not more).
But... when we're talking about phones, things are quite different. The communication algorithm between the battery and phone is more simpler and the battery itself doesn't know it's charge state. The phone will actively probe the battery in order to update it's status. So, if i remove the battery and drain it somehow, the phone will display it's correct physical charge next time i plug it in. This is possible because a phone battery and the phone itself is simpler by design then a laptop for example.
So why laptops used such complicated charge algorithms? Mainly because 2 reasons. One because laptop batteries are dangerous things. If improperly charged or damaged they CAN explode. If the cells are damaged, overcharged or the temperature is high, the controller chip will change the state of the eeprom memory so that the laptop and it's OS to see that the battery was damaged/empty and shutdown at once. The other reasons is quite commercial based. The charge controller counts each charge cycle and stores it in that eeprom memory. So if the manufacturer specified a specific number for the charge cycles, when this number is reached, the controller will simply rewrite the eeprom and state that the battery is "dead". So.. go get a new one.
I disassembled many batteries and among "dead" ones, i found many cases where the cells were actually in pretty good shape and functional. I measured cells with more then half the original design capacity still available, but the battery pack was reported as being "dead".
So back to hd2. As i've stated, phones use simpler charge/discharge algorithms. The better part is that they are more simplistic and efficient at measuring the actual physical state of the battery. So, a calibration isn't required like on some laptops.
However, sometimes is good to have a full discharge/recharge cycle. This being because of the chemistry of such a battery. It won't do miracles, it won't make the battery last longer on a charge but it could prolong overall battery life. Lithium is a very reactive element, a deep discharge about once a month will help reduce the effects of naturally occuring oxidation of such materials in an electrolytic compound.
My Motorola Defy MB525 is experiencing strange battery drains. It usually drains itself regardless of usage or power state. Even in a shut down state, the battery still continues to discharge. The strangest of all is that after each charge I'm able to use the device for about 36 - 40 hours, regardless of none, low, mild or heavy usage. For about 2 years, the battery lasted around 3 - 7 days.
At first I though, it was the battery. However, after I've purchased a new original Motorola battery, the issue still persists.
In addition, the first signs of this issue arose right after a CM11 change from the stock Android 2.2.2 and continued even after I've reinstalled the Android available .SRT file over RDS Lite for the 2.2.2 version.
I've tried different suggestions and tutorials (for example - CPU Deep Sleep, WiFi power management, Baseband Change, etc.) available on the forum, but without any use.
Thus, my only question :
Even tough the device works without any major glitches, as expected from such a device. Does the above mentioned issue relate to a Motherboard or Power Management/State Chip failure?
Btw...I've took the device apart to check if there are any signs of shorted elements or short-outs. Sadly, nothing of sort.
Any help and/or suggestion would be appreciated.
Hi, maybe try another CM11 nightly or another custom ROM to see if the same problem persists?
this [http://forum.xda-developers.com/showthread.php?t=1778492 thread] goes in-deep on battery problems, but, knowing a lot about electronics, I think in your case is just that inside the phone, there is a small switching-mode power supply, and it have a (fairly) large capacitor that can leak some current. When capacitors age they became more of a resistor... and that's why most of modern electronics break up. I would blame hardware in this case.
Is it possible to get dash charge working on our device?
No.
By far, not possible, you need the OnePlus blob for it, the Kernel driver and the needed changes in AOSP system/core code to make it possible.
Even coding the Kernel part of it doesn't help much since OnePlus has obviously created strong checks on that level. LeEco has done some changes, though, to allow more current in the QPNP controller flux at the cost of battery heat throughput. In don't think those changes would make charging faster at a point that you sacrifice Qcom's recommended charging factors to get 5min less charging time, also battery safety on this device is a little doubtful since they adopted a cheaper manufacturer.
We'll see if some code from dash charge in Kernel is helpful and can be adapted but it's too early to say anything since I don't have my device in hands and I'd need to buy some electrical equipment to measure those properly.
What we can do is hack the code to allow user tweaking of the max allowed USB voltage to allow more throughput in current but that's unsafe for this kind of battery, I did this on my LG G2 but the battery in that device is well known and much smaller, safer in that case.
Thanks for the info. After reading about Dash, one of the great things about it is that the load (or whatever) is done in the power block and not on the device (unlike Quick Charge 3.0). That means that the OnePlus stays very cool during charging.
My main concern is premature battery wear considering the amount of heat generated during charging. It would be really nice to be able to limit the current to bring down the heat. Some of us don't really need to have this thing fully charge in a record amount of time . Maybe we cam add the capability to reduce the current, but not set it above default. I would be super happy if we could get a stock kernel with a modification that allows for this sort of change .
Thanks!
slgooding said:
Thanks for the info. After reading about Dash, one of the great things about it is that the load (or whatever) is done in the power block and not on the device (unlike Quick Charge 3.0). That means that the OnePlus stays very cool during charging.
My main concern is premature battery wear considering the amount of heat generated during charging. It would be really nice to be able to limit the current to bring down the heat. Some of us don't really need to have this thing fully charge in a record amount of time . Maybe we cam add the capability to reduce the current, but not set it above default. I would be super happy if we could get a stock kernel with a modification that allows for this sort of change .
Thanks!
Click to expand...
Click to collapse
This is the main modification that LeTV developers did to make it charge faster. The current is not static, it has many variables and thresholds, battery temperature always reduces the current otherwise boom!
The max allowed temperature is HARD_HOT level:
Code:
dmesg | grep 'hard hot hysteresis'
This will be printed right after you start charging, in the middle of the charge (~45% to ~60%) the battery should be at the maximum possible stress it can handle and thus the command above will freak out and spam your dmesg, almost sure about that.
Code:
if (chip->health == POWER_SUPPLY_HEALTH_OVERHEAT && !chip->batt_hot) {
/* turn down the hard hot threshold */
chip->batt_hot = true;
set_prop_jeita_temp(chip, FG_MEM_HARD_HOT,
hard_hot - chip->hot_hysteresis);
if (fg_debug_mask & FG_STATUS)
pr_info("hard hot hysteresis: old hot=%d, new hot=%d\n",
hard_hot, hard_hot - chip->hot_hysteresis);
This usually happens when the battery goes overheat, which happens often on QC charger stack, obviously.
But LeTV changed it from 450 to 550, allowing more heat on the hard hot hysteresis threshold than default (this is Celcius / 10 if not mistaken), so 55°C is the max temperature that battery will get before throttling down the "current" (it's more complicated than that, way more) when the proper value is 45°C. The have also put the SOFT_HOT value to where the HARD_HOT used to stay allowing faster current and battery heat where it should already be throttling down.
Change: https://github.com/GalaticStryder/k...dc3#diff-ba1944522cdd0a230c7769e47eefcd48R247
OnePlus changed nothing in those factors, I didn't change those factors on my Kernel as well.
From device tree:
Code:
qcom,warm-bat-decidegc = <450>; // 45°C
qcom,hot-bat-decidegc = <500>; // 50°C
qcom,cool-bat-decidegc = <100>; // 10°C
If you install Ampere app you will see what Galactyc is explaining. I see the battery charging at 4A until battery temp reached 38C an then it start charging at 2.5A. Im using CM13 kernel, so maybe this is different in stock, but you can see the way it works.
In short what I'm doing here and what is the purpose of this. I was able to mod the phone in a way to be used as a 3D printer klipper firmware server by removing the battery and 3D printed a custom one, in which I placed a DC to DC step down module to use the 24v from the 3D printer and step it down to 4v to power on the phone and it all works great! If interested in doing this can share more details, stl for the custom battery and links to the step down module I used. The phone boots and runs perfectly! I run debian linux in container in linux deploy app in which I installed all the needed software to run klipper (klipper, moonraker and mainsail), installed custom driver to connect the printer serial to the micro usb on the phone and all works great!
My problem is that the phone battery level indicator slowly shows like the phone is discharging but it isn't in reallity because it is hardwired to stable voltage from the dc step down module I used. Currently installed android 6 (cyanogen mod 13.0-j3xnite) because the newer versions of android are pain in the a*s to run linux without android to cut it's services and hibernate it, so I'm looking a way to force or trick android think it's battery level stays the same or fake the numbers on it because I'm worried if the level goes down to 0 maybe android will try to shut it down.... I haven't experienced it because it "discharges" at very slow rate but I'm also worried to run a long print on the printer because of this. As you my assume I have root and bla bla... Searched the interned how to force android to set custom battery level but there are only fake apps how to trick friends or your bos that your phone doesn't have battery. Maybe I will need help from a developer how to trick android kernel to show custom or static battery level, or to use some magisk / xposed module for this. Please help me, highly appreciated! Thank you for your time!
Problem solved. Solution thanks to Renate on XDA!
Copy a file that contains only "1" on every hour with a custom magisk script over /sys/devices/sec-battery.4/power_supply/battery/batt_reset_soc from my AICP rom android 6. In this way the battery level gauge is being reset on every hour and depending on your voltage you are supplying the phone with it shows different % calculated on this. I supply the phone with 4.0V and it shows 80% battery left and runs forever. Good luck modders And thanks Renate!