Hack to improve Defy battery life by tweaking wifi ini files
I've been using CM10 on a Defy+ for a few days now. I've quickly noticed that I'm not getting exactly stellar battery life. Checking BetterBatteryStats indicated zero deep sleep, and "wifi_wake" as king of the wakelocks.
I realise that it's probably not wifi's fault but rather inconsiderate apps using wakelocks badly, still, something needs to be done.
Who is this for
People who, when their Defy+ has wifi on
, get absolutely no deep sleep
in BetterBatteryStats, and wifi_wake
or similar tops the kernel wakelock
Does this work when wifi is on but not connected to an AP?
No idea. Theoretically, wherever you come near an AP there will be beacons and DTIM's flying around so it might work. But if you're not going to be connected you might as well turn wifi off, either manually or with an app. I can recommend Wi-Fi Matic, it uses a clever trick (uses GSM cell IDs to detect proximity to a known AP).
Possible solution (*ROOT* needed. This was ONLY tested on Defy+ with CM10.)
After some research I came to the configuration files for the TI wifi module, which are located in /system/etc/wifi and called tiwlan.ini and tiwlan_ap.ini. After some digging around and reading the Texas Instruments doc for the module (sprugt8.pdf
), I'm prepared to offer a hack:
Reboot and see if BetterBatteryStats reports better (or any) deep sleep with wifi on and connected
This combination gives me
up to 85% deep sleep. YMMV because you probably don't have the same apps & background services installed as I do, usage patterns etc.
Increasing these values even further is possible (valid range is 1-50) but with only marginal improvements to deep sleep time and increasing issues with wifi (frequent disconnects in the case of weak signal). In other words, the connectivity problems aren't worth the extra 5% of deep sleep. Even so, if you manage to increase them (beacon in particular, I haven't tested large values as thorough as I did DTIM) and still keep wifi stable, please let us know.
Here's my findings for DtimListenInterval (on its own): 10 gives 25-30% deep sleep, 20 gives 42-50%, 30 goes up to 60%. Increasing it any further is pretty much useless, 50 (max) will get you to ~67% but expect heavy disconnects.
For BeaconListenInterval: 10 seems to be an upper limit when Dtim is around 25-30. Going over will cause disconnects even with very strong APs.
I haven't documented BeaconListenInterval on its own very rigurously, OR various combinations of the two, because I got bored of rebooting. Plus the fact I don't know when which of the two ini files will be used, so it's kinda like shooting in the dark. You're welcome to contribute your own findings.
But how do I edit those files?
You need root and any file manager worth its salt that lets you see the system files and edit them.
Is this dangerous?
I have no idea and I take no responsability.
It's probably a good idea to make a backup of those files, and, even better, slap the backups into a flashable zip on the root of your sdcard. In case something bad happens you can reboot in recovery and install the good versions back. Example flashable zip and tutorial here.
Remember, they go into system/etc/wifi/.
Warning: I used this on CM10 and Defy+
If you attempt it on anything else all bets are off. If the files are not there, you can't find the keywords and so on, you're on your own. Still, you can read the explanations below and try to see if anything helps.
tiwlan.ini and tiwlan_ap.ini control the behavior of the wifi module. I have no idea why there's two of them (or more, on some devices), but after poking around I've determined they must all be modified because they are used in different cases. (Different apps? Different circumstances? Different hardware parts? If anybody can enlighten us it would be super.)
These config files are similar, but different in some key aspects. Both my
files have dot11PowerMode=0 which means "auto", which means that it looks at AutoPowerModeDozeMode to determine if it uses short (2) or long (3) doze mode for power saving. tiwlan.ini has short mode, tiwlan_ap.ini has long mode.
This in turn means they use different listen intervals: short mode (tiwlan.ini) observes BeaconListenInterval, long doze (tiwlan_ap.ini) observes DtimListenInterval. Which is why we modify different properties in each file.
What are beacons and DTIMs? Simply put, beacons are a signal broadcasted by wifi access points periodically to let wifi clients they're there, and DTIMs are packages of special information about the AP. The most typical setup for most wifi APs is to send a beacon every 100ms i.e. 10 times a second, and a DTIM after every beacon, or at most every other beacon.
The default settings of "1" for BeaconListenInterval and DtimListenInterval means that the phone watches for these signals 5-10 times a second and, well, it's no wonder it doesn't get any sleep. Mind you, this does make for superb wifi connectivity, at the expense of battery life.
BTW, you can probably achieve similar effects by tweaking your wifi router to send beacons/DTIMs less often – all the wifi devices around your home will probably thank you. But of course you cannot control wifi APs everywhere you go, and it might backfire! Read below.
So why didn't "they" put better values on these settings?
For exactly the reason in the above paragraph: because you don't know what settings a particular AP you're trying to use has.
Here's an example. Say somebody tweaked their AP
and put 10 beacons a second and a DTIM every 10 beacons. This means a DTIM once a second, then you come along and tweak your phone
to only wake up the wifi connection every 30 DTIMs. That means 30 seconds, time in which the connection will most likely time out.
You cannot predict this kind of stuff so there's no safe default values other than "1", which mean "react as quickly as possible to any beacons/DTIMs we get because we don't know when we're getting another". My tweak is based on the assumption that the AP emits 10 beacons a second and DTIM with every beacon (beacon interval 100ms and DTIM interval 1). If the AP you use has been tweaked for more relaxed values these ini tweaks may backfire and cause disconnects!
Other potentially relevant ini settings
Here are some more interesting settings which could be further tweaked to get even better results:
See the TI pdf for details.
That's all folks
Thanks for reading this far. Please contribute
if you have insights, if I said stupid things or if you find settings that seem to work better.