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.
So after inspiron's post about the Adam battery life being pretty decent, here:
http://forum.xda-developers.com/showthread.php?t=948923
I saw some threads about how to make it better here on XDA and elsewhere.
Apparently the "Cell Standby" application takes up a decent chunk of battery life from any android tablet running it.
While I can find info about removing it on the nook color, such as the post here: http://forum.xda-developers.com/showthread.php?t=888216
I'm not sure if that'll work on the adam.
Has anyone had success in removing that process, or is any intrepid coders willing to try to find a way to remove it?
there was some information about this for the viewsonic tablet, which is closer to the adam, ill see if I can find the link to that. I'll end up messing with the adam this weekend.
There have been several posts from a luis84 over at notionaddicts.com and he indicated that he was able to shut it down using a variation of the nook script. He appears to be onto something with what he has done.
http://www.notionaddicts.com/forums/showthread.php/1437-Battery-life/page10
Here are his last couple of posts:
"adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot
is the code used.
of course that did not work on my Adam so I manually navigated to the directories and renamed the target files.
Here is my results: I don't know yet. I just did it, I will post results later. After a reboot the cell standby is gone which is a good sign."
"@Flaunt after letting it standby all night it lost 3% charge. I then proceeded to watch Justin.tv (no judging) for 2 hours in Bed this morning, which is LCD at 80% brightness + Wifi for data (Justin.tv is streaming) and it lost an additional 9%. So I would confirm it is a SUBSTANTIAL IMPROVEMENT. With these results, I could theoretically watch streaming TV for 11 hours without a problem.
I am fairly impressed. I still feel it can do better, there is a ton of other crap running. I am hopeful once honeycomb comes and real support for the TEGRA 2's power management system.
I recommend everyone to immediatly remove the cell standy service. One annoying fault, mine came back after a reboot so it looks like I would have to run the above command after every reboot, since I rarely reboot Adam this is not an issue. I will try it again and see if it comes back, if it does maybe we can automate the process somehow."
Basically my understanding, if I am reading his posts correctly, is that he manually changed two files "/system/app/Phone.apk" and "/system/app/TelephonyProvider.apk" to "/system/app/Phone.OLD" and t "/system/app/TelephonyProvider.OLD" and then after a reboot, the cell standby service process was no longer running, but after a subsequent reboot, it reappeared.
legaleagll said:
Basically my understanding, if I am reading his posts correctly, is that he manually changed two files "/system/app/Phone.apk" and "/system/app/TelephonyProvider.apk" to "/system/app/Phone.OLD" and t "/system/app/TelephonyProvider.OLD" and then after a reboot, the cell standby service process was no longer running, but after a subsequent reboot, it reappeared.
Click to expand...
Click to collapse
You can try use RootExplorer delete these files, it should be work.
Maybe a noob question here. Would removing/renaming phone.apk also remove the 3G data connection or only voice calls, which the Adam doesn't support anyway?
Sent from my HTC Desire using XDA App
litening said:
Maybe a noob question here. Would removing/renaming phone.apk also remove the 3G data connection or only voice calls, which the Adam doesn't support anyway?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
The issue is that because Android up till now (pre-honeycomb) has exclusively been a phone OS - there are certain apps and processes that may be running that deal with phone features. Those apps - even if a device does not support their function - may run in the background and drain battery life. For instance, and this is hypothetical, the phone app may constantly be searching for signal or phone antenna and never find it but keep running in the background.
As of yet - no one really knows what CELL STANDBY does - however it appears that removing the app improves batt life.
i will give this a try since i dont use my tablet as a phone...{silly people} lol
i usually get a 24-29% drain through a day with minimal usage. with most of it going to cell standy...whooping ~71%!
inspiron41 said:
i will give this a try since i dont use my tablet as a phone...{silly people} lol
i usually get a 24-29% drain through a day with minimal usage. with most of it going to cell standy...whooping ~71%!
Click to expand...
Click to collapse
Great Inspiron,
Can you check you still have 3G data functionality when you remove phone.apk and the other file mentioned.
I am not sure if these apps also handle part or all of the data connections (wouldn't expect them to but you never know).
Sent from my HTC Desire using XDA App
instead of seeing Cell Standby i see Phone Idle...should i be concerned? It's like consuming like 89% percentage of my battery usage after an hour.
Phone Idle - 89%
Wifi - 7%
Display - 4%
It all depends I guess... in that hour, how much did your battery go down? Going by the quoted NotionAddicts post, if they had only 3% battery loss when the adam was left on overnight, and assuming at least 6 hours, that is a total system drain of about .5% an hour. The only way to determine what your saving is to measure what battery % your losing while doing nothing with the Adam (screen off, in standby) with both the standard setup and the modified setup. I would try to do this overnight (to avoid withdrawl ) two nights in a row, keeping the time the same, and then comparing the results
If adam loses 25% after 6 hours with Cell Standby, then you can extrapolate a time of about 24 hours in standby. If the adam loses 5% after 6 hours with the Phone.apk/TelephonyProvider.apk renamed/removed, then you can extrapolate a time of about 120 hours in standby. Therefore, with those numbers, you would have 5 times the standby time with those apk's removed. (The numbers used are for illustrative purposes only)
Another thing people may want to try is removing/disabling the DRM Content service. I don't know if it would apply to the adam (as many other android phones don't have the issue), but I have a samsung epic 4g, and on the current stock rom, that is one of the biggest battery hogs because it won't let the phone sleep properly sometimes resulting in about 5-10% battery loss an hour (1500mAh battery compared to adam's 6500-7000 mAh battery (if my math is correct)). If you remove it, it may cause audio/video playback issues, but if you just disable it using Titanium Backup (by 'freezing' it) or Auto Starts (root needed for both), everything works fine.
Assuming you've enabled Market access already, you may want to make sure that everything in the market is still viewable. There were problems with the second to latest build of Nookie Froyo for the Barnes & Noble Nook Color because the dev had removed Phone and Camera APKs. Once he restored them, the apps were back for everyone.
legaleagll said:
There have been several posts from a luis84 over at notionaddicts.com and he indicated that he was able to shut it down using a variation of the nook script. He appears to be onto something with what he has done.
http://www.notionaddicts.com/forums/showthread.php/1437-Battery-life/page10
Here are his last couple of posts:
"adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot
is the code used.
of course that did not work on my Adam so I manually navigated to the directories and renamed the target files.
Here is my results: I don't know yet. I just did it, I will post results later. After a reboot the cell standby is gone which is a good sign."
"@Flaunt after letting it standby all night it lost 3% charge. I then proceeded to watch Justin.tv (no judging) for 2 hours in Bed this morning, which is LCD at 80% brightness + Wifi for data (Justin.tv is streaming) and it lost an additional 9%. So I would confirm it is a SUBSTANTIAL IMPROVEMENT. With these results, I could theoretically watch streaming TV for 11 hours without a problem.
I am fairly impressed. I still feel it can do better, there is a ton of other crap running. I am hopeful once honeycomb comes and real support for the TEGRA 2's power management system.
I recommend everyone to immediatly remove the cell standy service. One annoying fault, mine came back after a reboot so it looks like I would have to run the above command after every reboot, since I rarely reboot Adam this is not an issue. I will try it again and see if it comes back, if it does maybe we can automate the process somehow."
Click to expand...
Click to collapse
i can't give straight numbers, but after minimal uses, my battery drain down to 72% after 10.5 hrs. i was expecting my batteries to be at like 55-64%. that's with Auto-Brightness enabled and everything else disabled. but i did connect to the internet once to check whether i got the update
legaleagll said:
There have been several posts from a luis84 over at notionaddicts.com and he indicated that he was able to shut it down using a variation of the nook script. He appears to be onto something with what he has done.
http://www.notionaddicts.com/forums/showthread.php/1437-Battery-life/page10
Here are his last couple of posts:
"adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot
is the code used.
of course that did not work on my Adam so I manually navigated to the directories and renamed the target files.
Here is my results: I don't know yet. I just did it, I will post results later. After a reboot the cell standby is gone which is a good sign."
"@Flaunt after letting it standby all night it lost 3% charge. I then proceeded to watch Justin.tv (no judging) for 2 hours in Bed this morning, which is LCD at 80% brightness + Wifi for data (Justin.tv is streaming) and it lost an additional 9%. So I would confirm it is a SUBSTANTIAL IMPROVEMENT. With these results, I could theoretically watch streaming TV for 11 hours without a problem.
I am fairly impressed. I still feel it can do better, there is a ton of other crap running. I am hopeful once honeycomb comes and real support for the TEGRA 2's power management system.
I recommend everyone to immediatly remove the cell standy service. One annoying fault, mine came back after a reboot so it looks like I would have to run the above command after every reboot, since I rarely reboot Adam this is not an issue. I will try it again and see if it comes back, if it does maybe we can automate the process somehow."
Click to expand...
Click to collapse
On my HTC Evo with the Seidio 3500mAh battery I accidentally left it in airplane mode for 19 hours, battery loss was just under 3% also, I have not seen "cell standby" since two updates back (the one before christmas, not the one right after). Should be getting my Adam the first week of March and hope to be able to get some impressive battery life out of it. I always run my screen brightness at 12% or less indoors on my Evo, so I may spend most of my time in e-ink mode on the Adam. Since I got the wifi model, I'll be rooting and trying the afore mentioned renaming of the cell .apk's and I'm looking forward to anything else that comes up on XDA for battery improvement.
Here is my method of calibration.
You MUST BE ROOTED
Download terminal emulator from market.
1.Charge your battery fully.
2.Cable remain plugged in
3.Go to terminal emulator
4.type "su", and allowed by super user.
5.type "rm /data/system/batterystats.bin" then your battery stat has been deleted. There is no other notifying sentence or whatever.
6.Unplug the charger
7.You will see immediate battery drop at this moment. and this is where it has not been charged.
8.Plug charger and charge fully.
Your batterystat is already created automatically
9. Repeat 4~8
10. Now you will find the gap of immediate drop decreasing.
PS//
When the immediate drop becomes 99% it can be said that it is done.
I personally think this is the phone itself related bug or something.
Because what I found was when I plug in charger it immediately becomes 100% and unplug 99%. that means for galaxy S 100% is really when it is 100%. for example if its 999/1000 it recognizes it as 99%. Got what i am saying?
Anyway you will find that it will stay long at 99%.
Why is that method Proper .
As opposed to using Clockwork to delete battery stats .
jje
Beat me to it jje, also ive found if you remove the charger as soon as it say to it will drop to 98 99%, if i leave in in for 1/2 hour it will be 100% when charger is removed
Does not work for me. Before i remove batterystats it says 95%, after it too. No changes there...
Working well for me. After removing battery stats 100% stays for a long time.
Thanks for your info
seems to be working
seems to be working
thanks
The Permissions app on my phone shows a permission for "modify battery statistics". Explanation: Allows the modification of collected battery statistics. Not for use by normal applications.
The permission is used by the following Samsung apps: Settings, Software update, and MTP Application.
So I suppose there is also a way to do this from an app...
Actually, the battery needs to NOT go to 100% ...
it's done like that as a protection for you NOT to overcharge the battery to protect it's usable life...
so a drop from 100% to 98% upon discharging is actually good.
While I've had many Android phones, this is the first phone that I decided to use a battery charging controller to regulate how my battery is charged. I just wanted to share my journey with others and encourage others to try this out if you are not already.
Although there are several different battery charging controllers out there (and more than one named "ACC" which makes it even more confusing) I decided to use the Advanced Charging Controller module developed by VR25. I choose this module because I felt it provided the most customization.
Step 1 - Installation
Installing the module is easy. It is listed in the Magisk repository. Simply browse the available modules and find the one titled, "Advanced Charging Controller (acc) created by VR25 @ XDA-developers". There are several ACC modules, so make sure you install the one by VR25 to follow this thread.
Magisk will flash the module and start it automatically. You don't even need to reboot, although it is the only way to clear the Magisk notification that the module will be started at the next reboot.
Step 2 - Changing the Charging Switch Setting
I found that the default charging switch setting (auto) does not work reliably with our phones. Therefore I would suggest changing it using the commands below. Personally I have choose option 2 (battery/charge_disable 0 1) but I listed all the options with the quirks that I have found with each one.
Step 2.1 - open your preferred command line app - I use Terminal Emulator.
Step 2.2 - type "su" and hit enter to gain root
Step 2.3 - type "acc -s s" and hit enter - this is the command that allows us to select another charging switch
Step 2.4 - type what number of the charging switch you want to use.
Here are the available charging switches and the issues I have found with them:
1) Automatic - this switch tries to cycle through the available switches until if find one that "works".
- Passes the ACC switch test (type "acc -t"): Yes
- Charges and discharges according to the cooldownratio: No - I found that the phone would charge anytime it was plugged in and below the Pause threshold. It did not seem to wait until the battery level was below the Resume threshold.
- Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): Yes
- Begins charging when phone reaches Resume threshold: Yes
- Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: ???
- Suffers from wakelock issues when phone is plugged in but not charging: It does have a "overheat_mitigation" wakelock when on the battery idle mode, but because the phone is not using the battery power, it doesn't effect battery life and therefore I don't concern myself with this issue.
- Other issues:
2) battery/charge_disable 0 1 :
- Passes the ACC switch test (type "acc -t"): Yes
- Charges and discharges according to the cooldownratio: Yes
- Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): Yes
- Begins charging when phone reaches Resume threshold: Yes
- Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: ???
- Suffers from wakelock issues when phone is plugged in but not charging: It does have a "overheat_mitigation" wakelock when on the battery idle mode, but because the phone is not using the battery power, it doesn't effect battery life and therefore I don't concern myself with this issue.
- Other issues:3) battery/input_suspend 0 1:
- Passes the ACC switch test (type "acc -t"): Yes
- Charges and discharges according to the cooldownratio: Yes
- Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): No - phone begins discharging from battery when Pause threshold is reached but the phone is still plugged in
- Begins charging when phone reaches Resume threshold: Yes
- Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: No - may show charging icon when phone is really discharging, especially during cooldownratio times and the chime doesn't always ring when charging resumes.
- Suffers from wakelock issues when phone is plugged in but not charging: No
- Other issues: The phone seems to follow the cooldown charge/discharge times even before reaching the cooldown threshold. I find the phone pausing for 10 seconds (my cool down ratio) when the batter level might be a 50% - long before the 60% cooldown threshold I have set in the config file.4) dc/input_suspend 0 1:
- Passes the ACC switch test (type "acc -t"): NO, so this switch doesn't work with ACC
- Charges and discharges according to the cooldownratio:
- Starts discharging when the phone reaches the Pause threshold:
- Begins charging when phone reaches Resume threshold:
- Charging "chime" and battery icons correctly reflect if the phone is charging or discharging:
- Suffers from wakelock issues when phone is plugged in but not charging:
- Other issues:5) battery/charge_control_limit 0 1:
- Passes the ACC switch test (type "acc -t"): NO, so this switch doesn't work with ACC
- Charges and discharges according to the cooldownratio:
- Starts discharging when the phone reaches the Pause threshold:
- Begins charging when phone reaches Resume threshold:
- Charging "chime" and battery icons correctly reflect if the phone is charging or discharging:
- Suffers from wakelock issues when phone is plugged in but not charging:
- Other issues:
Step 3 - Configuration
You can configure the ACC controller using a couple of different methods. You can do everything using command lines, you can use the beta ACC app (see note below), or you can edit a config file that ACC creates when it is installed. Personally I found that editing the config file was the quickest and easiest method to make general changes.
The ACC config file is found at /storage/emulated/0/acc The file is named "config.txt" You can open the file with a text editor. I personally use the app Root Explorer. I long click on the file name, and then press the three dot button in the upper right hand corner. Choose "Open in Text Editor" and the config file will open and allow changes to be made. Saving the file will automatically push the changes to ACC, you do not need to reboot or restart the ACC daemon for changes to take effect.
I won't go into a lot of detail about all of the different configuration options here as the developer's xda thread is the best place to get that type of information. But I will talk about the most basic setting - the "capacity" setting. It is the second setting listed in the config file and it should look something like "capacity=0, 60, 70-80". Here is a break down of what those numbers mean:
- The First Number (0): is battery level were the phone will shut off. The default setting of 0 means the phone will turn off when the battery level hits 0. Personally I don't want my battery completely draining, so I have it set at 5.
- The Second Number (60): is the battery level where the module starts it's "cool down" functionality. Cool down (listed as coolDownRatio in the config file) is where the phone will stop charging briefly and then restart charging. The default "cool down" setting is coolDownRatio=50/10 which means the phone will charge for 50 seconds, and then stop charging for 10 seconds before charging again for 50 seconds, etc, etc, etc. This is designed to keep the battery temps low. A battery with a charge level less than this number (60 in this example) will charge without pausing, but when the battery level gets to this number or above, the phone will charge and pause based on the coolDownRatio.
- The Third Number (70): is the "resume" value. If the phone's battery level is below this resume value, the phone will charge. If the battery level is at or above this resume value, the phone will not charge even while plugged in.
- The Fourth Number (80): is the "pause" value. This is the battery level where the phone will stop charging and should not charge above this value.
The default settings are set this way because research has shown that a phone's battery will last the longest with the least amount of battery capacity loss if it is charged to a max of 80% of the battery's capacity, and allowed to discharge just a small amount (10%) before being charged again. I realize this goes against the old "wives tale" that our phone's batteries have a very limited number of charges and it is best to limit the number of charges by only charging the phone when it gets to a low level. This is not true in actual battery performance however and if you charge like this, you are actually decreasing your battery's life expectancy and performance.
Obviously the default settings may not be the best setting for you. The default settings are probably only practical for a device that is plugged in 100% of the time. Personally I have changed my capacity setting to capacity=5, 60, 70-90. This means my phone will turn off when the battery level reaches 5% (something it has never dropped to yet), it is charged to a max of 90% and will discharge to 70% before charging again, and the cooldown charging cycling starts when the battery is 60% or higher. Obviously I'm not on my charger all the time, so it is very common for my battery to drop below 70%. However, if the battery is below 70% and I have a charger at my disposal, I am going to charge the phone back to 90% rather than let it the battery levels continue to fall.
Final Notes and Misc Thoughts
There are lots of other options and commands you can use in ACC. Feel free to share any changes you like to make, or post if you are having problems getting the module to work as expected on the 3a. I hope this helps some people feel give the module a try.
There is an ACC app that is available now that allows you to control some of the settings from a nice GUI. I personally did not like using it as I found it would overwrite settings in the config file that I was not intending to be changed.
There is an ACC telegram group if you want to join and have direct communication with the developer and others.
Thanks to @jellopuddingstick for educating me on what the battery idle mode does and why it is beneficial to have it working!
if you want to extend your batteries life, one of the best ways is to not fast charge it. fast charging not only degrades it a bit faster because of the amount of current, but it also tends to heat the battery up more which makes it degrade even faster too. heat is the main reason i tell people not to use wireless charging.
pbanj said:
if you want to extend your batteries life, one of the best ways is to not fast charge it. fast charging not only degrades it a bit faster because of the amount of current, but it also tends to heat the battery up more which makes it degrade even faster too. heat is the main reason i tell people not to use wireless charging.
Click to expand...
Click to collapse
This is why I always use a low current charger unless I absolutely need a quick charge. I have used the Dash charger that came with my OnePlus 5 only about 10 times in 2 years.
As I use my phone more, I realize that none of the charging switches seem to work 100% of the time as expected. I'll continue to do trial and error tests, but please share if you find a switch that works consistently.
sic0048 said:
As I use my phone more, I realize that none of the charging switches seem to work 100% of the time as expected. I'll continue to do trial and error tests, but please share if you find a switch that works consistently.
Click to expand...
Click to collapse
I was having issues with ACC not working before installing the apk. I'll report back if I have any issues.
Nice guide BTW.
I've continued to edit my original post to provide as much information about the different charging switches and the issues I see with each one. Hopefully it is easy to understand.
I still find myself defaulting to the 3rd charging switch option and while it can act a little erratic sometimes, it does work normally most of the time.
I'm just curious if anyone has tried the "auto" charging switch in the latest ACC version? According to the release notes, there was some changes made to the auto system as it may not have been working correctly.
I'll try it here in a little while, but thought I would ask.
sic0048 said:
I'm just curious if anyone has tried the "auto" charging switch in the latest ACC version? According to the release notes, there was some changes made to the auto system as it may not have been working correctly.
I'll try it here in a little while, but thought I would ask.
Click to expand...
Click to collapse
I've been using the apk auto switch, no issues.
Is this working for anyone:
usb/current_max:500000
I have is set in the app as an On plugged option and It is not working for me.
gargleblarg said:
I've been using the apk auto switch, no issues.
Click to expand...
Click to collapse
The phone discharges at the pause threshold and not simply hold the charge at the threshold percentage?
I found the auto setting showed the same tendencies as switch 2 - not discharging below the pause threshold. But I haven't tried it with the new release which specifically mentioned the auto setting bring changed.
sic0048 said:
The phone discharges at the pause threshold and not simply hold the charge at the threshold percentage?
I found the auto setting showed the same tendencies as switch 2 - not discharging below the pause threshold. But I haven't tried it with the new release which specifically mentioned the auto setting bring changed.
Click to expand...
Click to collapse
I'm on 2019.6.14-r1 version.
I charged up to 80% and kept it plugged in to see if it would drop or maintain, it dropped. It took forever.
Edit: 8 hours later and it has only dropped to 78%
@creeve4, I can't get the On Plugged options to work either. I tried "./usb/current_max:500000" and "usb/current_max:500000", I tried unplugging/plugging in the charger, resetting the daemon, still no luck. The settings were saved to the config file correctly. No idea.
gargleblarg said:
I'm on 2019.6.14-r1 version.
I charged up to 80% and kept it plugged in to see if it would drop or maintain, it dropped. It took forever.
Edit: 8 hours later and it has only dropped to 78%
Click to expand...
Click to collapse
Interesting. That's unfortunately not what I experience.
I just tried the auto setting and plugged my phone in and it immediately went into what I am calling a "maintenance charge". It was only charging the phone by about 200 mA. I set the charging switch back to #3, unplugged and replugged in the phone and it is charging at about 1200mA which a pretty normal charging current for me.
It's this same roughly 200mA charge that I have seen previously with the auto setting after the phone reaches the set pause threshold - so the phone charges at normal current levels and then drops to the 200mA current after reaching the pause threshold. Admittedly, I did not allow the phone to reach the pause threshold this time (which would take forever at 200mA), but seeing that charging level at all leads me to believe that the auto charging switch is still not working for me (it should either be fully charging or full discharging). I suspect because the phone was above the resume threshold it defaulted to this maintenance charge (thinking the phone shouldn't be fully charged until it dropped below the resume threshold).
sic0048 said:
Interesting. That's unfortunately not what I experience.
Click to expand...
Click to collapse
What was the battery level when you plugged it in?
sic0048 said:
Interesting. That's unfortunately not what I experience.
Click to expand...
Click to collapse
That is interesting, have you tried updating yet?
I should also mention that I have only changed the percentage to 3% for the phone to shut off, the rest of the options are default.
Is anyone else getting the following message in the acc app after updating to the latest version?
creeve4 said:
Is anyone else getting the following message in the acc app after updating to the latest version?
Click to expand...
Click to collapse
I'm not using the app, so I can't answer your question. I was hoping someone else might chime in if they are using the app.
sic0048 said:
I'm not using the app, so I can't answer your question. I was hoping someone else might chime in if they are using the app.
Click to expand...
Click to collapse
I just needed to update to the latest app version. The module was updated before the app.
Did anyone else lose their config settings when updating the ACC module recently? I updated a day or two ago and woke up to my phone at 100% charge. I started troubleshooting and found that the config file was set to all the default settings. This means the charging switch was set to "auto" which has never worked for me and it explains why the module didn't pause the charging at the default pause setting (80%).
The release notes talked about a lot of changes in the config file, but it never mentioned that users would lose their settings and be reset to default. I was just curious if anyone else experienced the same thing or not.
There's a bit of misinformation / misunderstanding going on here, I think. The best control file for our devices is battery/charge_disable. The "maintenance charge" (ACC refers to it as "idle mode") you're referring to is a good thing! This is explained both in the ACC readme [1] and by the developer of Battery Charge Limit [2][3]. The ping-ponging between the upper and lower thresholds is a fallback, it's not the desired mechanism. Hope this clears things up!
[1] "Charging switches that support battery idle mode take precedence", https://github.com/VR-25/acc/blob/master/README.md
[2] https://forum.xda-developers.com/showpost.php?p=76523599&postcount=1834
[3] https://android.stackexchange.com/a/200037
umm, i would be happy if someone give an advice to me the best configuration for the best battery charging cycle, anyone can help me?
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!