Using a Samsung 2A travel adapter with adaptive fast charging with MotoG : How does it behave? part 2 : more data

Materials and Methods
Trying to keep things objective

See Part one for for the tools used and limitations inherent to the method used.
A few precisions :

• legend used in graphs:
  • Power-In (W) --> Power used by the samsung AC adapter
  • Power-Out (W) --> Approximated power delivered by the AC adapter
  • Out-disp (mA) --> Current displayed by Ampere App = Current received by the battery
  • Offset : +250mA (= Current used by the device idle, screen ON drain, wifi ON)
  • Offset (WifiOFF) : +160mA (= Current used by the device idle, screen ON drain, wifi OFF)
  • Out-real (mA) --> Current delivered by the AC adapter (out-disp + offset)
  • pm8226 T° (C) --> Temperature of pm8226_tz probe. (MotoG and MotoG 4G/LTE aka Falcon and Peregrine)
  • pm8110 T° (C) --> Temperature of pm8110_tz probe. (MotoE aka Condor)
  • Battery T° (C) --> Temperature given by battery probe
• ...

Charging and Time
Monitoring battery charge and Current over time

Charging curve is pretty common with a linear charge until 60% and then the rate starts decreasing. Nothing special there.
Charging Current follows the same behavior, showing that the power regulator of the MotoG does its job correctly limiting charging current to safe levels.

Charging and Temperature
Monitoring pm8226 and pm8110 Temperatures and respective charging current over Battery charge

Before showing any graph, we should keep in mind that results are highly inconsistent, T° is directly related to the way device is really idle or not, things can vary from 46 to 57°C!
I had a peak T° of 57°C when using Youtube, twitter and a few services running while charging. Though this peak T° is quickly going down to 52°C and then stabilize at about 50°C back to idle state

Do not use your device for moderate to intensive tasks while charging it (with high power charger) or it will fry!

Concerning OFFline charging, i had no way to monitor, but power used by the AC adapter is still between 7.9 and 8.7W (like ONline charging. the Screen T° felt (the pm8226 module is behind the center of the screen) is as warm as online charging when pm8226 was at about 48°C; obviously a felt T° is not objective.

We can see that the adapter provides a fairly stable current (most variations might due to measurements inaccuracies.) until 60% of charge, then it drops (expected.). Though the power management module that is pm8226 is extremely HOT (50+°C!!) --> Why is that?

• Doesn't it have an overheat protection? i'd love to investigate this...
• Is the AC adapter output too powerful for it? No, as we see, the module is able to limit current in the end of charge so it should do it at any time.
• Is the maximum Current accepted by the device to high for it? Motorola specifies the device to be able to charge with up to 1500mA, 1300 doesn't blow it up! I'm looking on a way to force a limitation to 1000mA and see if there are any improvements in T°

IMPORTANT : work hold on at this stage, i might continue it later. this article is published not to forget the already done part.

CM12.1 : A few Drawbacks

I'm using CyanogenMod ROMs since the very beginning (started with a fork of CM6 called MiniCM6 by XDA Recognized Developer nobodyAtall).

Every CM version since then had more and more features, less and less bugs: the Sony-Ericsson X10mini (e10i, aka Robyn) started with the 'well-known' "SDcard safe to remove" reboot bug that crashed the device twice a day in the early miniCM6 ages...,
CM12.1 on Falcon (Motorola MotoG, XT1032) is far from this, a lot more mature, but still lacks a few things

CM12.1
Some lacking Features and some issues

Here is a list of a few things that bothers me in CM12.1. Don't take it wrong, CM12.1 is nice and works pretty well, the following list is only a few "cosmetic" issues, user-experience related.

• Expanded Desktop
  • Sometimes the nav bar doesn't show up when swiping up. (It needs to swipe down to display notifications, and then, nav bar shows up)
  • On some specific apps the nav bar is "ghost" meaning that once displayed (after swiping up) touching return buttons behaves as if the user had touched the content behind [like an ad........])
