REVIEW & TIPS: extending the battery life on the N95; acbTaskMan vs. Energy Profiler

1.2 Nokia�s brand new Energy Profiler to the rescue!

Now that we�ve seen CPU Monitor 1.10 is absolutely useless for estimating the battery life differences between Symbian apps (as opposed to acbTaskMan, running (solely) in CPU usage tracking mode, on Windows Mobile), you will definitely welcome Nokia�s new Energy Profiler application. It helps not only app developers, but also end users wanting to find out how the different options, settings (for example, the different Wi-Fi transmit levels) affect battery life.

It�s available for download HERE. I really recommend playing with the hotkeys, controls a bit (even in a full random approach) and re-returning to the built-in help (in addition to the online one) so that you find out all these features. There are a lot of them and you�ll want to learn them all. I also recommend going through my case studies, which clearly show how even a non-developer can make use of it to reduce battery drain � or, for that matter, NOT to believe urban legends like �disabling Bluetooth dramatically increases battery life�.

It has, compared to acbTaskMan on WM, a slightly steeper learning curve. (Assuming you only run the latter in current displaying mode and don�t make use of the CPU usage chart module at all.) This is simply because it has far more, great features and a lot of hotkeys to master (as opposed to the strictly menu & context menu-based usage & the complete lack of features like running average and breakpoints of acbTaskMan). Again, you�ll want to master them all in order to be able to measure the battery life estimation as easily and reliably as possible.

Note that it only runs on S60v3 FP1 (and later, future) models. This means it will NOT run on �plain�, older S60v3 models. Bad news for owners of older models.

2. Case studies and recommendations for N95 owners

Now, let�s do some serious work: let�s examine how much power the N95 takes � all this with Energy Profiler, packed with screenshots and a LOT of myth busting and useful advice!

