What is *Cell standby* and how can I keep it from eating my battery?
Looking up my battery statistics, I almost always find Cell standby amongst the top consumers:
I never thought that "idle" would use so much energy. I saw that other people encounter similar problems:
Answers on those questions just give some raw ideas. I would like to know what exactly stands behind this, an whether there are ways to keep this "standby" from eating my battery?
These percentages should not be compared from one time to another; you should only use them as a guide to relative power consumption. Keep in mind that 100% of battery usage is not always the same. Just for an example, assume that cell standby consumes 10mw, the display 50mw, and other miscellaneous use consumes 40mw. In this case, your total use would be 100mw, and cell standby would be consuming 10%. If you turn the display off without changing anything else, cell standby would still be 10mw, but would show as 20%, since your total consumption is now just 50mw.
I'm aware of that, Tom. But my "usage pattern" is rawly comparable, and at least this gives an idea. I wish they would additionally provide absolute values here, though.
Some backgrounds as explained by ce4 on the question Does 'poor' reception deplete the battery quicker?:
The transceiver circuit is engineered with power saving in mind and will reduce sending power as much as possible if the reception is good. This also reduces the SAR value which is a measurement for exposure of the human body to radiation.
If the reception is bad sending signal strength has to be adjusted accordingly.
So that's what's really behind it: On poor reception, the device spends a lot of power to find a better/stronger signal (or any signal at all if lost). The following screenshot1 clearly shows those times, when you take a look at the bar titled Phone signal.
"The greener the cleaner": A bright green means "good reception" (the screenshot shows this at the begin and end, that is here: morning and evening -- so at home I have good reception). Getting yellowish: "Moderate reception". This uses more energy: compare it with the graph on top of it (not in the screenshot -- but the same as in the first screenshot), and you see the bar is almost flat where the cell signal is good -- but falls faster where it's not. See the little red spots: "no reception". And phone will power-up like crazy to find a new cell tower...
How to find out where the dead spots are?
I already showed in my answer on Does 'poor' reception deplete the battery quicker? how one can find out about those "Dead Zones" and where they are:
Apps like No Signal Alert2 and OpenSignalMaps3 monitor the cell signal in background, and record those areas, so they can show you a map of where the dead zones were. OpenSignalMaps has the plus of showing you all cell towers in reach, pointing out which you are connected to. It also offers you a "compass" giving the direction to the strongest signal.
However, my answer on how to automatically deal with those dead zones was not that detailed. So I played around a bit with different solutions -- and here's what I've found out:
How to automatically deal with those dead zones to save energy?
Apps to automatize Airplane Mode
I've reached fairly good results with two apps: Autopilot4 and NoBars Battery Saver5. Both monitor the cell signal and, when it drops to far, switch to Airplane Mode for a predefined time. The user can define how long that would be. After that timeout, Airplane Mode gets disabled, and cell monitoring takes over.
In the second graph of my question, this shows up as "gaps" in the Phone Signal bar: As the cell radio was disabled during Airplane Mode, no colors are shown; the system didn't know anything about signal strength in this time frame. And with the cell radio turned off, it also didn't use additional power (more precisely, it didn't use any power for this radio then) -- which was exactly what was intended.
With Autopilot, the only annoying side-effect was: For each signal check, it flashed on the display for about a second. Aside from that, it gives more options to be configured by the user. However, as the results of both apps where absolutely comparable, those extra options seem not really necessary, while being nice to have. Another plus of Autopilot is the log provided to the user: This way you can see the exact times of mode switches.
Apps to handle data network
I've also tested ShutUpBatterySaver6, which aims to handle the data traffic. Dropping below a certain signal strength the user can define, it disables AutoSync, and below a second definable level switches off mobile internet altogether.
It does, however, never activate (or deactivate) Airplane Mode, so the power used to get a (better) signal will still be the same. Though, with a bad signal data transfer uses more power than with a good signal, as e.g. package loss might be bigger. In the status bar I saw several times that it had AutoSync disabled7, so it seems to work. Not being a heavy data user (as the LBE stats in the same screenshot show), I could however not really tell how much help that brought: Compared to the two Airplane-Mode handling apps above, results in terms of gained battery duration were minimal (if any).
It would probably gain best results to join the two approaches. As I was not in the mood to check all possible combinations, I rather decided for the allmighty 6-letter-solution: T-A-S-K-E-R.
As most of you probably know, Tasker is the automation solution on Android. Guess it could even prepare coffee, if our devices had sensors to detect coffee and water. So I created some profiles for this great app -- and results were magnific!
So basically it's 3 Profiles, communicating via a common variable:
- %SIGSTATE < 1: check if the signal falls below ~25%. If so, disable mobile data, set %SIGSTATE to 1.
- %SIGSTATE < 2: check if the signal falls below ~15%. If so, switch to airplane mode, set %SIGSTATE to 2.
- %SIGSTATE > 0: wait for 5 min, then disable airplane mode, activate mobile data, wait another 15 sec (for the signal to be restored), set %SIGSTATE to 0.
In my global Init profile (which gets executed when Tasker starts monitoring), %SIGSTATE is set to 0 (if it is unset). All 3 above profiles additionally set notifications, as the screenshot above shows9. Each state maintains one notification (which gets replaced when the same state re-occurs), the most up-to-date state is always on the bottom.
Results seemed even better than with the two airplane-mode handling apps above, but that might also be due to slightly different signal conditions. So it should at least be comparable. Using one of these 3 solutions, I came home after about 11 hours with about 20% more charge left then without applying any of them.
Having said this, I will end this answer showing the Tasker profiles I created, so you might use them with your Tasker installation:
- Variable -> Variable Set: %SIGSTATE = 0
- Net -> Mobile Data: Off
- Variable -> Variable Set: %SIGSTATE = 1
- Alert -> Notify Vibrate: Title "IzzySignal"; Text: "Signal Low; Mobile data disabled (Signal: %CELLSIG)"
- Variable -> Variable Set: %WLANSTATE = 0
- Variable -> Variable Set: %WLANSTATE = 1 IF %Wifi ~ on
- Net -> Airplane Mode: On
- Net -> Wifi: On IF %WLANSTATE ~ 1
- Variable -> Variable Set: %SIGSTATE = 2
- Alert -> Notify Vibrate: Title "IzzySignal", Text: "Signal Lost; Entering Airplane Mode"
- Task -> Wait: 5 Minutes
- Net -> Airplane Mode: Off
- Task -> Wait: 15 Seconds
(give the device some time to find a new signal!)
- Net -> Mobile Data: On IF %ROAM ~ Off
(prevent bad surprise when returning from vacation abroad!)
- Variable -> Variable Set: %SIGSTATE = 0
- Alert -> Notify Vibrate: Title "IzzySignal", Text "Signal On; Airplane Mode disabled (Signal: %CELLSIG)"
Now for the profiles:
- State -> Variable -> Variable Value: Name "%SIGSTATE", Op "Math: Less Than", Value "1"
- State -> Phone -> Signal Strength: From 0 To 2
- State -> Tasker -> Profile Active: "SigLost", [x] Invert
(make sure to avoid a conflict: %SIGSTATE~0 && SignalStrength~1 would match both profiles condition)
- Task: SigLow
- State -> Variable -> Variable Value: Name "%SIGSTATE", Op "Math: Less Than", Value "2"
- State -> Phone -> Signal Strength: From 0 To 1
- Task: SigLost
- State -> Variable -> Variable Value: Name "%SIGSTATE", Op "Math: Greater Than", Value "0"
- Task: SigReturn
- Event -> Tasker -> Monitor Start
- Task: InitVars
Now that's just the basic concept, and can be extended with e.g. playing sounds, vibrating, flashing the display, and more. But the energy saving stuff is already in -- and does its job as described. Hope this can help you as well!
Another remark: At least with GSM (I cannot tell for CDMA), returning from Airplane Mode by default forces you to enter the SIM PIN. This can of course be switched off -- but in that case this additional protection is also gone when switching on the phone. No idea why this is not possible selectively, as it was with my pre-Android phones.
However, for some phones there's an alternative to some items in above tasks, which remove this limitation:
- In SigLost, instead of Net -> Airplane Mode: On use Phone -> Radio: Off if your phone supports this (my Droid2/Milestone2 does not, unfortunately). If you can do this, the WiFi check becomes obsolete (and your Task cleaner).
- The counter-reaction in SigReturn then also needs to be changed: Instead of Net -> Airplane Mode: Off, use Phone -> Radio: On.
Please let me know in the comments if this removes the limitation of the SIM PIN, as I cannot test it (my device does not support it, as described above).
Edit by t0mm13b
The interesting thing I noticed was that there was multiple tasker icons appearing on the Status bar, which made things confusing as to regards the state that the tasker profiles was running as; I discovered that by setting the Title for the 'Notify Vibrate' in each of the above tasks to be the same, the net result is, one singular notification titled 'IzzyTasker' shows up, with the appropriate message used instead.
Thank you! Took me about a week to collect all the statistics, test all the solutions, plus separating the good ones from the, hm, not so good ones ;)
Hehe -- thanks @t0mm13b for the update. Hint: The current state is always the "last one" (farther down than the others). So with different titles you get a little "log" added. But interesting discovery that the *title* is what makes a notification get replaced -- thanks for that!
This happens even when reception is good, though, it's not due to reception problems.
Awesome research, thanks for sharing! I'm setting up a llama profile similar to your tasker setup. Do you know what would be a good threshold value for weak and no signal? Afaik -113dbm counts as no signal, but what about weak signal strength?
As *Tasker* does not deal with dbm values directly, I didn't dig into those very deep. You could observe it for a while (or monitor it with e.g. RF Signal Tracker) to find suitable values. From my monitoring with that app, I agree to -113dbm meaning "out", no useful signal then. So you could start with -110=SigLost, -100=SigLow, better=OK – and from there play with the values until you're satisfied. I'd appreciate to read your results (values) here then :)
The magical value seems to be -105dbm. Everything above is represented by 2 bars signal strength, -105dbm and everything below is one bar or less. This holds true for a Samsung Galaxy S2 i9100.
I don't understand "On poor reception, the device spends a lot of power to find a better/stronger signal (or any signal at all if lost)." How does it use energy finding a better signal? I can imagine it scans frequencies, listening for a strong one, but unless it transmits, I don't see how that takes much more power than sitting on one frequency, listening. If it transmits...why? Is it to get a handshake? Wouldn't it be better if masts transmitted heartbeats very frequently so that phones could tell immediately if they had a good signal from one?
@Poldie, a receiver requires energy. If it already sits on a fine connection, it doesn't need to check for others. If it needs to, it must check whether "the other cell" is usable, if it can "get a lock" to the other tower (or gets refused, as it e.g. belongs to a different carrier). For that it also must transmit, of course. It might need to scan additional frequencies as well (2G/3G/LTE, each with different bands) instead of just sticking to the one it has a connection to. For a detailed technological description of this Android independent part, I cannot give an answer (I'm no engineer).
@wizlog Lollipop wasn't installed on the cell towers, and neither changed the GSM/UMTS/LTE protocols – so I assume the topic remains relevant. I don't have an LP device here (and no corresponding test environment or the time to run such a test) to see whether LP handles this more efficiently, but it certainly cannot do anything to signal quality (only react on it).