With the HD2's pretty short battery life compared to my previous HTC phones, and also as I was a bit bored , I decided to have a look at how much the different systems drain in the HD2, and did some tests.
So for anyone interested, here are the results:
Base consumptions: (pick the one that suits your situation)
Standby, phone on, WIFI+BT off, no connections active: 5mA
Processor running idle, screen off, connections as above: 55mA
100% CPU usage (Coreplayer benchmark), connections as above: 315mA
USB connected, connections as above: 125mA
Additions: (add this to the base one depending on what you have on)
Connections:
BT on, idle: +1mA
Wifi on, idle: +5mA BUT!! If you enable wifi during standby (with BsB Tweaks or the WifiNoStandby CAB), the processor does NOT go to standby
anymore, so the base needs to be the 55mA above!
Connected to EDGE, idle: not measureable
Connected to 3G, idle: +4mA
Beware those 2 will occasionally and unpredictably send data every now and then, so this doesn't necessarily mean much.
BT transfer (file copy through ActiveSync, 120kB/s, CPU usage ~2%): +80mA
Wifi transfer (file copy with Wifi Remote access, 1MB/s, CPU usage ~3%): +200mA
EDGE/3G transfer: Pretty impossible to measure due to so many variables, but can be extreme (total current consumptions of 850-1150mA, so very approximative 500-800mA draw from the data connection during page loads are common!), and leads to most of the energy draw when using the net a lot. EDGE uses more power than 3G, consumption is higher when network coverage is lower, bad network throughput or congestion also mean lots of retries/overhead and less effective data transfer, using power for a longer time until the data is finally there.
Memory access (large file transfer):
Internal read/write through ActiveSync (speeds 2.5 / 2.1 MB/s respectively): +20mA / +130mA
Card read/write through ActiveSync (speeds 3.2 / 2.7MB/s respectively): +25mA / +40mA
Card read/write in USB disk mode (speeds 7.5 / 5MB/s respectively): +40mA / +45mA
Backlight:
10%: +65mA
20%: +78mA
30%: +90mA
40%: +105mA
50%: +121mA
60%: +136mA
70%: +154mA
80%: +170mA
90%: +190mA
100%:+210mA
GPS:
+95mA
Flashlight (with HTC Flashlight):
Level 1: +32mA
Level 2 (same as camera flash on): +107mA
Level 3 (same as camera "bright flash during shot"): +530mA
And remember the battery capacity: 1230mAh
So with this you can calculate your battery life for various activities. For example:
- Playing a video with full backlight: Let's say the video is well encoded (30% CPU use, for example 720x400 1Mbps DivX), that's about 150mA base, + 210mA backlight = 360mA, resulting in about 3h20 battery life.
- Same at night with only 40% backlight: Life goes up to about 5h!
- Wifi during standby for an 8h night, or a program that somehow prevents the phone from entering standby: 60mA or 55mA respectively, draining about 40% of the battery during that time.
- GPS program, with 70% backlight: Let's assume 150mA for the processor as it has some work to do, 90mA for the GPS, 154mA for the backlight = 394mA, or 3 hours.
- Music through wired headphones, screen off: the 55mA base plus a little 5mA as MP3 decoding is nothing for the CPU = 60mA or 20h.
- Same with a BT headset, with about half the BT bandwidth: 60+40 = 100mA or 12h
etc.
Charging
[EDIT 14.04.10]
This is now a dedicated section as I did some more thorough charging tests.
So, as some of you might know, the HD2 has 2 charging "modes".
- One is USB, that is used if the phone is connected to a PC, or an unknown device. In this mode, the current the HD2 will draw from the port/charger is limited to approx. 470mA, to stay within the maximum of 500mA a USB port can supply.
- The other is "dedicated charger", which is recognised on the original HTC charger (and some others, it's becoming a standard for a "dedicated charging USB port") by shorting of the 2 data pins of the USB connector in the charger.
USB charge
Important to know, during USB charge, the phone will NOT go to sleep, as it's supposed to be connected to a PC, and be running either ActiveSync, Disk drive mode, or modem, and in all 3 cases would be expected not to shutdown. So not only the current supplied to the HD2 is low, but the phone draws some of it for itself, leaving very little for actual charge - so expect loooong charge times.
USB charge with screen on (backlight dimmed, 10%): 285mA
USB charge with screen off (standby): 345mA (which shows the processor still runs and draws the "base USB" current)
Dedicated charger
When used with a charger that has the 2 USB data pins shorted, such as the original charger, the HD2 will draw a current that is proportional to the voltage on the USB power lines. To measure this I have used the original supplied USB cable, a variable regulated power supply, USB socket (with data pins shorted), and 2 meters for voltage/current. Voltages are measured at the "PC" end of the USB cable, so not taking account of losses in the USB cable. Will talk more about this later on.
Current vs Voltage diagrams are attached. Charge current is proportional to voltage, linearly until it reaches the max charge current, approx 830mA. This was measured so that the only draw is charge. If the phone is turned on while at max charge current, it will draw extra, until it reaches about 980mA, and will then stop to respect the 1A rating of the stock charger.
Now, to the influence of USB cables. I initially had some trouble with inconsistant numbers, phone only drawing 670mA from the stock charger, i.e matching neither the ~350mA from USB, or ~830mA from stock charger in "normal" condition. Turns out that to make it more convenient on my workplace I was using an USB extension between charger and HD2 cable. It was a $2 extension I bought on Dealextreme. Removing it solved the problem... and after making those measurements I poked with it again. Turns out that at 1A current, the voltage drop in the extension (which by the way isn't longer than the HD2's USB cable) was 1.8V! Yep, nearly 2 Ohms for a 1.5m extension! Couldn't believe it.
I have a cheap Chinese microUSB cable that wasn't as bad,but still significantly more resistive than the stock one, hence me noting I used the stock cable for my tests. So, quality of the cables, extensions, adapters IS important! Note the phone correctly reaches full charge current a little bit under the 5V USB spec, so everything is well tuned.
Now, important to know, Most 3rd party chargers will not have the 2 USB data pins shorted, and will thus result in the same behavior as mentioned under USB charge, the processor will also be running continuously drawing the "base USB" current.
It is often possible to modify 3rd party chargers by opening them and shorting the pins, speeding up charge. The voltage/current curve behavior is actually helping there, because thanks to it if the charger is overloaded its voltage will most likely fall a bit, and the HD2 will thus draw less and find a nice balance point. This DOES NOT mean there's no possiblilty of damaging the charger, but all 3 I modified did well. One that was really weak resulted in not much more current being drawn after the mod than before (i.e voltage fell very low, approx. 4.4V), however the gain from not having the processor running like in USB mode still sped up charge a little.
Thank you, that is one useful chunk of comprehensive information
Could you please explain the exact measuring method for these tests?
40% backlight at night is a tough example tho, Lumos on my device is set to 10% for 0 sensor value, and only because I can't set it to lower than 10%... nice to know battery drain goes up twice from 10% to 60%!
Also, 100% is usually really necessary under direct sunlight, in a normal lit room probably 40% backlight is more than enough to watch a video... all in all, with your superinteresting info, the battery doesn't look like lasting "too short" now, but more or less "the right amount considering the battery capacity".
My iPaq 210 has a 2200mAh battery, just to make a comparison... that's why I could go for 8 hrs during some bus trips while watching tv series, and I just needed to swap battery and used a little of the second one.
What's your estimate of the drain caused by activating push email? I've recently been doing some rather crude experiments myself, and one provisional conclusion is that push email on a hotmail account uses a lot more battery than push email on an Exchange server.
Excellent stuff, you are to be congratulated.
I have a long held theory and I wonder if you are in a position to to test it?
I believe that battery consumption is greatly increased when an app is run from mem card and would be intrigued to see a comparison between an install to this as opposed to phone mem.
Any chance?
Battery levels
I found that power consumption of the battery got even worse after I went to Rom 1.66.707.1. However, after a few days, I let it run all the way out, switched back on, it ran out after a few minutes. Then after an overnight charge I found the battery (on standby) only went down by about 10 -12 % in 24hrs. I'm hoping this performance will continue.
What did you use for the testing?
pa49 said:
Excellent stuff, you are to be congratulated.
I have a long held theory and I wonder if you are in a position to to test it?
I believe that battery consumption is greatly increased when an app is run from mem card and would be intrigued to see a comparison between an install to this as opposed to phone mem.
Any chance?
Click to expand...
Click to collapse
That would be reasonable as reading from an external media will need energy to access its contents... still, once the app files have been loaded into the device's RAM, it shouldn't matter much
You could also test by comparing:
1) copy say 30mb from one location to another of the internal mem
2) copy from microsd to microsd
3) copy from mem to microsd
4) copy from microsd to mem
ephestione said:
Could you please explain the exact measuring method for these tests?
Click to expand...
Click to collapse
Simply using the built-in current sensor, getting the reads from AEBPlus battery information screen, and methodically turning things on/off once the others are evaluated and can be subtracted from the total reading.
ephestione said:
40% backlight at night is a tough example tho, Lumos on my device is set to 10% for 0 sensor value, and only because I can't set it to lower than 10%...
Click to expand...
Click to collapse
Really? You should force the backlight off then
I love bright images myself, so even in my bed in total darkness if I watch a video or photos I'll force 100% backlight I have Lumos set to force 100% for Coreplayer, Resco Photo manager and HTC album
Of course not for browsing or just messing around, in that case it's 20% for me
Shasarak said:
What's your estimate of the drain caused by activating push email? I've recently been doing some rather crude experiments myself, and one provisional conclusion is that push email on a hotmail account uses a lot more battery than push email on an Exchange server.
Click to expand...
Click to collapse
That's one thing I'd have no idea about... I've never used push email at all. And that's "standby usage", so hard to evaluate, as you never know when it kicks in.
Measuring that would need to be done on a long time. I'd say to leave your phone one night with push email off, one night with Exchange only, and one night with hotmail only, and then check the difference, preferably with a battery at about 80% charge at the start (mine seems to fall from 100% to 90% in a few minutes before becoming more regular, so I'd say the top of the scale isn't that reliable).
And I should really try push email once, that would be nice, but I *think* I have no provider that can do it for me... well I have a gmail account I never use, I should try to see if I can have it check my usual 3 mail accounts, aggregate and push... never really looked into that stuff.
pa49 said:
Excellent stuff, you are to be congratulated.
I have a long held theory and I wonder if you are in a position to to test it?
I believe that battery consumption is greatly increased when an app is run from mem card and would be intrigued to see a comparison between an install to this as opposed to phone mem.
Any chance?
Click to expand...
Click to collapse
Thanks
Well I'd tend to refute that theory, because when I tested the BT and Wifi in use I tried read from internal memory, write to internal, read from card and write to card, and all 4 were identical. I should have mentioned it indeed, but I was mostly interested to seeing if reads (wifi/BT "sending") and writes (wifi/BT "receiving") would have an influence on consumption, which wasn't the case, as well as whether the throughput was different, which wasn't the case either.
But I've done a few more tests, see the updated first post
One intersting thing is firstly that when the HD2 is connected to USB, the current draw grows significantly, so I've made a new "base consumption".
Next, the card is actually faster than the internal memory both in reads and in writes, tested both through activesync for consistency. Writing to the internal memory eats a LOT more than writing to the card. Reading from the card eats a little more than reading from internal memory, probably evens out as the reads are shorter due to faster transfer rate.
I've added some charging tests as well. Apparently, even if the phone "disconnects" from USB when turned off, the processor still runs and uses about the "USB connected" base current.
kilrah said:
Simply using the built-in current sensor, getting the reads from AEBPlus battery information screen, and methodically turning things on/off once the others are evaluated and can be subtracted from the total reading.
Click to expand...
Click to collapse
d'oh aebplus has a battery information screen, checking it right away In that case you'd have to take into consideration aebplus' current absorption anyway... which is not measurable as you cannot check the current intake of aebplus without aebplus being running
I have the cab on the sd already, but didn't install if after noticing that didn't work for button assignments with later versions of the rom... does it work for you on that side? I used the program all the time on my previous ipaq because it was oh so useful but never got around to notice it had a battery info subsection.
Really? You should force the backlight off then
Click to expand...
Click to collapse
Wouldn't have much sense doing it in the dark would it (admitting it's possible altogether on the HD2!)
But I actually used my oooold casio cassiopeia, about 7 years ago, with backlight turned off, while reading ebooks with speed reader plus during train trips, as the neon lights created a reflection good enough on the display so that I didn't need backlight...
in the end, the backlight died altogether and until I bought a new device, I managed to use it with light turned off
A flashing LED (incoming SMS warning, e.g.) seems to add consumption of 1-3mA.
Running FlexMail in background with a push service (IMAP IDLE) adds up to 30mA.
ephestione said:
does it work for you on that side?
Click to expand...
Click to collapse
AEBPlus works fine for me yes... but I don't have a "latest version" ROM AFAIK. I don't like WM6.5.x new softkey arrangement, so I'm staying with 6.5.
Anyway more about Push, I configured that through gmail yesterday, and it works just fine. I left it on during the night, and this morning I had lost 8% battery. So it's pretty much negligible. I received 2 e-mails during the night and was on 3G network.
this is a nice topic! i am interested in how much extra it uses when you are playing a MP3 with the build in HTC app?
maybe it would be a nice idea to make a program that outputs results like you pasted fast and easy (something like a benchmark app) so we can test different rom's fast? too bad i cant write anything otherwise i would try..
OK, seems MP3 uses 120mA screen off, both with Sense player and Coreplayer, so:
Processor running idle, screen off base + 65mA
But it seems to make some pretty big "jumps" once in a while. Maybe they both decode ior fetch from memory by "batches"...
my test,
HD2 rom 1.66
with BT on and BT off (configured but no connection to headset) difference in consumption is 60mA .!
BT is draining my HD2 .!
kilrah said:
OK, seems MP3 uses 120mA screen off, both with Sense player and Coreplayer, so:
Processor running idle, screen off base + 65mA
But it seems to make some pretty big "jumps" once in a while. Maybe they both decode ior fetch from memory by "batches"...
Click to expand...
Click to collapse
OK, I can't confirm the BT issue. Did you observe over a long period of time? The "quiet" current for MP3 I seem to get is 185mA with screen on and backlight at 10%, but sometimes it will climb to 280-320mA for a moment and go down again, both with BT on and off. With screen off for a while it seems to stabilise at the "quiet" level.
BTW, it seems that Advanced task manager isn't reporting CPU usage levels properly. Does someone know of a CPU monitor that works correclty on the HD2?
Yup. review over multiple 6 mins. all baseline(3g/brightness) setting the same. resetting each time for off on BT.
kilrah said:
OK, I can't confirm the BT issue. Did you observe over a long period of time? The "quiet" current for MP3 I seem to get is 185mA with screen on and backlight at 10%, but sometimes it will climb to 280-320mA for a moment and go down again, both with BT on and off. With screen off for a while it seems to stabilise at the "quiet" level.
BTW, it seems that Advanced task manager isn't reporting CPU usage levels properly. Does someone know of a CPU monitor that works correclty on the HD2?
Click to expand...
Click to collapse
Another consideration:
Data connection sucks power when used actively. Badly. As mentioned in the OP I haven't made comprehensive tests due to low monthly allowance, but I've had a look during normal use.
I'm pretty regularly doing 1hr train rides, during which I will be listnening to music , and browse the net at the same time. It's usually bright, so backlight will probably be at 70%. Signal is relatively low most of the time, on EDGE, inbetween small towns. When I'm on a "static" page (reading an already loaded page), current drain varies between 250 and 350mA.
But while loading a page, it will easily soar to 800mA+. Considering it takes 30-60 seconds to read a page, 20 to load a new one, and repeat... you can quickly see that this kind of usage leads to serious drain... in less than 2 hours the battery would be dead.
So be aware of how much power data connection will use. It's directly proportional to the amount of transferred data, and the worse the reception the more power it uses.
I should try using opera mini again, like I was always doing on my Kaiser. I never noticed excessive drain with it, but opera mini easily divides traffic by a factor of 10...
Just wanted to report that the new version of the superuseful BattClock has now a builtin battery current output, even if it's not really update once per second... seems more like one every 10 seconds.
I get ~240mA playing fullscreen stretched Frasier in lowest backlight (but that's with the keypad leds turned on all the time, I don't know why they don't go off, and I don't have keypadledcontrol installed... so that's a problem), and I get a total 630mA with HTC flashlight at maximum.
Good news! Bye bye Batti
Normal about the refresh time, the sensor only updates every 20 secs or so.
Some new considerations I posted somewhere else but should have put here.
After some time the HD2 seems to have better battery life, but usually it's not your battery lasting longer, it's just you not spending your day playing with the thing anymore.
It's always the same thing, the more a device can do, the more you do with it. On my first 1h train journeys after getting my HD2, I was able to kill 50% battery in 1hr. My first thought was "wow, with my Kaiser I would only use like 15%!!"
But then I took a second thought. I used 50%, but I was browsing the web, in bad reception areas, while listening to music the whole time. With my Kaiser, I'd put music on, check 3 webpages, then put it on the tray with just MSN connected and just pick it up to read/type a message once in a while.
On a next trip, I "forced myself" to do the same with the HD2. Just checked the news for 5 mins, then only listened to music and picked up msn once in a while, plus an unexpected 10min phone call. Guess what? I've only used 20% battery during the trip this time
The "problem" is that browsing with the Kaiser was just painful, so I'd just check the news and put it away. On the HD2 it's so comfortable I forget it and just spend my whole trip browsing heavy pages, which obviously kills battery in no time...
exactly my thoughts and findings
1. Abstract
2. Approach
3. Baseline configuration and results
4. References
5. Disclaimer
1. Abstract
Initially I was quite dissapointed with the battery life of the Samsung Galaxy S II i9100 with Android 2.3.4 out of the box. Coming from the Symbian world Nokia E71 I have been used to 6-7 days without recharging, while on SGS2 I got barely 1.5 days of normal usage. I started to optimize, and felt that the hardware is very capable for power saving, but the software is not optimized. After turning off all synchronization, going thru every program settings to switch to manual sync, switching to 2G network (EDGE in my area), turning off WiFi/Data/GPS/Background data I've got a busy day full of meetings at work (didn't touch the phone apart from 2 incoming calls and a few notes) and only 10% decrease of battery for 24h (100%->90%) which is amazing by itself. But I wanted to optimize more.
I have heard that other things like Custom ROM, freezing of system applications, task killers, Under Volting (UV), Under Clocking (UV) would help me too, but I was about to discover which one really helps in real use.
One lazy Sunday like today while being a bit sick allowed me to conclude an experiment of how far did I get in optimizing the power usage for a "baseline configuration" - WiFi/Data/GPS/Background data off, 2G network, all possible sync to manual - and the results are astonishing.
2. Approach
The approach to optimize the battery life is only one - PUT IT TO SLEEP AND DON'T LET IT AWAKE.
Having read a ton of articles on xda-developers.com and other places I have concluded that the strategy for optimizing includes these major steps:
2.1. Get a clean baseline Custom ROM where much of the "bloatware" is removed, so you have less to optimize - optional step but it helps to do it
This probably helps although not necessary. I'm not sure if the stock ROM will allow you to put custom kernels which will be needed in the next steps to optimize further.
But in any case you need to be at least "rooted" to apply some of the advice - either via a rooted kernel like CF-Root [8], or via an exploit like the DooMLoRD'a zergRush exploit [7].
2.2. Optimize the screen-on time
This is up to how frequently you use the phone
What you can optimize is to set a default "conservative" CPU Governor profile from 200MHZ to 1200MHz for regular usage - nothing really special, it's only slower on jumping to high frequencies.
If you have a kernel like RedPill Kernel [9] you can add an additional In-Call profile with "conservative" CPU Governor from 100MHZ to 800MHz - while you talk and phone to the ear it idles at 100MHz, but if you start a let's say Notes taking application, or go to turn on Bluetooth it will be snappy enough. Same holds true for listening to music or listening to books - but it's up to your imagination how to set a 100MHz profile in this case (maybe via Tasker). Have in mind that the 100MHz setting may be unstable on some phones because it's not standard, but mine is absolutely fine with that setting.
For setting the CPU profiles software like Voltage Control [5] (paid version for many profiles) is used.
CPU Governor "conservative" is crucial so you don't instantly jump to the highest frequency as it happens with the default "ondemand" governor (or its clones).
You can choose an I/O Scheduler appropriate for your CPU Governor based on the MagicConfig article in my references [14].
People also say that the following helps and I use it: turn off button LED lights, darker wallpapers, auto-rotation disabled, auto brightness on (I have to see the screen after all).
If you use kernel like RedPill Kernel [9] the button LED lights are undervolted by default, so you can leave them "on for 1.5s" for example.
If you have a Custom ROM like CheckROM Revolution HD V6 [10] with JKay Deluxe Settings you can set a Dark or Darker auto brightness profile - also usable to some extent.
One article in my references [12] also gives the power drain in milliwatts (mW) for each hardware device - go read it and you will understand how much the Amoled Display (Average - 370mW), LED lamp next to camera (1.3W), Camera (700mW), Bluetooth and GPS (110 to 180mW) etc. hardware actually consumes.
2.3. Optimize the screen-off time
2.3.1. Analyze Wakelocks
Wakelocks indicate when some application prevents the phone from going to sleep for some time. It does not necessarily mean that it does something significant at that time, and may be only a bad application design. Some applications really like to hold wakelocks periodically during the day for no reason, even if set to Manual sync etc. Examples of such applications are Facebook, 3G Watchdog... You milleage may vary but you can be sure that this hurts your battery life a lot. Any such application can be frozen with Titanium Backup or uninstalled if it's not a system application. Both count and total duration of the wakelocks are important.
BetterBatteryStats [1] has a screen to debug Partial Wakelocks and Kernel Wakelocks. You can also obtain the raw information via the console command "cat /proc/wakelocks".
2.3.2. Analyze Alarms
Alarms are a way to start jobs in the system at a predefined time. Many applications set alarms to get awaken and check/poll something before sleeping again. You should note that firing an Alarm is not necessarily connected to having a Wakelock - you can see many alarms firing but very few wakelocks. The problem is that too many applications set too many alarms for no reason. These activities also hurt your battery life a lot. Examples of such applications are Google Maps (at least for me)... As long as I have another GPS application with offline maps, I've simply frozen Maps with Titanium Backup. Another example was let's say Social Hub, but as long it was firing once per 24h, I didn't bother to touch it.
BetterBatteryStats [1] has a screen to debug Alarms which requires Root access. You can also obtain the raw information via the console command "dumpsys alarm".
2.3.3. Analyze Network Connections
If you get lost in the Wakelocks and Alarms, you can help yourself by checking what connections are kept alive while Internet is connected. OS Monitor [3] has a Connections screen which is equivalent to "netstat". This is also a good indicator what may be drawing unnecessary battery and respectively freeze/uninstall. In my case I can point that I've discovered that K-9 Mail had a bug with IMAP accounts - if I connect to an IMAP account set to manual/poll sync once, it keeps a connection open forever, until you restart or kill the process, but for POP3 account there is no problem... Being aware of such things really help with the battery life.
2.4. Optimize deep idle and sleep time
This is the most important goal in this article - how to get into deep idle/sleep and stay there, because this is the only real way to save energy on such a powerful device
CPU Spy [2] can show you how much time you spend in deep idle/sleep - with my baseline testing I've managed to get 99% deep idle/sleep which is amazing - only if the manufacturers gave us the phones in this state and we can build on that...! But it's the other way round.
Unfortunately the sleep mode on the stock kernel and the CF-Root kernel is not too deep. Entropy512 in my references [15] describes the following modes of idle/sleep:
IDLE - clock is gated but power remains (does not eliminate any static power consumption)
AFTR - clock is gated, CPU core power removed, cache power remains - this eliminates a great deal of static power consumption - cannot be entered if second core is active
LPA - AFTR + removal of cache power - cannot be entered if second core is active
IDLE is entered if the CPU is expected to be free for 4 msec (40 msec stock)
AFTR is entered if the CPU is expected to be free for 10 msec (disabled stock)
LPA is entered if the CPU is expected to be free for 40 msec (40 msec stock)
This compares to suspend, aka deep sleep, which takes around 150 msec to enter and 650 msec to resume, and the CPU must be at 800 MHz (or at least have enough voltage to support 800 MHz operation) during this time. Entering suspend/resume is very costly in terms of power due to heavy interrupt load.
Unfortunately my knowledge ends here, but flashing a kernel like RedPill [9] with Power Saving features and patches enabled improved the deepness of the idle/sleep very significantly, let's say 2 fold compared to the stock kernel. Sleep is entered faster and with more savings.
2.5. Optimize the modem/baseband
If all the points above are done, you can consider some savings from trying to flash newer modem/baseband compatible with your Custom ROM for better power savings during Calls and Data transmission. I did not get deep into this yet, but it's rather a big Voodoo, because the contents of the various modems are not public and you can only read feedback like "works very good for me" and "totally awful", which is not very scientific. Initially you can try staying with your original modem or the one provided by the Custom ROM, and optimize the previous points.
2.6. Optimize other stuff
2.6.1. Under Volting - will probably help, but for every frequency you need to choose voltages that are not too low to keep the phone stable. You can try the UV profile from the MagicConfig article from my references [14].
2.6.2. Under Clocking - I consider trying to use 100MHz useful for some scenarios, but only as an additional profile. After all the phone is very powerful and snappy to cripple it with 100MHz-1000MHz profile as default.
2.6.3. Automatic Task Killers - absolutely worthless peaces of software [16]. Android OS is good at power saving. It is very power saving conscious actually, of course combined with capable to sleep hardware. The only reason to kill a process is if it locked on holding some resource/connection forever, and OS Monitor [3] can kill it.
2.6.4. Battery charging - charge the battery as frequently as you want, but be sure to not keep it constantly on high charge (90-100%) [18], as long as this is not a good state for storage. Making bigger cycles helps to maintain better battery life. Some sources say cycling from 0% to 100% is not optimal [17], but from my experience through the years this way also works good for battery longevity, and maintaining small loss of capacity. I can give an example of losing up to 10% of battery capacity per year compared to design capacity with this method. You can view such statistics in Power Management tools in Lenovo ThinkPads etc.
Note that the battery indicator has some tweaks around 100% so consider the following:
- When charging for me it hops from 98% straight to 100%. If you disconnect now, it drops to 98% again, and this is what other people complain from too. Just wait some more time and it will charge to real 100% to have more battery life.
- The indicator stays at 100% longer than at any other value. So when testing, always test from the same baseline, e.g. always charge to 100% before comparing results.
3. Baseline configuration and results
CheckROM Revolution HD V6 PDA XWLA4 (Android 2.3.6) + modem XXKI4 (was XWKL1 but changed for no reason) + kernel RedPill 1.3.
WiFi/Data/GPS/Background data/Auto-rotation/Button LED lights - OFF
Any type of Sync or Polling - OFF/MANUAL, using local Contacts and local Calendar
Widgets - AccuWeather.com on MANUAL and Today view from Calendar.
Network: 2G (EDGE in my area)
Background and lock screen: Dark wallpapers
CPU default profile: conservative 200MHz-1200MHz
CPU in-call profile: conservative 100MHz-800Mhz
Because I don't want to wait a full day for the statistics, I'll post now for 8 and 12 hours, and tomorrow add for 24 hours.
(See the attached images, because I'm not sure how to embed them in the text)
4. References
[1] BetterBatteryStats XDA Edition - http://forum.xda-developers.com/showthread.php?t=1179809
[2] CPU Spy - https://market.android.com/details?id=com.bvalosek.cpuspy
[3] OS Monitor - https://market.android.com/details?id=com.eolwral.osmonitor
[4] Titanium Backup (paid version) - http://matrixrewriter.com/android/
[5] Voltage Control - https://market.android.com/details?id=com.darekxan.voltagecontrol
[6] Android Terminal Emulator by Jack Palevich - https://market.android.com/details?id=jackpal.androidterm
[7] DooMLoRD's Easy Rooting Toolkit [v4.0](zergRush Exploit) - http://forum.xda-developers.com/showthread.php?t=1321582
[8] CF-Root Kernel - http://forum.xda-developers.com/showthread.php?t=788108
[9] RedPillKernel_Rev1.3 - http://forum.xda-developers.com/showthread.php?t=1288850
[10] CheckROM Revolution HD V6 - http://forum.xda-developers.com/showthread.php?t=1312240, http://checkrom.com/
[11] Premium Dark Wallpapers - http://forum.xda-developers.com/showthread.php?t=1474798
[12] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks - http://forum.xda-developers.com/showthread.php?t=1369817
[13] Getting the Most out of the Battery on your Android device - http://softbanksucks.blogspot.com/2011/10/getting-most-out-of-your-battery-on.html
[14] MagicConfig for UV and CPU Governor + I/O Scheduler combinations - http://forum.xda-developers.com/showthread.php?t=1466017
[15] Entropy512 explained CPU idle states - http://forum.xda-developers.com/showpost.php?p=23252902&postcount=17
[16] Android Task Killers Explained - http://lifehacker.com/5650894/andro...ed-what-they-do-and-why-you-shouldnt-use-them
[17] Li-Ion Battery Charge Cycles, Voltages and Storage analysis - http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries
[18] IBM/Lenovo recommendations on Li-Ion battery treatment - http://forum.xda-developers.com/showpost.php?p=23258191&postcount=19
5. Disclaimer
Paid apps are mentioned here for clarity. You can of course find an alternative if such exists. Free (no ads) versions of software were listed where possible.
Needless to say that all advice here must be applied only under your own responsibility.
Results at 25h usage: The battery indicator has dropped down to 94%.
However it's a bit hard to predict how much is it going to last this way as long as after initially staying at the value "100%" the indicator decreases a bit faster.
See attached screenshots.
Thanks for the detailed post but i still don't understand why people insist on having a smart phone and then turning off any good feature in it to get 2 days of work out of it.
Agent_Adodas said:
Thanks for the detailed post but i still don't understand why people insist on having a smart phone and then turning off any good feature in it to get 2 days of work out of it.
Click to expand...
Click to collapse
That depends if you dont want xxxx app running every day why run it and why let it connect on a daily basis . Its a Smartphone not a dumbphone that controls the user .Nothing in the Smartphone design says hey guy you are really uncool if you don't have everything turned on .
I turn on what i want when i want but then again i am not sad enough to live my life on facebook .
jje
there's nothing wrong with killing background tasks that eats your battery, but to me it looks funny to turn off WIFI, 3G, Sync or polling.
anyway, that's what i think, other people may think different and will prefer to save on battery life.
Agent_Adodas said:
there's nothing wrong with killing background tasks that eats your battery
Click to expand...
Click to collapse
:facepalm:
http://lifehacker.com/5650894/andro...ed-what-they-do-and-why-you-shouldnt-use-them
Unless you love using terribly coded apps.
This is a Baseline - my initial starting position. Yeah I don't feel cool for running tons of unneeded stuff Actually after 15 hours of uptime I feel pretty bad and a slave of the charger.
I hope to tell more people in a single post what can be optimized, stripping off any superstition, voodoo and some pointless beliefs circulating in the web
I don't say "do like me", but instead what a great hardware SGS2 + core Android software actually seems to be
Please also note I didn't limit myself to 1000MHz, do not recommend reducing voltages etc... the struggle is to put the software in control, not to cripple the experience.
Additionally, I have WiFi at work, at home, at the gym, and between them I'm driving... for that reason I don't need unlimited data. And for new mails I actually get SMS and know when to fetch the mail. If it's important I can turn on the data as well. On business trips abroad there is no unlimited data anyway too - only WiFi at the office and at the hotel. So there are different scenarios...
Serious Observations Bro!
Must say, very clear,simple and awesome way to put together things...will try this out and post again!
Thanks a ton bro! Love the efforts and for helping us out!
Great tips mate... I knew many of them before but i will not use them so much.. I have a feeling that it criples my phone... Limiting my usage of the phone... Instead i have a custom rom,custom kernel ,an extra standard battery,car charger...
I even tryed once to apply most of your tips but they gave me a couple of hours extra batt life. My problem is network signal coverage-edge is fine(but who can surf on egde ?!? ) ,3g and hspda signal is not so good (i travel a lot by car all over my country) and the phone keeps trying to get better network signal and uses more battery...
So most of your tips work if u want to criple your phone and if ur network has great coverage...
Sent from my GT-I9100 using XDA
Using a slow scaling cpu governor defeats the purpose of battery savings. You want something that will scale up fast and scale down just as fast. That way the task gets completed quicker and the cpu can go back to an idle state faster.
Slower governors take longer to complete a task and that uses more battery.
I rather OnDemand complete something in 2 seconds jumping immediately to 1.2Ghz than Conservative in 4 seconds scaling it's way up each step and then scaling back down slowly.
Sent from my GT-I9100 using Tapatalk
Elisha said:
Using a slow scaling cpu governor defeats the purpose of battery savings. You want something that will scale up fast and scale down just as fast. That way the task gets completed quicker and the cpu can go back to an idle state faster.
Slower governors take longer to complete a task and that uses more battery.
I rather OnDemand complete something in 2 seconds jumping immediately to 1.2Ghz than Conservative in 4 seconds scaling it's way up each step and then scaling back down slowly.
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
Not true if I'm typing notes. Ondemand will struggle to take me on high frequency, while I'm browsing the texts... Do you need high frequency when reading forums?
Actually I have no problem to play Asphalt 6 and Angry Birds on 1200MHz with this setup
It takes you more cpu cycles to get Asphalt or Angry Birds fully loaded with Conservative than it would with OnDemand.
And you have to remember we have dual-core cpus. It's to your benefit to get both cores scaled up faster to finish the task.
You don't notice this as much because the difference is probably in the milliseconds. But Conservative is more of a power hog than OnDemand.
Sent from my GT-I9100 using Tapatalk
Wow, thats massive and informative! Too good job Sir! Hats Off!
Elisha said:
It takes you more cpu cycles to get Asphalt or Angry Birds fully loaded with Conservative than it would with OnDemand.
And you have to remember we have dual-core cpus. It's to your benefit to get both cores scaled up faster to finish the task.
You don't notice this as much because the difference is probably in the milliseconds. But Conservative is more of a power hog than OnDemand.
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
Agree. All that advice is mostly targeted to battery conscious people, this is not a gaming setup There is no one best configuration for all.
It's also not about what exact values to choose, but what approach to take for battery life improvement.
Can't wait to run a UV kernel once the sources drop. That there helps quite a bit to conserve battery.
Sent from my GT-I9100 using Tapatalk
I know pretty much all of this already but it's a useful guide for noobs for sure.
I don't bother anymore with SetCPU or any of that anymore and to be honest it's had little or no impact on battery life which is still excellent.
gingingingin said:
0: IDLE - CPU not clocked
1: AFTR - something not totally clear to me, but an alternative way to IDLE the CPU - ARM Off Top Running with L2 cache keeping its state
2: IDLE+LPA - IDLE + DEEP IDLE - also some parts of hardware are powered down
3: AFTR+LPA - AFTR + DEEP IDLE
Click to expand...
Click to collapse
These are not deep sleep states. Deep sleep is also known as "suspend" - where almost the entire system is shut down.
These are CPU idle states, which allow the core to save power even when the system is "running". They take significantly less time and energy to enter, but save less power. Also, there are only three of them - IDLE, LPA, AFTR. See arch/arm/mach-s5pv310/cpuidle.c in the kernel source for more details.
As an example, with kernels that have the cpuidle backport from the Tab 7 Plus:
IDLE is entered if the CPU is expected to be free for 4 msec (40 msec stock)
AFTR is entered if the CPU is expected to be free for 10 msec (disabled stock)
LPA is entered if the CPU is expected to be free for 40 msec (40 msec stock)
There are some rules that can cause lower states to be entered even if the cpuidle governor chooses LPA or AFTR. (cpuidle governor has nothing to do with cpufreq governor).
Your descriptions of the states are pretty close to what I understand them to be:
IDLE - clock is gated but power remains (does not eliminate any static power consumption)
AFTR - clock is gated, CPU core power removed, cache power remains - this eliminates a great deal of static power consumption - cannot be entered if second core is active
LPA - AFTR + removal of cache power - cannot be entered if second core is active
The above are why 100 MHz is pointless on our device, and in my experience, actually can increase power usage. The achievable voltage difference between 100 MHz and 200 MHz is insignificant for most peope, and if the voltages for two frequencies are the same, it's better to run at the higher frequency and drop into AFTR/LPA to shut off core power more often. The PDF linked from Ezekeel's post at http://forum.xda-developers.com/showthread.php?p=21785924#post21785924 is a useful read on this topic, especially section 6. While it's fairly old, most of the concepts remain valid. For this reason, 500 MHz also doesn't consume much more power than 200 for a given fixed amount of load due to having the same voltage stock as 200 (however, it does increase some internal clocks I believe, leading to slightly increased power) - so when the screen is on I have it set to 500 MHz minimum.
This compares to suspend, aka deep sleep, which takes around 150 msec to enter and 650 msec to resume, and the CPU must be at 800 MHz (or at least have enough voltage to support 800 MHz operation) during this time. Entering suspend/resume is very costly in terms of power due to heavy interrupt load, which is involved in 90% of complaints about high "Android OS" battery usage on Gingerbread. However I believe from some of the testing I've run that improved cpuidle greatly reduces this penalty.
With the improved cpuidle patch, even when I use the Wake Lock app to hold a permanent wakelock for testing purposes, my standby drain is only 1.5%/hour or so. When not holding a wakelock, 0.5%/hour on wifi is easily achievable. It gets much worse at my desk at work, where the signal is weak and the cell radio eats huge amounts of power - there it's around 1%/hour.
Edit: As to task killers - all of the people saying "task killers are worthless" talk about memory management only. The fact is, unfortunately, that there are some crappy apps out there that use too much CPU or hold insanely long wakelocks that you just have to use occasionally. Facebook is still the #1 example here - Facebook is a major battery hog, therefore when you're done with it, you must kill it with fire. However, NEVER use an autokiller and never use it for memory management!
Regarding battery charging, I wonder have you read this article before : batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries (please add http)
The fact seems to be completely opposite from your theory in 2.6.4.
Sent from my GT-I9100 using xda premium
Not sure, the battery article is a bit doubtful. For me at least the testing sequence is strange:
1. Charging current of 1C is a bit high, to say the least. Quick chargers have never been optimal for any type of batteries.
2. Discharge current of 1C is huge and far from being realistic for a mobile phone.
Also if we interpret the results it becomes that at 10% DoD we get 4700 small cycles, which is close to 100% DoD with 500 big cycles... Actually the results are in favor of the 100% DoD.
Of course my interpretation can be wrong, but so far I have got the opposite idea of that.
For practical purposes I can give an example of a Nokia Li-Ion battery thoroughly fully discharged and for 2 years it retained at least 80% capacity. I'd estimate the number of cycles to be 120-150.
On my current laptop the ThinkPad Panasonic battery was always almost completely discharged via settings, attaching screenshots. At 328 cycles and 3.5 years since first use it retains 88% of the design capacity. This is quite a good achievement for a tortured battery I'd say
Note: See the advice/sentence written in the top box by my good old IBM manufacturer (now Lenovo). "... battery deterioration may occur faster if the battery is constantly charged at 100%. Lowering the charge thresholds ... will help increase its lifespan". These guys know their job... I think their sentence almost surely relates to storage though. Storage at 50% is much better than storage at 100% charge. There is room for interpretation again.
Note: This is my second battery on this laptop, the first one Sanyo was a bit worse with the same treatment (maybe older technology) and after 2 years its electronics suddenly failed, while at around 150 cycles.
Entropy512 said:
The above are why 100 MHz is pointless on our device, and in my experience, actually can increase power usage. The achievable voltage difference between 100 MHz and 200 MHz is insignificant for most peope, and if the voltages for two frequencies are the same, it's better to run at the higher frequency and drop into AFTR/LPA to shut off core power more often.
Click to expand...
Click to collapse
First of all, thanks for the detailed explanation of the states.
I remember from the school/uni that the power used is proportional to the frequency. If we have static consumption in the chip it will not be affected by changing the frequency, but the dynamic part of the consumption is essentially doubled when running on 200MHz compared to 100MHz. I don't know the ratio dynamic_consumption:static_consumption for my chip, but it may be around 1:1.
The formulas were something like that: http://forums.anandtech.com/showthread.php?t=119229