View source for Power management requirements
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Power management requirements.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Power management requirements.
Here are some non-specific requirements for OpenMoko regarding power management of the phone. There are two general classes of requirements:
Like so many requirements, we would want more than is possible in theory or than is possible in practise with our resources. Like in all design, trade-offs have to be made between various desirable properties. For details about the hardware and drivers, and what's actually possible, see Neo1973 GTA01 Power Management. An important part of the implementation regarding management is being able to follow the charge state accurately and to forecast what the state is in say 10 minutes. This is made more difficult by battery aging.
Here the trade-off is between system simplicity and using all the power we get versus being easy to use and tolerant to "user errors". It's actually always possible that we lose all charge due to the small current drawn even while the system is fully off, but we can make this a very special corner-case.
Battery is too empty if:
We need to have separate checks for these cases:
Here the trade-off is between system simplicity and responsiveness and quality of all features versus longer run-times without the need to charge. Typically the return from a slow-power mode is not instant and the user will have to wait a moment (short or long).
Power saving options we have in general:
This is easier the more we can hide the details from the user in the previous sections.
Things the user needs to know:
Challenges: