Jump to content

Recommended Posts

Guest JT_daniel
Posted
One here - nothing suspicious for me (see previous post), I keep on using FW (Pro v1.0.8) with all ROMs and see the difference - it shouldn't be this widget... Or might be that with 2.3 it is not working properly?

I'm on 2.2, Totyasrác. I'm currently on GEN 1 Swedish Spring RLS 5. How often do you sync the weather? I keep it at 2 hours normally, which isn't that bad. But even during its non-syncing time, it appears to be using CPU, which I don't know why!

Guest Grain
Posted
There is no such thing as a 100% charge on Android. That'd probably be the first thing I'd mention about battery life. There's what Android thinks is 100%, and there is the reality, which can often be significantly less than 100%. For evidence of this charge the phone to 100% over USB with it switched on. Now switch it off with the cable still connected. The indicator light will always turn red, and it may actually charge for a significant period of time before turning green. So, did the phone just lose a bunch of battery power from shutting down, or is what Android thinks is 100% less than what the phone's hardware thinks?

I'd be surprised if Android controlled the charging process. That would be a safety risk. What if Android crashed/hung and the battery stayed in charging mode? I smell burning Blades.

Probably the charging circuit retriggers if you switch off the Blade. It'll charge a bit until some timer says "ok, now look at the voltage" or something. LiIon charging is a slightly complicated matter.

Simple tests like these (which everyone can easily reproduce) tell you not to trust everything Android tells you about the battery. All the testing I did, when CM7 had its initial battery issues, showed me that Android's battery measurements aren't much use for gauging battery usage over shorter periods of usage either

Yes, definitively true.

When the indicator light turns green on the first phone pull the battery. Wait for the second to reach green. When it does plug the other phones battery back in. Now, in theory, both are working from a fairly equal charge.

Doesn't matter. The battery indicator doesn't measure some absolute value but uses a kind of dead reckoning for estimating battery status.

See FAQ: How to troubleshoot high battery drain?

Guest Matthew Ferguson
Posted
OK, some clarity required regarding what is commonly called "Battery Life". Before getting in to detail, it is worth reminding you that Smartphones are designed with large screens, fast processors and masses of connectivity. Which means they will use more power than an old Nokia flip-phone. This is something you need to get your head around.

So, what actually uses power in your Blade? And why should the ROM you use have little effect on battery life?

The Processor (aka CPU).

In this application, the CPU uses more power when the frequency it is running at increases. The higher the frequency, the faster the CPU processes instructions, in simple terms. In the case of the Qualcomm MSM7227 ARM6 CPU in the Blade, the specified maximum CPU frequency is 600MHz. So, if the CPU is running at 600MHz, it uses the most power. Reducing the operating frequency reduces the power consumption, almost linearly. The CPU in the Blade has a minimum operating speed due to the internal watchdog, but the value is not generally known as the MSM7227 is under NDA. To this end, the known safe minimum speed used is 122.88MHz. So, if we can ensure that when the processor is doing very little, such as just "listening" for SMS or phone calls, it is operating at this (theoretical) minimum speed, we will use the least power. How do we ensure that? The Linux kernel has a number of "scaling governors" coded in that allow the CPU (in any hardware, not just phones) to change operating speed according to the current load, scaling governor type and settings. The Blade ROMs generally default to the "ondemand" governor set to vary the CPU operating frequency from 245MHz to 600MHz, depending on load. The ondemand governor will increase the CPU frequency quickly when the load exceeds 90% (in the Blade ROMs) and reduce it as the load decreases. (I set the minimum CPU frequency to 122MHz for an even lower low-load power consumption). I'm not going in to the behaviour of all the other governors here, nor the settings available, but clearly any ROM or app that prevents the CPU from reducing its operating clock frequency will use more power and the battery will discharge faster. This is partly ROM dependant - particularly if the scaling governor is not set correctly

The Display

2 types of display exist on the Blade. TFT (aka LCD) and OLED. Both have their merits and demerits and personal preference will come in to play in terms of appearance, colour rendering and so on. That aside, and back to facts, the Display is a significant power user. In basic terms, irrespective of the technology, the brighter the display, the more power it uses. The power consumption of the TFT display is wholly dependent on the LED backlights, the display itself uses almost nothing. The OLED display is an active display, so it emits light itself without the need for backlights, but still uses more power when brighter. Contrary to popular belief, the TFT display is capable of being brighter, and darker than the OLED, and can also consume less power when fully dimmed. It is also not commonly understood that the OLED display consumes more power when displaying white/light colours then blacks/dark colours. The TFT displayed colour matters not one bit in terms of power consumption. So, the dimmer the display of either type, the lower the battery consumption. OLED displays tend to consume more power than their TFT equivalents, brightness for brightness. This is not ROM dependant as such - only if the ROM uses lousy autobrightness control

Poor code

Unless the kernel and lib files have been seriously knifed, the code should run without issue. Problems only usually occur when code tends to "poll" devices too frequently rather than rely on interrupts to kick them in to action. This should not occur in mainstream ROMs. This is not (mainstream) ROM dependant.

The GPU

The Graphics chip consumes power depending on how much work it's doing. 3D work, video and Live Wallpapers take their toll. Heh, just like Windows Aero or Linux Compiz. Turn Hardware acceleration off too. Pointless. This is partly ROM dependant

Radios - Telephony

The Blade, like most other Smartphones, has a number of Radio functions. Those concerned with telephony include the GSM/GPRS and UMTS (3G/3G+) devices in the phone. So every SMS, Voice Call or Data transfer uses the Telephony Radio devices in the phone. What is worth understanding is that in areas of weak carrier signals, the phone will increase its RF power output in order to eatablish and maintain a link. This really does increase the battery consumption, and goes some way to explain why, as you travel around, the battery consumption appears to vary considerably. It is usually better from a battery life perpective to switch to an alternative signal type if possible, even at the expense of speed. This is not ROM dependant as such.

Radios - Bluetooth

Bluetooth in the Blade is rather primative. Bluetooth should be turned off when not required as it will increase the drain on the battery by an amount that is not ROM dependant.

Radios - WiFi

WiFi, like Telephony Radio, will vary its radiated RF power dependent on the signal strength from the AP to which it is connected. WiFi is a significant battery drain when in use, and users are advised to 1) switch Network Notification off and 2) ensure that WiFi is set to switch off with the display. That way, WiFi can be left "On" and will not use any power at all until the phone is running and reconnects. WiFi battery use is not ROM dependant as such.

Radios - GPS

The GPS receiver in the Blade comsumes power, but is not massive. It is OK to leave it enabled - it is only used when required. This is not ROM dependant.

Radios - FM Radio

The Blade has an integral FM band radio receiver. This is fine, except it tends to prevent the phone from sleeping, and has a tendency to continue to run when the user believes it is "closed". I have come across several user problems where the FM Radio is the sole cause of battery discharge. This is not ROM dependant.

Audio volume/haptic feedback.

These have a very minor effect on power use and can be disregarded in the grand scheme. These are not ROM dependant.

Drivers/Lib Files/Modules

Poorly coded or buggy lib files and/or fudged hardware modules (.ko) can cause incorrect hardware operation and enable devices that should not be enabled, thus consuming your Li-Ion atoms. Shouldn't happen with mainstream ROMs or derivatives. Not ROM dependant as such...

So, what we have seen so far is - the ROM you choose is fairly unlikely to have a significant effect on your battery life... unless the ROM is known to have serious bugs (CM7, for instance)

ROM dependant

The CPU clock frequency has a major effect on battery life, so if the ROM (or your settings if you have CPU governor access) overclocks the CPU or prevents it from reducing to a low frequency, then battery life will suffer.

The display needs to be illuminated - no ROM can avoid that, so one ROM to another will not affect battery life in this way. If you use autobrightness, one ROM may have good control and another may not. As anyone who has used my remixes will know, I have modified the autobrightness behaviour every time. The stock behaviour is not good enough on any count.

User dependant

Turning radios off when not in use will save battery, but that gets away from the point of a phone, or indeed a Smartphone. It is better to limit the amount of syncing or increase the syncing period to retain the Smartphone aspect of the Blade. If you receive dozens of GMails every hour, expect the battery to drop...

Summary

If you are experiencing what you perceive to be high battery consumption on a new ROM, consider this:

  • Are you using a ROM that is Alpha, Beta, Experimental or in Test or known to misbehave? Expect issues.
  • You must ensure that the ROM install was 101% clean and you wiped the Battery Stats in CWM
  • You need to use the phone normally and charge/use over a couple of days at least to settle the battery stats
  • You need to ensure that you have not missed any settings that affect the display brightness or its ability to turn off
  • You need to ensure that you have not missed any settings that affect the CPU frequency, if accessible
  • You need to ensure that you do not use HW acceleration or AHB overclocking
  • You need to ensure that you have not missed any settings that affect the phone's ability to sleep
  • You need to ensure that you have not missed any settings that cause WiFi not to turn off with the display
  • You need to ensure that you have not added any apps that prevent the phone from sleeping completely
  • You understand how and when to use Spare Parts to determine with accuracy what has been using you battery
  • Try noting the battery level, go to full airplane mode, leave phone for a few hours, check battery. Same? Kernel behaving.
  • Watch the FM Radio app...

You should refrain from complaining based on your own subjective view after just a few hours use... please. It helps no-one.

You should also avoid ROMs that are in test... unless you are happy to report your findings in a constructive way and have an objective view.

I hope that clarifies a few things and gives you something thought-provoking. I can elaborate as required... if anything is unclear.

I notice a lot of this says "shouldn't be ROM dependant" not isn't. We've all noticed differences between ROMs, and we all know certain ROMs out there are running on builds of stock ROMs ZTE has updated - JJ and FLB, for instance, suggesting that the OEM changed something to improve them, possibly for battery life?

Guest ThrashMan
Posted

Was it REALLY necessary to quote the whole of LanceH's post? :unsure: :)

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.