Note that you can zoom in/out both the time (X) and the Watts (Ampers / Volts / temperture) (Y) axis in both applications. In acbTaskMan, you need to do this via Display / Timescale (where you can select between 2, 5, 10, 15, 30 minutes, 1, 3, 6, 12 and 24 hours. In Nokia�s app, by using the # and * phone buttons, you can do exactly the same. I�ve extensively used this when presenting the screenshots below; this way, it was, for example, possible to squeeze even half-hour-long tests into one screenshot.

Pay special attention to the running averages in the with white vertical bars separated regions � in most cases, they give you a pretty much perfect average of the measured power consumption.

2.1 Backlight levels

First, let�s take a look at the power usage of the different backlight levels. In the following screenshot, the lowest and the highest settings are depicted. The battery consumption of the lowest backlight level starts right at the beginning (the running average showing the 0.27W of the case of enabled backlight); the second, with the highest backlight, after the second vertical bar (restart). There, the running average doesn�t show the power consumption of the backlight (but an average between the next section), which was around 0.61W. The backlight timeout was set to 15 seconds in order to make the backlight power consumption metering as reliable as possible (as opposed to, say, an 5 second timeout).

As can clearly be seen, the highest setting increases the power usage by about 0.48 Watts (0.61-0.13 W), while the lowest with about 0.14W (0.27-0.13 W). This also means that, especially with the lowest setting, you won�t have a high battery drain when always enabled � that is, don�t set the display timeout to, say, 5s, and, then, just try to make out what�s on the screen using an external light.

(BTW, these results are pretty similar to what I�ve measured on Windows Mobile devices � see for example THIS. On older, Intel Xscale 27x-based non-phone devices with much bigger screen (requiring proportionally more power to be backlight), the highest backlight level resulted in a much higher power consumption. The lowest backlight level, on the other hand, doesn�t generally have dire consequences and high battery drain. That is, you can always let the backlight on your WinMo devices too and don�t wear out your eyes staring on the screen with no backlight at all. This is particularly useful on the, currently, most widely used 2.8� touchscreen-based HTC(-manufactured) models. The sole reason for this is the legendarily bad outdoor visibility of all these screens.)

2.2 Wi-Fi power setting levels

Second, let�s take a look at the Wi-Fi power level setting. Many recommend decreasing the Wi-Fi transmit power level from the default 100 mW to the lowest 4 mW to save some battery. (This can be done in Tools / Settings / Connections / Wireless LAN / Options / Advanced Settings (answer Yes) / TX Power Level as can be seen in THIS screenshot.) Let�s see whether this indeed results in any battery saving (or not).

In this test, first, before the white (restart) bar at ~4:35, I quickly downloaded a page with Nokia Web and, then, just let it sit there; all this in 100 mW mode. As you can see, the Wi-Fi transmission caused a constant ~0.65W (see the ~0.8W regions; I�ve subtracted the base power usage of the phone with the lowest brightness level; that is, about 0.14W); this region is, of course, packed with some short peaks.

The 4 mW transmission power case starts at the white (restart) bar at ~4:35. As can be seen, the peaks and the constant ~0.8W power usage at the beginning quickly decreases to ~0.27W (that is, the usual power usage of the phone without any task running, with minimal backlight), which, then, decreases to about ~0.14�~0.15W when the 15-sec backlight setting times out (and the backlight switches off). This is very rarely interrupted with a quick power peak, which costs exactly the same battery in both the 100 and 4 mW case.

This all means there doesn�t seem to be ANY difference between the two settings.

2.2.1 Searching for Wi-Fi networks

Let me also quickly elaborate on the CPU usage of staying on the Standby screen and making the N95 continuously search for Wi-Fi networks:

The above screenshot shows two entirely distinct phases. The first is taken after stopping to browse in Nokia Web (but still staying connected by not terminating the browser), which was over Wi-Fi. The lack of any excessive power consumption clearly shows that no scanning is taking place when the Standby screen is invisible. (Of course, you can also override this default behavior if you deem it useful; see Menu / Tools / Settings / Connection / Wireless LAN / Show WLAN Availability to change this.)
The second was quickly returning to the Standby screen and rescanning for networks. The three distinctive peaks in the second half of the screenshot show three quick, consecutive scans for these networks.

2.3 Multimedia playback, A2DP and the power Energy Profiler itself takes

2.3.1 MP3

Now, let�s take a look at the power consumption of the following activities:
[LIST=1]
[*]MP3 and WMA (see next subsection) playback (using the wired factory headphones at 70%)
[*]The same via A2DP
[*]How much power Energy Profiler itself consumes � that is, is it worth sending it in the background or let the screensaver �kick in� as quickly as possible [/LIST]

The following screenshot depicts all these cases and is, therefore, VERY informative:

After the first bar (note that this shot is made with a zoomed-out timescale; this is why the �0� mark doesn�t start right at the left), you can see the quick drop in battery usage because of the 5-sec timeout of the lowest backlight level. After 55 additional seconds (I�ve set the screensaver to kick in after a minute), there�s another change: the power consumption further decreases as Energy Profiler no longer draws on the screen / scrolls it. Drawing on the screen, no matter how well a particular application is written / optimized, will always consume SOME power. As can be clearly seen in the screenshot, the difference is about 10-20 mWatts � not much; but you can still take this into account when using Energy Profiler and striving for the best and most reliable result possible. That is, either set (Settings / General / Personalization / Display / Power Saver time-out) the screensaver timeout to as low as possible � for example, to 5 seconds -, or, alternatively, send Energy Profiler into the background to stop it consuming additional power because of the constant screendraws & scrolls. As can also be seen, in the latter case (no backlight, no active screen drawing by Energy Profiler but the screen saver �kicking in�), MP3 playback (via the headphones) consumes about ~0.45W.

Incidentally, in the upper right corner of the screen, you can see �7:58� as the estimated battery life with the given current � that is, with 0.45W. This pretty much corresponds to my previous v20 battery life tests done with wired headphones and WMA�s. See THIS (cross-posted to HERE) for more info on these previous tests.

Now, let�s take what effect A2DP has on the multimedia playback. Quite a big, actually: about 230�250 mW (~0.70 - ~0.45W), as can clearly be seen in the screenshot.

2.3.2 WMA

Let�s repeat the same for WMA, which involves a little bit higher CPU usage than MP3, which is also evident if you browse my old (v12) battery life test results:

As can clearly be seen, wired headphone-based playback consumes, in general, 0.49W (0.04W more than with MP3), while the same figure with active A2DP is ~0.72W. As the second (A2DP) part has the focus, its projected total battery life is printed in the upper right corner (5:04 � again, it�s almost exactly the same that I�ve measured with my full tests); with the wired case, 7:31 is shown, which is a bit lower than the battery life (7:55) I�ve measured, but is still close.

2.3.3 Another example of CPU Monitor�s being unreliable; MPEG-4 video playback with RealPlayer and CorePlayer

Finally (in this multimedia-related section), just an example of how unreliable the results of CPU Monitor 1.10 are. In my past articles (see for example THIS) I�ve already mentioned that, with A2DP enabled, I�ve measured a ~40% relative CPU usage increase (meaning a ~15% absolute increase) with the built-in RealPlayer and even more with the current beta2 of CorePlayer. I�ve even depicted the former case with the following screenshot:

Here, the CPU usage (as reported by CPU Monitor) of the video playback without A2DP is visible under the �eRA� substring of �FreeRAM� in the centre; the playback with A2DP enabled under the � 20� to the right of it. As can be seen, according to CPU Monitor, enabling A2DP should result in a massive power consumption increase.

Now, let�s see what Energy Profiler reports of this case.

The first half of the test is taken with A2DP enabled; the second half with it disabled. I�ve played a high-quality VGA-resolution video recorded with the built-in camera. As can clearly be seen, the A2DP case consumes only a BIT more energy. Don�t be mislead by the single average (which shows a bit bigger power consumption for the non-A2DP case); it�s, when also taking into account the starting and ending regions, which, unfortunately, took quite a lot of time because I needed to switch to (and, at the end of the video clip, from) RealPlayer all the time. It, however, isn�t THAT big � actually, for some reason, MUCH lower than with the MP3 / WMA cases above. I, frankly, don�t understand why this is taking place.

I�m pretty sure the real CPU / power usage is somewhere between the values reported by Energy Profiler and CPU Monitor. This would also explain why there�s a noticeable (about 28%) frame drop increase in CorePlayer (see my related test results) while benchmarking the VGA resolution DivX (MPEG-4 Part 2) video playback with middle video quality. (CorePlayer still doesn�t support the hardware multimedia decoder capabilities of the 3D & media accelerator part of the TI chipset; this is why it can�t decode full VGA videos in real-time when running in high-quality mode.)

2.4 Bluetooth

Now, the evergreen question of Bluetooth: should you leave it on, should you make it at least non-discoverable or should you switch it off whenever possible. The following screenshot (in the first part, BT was on and discoverable; in the second half, it was off) clearly shows there is very little (almost unmeasurable) difference:

Incidentally, this is what I�ve measured on most (but in no way all!) up-to-date, modern Windows Mobile phones (NOT phone-less models � they have sometimes much worse results as can be seen in HERE) as well. See for example THIS and THIS for more info if interested on the (almost negligible) additional power consumption of the HTC Universal / Wizard.

2.5 Active (but stalling) data connections: 3G vs. pre-3G

Let�s also take a look at the additional power usage of constantly maintaining an active connection to the server. For this test, I�ve used both a 2.(7)5G (EDGE) and a 3(.5)G UMTS connection; EDGE being the first in the screenshot, UMTS the second. (Note that while my network is HSDPA-capable, HSDPA is only actively used when transferring data. This is why I�m only speaking of UMTS when referring to stalling connections.

The different sections are as follows: very good (full bars) 2G signal; between 0 and 3 bars fluctuating (that is, in general, weak) 3G signal; strong (6 bars) 3G signal, again very good (full bars) 2G signal and, finally, a bit weaker 2G signal. The projected battery life, in this order: 20:30, 6:40, 12:59, 26:35 and 16:08.

The results are pretty staggering: when there is an active connection to be maintained, 3G produce far worse results than 2G, even when the signal is strong. (And, when it�s weak, the results are downright disastrous). This means you should NEVER EVER leave for example any messaging or mailer app running in the background for an extended time. Messenger apps like Fring will just chew through your battery in no time if you leave your handset in 3G mode! ALWAYS switch back to 2G if you plan to continuously run always-connected apps! (This is true on both the Symbian and Windows Mobile platforms.) To do this, go to Programs / Tools / Settings / Phone / Network / Network Mode as can be seen in HERE. Note that if your N95 is a branded one, you may NOT see �UMTS� on the list. Nevertheless, it shouldn�t bother you: �Dual mode� instructs the handset to use 3G whenever possible, while GSM always forces it to stay at 2G networks. For Windows Mobile users, you MUST read THIS article on how you can switch the easiest way.

Note that I�ve also exported this report as a CSV file; it�s available HERE.

2.6 Power consumption difference between standard (non-data) 3G and 2G connections

Seeing the disastrous results (otherwise common to ALL mobile devices � not just the N95) in the previous section, you might also want to ask whether constantly leaving 3G without an active connection will result in any problem. To answer this question, I�ve continued making some serious tests and come up with the following test result screenshot:

The first half of this shows the case of a very good (6 bars � the maximum is 7) 3G signal; the second shows a pretty bad one (again, fluctuating between 1 and 3 � placed in exactly the same place as with the previous case when an active data connection was maintained). (The full battery life estimation with the second, non-focused area is 21:17).

The results are really interesting. While there�s no measurable difference between the 3G and the 2G connection in the case of a very good signal (both are around 0.08�0.09W), this isn�t the case with the case of a bad one, where the 3G connection itself (even without being connected) results in power usage peaks.

To be absolutely sure this is typical for 3G but not that big a problem under 2G (when the latter operates on weak(er) signal), I�ve repeated the test with a much lower (3 bars but not fluctuating, unlike the 3G one) 2G signal. The results are much better and there are no visible anomalies or power peaks. This is shown in the following screenshot:

(The first half of the chart shows a non-connected state; the second shows a stalling 2.5G (this time, GPRS, not EDGE) data connection with Messaging.)
Hope you�ve found this section instructive; now, let�s move on to the direct comparison between acbTaskMan and Energy Profiler.

3. Compared to acbTaskMan on Windows Mobile...

3.1 Cons:

[LIST=1]
[*] Energy Profiler is unable to monitor CPU usage, only battery usage / temperature; this also means you can�t track individual processes
[*]It�s not possible to subtract the additional battery usage caused by Energy Profiler itself from the full usage. While Energy Profiler consumes really little battery, this could still have been implemented � for example, by just subtracting a predefined constant from the figure.

Let me point out again that the battery life estimations have been VERY close to the actual battery life I�ve measured (see my past v20 firmware articles) so this isn�t really an issue � unlike on Windows Mobile, where you MUST pay attention to the power consumption of acbTaskMan itself, as long as you don�t run it in the slowest mode.
[/LIST]

3.2 Pros:

[LIST=1]
[*] Energy Profiler has excellent exporting capabilities: Excel file, only the current view, all the screenshots etc. Opposed to this, acbTaskMan is �only� able to export a(n, otherwise, VERY detailed) Excel-compatible CSV log file; it has no, for example, built-in screenshot taking / exporting or exporting the entire series of measurements as a series of screenshots (an example directory list shot is HERE).

Nevertheless, acbTaskMan�s file logging capabilities are, as has already been pointed out, just great. It contains (almost) the same information as that of Nokia � and, of course, also the memory usage and detailed (!) process information (process name, CPU usage and, with a selected, �charted� process, its memory usage) in the order of their CPU usage. (That is, it doesn�t log all processes, only the ones with the highest CPU usage � and, of course, the selected one).

I�ve made a screenshot showing Excel rendering these results. I�ve set acbTaskMan.exe to be the charted app; this is why its name, CPU and memory usage are visible in columns F, G and H. Column I and J contains the process that uses the biggest CPU time in the system; in the first half of the logging results, it�s the same acbTaskMan.exe. With the second half, on the other hand, when I activated Pocket Controller on the desktop, PCCommLoader.exe �kicked in� with a much higher CPU usage and, consequently, became the process listed in I and J, �shifting� acbTaskMan.exe, which remained the second most CPU time consuming app, to the K and L columns. Incidentally, the power column (E) is also worth checking out: when I started Pocket Controller and the CPU usage skyrocketed (from 4-5% to around 40%), the power usage also became serious: from around 50mA to around 410 mA.
[*]it also measures Voltage and temperature, not only Amperage. This means more reliable total power requirement analysis, independent of the (remaining � don�t forget it somewhat decreases and, consequently, the Amperage somewhat increases with a (slightly) depleted battery) voltage of the battery.

I don�t, however, consider this to be a major flaw with acbTaskMan. If you do your tests with a 100% topped up battery, the actual voltage of the battery won�t count much as you can assume the voltage of the battery is almost the same and you can, therefore, pretty much rely on the simple Amperage results.
[*]Running average computed from the latest restart / marker. It can be VERY useful. acbTaskMan, unlike its (free) predecessor, acbPowerMeter, doesn�t have any similar feature.

Speaking of the old acbPowerMeter, it did averaging (see for example THIS screenshot), but lacked the running total � the numeric value of the current power consumption.
[*]When an external charger is attached, the background of the chart will be changed to grey as can be seen in THIS screenshot. acbTaskMan doesn�t support this. (On WM, attaching the charger will also really increase the current measured by the tool as can be seen in THIS screenshot, showing a total of 600 mA, as opposed to the non-charging state.)
[*]Much more frequent updates without a noticeable increase in CPU usage � acbTaskMan is definitely worse in this respect (because of operating system restrictions)
[*]Adding markers any time (with both long-pressing 5 or quickly restarting (2 or menu) the measurement).

This not only helps with identifying a certain area in the timeline, but is also a tremendous help with calculating the running average (see the second bullet above).

As an example to show the importance of the former feature, let me refer to one of my older articles on using acbTaskMan, which has several screenshots of the app. For example, while explaining the following one:

as I couldn�t use markers, I had to rely on the readers� ability to correctly identify the 100/80/20% cases (see the explanation right under the first screenshot in section �2.1 The filesys throttler � benchmarks� in the original article), which isn�t guaranteed with, say, a newbie. Then, just inserting (vertical) markers to the points when the activity started, it�d be much easier to refer to the �first�, �second� and �third�, easily-visible markers.

As far as the power average is concerned, it is totally recomputed for the section started to be (re)computed when you insert a new marker anywhere, while keeping the old average. This can be of extreme help when you need absolutely the most reliable results. An example of the latter is clearly visible in the following screenshot:

Here, there�re two running averages displayed; the first starts about 1:59; the second at 2:29. The first average shows 4.63 Watts (showing � along with the grey background � that the device was on charger); the second 3 Watts (showing the mean between the previous 4.63 Watts and 0.7 Watts; the former having somewhat more weight because of the time of the measurement). The average results� being stored is a real gift and can prove very useful when, otherwise, it�d be very complicated to correctly estimate the average power consumption over a given time.

[*]Supports sliding over the window � can prove useful when, for example, you want to hide what happened in the last seconds (you can�t be quick enough to stop measurement without this not being reflected in the power usage) not to confuse the readers. This is impossible with acbTaskMan � with the latter, you can�t slide the view and, consequently, can�t hide the last seconds. (Fortunately, as acbTaskMan, generally, uses a far lower sampling frequency, quickly pausing it via Menu / Pause, in general, doesn�t result in a visible and/or annoying CPU usage / power consumption increase.)

[*]Has an excellent box plot / histogram mode, which acbTaskMan completely lacks. Two screenshots:

[*]Definitely lower CPU usage than acbTaskMan, unless you switch the latter to even (annoyingly) slower sampling (Display / Update Speed: Low or, to really reduce the CPU usage to ~1.5% (on 624 MHz / PXA 270), X-Low) on the latter.
[*]The timescale is much more usable in Nokia�s app than in acbTaskMan. In the latter, there�re only two time points: �X Min./Hour(s) Ago� and �Now�. Of course, the file-based logging will still have a precision depending on the global frequency set in Display / Update speed.

This means you can even identify seconds in Nokia�s app. In acbTaskMan, you will need to consult the log file for this.

[*]Much better built-in help than in acbTaskMan � much easier to get a grasp of how the app should be used (example screenshots: 1 2 3). Also, the online docs is far more informative than that of acbTaskMan. [/LIST]

UPDATE (12/02/2007):

1. Make sure you check out THIS HoFo, THIS and THIS AAS and THIS The Register threads.

2. in the meantime, I�ve continued testing, mainly for three reasons:
[LIST=1]
[*]HERE (do check it out � there are a lot of information there; note that you should read the entire thread BEFORE drawing conclusions from any post!), �Stewart Atkins� stated he had five (5) Watts (!!!) of power usage during video playback, which corresponds to about 50 minutes of total battery life
[*]in the same thread, �Jasmine� stated Nokia�s app itself burns �about a third of a watt�, which I in no way think is right
[*]and, still in the same thread, one of the developers, �MikaK� stated using the 5s mode results in the most accurate measurements (as opposed to the default, 0.25s sampling)
[/LIST]

For this test, I�ve run some serious benchmarks with CorePlayer, the leading desktop & mobile cross-platform (Palm / Windows Mobile / Symbian) video player. I�ve used the built-in benchmarking utility, playing back a 640*480 DivX video stream at medium quality.

The video played back is the second episode of �Battlefield Scandinavia�. It starts with a very demanding, high-rate, wildly animated computer animation (causing dropped frames even at this Medium quality on the current, still non-hardware-decoder-based version of CorePlayer on the N95); the next part has far less animation (mostly zooming in/out of maps). The vast difference needed to decode the first part (as opposed to the second) will also be visible in the chart.

The following screenshot shows four cases (the first two aren't separated!):

These are as follows:
1. default, benchmarked playback with speakers
2. the same with A2DP (to see whether there�s any additional battery drain � there doesn�t seem to be, but the benchmark results still drop by about 27%, from 112 to 88% showing there is still something taking up some CPU cycles)
3. speaker-based playback again (just like with bullet 1)
4. still a speaker-based playback but, now, with a 5-sec sampling rate

As can clearly be seen, there isn�t any notable difference between the results � the 5-sec sampling rate in no way decreases the total power usage. This is also reflected in the benchmark results returned by CorePlayer itself: it�s ~112.5% in all the three non-A2DP cases, decreasing to ~88% with A2DP enabled. Without any kind of benchmarking running in the background, it�s still around ~112.5%, which clearly shows the additional CPU usage introduced by Energy Profiler is negligible. This is definitely very good news.

Finally, again, it seems you don�t need to switch to 5s sampling either - frankly, I don't get why MikaK instructed the folks to do so.

UPDATE (12/02/2007, later):
In HERE, I have been asked to do some additional Wi-Fi tests with file upload to pinpoint the difference between the 4mW and the 100mW transfer power settings. As I�ve done several tests like this in the past (see for example THIS), I at once knew what to do. I downloaded THIS free FTP client and, from the storage card, I�ve benchmarked uploading a 24M file to a computer in the same LAN as the Wi-Fi router the N95 connects to. In addition to the power charts, I've also used a stopwatch to measure the transfer time.

I�ve made two tests to be absolutely sure (with a reboot in between).

The first test:

About 2 metres (4 feet) away:

1st, 100 mW: crash after some 15M
2nd, 100 mW: 2:30
3rd, 4 mW: 2:54 (took slightly longer because the transfer, for some reason (an internal bug in the FTP client), stalled for some time.

About 6 metres, still the same room
4th, 4 mW: 2:30

Two walls in between:
5th, 4 mW: 2:45

Three walls in between:
6th, ~3:00

Second (after a reset, still at 4 mW):

The same as the three case above: stopped after transferring 130k
2nd: client crashed after transferring 17.5M (this FTP client likes crashing...)

As can be seen, there isn�t much difference between the 100mW and the 4mW case. With the latter, the N95 will still burn much more power than 4mW when the signal is weak (see the sixth case, with three walls in between, in the first screenshot and compare it to the cases of the same room / two walls). I don�t even know whether there�s any sensitivity difference between the 100 mW and the 4 mW case � I haven�t seen any. There isn�t any difference in the power used / transfer times, that�s for sure.

UPDATE (12/03/2007): I�ve continued benchmarking the power usage with active network connections to find out the optimal selection of network usage. The following screenshot shows a continuous web browsing (with occasional Messaging POP3 downloads) with Opera Mini 4, using the lowest brightness level (& at night & opened and heavily used (for OM scrolling) slider; that is, the buttons were almost always lit), Bluetooth off (not that BT would have any effect on the outcome, it consumes so little power) over EDGE with weak and, according to the N95�s bars, highly (between 0 and 3 bars) fluctuating signal.

As can clearly be seen, even with such, fluctuating signal, the power consumption is very moderate; it averaged to 0.49 Watts, which corresponds to about seven and a half hours of continuous use. Again, note that all this shows a case of active use, tons of page downloads, scrolling, navigation. Taking this into account, the results are extremely good � and, of course, MUCH-MUCH better than the 3G case with a weak 3G signal. I�ll also publish similar, heavy-OM-use tests with strong EDGE (2.75G) and weak 3G signals so that you can see the difference � stay tuned.

UPDATE (12/03/2007, later):

As promised, I�ve continued running some real-world tests. I�ve continuously used Opera Mini 4 (and, at the beginning, Messaging � hence the longer power usage peak at the very beginning) for some 20 minutes under exactly the same (lowest backlight, dark environment, screen and keypad constantly illuminated with backlight, no BT, no other tasks) conditions as the previous weak-signal EDGE test. I�ve forced a UMTS-only connection with weak signal (fluctuating between 0 and 3 bars; sometimes reconnecting); that is, I didn�t let the phone switch back to the 2G band (this way, I had some 6 or 7 reconnections because of the low signal). The results are as follows:

If you take a look at the running average (1.04W), you quickly realize that it�s more than two times greater than the previous case with the weak EDGE signal. Yes, when the signal is weak, selecting 3G over 2G is a VERY bad choice (for data - exactly as with standard phone), unless you REALLY need the additional speed.

I�ll soon publish real-world Opera Mini usage test results with strong and stable 3G signal � stay tuned!

UPDATE (12/03/2007, again later): As promised, the new Opera Mini real-world usage results: 3.5G with strong signal (always switched to HSDPA for download); otherwise, exactly the same circumstances as in previous tests.

As can clearly be seen, while the situation is a bit better than in the case of weak signal, the total power consumption is almost exactly twice (0.97W) of that of the (weak-signal!) EDGE case. That is, your battery will deplete twice as fast as with 2G data connection even if you have very good 3G signal.

(Full CSV file HERE.)

UPDATE (12/04/2007):

More info on power consumption of constant (streaming) data connections

I�ve made some additional tests to find out whether the battery consumption depends on the actual transfer rate. For this test, I�ve used the just-released Nokia Internet Radio, with two stations. One of them is a low-quality, mono, 24 kbps one (Genre / News / Veluwe FM Putten); the other is a high-quality, stereo, 192 kbps (Language / Finnish / Bassoradio) station. This means the former can be played back over even a plain, slow GPRS connection and the latter can still be played back over an EDGE connection.

BY selecting two radio stations really differing in streaming speed, my main goal was to find out whether the power consumption of the modem is proportional to the streaming speed.

(all these figures with A2DP enabled; without A2DP, they�re all about 220 mW lower)

This chart proves the following: the power usage is totally independent of the actual data rate and only depends on the technology (2G vs. 3G) used. In this regard, there�s no difference between GPRS and EDGE modes � they consume the same power. This is certainly very good news: after all, EDGE can be acceptably fast (unless your wireless operator doesn�t provide you with the maximum speed available � some of them, unfortunately, go this way).

This also means if you either listen to low-speed (generally, up to 30 kbps) radio stations (not available as a higher-speed stream) even playable over GPRS connections OR you have EDGE and you don�t listen to radio stations over 192 kbps, you most probably can safely fall back to using 2G to save some 600 mW, which means you can greatly improve the battery life of your handset.

VERDICT: All in all, if a 2G connection is able to reliably stream a given radio station, force your handset to operate in 2G mode. Don�t forget: EDGE connections can still be able to play most, if not all, radio stations. Try extending your battery life!

(guys and gals, sorry for having to slice it up into several parts � the forum settings only allow for posting 10k-long posts at a time.)

Terrific and comprehensive report! Probably deserves a technical sticky status.😊

Great review and tips. Thanks a lot for your hard work. 😊

Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.

Good article, but didn't really show anything new. Well, everyone knew 3G drains more battery life than 2G, weak signal is worse than good signal, wired headset uses less than A2DP etc.

But I do appreciate the effort put in proving it!

rottie wrote:Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.

Good article, but didn't really show anything new. Well, everyone knew 3G drains more battery life than 2G, weak signal is worse than good signal, wired headset uses less than A2DP etc.

Well, it has some interesting, quantitive and pretty revolutionary results; for example, it shows 3G doesn't consume more power if and only if there's a good signal (as opposed to the case of bad signal) and that, contrary to what many N95 users think (and also recommend), Bluetooth doesn't really increase the battery consumption.

Of course, I agree the majority of this stuff isn't anything new to most N95 users 😊

rottie wrote:Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net.

It indeed is. However, if the 3G signal where you are is good and you always exit the apps that use your 3G connection as soon as possible (also meaning you don't run Messenger-like apps for hours), you won't really see any battery life degradation.

Alternatively, you may want to consider switching to Opera Mini as the main browser - it's very fast even over a slow GPRS connection.

Menneisyys wrote:It indeed is. However, if the 3G signal where you are is good and you always exit the apps that use your 3G connection as soon as possible (also meaning you don't run Messenger-like apps for hours), you won't really see any battery life degradation.

Alternatively, you may want to consider switching to Opera Mini as the main browser - it's very fast even over a slow GPRS connection.

And if I'd want a slow internet browsing I'd buy an iPhone...😊

This is an excellent report! I'm surprised that blue tooth being on or off makes very little difference in battery consumption. I always thought that leaving blue tooth on (and discoverable) drained the battery a lot faster than normal.

rottie wrote:Are you suggesting that one should suffer using GPRS on HSDPA ENABLED phone to save battery???

Not really - I meant you can have almost exactly the same page download speeds using GPRS (let alone EDGE) if you use Opera Mini than with Nokia Web / Opera Mobile over a HSDPA connection. Opera Mini 4 rocks.

BTW, if you do remember to exit Nokia Web / Messaging (and, thus, terminate the connection) after the session, you won't see much difference in battery life. It's on the long run (say, Internet connections active for more than a few minutes) that the vastly increased power drain of active 3G data connections "kick in" and severely degrade battery life.

regimorales wrote:This is an excellent report! I'm surprised that blue tooth being on or off makes very little difference in battery consumption. I always thought that leaving blue tooth on (and discoverable) drained the battery a lot faster than normal.

Did you (or, anyone) test this in real life? With a removed SIM card & offline mode (so that nothing has any effect on the phone), the time for the battery to completely discharge.

There MAY be differences; it's just that they're not measurable, they're so minor.

Or, at least not measurable with this tool. I don't think this - the problems of the tool - is the case, however. With all my multimedia benchmarks, which I've also done using the "traditional" "let the N95 play some test WMA's / MP3's until the battery completely depletes", I've got exactly the same results as with running the tool.

Finally, keep in mind that microelectronics is continuously evolving. While a BT module in a, say, four-year-old phone may have had a noticable adverse effect on the battery life, current BT modules are far better in this respect. Not only on Symbian, but also on Windows Mobile and other mobile platforms - even dumbphones. (I've made a LOT of tests on Windows Mobile to find out the battery life of the phones with and without BT. The results also back up this.) Exactly like the IrDA "myths" with Windows Mobile, those old "rule of thumbs" ("deactivate BT whenever possible"😉 are not necessarily true any more.

UPDATE (12/02/2007):

1. Make sure you check out THIS HoFo, THIS and THIS AAS and THIS The Register threads.

2. in the meantime, I�ve continued testing, mainly for three reasons:
[LIST=1]
[*]HERE (do check it out � there are a lot of information there; note that you should read the entire thread BEFORE drawing conclusions from any post!), �Stewart Atkins� stated he had five (5) Watts (!!!) of power usage during video playback, which corresponds to about 50 minutes of total battery life
[*]in the same thread, �Jasmine� stated Nokia�s app itself burns �about a third of a watt�, which I in no way think is right
[*]and, still in the same thread, one of the developers, �MikaK� stated using the 5s mode results in the most accurate measurements (as opposed to the default, 0.25s sampling)
[/LIST]

For this test, I�ve run some serious benchmarks with CorePlayer, the leading desktop & mobile cross-platform (Palm / Windows Mobile / Symbian) video player. I�ve used the built-in benchmarking utility, playing back a 640*480 DivX video stream at medium quality.

The video played back is the second episode of �Battlefield Scandinavia�. It starts with a very demanding, high-rate, wildly animated computer animation (causing dropped frames even at this Medium quality on the current, still non-hardware-decoder-based version of CorePlayer on the N95); the next part has far less animation (mostly zooming in/out of maps). The vast difference needed to decode the first part (as opposed to the second) will also be visible in the chart.

The following screenshot shows four cases (the first two aren't separated!):

These are as follows:
1. default, benchmarked playback with speakers
2. the same with A2DP (to see whether there�s any additional battery drain � there doesn�t seem to be, but the benchmark results still drop by about 27%, from 112 to 88% showing there is still something taking up some CPU cycles)
3. speaker-based playback again (just like with bullet 1)
4. still a speaker-based playback but, now, with a 5-sec sampling rate

As can clearly be seen, there isn�t any notable difference between the results � the 5-sec sampling rate in no way decreases the total power usage. This is also reflected in the benchmark results returned by CorePlayer itself: it�s ~112.5% in all the three non-A2DP cases, decreasing to ~88% with A2DP enabled. Without any kind of benchmarking running in the background, it�s still around ~112.5%, which clearly shows the additional CPU usage introduced by Energy Profiler is negligible. This is definitely very good news.

Finally, again, it seems you don�t need to switch to 5s sampling either - frankly, I don't get why MikaK instructed the folks to do so.

rottie wrote:Ok, but it's a pain to change the network settings to 3G everytime one wanna check something on the net...

But in newer phones like the N95, you can change network mode on-the-fly, for it's not restarted automatically like older models.

In phones like N95, you can easily go to GSM mode when you don't need speed, i.e. when phone is in standby, or you want to stream some low quality content.

If you only want to be online for hours in your favorite IM service to chat now and then, why would you use UMTS and drain battery faster, if you won't need 3G speeds for a regular chat (without file transfer)?

rottie wrote:
...everyone knew 3G drains more battery life than 2G, weak signal is worse than good signal, wired headset uses less than A2DP etc...

if Bluetooth stuff is included in your etc, i must say i've never seen such statement in forums or web sites.
In all places (maybe not all, but in the massive majority), you're always suggested to turn Bluetooth off, cause doing this would "save a lot of battery life"

i have a question for you, Menneisyys.
You told there're no significant differences in battery usage between 4mW and 100mW when downloading a page over WIFI.
But have you performed the same test, but uploading a file instead downloading?

best regards

alb3530 wrote:I agree with you in phones like the N90 or N70, that restart automatically when you change network mode.

But in newer phones like the N95, you can change network mode on-the-fly, for it's not restarted automatically like older models.

In phones like N95, you can easily go to GSM mode when you don't need speed, i.e. when phone is in standby, or you want to stream some low quality content.

If you only want to be online for hours in your favorite IM service to chat now and then, why would you use UMTS and drain battery faster, if you won't need 3G speeds for a regular chat (without file transfer)?

Yup, in these cases, it's mandatory to fall back to 2G - 3G, when maintaining an active data connection (independent of the signal strength!!!!), chews thru the battery.

if Bluetooth stuff is included in your etc, i must say i've never seen such statement in forums or web sites.
In all places (maybe not all, but in the massive majority), you're always suggested to turn Bluetooth off, cause doing this would "save a lot of battery life"

The same is stated about IrDA on Windows Mobile. (On WM, you can permanently enable it, unlike on the N95.) I've done some really serious, several-day-long tests with IrDA (and BT) and found out that it's no longer the case. That is, the high power requirements of IrDA is more of an urban legend now - as opposed to the past (old hard/firmware). (I still remember the Sony-Ericsson t68i (and, before that, the Ericsson 520m), where IrDA did consume a LOT of battery. That's no longer the case with currend handsets.)

i have a question for you, Menneisyys.
You told there're no significant differences in battery usage between 4mW and 100mW when downloading a page over WIFI.
But have you performed the same test, but uploading a file instead downloading?

Thanks for bringing up this q; I run some tests with my local FTP server and post a generic update.

UPDATE (12/02/2007, later):
In HERE, I have been asked to do some additional Wi-Fi tests with file upload to pinpoint the difference between the 4mW and the 100mW transfer power settings. As I�ve done several tests like this in the past (see for example THIS), I at once knew what to do. I downloaded THIS free FTP client and, from the storage card, I�ve benchmarked uploading a 24M file to a computer in the same LAN as the Wi-Fi router the N95 connects to. In addition to the power charts, I've also used a stopwatch to measure the transfer time.

I�ve made two tests to be absolutely sure (with a reboot in between).

The first test:

About 2 metres (4 feet) away:

1st, 100 mW: crash after some 15M
2nd, 100 mW: 2:30
3rd, 4 mW: 2:54 (took slightly longer because the transfer, for some reason (an internal bug in the FTP client), stalled for some time.

About 6 metres, still the same room
4th, 4 mW: 2:30

Two walls in between:
5th, 4 mW: 2:45

Three walls in between:
6th, ~3:00

Second (after a reset, still at 4 mW):

The same as the three case above: stopped after transferring 130k
2nd: client crashed after transferring 17.5M (this FTP client likes crashing...)

As can be seen, there isn�t much difference between the 100mW and the 4mW case. With the latter, the N95 will still burn much more power than 4mW when the signal is weak (see the sixth case, with three walls in between, in the first screenshot and compare it to the cases of the same room / two walls). I don�t even know whether there�s any sensitivity difference between the 100 mW and the 4 mW case � I haven�t seen any. There isn�t any difference in the power used / transfer times, that�s for sure.

UPDATE (12/03/2007): I�ve continued benchmarking the power usage with active network connections to find out the optimal selection of network usage. The following screenshot shows a continuous web browsing (with occasional Messaging POP3 downloads) with Opera Mini 4, using the lowest brightness level (& at night & opened and heavily used (for OM scrolling) slider; that is, the buttons were almost always lit), Bluetooth off (not that BT would have any effect on the outcome, it consumes so little power) over EDGE with weak and, according to the N95�s bars, highly (between 0 and 3 bars) fluctuating signal.

As can clearly be seen, even with such, fluctuating signal, the power consumption is very moderate; it averaged to 0.49 Watts, which corresponds to about seven and a half hours of continuous use. Again, note that all this shows a case of active use, tons of page downloads, scrolling, navigation. Taking this into account, the results are extremely good � and, of course, MUCH-MUCH better than the 3G case with a weak 3G signal. I�ll also publish similar, heavy-OM-use tests with strong EDGE (2.75G) and weak 3G signals so that you can see the difference � stay tuned.

UPDATE (12/03/2007, later):

As promised, I�ve continued running some real-world tests. I�ve continuously used Opera Mini 4 (and, at the beginning, Messaging � hence the longer power usage peak at the very beginning) for some 20 minutes under exactly the same (lowest backlight, dark environment, screen and keypad constantly illuminated with backlight, no BT, no other tasks) conditions as the previous weak-signal EDGE test. I�ve forced a UMTS-only connection with weak signal (fluctuating between 0 and 3 bars; sometimes reconnecting); that is, I didn�t let the phone switch back to the 2G band (this way, I had some 6 or 7 reconnections because of the low signal). The results are as follows:

If you take a look at the running average (1.04W), you quickly realize that it�s more than two times greater than the previous case with the weak EDGE signal. Yes, when the signal is weak, selecting 3G over 2G is a VERY bad choice (for data - exactly as with standard phone), unless you REALLY need the additional speed.

I�ll soon publish real-world Opera Mini usage test results with strong and stable 3G signal � stay tuned!

UPDATE (12/03/2007, again later): As promised, the new Opera Mini real-world usage results: 3.5G with strong signal (always switched to HSDPA for download); otherwise, exactly the same circumstances as in previous tests.

As can clearly be seen, while the situation is a bit better than in the case of weak signal, the total power consumption is almost exactly twice (0.97W) of that of the (weak-signal!) EDGE case. That is, your battery will deplete twice as fast as with 2G data connection even if you have very good 3G signal.

(Full CSV file HERE.)

Menneisyys wrote:(guys and gals, sorry for having to slice it up into several parts � the forum settings only allow for posting 10k-long posts at a time.)

Just noticed the restriction only applied to under-50 posters. Now, I can post much longer posts without slicing them into 10k chunks.

UPDATE (12/04/2007):

More info on power consumption of constant (streaming) data connections

I�ve made some additional tests to find out whether the battery consumption depends on the actual transfer rate. For this test, I�ve used the just-released Nokia Internet Radio, with two stations. One of them is a low-quality, mono, 24 kbps one (Genre / News / Veluwe FM Putten); the other is a high-quality, stereo, 192 kbps (Language / Finnish / Bassoradio) station. This means the former can be played back over even a plain, slow GPRS connection and the latter can still be played back over an EDGE connection.

BY selecting two radio stations really differing in streaming speed, my main goal was to find out whether the power consumption of the modem is proportional to the streaming speed.

(all these figures with A2DP enabled; without A2DP, they�re all about 220 mW lower)

This chart proves the following: the power usage is totally independent of the actual data rate and only depends on the technology (2G vs. 3G) used. In this regard, there�s no difference between GPRS and EDGE modes � they consume the same power. This is certainly very good news: after all, EDGE can be acceptably fast (unless your wireless operator doesn�t provide you with the maximum speed available � some of them, unfortunately, go this way).

This also means if you either listen to low-speed (generally, up to 30 kbps) radio stations (not available as a higher-speed stream) even playable over GPRS connections OR you have EDGE and you don�t listen to radio stations over 192 kbps, you most probably can safely fall back to using 2G to save some 600 mW, which means you can greatly improve the battery life of your handset.

VERDICT: All in all, if a 2G connection is able to reliably stream a given radio station, force your handset to operate in 2G mode. Don�t forget: EDGE connections can still be able to play most, if not all, radio stations. Try extending your battery life!

UPDATE (12/05/2007):
(This article refers to the just-released radio app I've already mentioned above.)

Guys and gals, I�ve made some VERY serious tests.

First, my generic remarks:

[LIST=1][*]Will it receive aacPlus (aka AAC+ and HE-AAC) support some time? Right now, it only (fullY) supports the, in webcasts, very-very rarely used AAC streams. Sure, it does play aacPlus streams too, but downsampled and in mono only, while the vast majority of these streams are stereo, even at 24 / 32 kbps, and only really the slowest (around 10 kbps) are mono. (AAC decoders can be used to decode aacPlus at a much lower sound quality, as was also the case with the MP3 Pro / standard MP3 set-up.) And, of course, Music Player in the N95 already contains aacPlus support (a decoder) � why not use it?

This question is particularly topical as mainstream Windows Mobile players doesn�t really have HE-AAC support as can also be read HERE; some of the most popular ones (for example, Pocket Player) not even plain AAC support (as yet). Seamless aacPlus support on Symbian could be the killer application even for some WinMo users (if you want to make the platform more appealing to them, that is).
[*]The bug several of you�ve already reported, that is, app�s inability to start is a real pain in the back because it necessitates removing the app altogether and reinstalling it. You can very easily reproduce the bug (if you haven�t already run into it) by just clicking THIS 24k aac+ link. After you exit the radio player, upon a subsequent restart, it�ll no longer run and you�ll need to completely reinstall it. (Tested on the N95 with firmware version v20; tested with both the internal memory and the card)
[*]It doesn�t register the M3U extension, only PLS. This should be changed � after all, it�s SHOUTcast / Icecast / MP3-compliant and many radio stations use MP3.
[*]What about adding OGG support? 😉 In several countries, where aacPlus isn�t (at all) used, for example, Finland, it�s still the only way to converse bandwidth (as opposed to the about two time more bandwidth-wasting MP3 streams). (I whish I Finnish stations switched to aacPlus though so that they could become accessible with GPRS only.)
[*]I�ve created a demo web page where you can test the different stream types, M3U extension etc. It also links to some link repositories. It�s available HERE. [/LIST]

Second, in addition to my past tests (see THIS), some additional 24 kbps + GPRS power usage tests taking over an hour total:

A 24 kbps 44 kHz stereo aacPlus stream playback (of course, as there is no aacPlus support, only in mono and 22 kHz):

24 kbps 24 kHz mono MP3 stream playback:

Both via the built-in speakers (unlike with the prev. test, where I utilized A2DP too) at moderate volume.

As can clearly be seen, AAC and MP3 playback consume approximately the same power AND the results are pretty similar to those published earlier. (Don�t forget that these are 2G results, not 3G ones! A 3G connection would have had about 600 mW more power usage.)

Thanks, great piece of work.

On the more general subject of Li-Ion battery care. We all know that they don't suffer from 'memory effect' and that they don't need to be drained regularly, indeed its bad for them.

I have seen in laptop manuals advice that the (Li-Ion) battery should be drained and fully recharged about once a month to keep the battery charge level meter accurate. Do you know if this advice would apply to mobile phones such as the N95? Or do they measure battery charge level completely differently?

andykn wrote:Thanks, great piece of work.

On the more general subject of Li-Ion battery care. We all know that they don't suffer from 'memory effect' and that they don't need to be drained regularly, indeed its bad for them.

I have seen in laptop manuals advice that the (Li-Ion) battery should be drained and fully recharged about once a month to keep the battery charge level meter accurate. Do you know if this advice would apply to mobile phones such as the N95? Or do they measure battery charge level completely differently?

I'm not entirely sure these notebook manuals are up-to-date. Many people (including even phone / notebook companies) still think batteries should be completely drained at least from time to time, as was the case with NiCd (and, to a lesser degree, NiMH) batteries. I think this is also a "leftover" from the Nickel (NiCd/NiMH) times and, IMHO, is no way a good practice today, in the Li-Ion world - not even with laptop batteries.

With Lithium-based batteries, if you regularly use them, you should make sure you always keep the device on the charger whenever possible. No "conditioning" (deep discharges) should take place. There're some numeric results showing this in effect with the Nokia N95: see http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2289&more=1&c=1&tb=1&pb=1

Regarding the charging test referenced above, there's one big flaw with the test:

The tester should have tested the durability of the batteries BEFORE the week of different charging regimes to ensure that they performed the same BEFORE the test.

The fact that they perform differently AFTER the test has no value if you do not know how they performed before.

It could be that the phone/battery showing the worst results after the test, was just as bad before!

BTW, in the meantime, I've been changing some mails with the devs of the app and it has turned out if you set sampling to 5s (from the default 0.25s) AND disable automatic screenshot making (set Options / Trigger / second tab / Screenshot trigger to "Manual only"😉, you'll indeed further reduce the (again, already pretty low) load Energy Profiler causes. With these settings, I've re-made some of my tests; for example, I've measured about 0.05W less power consumption with playing back MP3 content.

See my Symbian-related remarks and example shots at http://www.allaboutsymbian.com/forum//forum/thread/67595/ for some of these new tests.

Peter321 wrote:Regarding the charging test referenced above, there's one big flaw with the test:

The tester should have tested the durability of the batteries BEFORE the week of different charging regimes to ensure that they performed the same BEFORE the test.

The fact that they perform differently AFTER the test has no value if you do not know how they performed before.

It could be that the phone/battery showing the worst results after the test, was just as bad before!

Thanks for pointing this out; let's see what the original author answers.