REVIEW & TIPS: extending the battery life on the N95 (and WinMob); acbTaskMan vs Energy Profiler

It was almost two years ago that I’ve published an article in the paper version of Smartphone & Pocket PC Magazine on increasing the battery life on Windows Mobile devices. (Note that, should you be interested in the whole series of similar tips and later (again, Windows Mobile-only) articles, this article is only one of the several. See for example THIS blog category for some more.) Now that I’ve, thanks to "Beck" from the sprites & bites blog, become a proud owner of a N95, I thought I would write an article on how you can do the same on the Nokia. (A shameless plug: I heartily recommend the sprites & bites blog if you're interested in desktop console gaming (currently, it officially discusses the MS Xbox 360, the Nintendo Wii and the PS3))

I not only shed lights on the secrets of extending the battery life of the N95, but also scrutinize how the just-released V20 firmware version behaves and review the brand new Nokia Energy Profiler (runnable on all S60v3 FP1 models) too. Finally, while doing the latter, I’ll also compare Energy Profiler to acbTaskMan, the, currently, best Windows Mobile profiling tool to do the same. By this, I help both Windows Mobile and Symbian users and developers, most importantly, those of acbTaskMan and Energy Profiler, respectively. All this in order to make their products even better – after all, both these apps have unmatched features and goodies not available in the other. Let me point out, for example, that in my previous combined WinMo & Symbian review of Palringo was also much more useful for Windows Mobile users than a single-operating system review because, as was noticed, the Symbian version of the same program supported a rudimentary logging (history), as opposed to the Windows Mobile version. Emphasizing this and, consequently, pushing the developer to implement the same on Windows Mobile is very important. These two-operating system reviews are, therefore, very useful in this respect. Tw… many birds with one stone, yeah :)

1.1 Target audience

As with some of my later articles (see for example my Palringo review as another example), I publish exactly the same article for both Windows Mobile and Symbian (more closely, Nokia N95) users. The article can be appealing for both types of audience for the following reasons:

  1. while the case studies (and the battery life tests) have been run on the Nokia N95-1 (with the latest, v20 firmware version), the results can be easily generalized for Windows Mobile. An example of this is the 3G vs. pre-3G power consumption I’ve dedicated several articles to (see for example THIS and THIS). Now, Windows Mobile users can also see it’s true what I’ve stated: it’s always preferable to shut down unused, stalling data connections whenever possible (particularly if they’re 3G) and it’s preferable to be connected to a pre-3G network than to a 3G one if you don’t (currently) need the special features (UMTS / HSPA data, video phoning etc.) of the latter. The numeric results (which, again, are almost exactly the same on Windows Mobile devices) clearly show I was right. This is one of the reasons Windows Mobile users should read this article / check out the results.
  2. still as far as Windows Mobile users are concerned, users of acbTaskMan will want to pay special attention to the chapters explaining the differences between Nokia’s solution to that of acbTaskMan. Nokia’s app has several advantages over acbTaskMan which, hopefully, will also be introduced in the latter. After all, acbTaskMan is the de facto system meter tool used by most Windows Mobile fans, hackers, programmers and reviewers. Finally, I also provide some new information on acbTaskMan itself; for example, I thoroughly elaborate on the excellent logging capabilities of the latter versions. I still haven’t done this because when I reviewed the program, it still had no logging support.
  3. if you’re a Nokia N95 user, you will find answers to a lot of questions. And, hopefully, you won’t be angry with me because I also refer to Windows Mobile. It’s far easier for me to maintain only one copy of my article than two entirely different versions, one meant for Symbian users (not mentioning WinMo at all) and one for Windows Mobile users (eliminating strictly N95-related and, to Windows Mobile, not applicable contents). Even the size of this article is pretty much prohibitive when it comes to making two different derivative subversions of it, let alone the additional work needed to synchronize the updates upon subsequent enhancements (which I frequently do to my previously published articles).

1.1.1 Why this can be important?

Benchmarking applications or the operating system / the hardware, as a tech writer, leading blogger and Best Software Awards 2007 Manager for Smartphone & Pocket PC Magazine, has always been very important for me. If you take a look at my past (and future) articles, you see I’ve always paid special attention to battery life. I’ve always recommended apps that consume the least power. An example of these articles is Everything you will ever need to know about the power consumption of Pocket PC audio players. It lists the power consumption of each and every Windows Mobile multimedia player. This isn’t without reason: selecting the right setting, the right app can result in really extended battery life.

As an end user, you may also want to strive for finding the apps and settings resulting in the best possible battery life. Therefore, you’ll also welcome an app and tips that does exactly this.

1.1.2 The (Symbian) history of system metrics apps

On Symbian S60v3rd, so far, there haven’t been comparable utilities – that is, an app that does show the current power usage of your handset. There was only one utility,’s CPU Monitor 1.10 for Series60 3rd, which I’ve found absolutely useless when assessing battery usage. The sole reason for this is that, it seems, the CPU usage figures it provides have (almost) nothing to do with the real battery drain. For example, when you play back MP3’s using the wired headset (with moderate sound volume), it displays 3% CPU usage – and it does exactly the same when using A2DP. However, if you do use A2DP, the battery life will be severely degraded, compared to the case of using the wired factory headphones – or, even the case of the built-in, great stereo speakers of the N95 (unless you listen to music at the greatest possible volume on the latter).

This is diametrically opposed to the case of Windows Mobile, where you can easily estimate the battery life degradation caused by, for example, enabling A2DP. There, the CPU usage figure acbTaskMan, used in the CPU usage mode, presents can reliably be used to estimate battery life. Note that you can also make acbTaskMan display the current battery drain (if it’s compatible with the given handset in this mode – it isn’t with several TI OMAP-based models like the Wizard); then, it becomes pretty similar to the (only) mode Energy Profiler offers.

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:

  1. MP3 and WMA (see next subsection) playback (using the wired factory headphones at 70%)
  2. The same via A2DP
  3. 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

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:

  1. Energy Profiler is unable to monitor CPU usage, only battery usage / temperature; this also means you can’t track individual processes
  2. 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.

3.2 Pros:

  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.

  2. 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.

  3. 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.

  4. 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.)
  5. Much more frequent updates without a noticeable increase in CPU usage – acbTaskMan is definitely worse in this respect (because of operating system restrictions)
  6. 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.

  7. 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.)
  8. Has an excellent box plot / histogram mode, which acbTaskMan completely lacks. Two screenshots:

  9. 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.
  10. 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.

  11. 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.

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:

  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
  2. 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
  3. 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)

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!

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:

  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).

  2. 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)
  3. 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.
  4. 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.)
  5. 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.

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.)

UPDATE (12/10/2007): 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 HERE for some of these new tests.

Don't have specific, numeric results; however, when my N95 is always connected (not actively transferring anything - just connected), 3G pretty quickly chews thru the battery. GSM (EDGE) not that fast.

Syndicate content