Battery Life: the Unexpected Extinction (OR how we lost it)

Since the very beginning of Android everyone has been talking about Battery Life... and how bad it is; but why that much hate?

Let's investigate:

For the following, i had only based the research on the devices i owned/used:

• Sony Ericsson Z530i
• Xperia X10mini (E10i)
• Motorola Moto G (XT1032/XT1039)
• Motorola Moto E (XT1022)

Impacting points But... What are the culprits??

Here are some, but i'm sure there are many more things that impact battery life.

Hardware:

• Device global power and Screen size/technology vs battery size
• Antenna quality and network coverage

Software:

• Firmware: Kernel, ROM... (implementation, and optimization regarding hardware)
• background services (viber, facebook, google services [location seeking, google fit, google wear, ...], ...)

User:

• User habits
• ...

There are lots of variables in the equation so we cannot "benchmark" them as we do for performances; the following won't give answers, but more questions that anybody should ask themselves when talking about battery life.
A good study would need known and fixed variables to investigate on one specific variable, with negative and positive controls, triplicates, and statistics to show significant differences. But we have none.

Hardware Power, Screen Size/tech, Battery Size...

We have 4 (5) devices from 3 generations:

• The "old phone"
• The early smartphone (The e10i was shipped with android 1.6 donut!) and
• The current gen entry/middle class smartphones (XT1022-XT1032-XT1039)

The oldest features a 128*160px screen for a 900mAh battery and could handle more than a week and a half without the need of a charge (up to 2 weeks with moderate usage)
The X10mini features a 240*320px screen for a 950mAh battery and could only stay on for about 24hrs-48hrs
The MotoG: 720*1280px for 2070mAh (24-48hrs)

The MotoE: 540*960px for 1980mAh (48-72hrs, and up to a week with fair usage)

Here is chart about battery capacity (mAh) and screen surface (px) coefficients between my first phone (Z530i) and the newer devices:

device	length	width	surface (px)	battery (mAh)
Z530i	160	128	20480	900	surface increase	battery increase
E10i	320	240	76800	950	3,75	1,06
XT1022	960	540	518400	1980	25,31	2,20
XT1032	1280	720	921600	2070	45,00	2,30

Z530i --> XT1032 : 2.3x battery capacity increase, but a 45x wider screen!!
Luckily, battery life had not been decrease by 20! (only by 7~14)

Screen technology also plays a role in power consumption: 
A standard TFT/IPS screen uses a whole backlight that is either ON or OFF (+ brightness levels) meaning similar power used regardless the displayed content.
On the opposite, AMOLED based screens don't have any: these screens features LEDs for each pixel that are completely OFF when a screen part is black meaning NO power used at all!
The previously named devices are all using TFT/IPS based screen though.

CPU and GPU are not much relevant (regarding clock since MHz/W has been increased a lot making newer devices a lot more efficient); this point would need a whole in depth article, so we won't study this much now.

Antenna quality has a lot to do with battery life, the better the antenna, the better the life: the device would need less power to get same signal, saving some more juice.

Network Coverage isn't directly linked to hardware (since it is not relateed to the device itself, --in fact yes if we consider the bands handled by the device and the ones provided by the MNO--)

Software Hardware isn't the only one

Implementation and optimization:
A well optimized software for a specific hardware can move mountains, as easily as a bad one will sink in the deep see...
That's easy to show for benchmarks (see my comparison between stock and CM11 on MotoG and impact on MFLOPS), but hard for battery life (too many other un-fixable variables).

All we can say here is that a process that needs more CPU cycles to perform an action will keep it awake longer, thus resulting in more power consumption and a shorter battery life.

Background services:
Google IS Evil, yes, their services are running in the background at any time and everywhere. Most of them won't be used by the end user, but f***k it, they are alive!
"- i'm looking at you location seeking, google fit, google wear, google search,..."

Facebook (app and messenger), Viber, ... All these apps use some services to keep refreshing for potential notification, calls, pokes...

What can we do?
Seek for wakelocks using Wakelock Detector,
Hibernate apps you don't use with Greenify,
Ask in the Forums for some advice

User habits 99% of bugs are between screen and chair

Who said the device was all culpable?

Look at yourself, what are you doing with your device right now? maybe reading this article from you phone/phablet? Playing all day long? Answering emails? Checking twitter/facebook/whatever? Browsing 9gag?

Didn't you changed your usage of the so called 'smart'-phone? are you doing the same as you were on your old 'not-that-dumb'-phone?

Wacom Intuos CTL-480 and Linux Mint 17.1

I recently purchased a Wacom Intuos Pen CTL-480, that i'm now using exclusively with Linux (mostly Linux Mint 17.1 x64 Cinnamon and Xfce edition)

This won't be an unboxing as there are many on the Internet. One observation though, i was pretty surprised that the wireless kit is 100% embedded in the tablet once plugged in it :

After the cover is placed back: everything is totally invisible. Well done Wacom! (when i purchased it i wasn't sure it would be that much stealth and feared it would make an hideous extension on the back)

Let's talk software: 

On Linux Mint 17.1 Cinnamon ==> Plug&Play (mostly)

Only thing missing : the four buttons on the tab are mapped by default, but cannot be reset using that utility. 

Playing with xev and xinput might be necessary.

MyPaint and GIMP perfectly handle the tab.

Major issue with battery status of the wireless kit:

Here is one of my very firsts paintings (using MyPaint and its marvelous brushes):

a few screenshots of steps to draw a baby dragon :

Quick Review: Hybrid Armor for Moto G : ageing

With time going on, things are ageing and a lot more when daily used. Here is the result of day to day use of a Cheap "Heavy Duty" case:

My first article about that case was written on June 17th 2014.

At that time it was brand new :

Wear and Tear Cosmmetic ageing

Time made its duty since then:

Coating is wearing a lot, not only in the angles, but also where some scratches were made:

Contrary to the "3 months later" post, the coating isn't simply getting scratches but even ripping off! 

Device protection Mechanical properties

Despite the bad cosmetic state after those 7 months of intensive usage, the mechanical properties of both rubber and hard plastic are still like on first day: providing an excellent protection to the device.

5$, 7 months (until now, but it may still last for quite a longer time) : for about 70 cents/month, it saved my device from a deadly crash a few times! It might not be pretty, but that's not what i asked it for.

CT406 : proximity and light sensor on MotoG

The CT406 module is both an Ambient Light Sensor (ALS) and a proximity sensor.

There are not much documentation on this product so here is what i understood from my research:

the above picture is a macro-picture of the ALS/prox sensor of my MotoG (MotoE has exact same module, but on the left side of the screen)

• On the left we can see a InfraRed LED (near IR range since we can see a little reddish light in the dark, but my camera catches part of IR spectrum and displays some kind of purple)
• In the middle there is a black spacer.
• On the right this looks like to be the sensor itself (from here, we know that the sensor is only an ALS that works as proximity sensor when coupled to an external IR-LED)

Here is the TAOS TSL277x chip that seems to be the base of the CT406.
TAOS (Texas Advanced Optoelectronic Solutions) brand is now known as ams.

Superposing my picture and that artwork: Pretty identical, right?

The pins are arranged this way (scheme is rotated 90° right compared to my picture):

How does the proximity sensor works? IR reflection...

The IR-LED emits Red-InfraRed lights and the right part detects if it is reflected or not (reflected == near; non-reflected == far)

To test this, it would be nice to use an external IR-LED and hide the embedded one to see if the sensor still say "far" when under IR light and "near" when IR light is turned OFF.

On our devices, the ALS sensor can only response a "high/low" output, but without the glass panel (that filter some IR) and a reworked program it could be used as presence detection (longuer range) [Source]

How does the ALS sensor works? Wide range light detection, IR detection, and human sight.

The chip features 2 photodiodes (one responds to wide range light: ch0; the other only gets IR: ch1)

In the above diagram we see ch0 respond to light from 300 (near UV) to about 1000nm (IR)
Humans see light from 390nm to 700nm (about, this means from deep-blue/ultra-violet to deep red/infrared), 

Humans don't see IR, therefore, light emitted from 700 to 1000nm produces a response from the light sensor (ch0) but Humans are actually in the dark, that would scale up light intensity of the device screen for no "human understandable reason".

That's what the IR sensor (ch1) is used for: the chip calculates something like ch0-ch1= actual human visible light intensity. Actually this is more complicated than this [Source, page 8&9]
The ALS operations have for duty to calculate what a real human would see (so, a spectrum without IR) in order to light the screen at the right human friendly level.

Luxmeter ALS outputs Lux that are then used by the device

The ch0 could give directly the light intensity with no real calculation if the system was open (no glass, whatsoever), and if there were no IR sensor. [See more page 10]

Real Life How does it work inside the MotoG?

Basically, the CT406 contains the following components :

• a sensor that is made of 2 photodiodes, one is wide range and reacts to human visible spectrum + IR; the second one reacts to IR only.
• an Infrared Light Emitting Diode (IR-LED)

The light sensor "reacts" to visible spectrum by using the signal coming from the wide range photodiode minus the IR one.

The proximity sensor is basically the IR photodiode reacting to IR light emitted by the IR-LED and reflected by a near surface.

The module speaks to the device using i2c protocol.


Proximity sensor has two states : 

• near (what the devices call "3cm") and 
• far (what the device calls "100cm")

The ALS has the following working range: 

• 2 lux (the light intensity is lower than sensor threshold)
• 65535 lux (fully saturated)

"The device can saturate if the light is brighter than can be accumulated with the light−to−frequency conversion. The full scale value for saturation will depend upon the integration time programmed into the device. In saturation, the device accumulates 1024 counts for each 2.72 ms of integration time programmed. For each ATIME programmed, the maximum count (saturation level) is the lesser of (1024 * (256 − ATIME)) or 65,535."


This explains a few things about why the screen is not at the intended brightness level.

• If the light isn't a wide range one; like a "white LED" which is actually a blue led with phosphor coating == the blue shift will saturate the sensor despite the "real" (== human felt) brightness is much lower.
• If the light is PWM controlled == is being lighten ON/OFF at high frequency to get desired "global" intensity : it would saturate the sensor  regarding sampling.
• if the light is a fluorescent light (same as for PWM controlled ones)

CM12 and MotoG

First overview Tip and Tricks

Here are some things i found after playing a little with CM12-20150108 Nightly :


How to get root ?

1. Enable Dev settings (multiple tap on "Build Number" in /settings/about phone/)
2. Go to Dev settings
3. Root access : Change to Apps and ADB

How to get Terminal app back?

It is now disabled by default, simple enable it in Dev Settings by toggling "Local Terminal"

That's all for today folks!

This blog might be totally reworked in the coming months but i don't have much time at the moment...

MotoG : Pure CPU Benchmarks, the limits

To point out pure CPU Benchmark flaws, we'll observe how does a moto G (Falcon or Peregrine, this has no relevance) behaves with Linpack Benchmark when running on Stock 4.4.4 Motorola ROM or CM11-20141124-nightly (4.4.4).

We have seen previously that Linpack didn't use all cores and was limited to 3 threads in multi-thread benchmarking (when comparing s200 and s400 SoC).

Now, we will compare MFLOPS performance between two ROMs that has similar user experience (smoothness mostly)

Stock 4.4.4 Motorola ROM vs CM11

both @1190MHz, Interactive governor.

Stock Motorola features a nearly doubled score for both Single and Multi-Thread, but does that mean it is really better optimized?

• In a way, yes, CM11 is made to be compatible with most devices, so we encounter similar problem seen with Windows against iOS : 
• An OS that fits all against a fully optimized one made for a few specific hardware. Motorola obviously optimized their software to get the best of this great device
• If you compare with the MotoG vs MotoE test, you'll see that the MotoG running CM11 has lower results than MotoE running stock ROM ...

• On the other hand, that's not all a matter of optimization :
• CM11 features KSM, zRAM, and many things that use CPU cycles to compress memory (zRAM) or merging merge-able things (KSM) ==> this reduces CPU pure performance but increase multi-tasking ability.
• The war of versatility and customization against slickness and stability...
• Honestly i can't see difference in user-felt performances...

Actually, i don't see any issues by using CM11 as a daily driver on my XT1032 (Falcon), it is not because a Benchmark say something that it is true in "real life"...

• Don't use CM11 on Moto G if you want to show off with high CPU benchmark results ...
• Stock Motorola ROM is close enough to AOSP to be acceptable as daily driver
• Xposed helps you to get the best of stock ROM
• CM11 is great for end-user customization

The real conclusion is the following :

Don't trust Benchmarks as incontestable truth, they helps to compare devices and  ROMs, but never really tell you how good devices/ROMs are.

Moto G and Moto E : snapdragon 400 vs 200

Snapdragon 400 vs Snapdragon 200 based on msm8926/8226 vs msm8610

After we studied MFLOPS per MHz ...

It is now time to compare MotoE and MotoG:

Moto G and E features a Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz)

Note that previous benchmarks were performed with ONDEMAND governor on CyangenMod11 ROM, but stock Moto ROM uses Interactive by default (i didn't expected that...) so the following has been made with interactive for both devices (needed to re-bench MotoG >_<)

to check above results are applicable despite governor modification : 

MFLOPS per governor on MotoG (Falcon, CM11) @1190MHz

No significant difference between ONDEMAND and Interactive governors for the specified test.

Moto G (Peregrine) vs Moto E (Condor) msm8926 vs msm8610

To improve accuracy, instead of using my Falcon (XT1032) running CM11, we will compare results obtained on a Peregrine (XT1039) running Stock Motorola ROM :

Both Benchmarks have been run on Motorola Stock 4.4.4 ROM on Moto G (Peregrine) and Moto E (Condor):

There is no differences between msm8226 (Falcon) and msm8926 (Peregrine) despite LTE capability of msm8926, that's why we will use a Peregrine for the following part.

MotoG (Peregrine) vs MotoE (Condor) @1190MHz, stock 4.4.4

We have quite similar results on Single Thread application for one simple reason, the number of cores does not have any impact. Since the clock speed is the same, the results are the one expected.

On Multi-thread the difference is quite huge between the quad-core and the dual-core, though we don't see a x2 ratio by doubling the cores number.

MFLOPS divided per the amount of cores

x/4 for msm8926 and x/2 for msm8610, Single Thread as control.

We should have observed a similar result between Single and Multi/nbCore...
Is the msm8926 really shitty at multithreading? i don't think so, looks more like if linpack or the system only uses 3 Threads...

If we apply a corrective divider (3 instead of 4) the results are perfect :

MFLOPS divided per the amount of threads used

x/3 for msm8926 and x/2 for msm8610, Single Thread as control.

Moto E (Condor) and Moto G (Peregrine or Falcon) should have similar performance in single threaded applications.

Though the 4 Cores may no be used at their full potential in some apps, multi-threaded applications should be better handled by the msm8926/8226 featured by moto G.

Moto G? or Moto E? Which one for What...

For moderate usage, Moto E is quite enough compared to Moto G : 

• It is not weaker on Single Threaded applications
• It has a smaller battery but both smaller CPU and half size Screen in pixels (960*540 vs 1280*720) will give it a great battery life.

Moto G is still the best quality/price in its category (prefer the Peregrine version and not the Moto G 2014 aka Titan)

• Multi-threaded applications will obviously run better on it
• The better Screen density improves user experience on long term usage
• A far better Camera...

A complete Moto G - Moto E versus is available on versus.com (note that Moto G Peregrine does not have 16GB of internal memory ... but only 8, and an SDcard slot.)