Battery Saving
(→Use the Kernel for Power Users) |
(→Powersave bias) |
||
| Line 20: | Line 20: | ||
=== Powersave bias === | === Powersave bias === | ||
| + | |||
| + | The powersave bias setting modifies the behaviour of the ondemand governor to save more power by reducing the target frequency by a specified percentage. This can be used to limit the extent to which the phone will overclock, according to user-specified criteria. | ||
= Background power saving techniques = | = Background power saving techniques = | ||
Revision as of 15:01, 17 May 2011
This page aims to document "power user" techniques for extending battery life, i.e. automating various aspects of the phone's behaviour with a view to extending battery life. It is currently a stub/work in progress; the aim is not to reinvent the wheel but to draw together a variety of approaches to battery saving.
Contents |
Before you start
Set sensible defaults
The techniques here all involve automating the process of turning various things on or off according to the activity of the phone. Before there's any point in doing this, you'll want to have set the phone up more or less the way you like it, turned off anything you don't use, set reasonable defaults and made such optimisations as you can. You'll want to have had your device for a while, and be familiar with Kernel_Power and DbusScripts.
Use the Kernel for Power Users
Not just for Overclocking, the Kernel_Power package helps to save battery power and makes it easy to configure CPU frequency scaling. You should be using this for power saving purposes even if you never choose to go over the stock 600MHz.
Enable SmartReflex
Reports are mixed on SmartReflex; some users report crashes, while others use it with no problems and report improved battery life. There seems to be general concensus that it limits overclocking to 805 MHz and will cause crashes in combination with overclocking above that figure. The author uses SmartReflex on VDD1 and VDD2 without problems, at CPU speeds from 250-805MHz.
Undervolted kernel
Follow the information on the Overclocking page, but don't just grab the "ideal" profile and assume it'll be ideal in terms of battery life. If your device is happy and stable on the "starving" profile, with SmartReflex on, then you're onto a winner.
Powersave bias
The powersave bias setting modifies the behaviour of the ondemand governor to save more power by reducing the target frequency by a specified percentage. This can be used to limit the extent to which the phone will overclock, according to user-specified criteria.
Background power saving techniques
Techniques in the "background power saving" section should have little or no negative impact on the performance or usability of the phone but should save power in the background when the phone is not actively being used.
Actions on phone lock/unlock
One of the simplest uses of DbusScripts is to detect when the phone is locked or unlocked and run scripts to reduce the cpu frequency, system load, etc.
Suspend user processes
See Xagoln's post: http://talk.maemo.org/showpost.php?p=1005668&postcount=1
Change kernel powersave bias
Over on the Overclocking page, Fecn describes a set of scripts to modify the Kernel_power settings on phone lock/unlock, basically to underclock the CPU (or at least, undo overclocking it) whilst the device is locked.
Invasive power saving techniques
Techniques in the "invasive power saving" section save power by intentionally limiting the activity and/or functionality of the phone. This can have unintended consequences, so be sure you understand what you are instructing the phone to do before you do it.
Take IM / e-mail / other connections offline
Change radio mode
Keeping the phone in 2G mode except when 3G is needed for data will seriously enhance battery life at the possible expense of
- not having 3G connected per default when you launch a 3G application
- interrupting any Internet connections/phone calls when radio mode is changed
- forcing any background Internet traffic to GPRS
- impacting on viability of some messenger services, notably MSN
Therefore, many users drop to 2G mode manually, using something like qwerty12's 3G/2G Mode Selection Applet or David Lorenz's power saving script. These work fine if you remember to use them before remaining battery life becomes a problem. An alternative approach is to attempt to automate this such that the phone spends most of its working life (and makes and receives most calls) in 2G mode. We should then switch to dual mode when it is useful to do so, and switch back when it is no longer required.
The first part of this, the downgrade to 2G, is easy to script. We can do this any time the phone gets locked, provided we check that we're not on a call at the time. It's also nice to add a delay so that the phone only bothers to downgrade the radio mode if it gets locked and stays locked for a minute; we don't want it changing radio modes every time I throw the phone in my pocket to change buses. So, to achieve this:
- from our existing "on lock" script, we call a "try to set 2g" script
- have that script sleep for a while, to see if we unlock again
- have that script check for any good reasons it should not change radio mode
- have that script downgrade the radio mode to 2G
So, getting the phone to auto-downgrade to 2G is not hard (scripts to follow).
Slightly harder, though, is getting the phone to upgrade the connection again automatically when we do things that might require 3G. We certainly don't want to change the radio mode every time we unlock the phone, but we can do so on detecting the launch of known 3G applications (again assuming that we're not on a call at the time). However, these applications run within the user session, so you'll need to set up a second instance of DbusScripts running on the session bus in order to process the relevant events.