Woe ’pon me! Woe! Wo … right. It’s actually the Nokia N900 who has the regrettable battery woes, and I confess it is driving me up the wall and down the other side.
Let’s recap. As almost everything else about the N900, the battery life had been criticised in various anti–Nokia blogs and reviews. It ought come to no surprise that I found these comments as far from real life as possible.
So, I did some testing of my own. In short, I got about nine (9) hours of battery running an IM client over 3G, plus a few other applications; eight (8) hours of music and three (3) hours of video. All acceptable times for a device of this class.
Imagine, if you will, my surprise when, after the PR 1.3 update, it went from a full charge to running out of power in four hours of doing nothing much at all.
As I use the phone as an alarm clock, I doubt you’ll begrudge me my use of four letter words as I was awoken an hour early by the low battery warning …
Frothing somewhat at the mouth, I decided to do some tests before downgrading. All I’ve read suggest that PR 1.3 improve battery life; not the other way around.
So. First we establish the rules.
- Establish a minimum of two measurement techniques.
- Establish a number of distinct scenarios.
- Charge the battery until the device indicate it is full.
The first technique is the BatteryGraph application, which can give me an indication over time of power levels vs. cpu load. However, the application has no specific log so can’t tell me precisely the amount lost per hour.
Luckily, the N900 is a Linux–device. So, navigating the unfortunate choice of bash as our shell, and adding some trickery, we can use the following script:
while true ; do date ; hal-device bme | grep percentage ; echo "" ; sleep 3600 ; done
It’s function is simple enough. Once every hour it output the date, the percentage of battery left, and an empty line. This gives us a time–line.
In all of the following test scenarios, the unit was freshly booted, and the BatteryGraph application was running alongside the above power test script.
Wifi + OpenVPN
No other applications were in use. This yielded an average of 2.6% battery drain per hour over five hours.
11:38 - 90% 12:38 - 88% (2% loss) (2.0% avg. loss) 13:38 - 87% (1% loss) (1.5% avg. loss) 14:38 - 84% (3% loss) (2.0% avg. loss) 15:38 - 79% (5% loss) (2.8% avg. loss) 16:38 - 77% (2% loss) (2.6% avg. loss)
Estimated stand–by time: 36.53 hours.
No other applications were in use, and OpenVPN was turned off. This yielded an average of 2.2% battery drain per hour over five hours. The unit was moved over a distance of 30km during the test, so as to provoke roaming.
17:53 - 92% 18:53 - 90% (2% loss) (2.0% avg. loss) 19:53 - 87% (3% loss) (2.5% avg. loss) 20:53 - 85% (2% loss) (2.3% avg. loss) 21:53 - 84% (1% loss) (2.0% avg. loss) 22:53 - 81% (3% loss) (2.2% avg. loss)
Estimated stand–by time: 43.18 hours.
3G + OpenVPN
This is my suspected culprit. I engaged Wifi, established an OpenVPN link, and switched to 3G. Since the VPN profile is connection–specific, it was now defunct.
It lasted four hours — then I was down to 17% power, and found it prudent to end the test. The average power drain was 19.25% hourly; a rather terrible result compared to before.
16:04 - 94% 17:04 - 79% (15% loss) (15% avg. loss) 18:04 - 68% (11% loss) (13% avg. loss) 19:04 - 46% (22% loss) (16% avg. loss) 20:04 - 17% (29% loss) (19% avg. loss)
Estimated stand–by time: 4.9 hours (!)
Once the test was complete I connected the charger. The battery drain stopped at 15% charge — but it did not increase. A quick reboot, and I was at 70%. This latter part makes no sense at all.
The former, however, just might. We use two VPN connections; two distinct profiles. One, used with Wifi when at the office, utilise a route to our internal LAN. This does not work with 3G or out–of–office Wifi, which uses a different profile optimised for the cellphone company’s network.
If, or so the theory currently go, the Wifi is turned off, but the OpenVPN configured for use with it is active, the vpn client will, every fifteen seconds, ping the server via a route which takes it out into the 3G network, and there stops dead. Every sixty seconds a renegotiation is initiated; as that doesn’t work the client tries to look up DNS for the server.
That, in turn, means that the 3G radio will effectively be at full power the entire time, and never go into stand–by mode. Might explain the battery drain, huh?
In order to test this theory, we set up a different scenario: turn the 3G connection on, keep Wifi loaded but not used, and the correct VPN profile loaded. If the same drain can be seen, then the OpenVPN configuration is likely to blame. If the drain is not as severe, then the above theory is likely correct.
12:52 - 96% 13:52 - 88% ( 8% loss) ( 8.0% avg. loss) 14:52 - 74% (12% loss) (10.0% avg. loss) 15:52 - 62% (12% loss) (10.7% avg. loss) 16:52 - 53% ( 9% loss) (10.2% avg. loss)
At this point in the narrative we can conclude that a new theory is urgently needed. The drain curve is not as steep as before, but clearly a more thorough examination is required.
Next we looked at the OpenVPN config. The ping and ping–restart options appeared likely scoundrels, as it would be these who’d force power–on of the 3G radio.
Subsequently we changed the values from the current 15s/ping and 60s/ping–restart to 60s and 300s respectively, and re–ran the test.
20:02 - 96% 21:02 - 85% (10% loss) (10.0% avg. loss) 22:02 - 79% ( 6% loss) ( 8.0% avg. loss) 23:02 - 62% (17% loss) (11.0% avg. loss)
The changes didn’t do much. The problem does not occur, as seen by previous tests, on Wifi+OpenVPN. Could it be the 1400 bytes MTU used with GRPS? That might cause fragmentation.
Or it could be swamp gas reflecting of Jupiter. At this point we have no idea what to look at next.
Since the topic of playing music tend to entertain people, I’ve included one final scenario.
Here I started by making the assumption that the internal speakers will have a higher impedance than external headsets. This is based on advice from someone who knows their crap.
However, it is more likely that people will use a headset; something akin to the Koss PortaPro, perhaps? At 60 ohms it is certainly a better test than the, to me incomprehensible, jammed–inside–ears ‹buds› that are so common.
The volume was set to maximum, something I do not recommend while actually listening.
11:42 - 95% 12:42 - 90% (5% loss) (5.0% avg. loss) 13:42 - 83% (7% loss) (6.0% avg. loss) 14:43 - 78% (5% loss) (5.7% avg. loss) 15:42 - 70% (8% loss) (6.2% avg. loss) 16:42 - 66& (4% loss) (5.8% avg. loss)
Estimated effective time: 16.4 hours.
Wifi with OpenVPN has an average battery loss of 2.6% per hour. 3G without OpenVPN a loss of 2.2% per hour. 3G with OpenVPN lose approximately 10% per hour, and audio–only will drain the battery at a rate of ca. 6% hourly.
No, the numbers make no sense to me either.