Posted on 2010-01-13 00:10 UTC by Brad Grigor. Status: Under consideration, Categories: Devices.
"Power" users (pun intended) will not achieve all-day computing on the N900 with the supplied battery due to the high drain of the various radios, the added load of the GSM radio and phone application and certain other applications. While other brainstorms are looking at improving application efficiency, this brainstorm is looking to improve the battery in the N900.
The Talk discussion thread is at http://talk.maemo.org/showthread.php?p=467478
Posted on 2010-01-13 00:11 UTC by Brad Grigor.
An easy way to double the battery output is to literally bond two batteries into a single package. This "twin-pack" doesn't need to be twice as big as the original BL-5J battery--perhaps only 50% thicker--since some of the casing and internal circuitry don't have to be duplicated.
The "twin-pack" battery would be sold with a replacement battery cover to accommodate the extra thickness. This would add another "bump" of perhaps 2 or 3 mm on the back of the N900.
Posted on 2010-01-13 00:58 UTC by Leonid Yegoshin.
Mark each application (daemon) with class of real-time. The real real-time application (like wlancond) can be run as usual, but the rest (most of daemons) can be waked-up at some modulated periods. The CPU start-stop consumes a power and grouping non-real time daemons at the end of period would help conserve a battery power. It also can help voltage regulation works more efficently.
Posted on 2010-01-13 03:17 UTC by Erik Nygren.
Background tasks which require the network (such as checking for new email, twitter/RSS/weather/facebook/stock updates, new IMs, synchronizing contacts, etc) are likely to be independent for many existing applications. This means that the GSM radio needs to be spun up more often than necessary.
The appropriate API or service could help coordinate and consolidate this traffic. For example, applications could register minimum and maximum update frequences, as well as expectations about the amount of data transfer that will be needed. A central coordinator could then bring up the radio/network and notify applications via DBUS to perform their communications. The applications would then acknowledge when communications have completed.
This daemon/service could also:
(Perhaps this should be a separate brainstorm idea rather than a solution here?)
