I have had my tablet off the charger now for 1 day 14 hours and I have 61% battery left. I have used it periodically to read the paper and check email over the course of the least two days.
My settings include auto brightness, screen sleep after 10 minutes and wifi always on. I let the tab go to sleep on its own.. I do not force it with the power button. I revive it with the volume control.
I am running for months now tnt 4.1.0
I am not sure why there are complaints about a true "standby" or sleep state as I can not expect any better always on battery life than this.
insight3fl said:
I have had my tablet off the charger now for 1 day 14 hours and I have 61% battery left. I have used it periodically to read the paper and check email over the course of the least two days.
My settings include auto brightness, screen sleep after 10 minutes and wifi always on. I let the tab go to sleep on its own.. I do not force it with the power button. I revive it with the volume control.
I am running for months now tnt 4.1.0
I am not sure why there are complaints about a true "standby" or sleep state as I can not expect any better always on battery life than this.
Click to expand...
Click to collapse
There are two levels of sleep. Screen off but CPU on and wifi on will run about 3% per hour. If you run the stock rom and let it go into deep sleep it will halt the CPU and shut down wifi after 2 minuets or so, and in that state it should burn about 1% per hour. It wont do alarms or reminders or check emails when in deep sleep.
So you can go about 33 hours without deep sleep. Or pretty much one day of use with alarms/alerts/push email. Or 3 days and off and on use with deep sleep. I prefer the one without deep sleep. I just charge it every night. I agree though, in with case it seems fine to me.
There are so many threads on this issue... it'd be good for the mods to combine them or lock/link to one master? Much like the 96% issue... both need dev attention and less General threads!
I have raised a bug with CM7 on the idle power problem. Idle power usage is huge compared to other devices. Hopefully this can be fixed...
http://code.google.com/p/cyanogenmod/issues/detail?id=3714
galapogos01 said:
There are so many threads on this issue... it'd be good for the mods to combine them or lock/link to one master? Much like the 96% issue... both need dev attention and less General threads!
I have raised a bug with CM7 on the idle power problem. Idle power usage is huge compared to other devices. Hopefully this can be fixed...
http://code.google.com/p/cyanogenmod/issues/detail?id=3714
Click to expand...
Click to collapse
"Currentwidget shows >300ma power usage at idle" from your report... do you happen to have the OC pegged high in SetCPU? Because wifi on, bt off, idle/screen on should be in the low 200s (214mhz clock scale) and wifi on, bt off, idle/screen off should come in at 100-120.
This isn't a "dev" issue - it's a hardware design issue. The gtab isn't designed for long standby, no amount of dev attention will fix that. 100ma seems to be the floor (with wifi on.)
schettj said:
"Currentwidget shows >300ma power usage at idle" from your report... do you happen to have the OC pegged high in SetCPU? Because wifi on, bt off, idle/screen on should be in the low 200s (214mhz clock scale) and wifi on, bt off, idle/screen off should come in at 100-120.
This isn't a "dev" issue - it's a hardware design issue. The gtab isn't designed for long standby, no amount of dev attention will fix that. 100ma seems to be the floor (with wifi on.)
Click to expand...
Click to collapse
I agree, I can go about 30 hours before I have to charge it again. I do let it sleep but keep the wifi active as it has issues otherwise. It is a hardware limitation on the device not a dev issue.
schettj said:
"Currentwidget shows >300ma power usage at idle" from your report... do you happen to have the OC pegged high in SetCPU? Because wifi on, bt off, idle/screen on should be in the low 200s (214mhz clock scale) and wifi on, bt off, idle/screen off should come in at 100-120.
This isn't a "dev" issue - it's a hardware design issue. The gtab isn't designed for long standby, no amount of dev attention will fix that. 100ma seems to be the floor (with wifi on.)
Click to expand...
Click to collapse
This was with wifi on, bt off, screen on auto brightness, cpu pegged to 214mhz with screen off, pershoot kernel.
I disagree that it's not a developer issue. Based on my experience with Android on the HD2, a lot of the battery usage issues eventually came down to kernel optimisation -- incorrect GPIOs causing devices/sensors to remain on when the kernel thought they were off, high bt idle drain, incorrect voltages against cpu speeds in the scaling tables, backlight driver loops, etc. I do not think this is related to the device itself.
I can get ~48 hours standby, but this thing should be measuring standby in weeks, not days. My HD2 can get >2 days standby, probably 4 or 5 in airplane mode. It draws 3ma!
Cheers,
Jason
galapogos01 said:
It draws 3ma!
Click to expand...
Click to collapse
Right - that would be a firmware deep sleep, where the firmware halts the cpu, and powers down hardware.
Note that when cpu halt ends the control of the OS right there.
The gtab's "deep sleep" isn't a whole lot better than "screen off, cpu lowest speed." No amount of kernel work is going to fix that.
Running VEGAN Ginger Edition, I get a full 8 hour work days use at the cost of about 20% battery life, probably about 6 hours of that is idling, the other two are browsing the web / goofing off playing Meteors or something.
Following many SGS2 battery drain threads, I've come to this conclusion that it is due to the rare combo of SGS2 with certain routers. This might be what the AOS bug is all about.
With newer kernels we are no longer able to see this drain easily on BetterBatteruStats. Instead, I've used SystemTunerPro to do many many recordings at 1 minute intervals to record the CPU usage with wifi on/off, with my regular set up, and with a bare rom with nothing else installed.
My findings: with a freshly installed rom or not, as soon as wifi is connected to my Dlink DIR-655, the CPU usage increases from roughly 0.3% to 1% (averaged over a 10-minute sampling period with screen off, background sync off), which drops back down as soon as wifi is turned off. More interesting, when the Dlink router is out of range, turning on wifi does NOT drain the battery.
I was puzzled by the result, so I went to a local coffee shop and connect to the public wifi access point, no increase with CPU usage whether on wifi or 3g only. So something is wrong with the Dlink DIR-655.
So, following some searches, this seems to be a somewhat recognized issue by some SGS2 owners (not too may because I bet not many would not suspect that the router could be the culprit). I tried changing from auto channel to CH8...11, changing from wireless N to G, changing authentication from wpa to wep to open, each time I change something, I made a new recording with wifi on compared to wifi off. Same thing. Only when connected to my Dlink DIR-655 does the drain occur.
Note: you cannot tell if your battery is being drained by just analyzing your wakelocks. In this wifi battery drain test, no wakelock stands out in terms of time on CPU. But if you use battery monitor widget pro, you can leave your screen off and let it plot. If with screen off your current draw is 100mh or above, here you have a battery drain. Your phone can very well be in "deep sleep" when this happens.
What to do:
I use JuiceDefender to make sure wifi is turned off when screen is off. You should set wifi sleep policy to never. Even though you could set it to turn off when screen is off, sometimes wifi cannot be turned off successfully using this method. When that happens battery drains without you knowing. This is why people have a fully charged phone before going to sleep and wake up with a dead battery.
Now it's your turn to share your experiences. If your SGS2 drains battery:
Do you have a Dlink router?
Do you have a DIR-655?
Or do you have this router by but have no battery drain.
Sent from my GT-I9100 using Tapatalk
I have the same problem with my DIR 655 and SGS2. In 18 hours with WIFI on, Android OS was top process with around 9h runtime. I also changed the WPA, channel etc. settings without result. Currently I want to downgrade the router firmware from 1.35NA to 1.21. In BBS, if I order the kernel wakelock by count I get one for about 140K, and it's active only when connected to wireless. I think the router doesn't let the SGS2 to sleep for more than several hundred miliseconds. You may play with advanced wireless settings in the router and change the Beacon Period and DTIM Interval values. I only hope that DLink will address this issue.
Cheers
Hi Sysod,
Did changing thevbeacon period solve your issue? Or downgrading router firmware to 1.21. From the Dlink changelog I don't see how it can improve our situation.
Sent from my GT-I9100 using Tapatalk
I have played a bit with beacon settings without succes. I noticed a decrease in battery drain, but also a decrease in wireless performance and I stopped tweaking. I'll see if dlink do something about it or else I'll buy a new router. The firmware to my router can't be downgraded, unfortunately, even with the russian modified one.:banghead:
Thinking I'm having this problem myself.
While researching I found this
http://forums.dlink.com/index.php?topic=38655.0
ehrw said:
Thinking I'm having this problem myself.
While researching I found this
Click to expand...
Click to collapse
Why I didn't think of this? After reading that thread, I fired up Wireshark on the laptop. I found many broadcast ARP packets originating from my 2 PCs. The culprit was the Cannon scanner software. After I disabled it, no more broadcasts and no more battery drain. Android OS is still high, but this might be a fault in reading.
Cheers
This router is terrible. I have had so many issue with it as well as mobile/laptop battery drain.
I just got a new router (not from Dlink) and battery levels consumption is what I would call normal, as in what I would get at work/wifi AP.
I guess this about confirm the combination of dlink dir 655 and sgs2 is bad for battery. I was going bonkers with my battery flat out in few hours once connected to my dir655.
Without connecting to wifi, based battery usage apps, I can get about 1% for 20-23 minutes and it took 1% for 6 minutes with wifi connected.
Now that I found this thread, I will be using my older 150n linksys/Cisco, for the next few hours to check if this is really a dlink issue combo with android since my son battery on his galaxy mini and the older galaxy s also flat out in less than 10 hours.
wcg707 said:
I guess this about confirm the combination of dlink dir 655 and sgs2 is bad for battery. I was going bonkers with my battery flat out in few hours once connected to my dir655.
Without connecting to wifi, based battery usage apps, I can get about 1% for 20-23 minutes and it took 1% for 6 minutes with wifi connected.
Now that I found this thread, I will be using my older 150n linksys/Cisco, for the next few hours to check if this is really a dlink issue combo with android since my son battery on his galaxy mini and the older galaxy s also flat out in less than 10 hours.
Click to expand...
Click to collapse
So, did it help?
DLink DIR-615, same issue, I was about to RMA the phone!
PS:
My fix with an updated DLink DIR-615: change WPA2 Protection from TKIP+AES to AES (TKIP only did not work with my i9100). In G Only it seemed draining even less (quick test), but I got this router for N+G and it seems working now.
Changing the DTIM interval from 1 to 255 solved the issue for me.
Had a battery loss of ~4% in 6-7 hours.
Let me know if this worked for you.
Gr,
Deva
I too am having this issue, but not on every single ROM that I run. I have a SII and so does my wife, running different ROMs. My phone has this battery drain problem with the Blu Kuban Kernal where I did not see it before. My wife is running Calkins old GB Rom and does not seem to have the issue. Changing the DTIM interval from 1 to 255 did not solve the issue for me, although it did seem to help. My phone stayed in deep sleep mode about 5 percent moer after changing this setting.
I think you should find Elins tech.szelins.com
I was wondering if anyone was experience a problem with the mediapad. I have two units and they have both been experience the same symptom. The unit would awake from deep sleep mode and drain the battery with the screen on and the CPU on full. I have been monitoring my tablet and the cpuspy records the tablet in deep sleep mode for 136:46 with other CPU speeds at less than 2 minutes. However, at 1188mhz, it was recorded for 4:56 minutes which is draining the battery so when I turn it on, it notifies me that it has 2% left. I've used betterbatterystats but I don't quite understand how to read the data. It says that it's been away for approx 5 hours which is when the CPU was at 1188mhz.
More info
This was happening on HC as well, so I'm wondering maybe if these units are defective if no one else is experiencing it. Having said that, I've read that huawei warranty/CS is horrendous.
Any help would be appreciated it is appearing on two identical units.
Cheers!
My S9+ (exynos) does not appear to be entering deep sleep. There doesn't appear to be any unusual activity other than cell standby being quite high (was in a low signal area this morning but not usually the case)
Currently unable to install better battery stats but was interested to see if anyone else had been experiencing this, potentially since the last update and if there was:
A) a specific app or process causing this
B) solution to the issue
Any help appreciated
Hi All,
Just got my GTR 47, very good looking & quality watch, when brightness is high the screen is spectacular with watch face that has 3D deep, for the sleep detection it does not detect when I am not sleeping, it find when I go to bed and wake up in the morning but between this I get up often at night to p and it did not detect that. anyone got this watch to better detect the sleep pattern. (compared to my fitbit blaze that was able to detect when I was not sleeping even if I was staying in bed).
thank you all.