• "Per App" Expanded desktop
  • Enabled for all is nice,
  • Per app settings is nice, -when "Enabled for all" is un-checked-
  • BUT why can't we make per app customisation, when "Enabled for All" is checked? that would help when the user wants the expanded desktop to be enabled for NEARLY all apps, but keeping a few apps with both nav and status bar.
• 'The random Black Screen' with AmbientDisplay (with wave to wake, an pocket mode enabled)
  • In some rare cases, getting a notification wakes the device, but screen goes black (the only way to "fix" is force rebooting the device). Still no way to reproduce found yet,
• LiveDisplay : Automatic settings
  • Automatic settings only work when location is enabled. A great addition would be to set time of start and time of end of 'night-mode' as whe can do with F.lux or RedShift for users that don't keep location enabled all-the-time.
• LMK, is that really an issue?

Feel free to comment below, and i will update this article with your own feelings about the lacking features and the issues that bother you in CM12.1 (don't forget to tell your device if the issue is specific to a branch

For those complaining about Battery Life, don't forget to read this article ;-)

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)

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

CPU Freq and Performances : Single and Multi Thread

Linpack Benchmarking for Moto G, Single and Multi-Threads...

Before we compare Moto G and E Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz), let's see how the Moto G performs with ONDEMAND governor and increasing CPU Clock.

MFLOPS and CPU Clock speed On Moto G XT1032 aka Falcon, CM11

A MotoG XT1032, running CM11-20141124-NIGHTLY has been used for MFLOPS per MHz tests.

The CPU is downclocked at 787MHz, and then frequency is raised up to nominal Frequency that is 1190MHz. Here are Single and Multi-Thread MFLOPS results.

You can note that 998MHz had inconsistent results due to high standard deviation...

MFLOPS/MHz A closer look to the results

Multi-thread results raise quicker than Single Thread, let's explore this closer :

As we can see, 

• MFLOPS/MHz ratio does not increase much for Single Thread, but,
• For Multi-thread the ratio increases between 787 and 998MHz but then stagnates : This means that MFLOPS increases in a linear way as Frequency is raised.

This can be explained by the following fact : 

The OS needs some CPU cycles to stay ON, so under a certain frequency it conflicts with Linpack work and decreases performances more than expected.

Conclusion? As a conclusion, we can say that CPU clock increase is more effective on multi-threaded applications (in a quite linear manner) than on Single threaded ones.

Moto E and Moto G : 2 White LEDs

After my articles about the "Two LEDs" discovered on MotoE (and suspected on MotoG) i received a lot of questions about them : 

• Are there really Two LEDs there??
• Are they really White and not RGB "mis-configured"?

So i made non-destructive tests using a microscope on Moto E:

For some reason, MotoE LED hole is transparent and we can see through it (that's not the case for MotoG)

2 LEDs The proof that MotoE has 2 LEDs

Here is a picture taken at x100 of the notification LED ON (triggered through /sys/class/leds/white since the brighter one was too bright to allow me to take a pic of it lighten up with my set up)

Each "yellow" rectangle is a LED chip (you can see the two wires on the left one)

This is proof there is two LEDs, i was able to light them both using the following : 

echo 255 >/sys/class/leds/charging/brightness #to light the left and brighter one
echo 255 >/sys/class/leds/white/brightness #to light the one on the right

White LEDs The proof that Moto E has white only LEDs

On the above picture, you can see a closer view of the LED: its inner components and something interesting :

• there are 2 wires: this should correspond to +/- (proof of Single color LED)

[source : Wikipedia]

• The light emitted is white (that could be RGB set to 255:255:255) BUT, there is a Blue shift (the blue luminescence you can see around the center of the LED) which  corresponds to a Blue LED with a phosphor substract coated on it giving the White light.

[source : Wikipedia]

We now know that Moto E has 2 LEDs and that they are White only, 
I cannot prove it for motoG until complete teardown (the LED hole does not allow to see through it and observe the LEDs) but there are good chances that it also has 2 white LEDs regarding the behavior in previous tests.


Make sure you read these articles to understand how this started :

MotoG play with the LED

MotoE play with the LED

Moto G : Play with the LED

Moto G has a White-only notification LED (as actual Knowledge, might be proved wrong later on... ==> proof has been given since then)

I miss the RGB led of my X10 mini, and the charging LED notification

We can't override the LED color since it turned out that the LED is White and not RGB, but we can play with the triggers :

in /sys/class/leds/, we can find the following folders (that are symlinks):

• charging/
• lcd-backlight/
• led:flash_0/
• led:flash_torch/
• rgb/
• torch-light/
• white/
• wled:backlight/

For a start, let's play with /sys/class/leds/charging/:

• brightness
• device/
• max_brightness
• power/
• subsystem/
• trigger
• uevent

Brightness Is that LED dimmable?

adb shell

su

echo 255 /sys/class/leds/charging/brightness

• Using /sys/class/leds/charging/brightness this LED only takes two states: 0 and 255 (in fact 0 and != 0)
• Using /sys/class/leds/white/brightness the LED can be set to any value between 0 and 255 (but it is overridden if a notification comes and the value is set bat to 0...

Triggers Testing and setting the triggers

What are the triggers available ?

catching values :

cat /sys/class/leds/charging/trigger

output:

[none] bkl-trigger usb-online flash0_trigger torch_trigger mmc0 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid bms-online 

The ones we know the use :

• [none] (default, LED does nothing)
• blk-trigger (used by ./wled:backlight/trigger)
• usb-online (lights up when USB connected)
• flash0_trigger (used by ./led:flash_0/trigger)
• torch_trigger (used by ./led:flash_torch/trigger)
• mmc0 (I/O triggered, lights when mmc0 is in use)
• battery-charging-or-full (full time ON LED when charging or charged)
• battery-charging (full time ON LED when charging)
• battery-full (full time ON LED when charged)
• battery-charging-blink-full-solid (blinks until charged)

To get Blinking during charging :

echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger

making sure it worked:

cat /sys/class/leds/charging/trigger

Output:

none bkl-trigger usb-online flash0_trigger torch_trigger mmc0 battery-charging-or-full battery-charging battery-full [battery-charging-blink-full-solid] bms-online 

Since */charging/brightness does not dimm LED, the LED stays at full power.

Comments Some Strange behaviors :

During test i was able to show that using /sys/class/leds/charging/trigger overrides any other trigger (if a notification comes, then it won't change the pattern) in fact i recently found that MotoG has 2 LEDs and that they can be lighten up the same way it works for MotoE :

• /sys/class/leds/charging/trigger → first LED, can be set to on/blinking while charging, although at full brightness.
•  /sys/class/leds/white/trigger → second LED, can be dimmed, but the LED turns back off when a notification comes in.

Though using /sys/class/leds/white/brightness allows to use 0~255 values to dimm the LED it is overridden by any incoming notification that set brightness back to 0. ==> Cannot be used as battery blinking notification.

For now, the best way is to set "first" LED (/sys/class/leds/charging/) for charging using dedicated trigger and keeping the "second" one to none (and used as notification LED as it is by default) and get both working together this way.
What we need is to find a way to dim the "first" LED

Got the idea to play with LED thanks to carock @XDA

Orzly Premium Tempered Glass : Screen Protector

Orzly Premium Tempered Glass : 

Screen Protector for Moto G (Falcon/Peregrine)

Ordered two screen protectors (one for my Falcon, and one for a Peregrine : same Screen, so same Protector)

Features (as claimed on the box) Oleophobic Coating (Orzly Tempered Glass Screen Protectors have an oleophobic coating, this hels prevent fingerprints and other contaminants as well as making it easy to clean). Whole Transparency (The silicone adhesive surface ensures there are no gaps between the screen protector and your screen. This helps to ensure the clarity of your screen is not reduced). 8-9H Surface Hardness (Stronger than PET film screen protectors). 0.24mm thickness (Made from chemically treated, transparent tempered glass, the screen protector is only 0.24mm thick, making it ultra thin and light). Sensitive Touch (Highly responsive with your device's touch screen). Shatter Proof (If shattered, the screen protector breaks into small pieces that do not have sharp edges. This makes them safe to use).

What's in the Box? Tempered Glass Protector Alcohol cleaning cloth (wet) Cleaning cloth (dry) Applicator card Dust remover stickers (x2) How-to After opening the main box :  Alcohol cloth, dry cloth and small applicator card, paper box In the paper box (click to enlarge the pictures and read the How-to) : Tempered Glasse Screen Protector, 2 stickers, How-to

How to apply? Go somewhere there is NO dust (a wet atmosphere is recommended, since dust won't fly freely ==> i didn't applied in this conditions, consequently, some dust came in the process (see below) Remove the previous screen protector used if any Use  the alcohol cloth to clean the screen surface Dry the screen with the microfibre (dry) cloth Use Dust removing stickers to eliminate any residual dust Pull back the plastic layer (labelled "(1) Please peel off this mask BEFORE application) Carefully position the screen protector onto the device's screen. Make sure to align correctly the speaker cut out with the screen's one. /!\ at this time, any single piece of dust hanging around in the room will come simply to take your work down /!\ Press down gently at the center of the screen so that the protector's adhesive will spread (mostly no need to press much, positioning on the screen will start spreading) Use the applicator card to push out the edges (it is said that small bubbles will disappear in 1~2 days ... we'll see...  Clean the Screen Protector and enjoy :D

Result? Looks as if there were nothing on the screen ... But i failed somewhat and a little piece of dust got stuck (creating the small bubbles on the bottom right of the pic, near power button):       Edit : looks like the bubbles are slowly vanishing (silicone layer in action) ... only little light deviation/diffraction due to the very small piece of dust stuck, but it is now so small that only an attentive look allows to see it, no impact on user experience anymore.

Pros & cons Pros :  Won't get scratched easily as a PET (plastic) film would be Better screen protection than PET film? Better transparency than PET film (and should not get yellowish with time passing) User cannot say if there is a protector or not by finger feeling If well applied, user cannot say there is something on the screen (by sight) regarding package : it is great to have a good looking package AND all accessories needed to perform the application. Cons : Will break on shock where a PET screen would get slightly deformed but resist. Fingerprints will stick despite Oleophobic coating (not more than with PET film though)  Expensive (got it for 10€ when a PET film costs 1) ==> But worth the price! Thickness is low, but it was nearly too thick to correctly cohabit with my protection case, make sure your case will accept this extra thickness before purchasing! NB : Application is quite tricky, as much as it is to correctly apply PET film, simply different : so no way to compare both on this side.

Xposed and Moto G (2)

Xposed & Moto G

Here are a few Xposed modules i currently use on my device [XT1032] (in addition to CM11) : 

Simply click on the links to get more about these modules

• Acdisplay by AChep (Apps' additional module)
• AcitvityForceNewTask by GermainZ
• CrappaLinks by GermainZ
• Identiconizer! by GermainZ (Apps' additional module)
• PlayPermissionsExposed by GermainZ
• CpuTemp in Statusbar by m11kkaa
• Greenify by oasisfeng (Apps' additional module)
• Unbounce by cryptyk
• MagnetOff by dubidu (disabled atm, but i enable it when needed)
• Play Store Fixes by rovo89 (disabled)
• XForceEnter by CNexus (disabled)

For another device i had to set up [XT1039, MotoG LTE] for 'standard End-User' in addition to Motorola Stock ROM : 

• Acdisplay by AChep (Apps' additional module)
• Greenify by oasisfeng (Apps' additional module)
• GravityBox [KK] by C3C076
• APM+ by kennethso168
• Unbounce by cryptyk