As the subject asks, why does it drain the phone so much?
On my nokia symbian phone, it is connected to my asterisk box 24/7 over wifi and will last for days.
My galaxy nexus will drain out in hours if connected via wifi to my asterisk box.
The SIP qualifys are every 60 seconds.
Has anyone been able to get decent battery life for incoming SIP on ICS?
A somewhat related question I have; does anyone know of an app that will enable incoming SIP only when on wireless?
Thanks
It is because either the app or the build prop on the phone has the wifi scan rate up high. That means it needs to have a stable and solid connection so scanning for the wifi source more regularly ensures it doesn't drop a call or miss a message or what ever.
You can do one of a few things. You can freeze the app using Titanium backup and then unfreeze it when you need to use it and or you can drop the wifi scan rate from what it is now to a higher number i.e. 20 = 20 seconds (thats intervals between scans) and 180 is a large interval between scans. Above 180 and your starting to run the risk of having a call drop out on you if you are not on a solid wifi connection.
I am looking into a way of either modifying the default prop or possibly a script into adjusting the wifi scan rate to enable users to turn the scan rate down when not engaged in a wifi call and then turn it back up if they wish to (i.e. whilst on a wifi call or in a area of poor signal strength).
Related
Hi Guys, I have a Motorola Atrix and a small problem with the WLAN. (but i think its a Android problem)
The Wi-Fi Sleep Policy stands on “When screen turns off” to save Battery.
Now, when I unlock my phone it takes a lot of time until the Wi-Fi connection to a known AP is done. The time it takes until the connection is established, is related to the wifi.supplicant_scan_interval in the biuld.prop file.
In my Rom (Neutrino 2.6) it is set to 120 seconds. That means, when I wake up the phone and unlock, the phone turns on the Wi-Fi and then it waits 120 seconds till a Wi-Fi scan performs. After this scan, the phone knows that a known Wi-Fi is in range and the connection will be made.
But I have no desire to wait so long for connection.
Can someone make a script or something else that tells the phone to make a Wi-Fi scan when the device will be unlocked?
Or is there an other solution?
If you're rooted, you can use a root file explorer like Slide Explorer or Root Explorer in Play Store, navigate to /system, find build.prop there, open it with a text editor and change the wifi scan interval to a lesser value and save the new build.prop
Be aware that scanning for wifi too frequently will drain your battery faster.
Sent from my Desire HD using xda premium
This is exactly that, what I don't want.
I want a high scan intervall to have a low battery drain. But i want, that the phone do one scan after an unlock.
Can anyone let me meaning of enabled/disabled fast dormancy..Actually what use this fast dormancy and its workout???
There are literally dozens of threads about this but it may be hard to get the needed information since many clueless people spread misinformation about fd.
First of, fd has something to do with data network and is only relevant in 3G (including HSPA) networks.
2G (Gprs, Edge) do not have such a feature.
3G network use a very high frequency which directly means that they need more power per second than 2G but also have a higher throughput rate, making it's power/work ratio lower (=better) than 2G.
However there is an issue with this feature: even when not actually in usage it drains your battery far too quickly.
Now, noone might care if you were to tranfer data non-stop but mobile phones have a history of idling 99% of their life.
One might say "hey let's go back to 2G when there is little to no activity" but unfortunately that won't work since 3g and 2g (in fact all generations) are incompatible to each other which causes a brief interruption in connectivity and closes all open connections.
As a result the network engineers decided to opt for a technique they called fd and which basically turns off 3G.
Usually when a phone connects to a 3g network it has to run through a long, complicated and time-consuming handshake process in which it is attributed, amongst others, the IP adress. These details are all discarded when the connection is lost or cleanly disconnected.
(Note: changing antenna is not considered a lost connection but uses a special soft- or hard-failover protocol)
So if the phone was to just turn off the 3g it would not work but there needs to be a consentual agreement with the network antenna to keep the data in store and reserve the resources attributed with the phone.
Now we can turn 3g off and save battery, knowing that we can revive the connection anytime we havo to send data.
(Naturally if we keep the connction offline for some time the network will just assume we lost data connectivity and free the resources anyway)
However what about receiving data (most notably Google C2DM long-polling)?
To receive data we have to turn the 3g network on again (wake up from fd) and request any pending packets the network temporarely delayed for us. If data is present, the phone completely wakes up from fd, otherwise it will go straight back to fd.
The interval between 2 polls is provider-dependant and is roughly 5 to 30 seconds of sleep time.
In a nutshell
-fd delays incoming data by up to poll-interval seconds
-if the interval is too low, fd will not save power
- if the networ does not support fd, the battery drains faster thao with fd disabled
- fd usually saves a lot of battery
-fd causes a lag on the first outgoing byte of a transmission
Sent from my GT-I9300 using xda premium
d4fseeker said:
There are literally dozens of threads about this but it may be hard to get the needed information since many clueless people spread misinformation about fd.
First of, fd has something to do with data network and is only relevant in 3G (including HSPA) networks.
2G (Gprs, Edge) do not have such a feature.
3G network use a very high frequency which directly means that they need more power per second than 2G but also have a higher throughput rate, making it's power/work ratio lower (=better) than 2G.
However there is an issue with this feature: even when not actually in usage it drains your battery far too quickly.
Now, noone might care if you were to tranfer data non-stop but mobile phones have a history of idling 99% of their life.
One might say "hey let's go back to 2G when there is little to no activity" but unfortunately that won't work since 3g and 2g (in fact all generations) are incompatible to each other which causes a brief interruption in connectivity and closes all open connections.
As a result the network engineers decided to opt for a technique they called fd and which basically turns off 3G.
Usually when a phone connects to a 3g network it has to run through a long, complicated and time-consuming handshake process in which it is attributed, amongst others, the IP adress. These details are all discarded when the connection is lost or cleanly disconnected.
(Note: changing antenna is not considered a lost connection but uses a special soft- or hard-failover protocol)
So if the phone was to just turn off the 3g it would not work but there needs to be a consentual agreement with the network antenna to keep the data in store and reserve the resources attributed with the phone.
Now we can turn 3g off and save battery, knowing that we can revive the connection anytime we havo to send data.
(Naturally if we keep the connction offline for some time the network will just assume we lost data connectivity and free the resources anyway)
However what about receiving data (most notably Google C2DM long-polling)?
To receive data we have to turn the 3g network on again (wake up from fd) and request any pending packets the network temporarely delayed for us. If data is present, the phone completely wakes up from fd, otherwise it will go straight back to fd.
The interval between 2 polls is provider-dependant and is roughly 5 to 30 seconds of sleep time.
In a nutshell
-fd delays incoming data by up to poll-interval seconds
-if the interval is too low, fd will not save power
- if the networ does not support fd, the battery drains faster thao with fd disabled
- fd usually saves a lot of battery
-fd causes a lag on the first outgoing byte of a transmission
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
This was really helpful.
Thank you.
here goes a click on the Thanks button.
In order to receive real time Google Voice phone calls, I need to maintain an active internet connection. Everything I've read suggests that Wi-Fi is the most power efficient way to do this. However, my idle power consumption when using Wi-Fi is 2% per hour, vs 0.8% per hour on 2g (0.4%/hr when mobile data is off). Does anyone else have similar results, or is there something wrong with my set up?
I've noticed the watch doesn't seem to maintain wifi connectivity nor does cloud sync appear to work. As soon as I'm out of bluetooth range, the watch shows disconnected. I've re-entered the wifi password numerous times but it refuses to remain connected to it. Has anyone else experienced this? Any thoughts on how to resolve?
Have you checked your wifi timeout? I think the max is 180 minutes. Mine was disconnecting and then disabling it after timeout. I changed it to 180 and it's better, not perfect because it times out while i'm at work. Definitely improved when around my house.
Connected to a hotel WiFi network with my Pixel 6a, every few seconds/minutes, irregularly, the phone makes the default notification sound. After much f***ing around, I determined that it happens every time the hotel's generally fast but somewhat intermittent WiFi reconnects on the phone. It's one of those WiFi networks with a 'lobby ambassador' which intercepts connections and asks you to login, and thereafter it remembers the device MAC and does not intercept your device's communication attempts anymore.
Every time the phone reconnects to this network, which is frequent because apparently my room is a bit out at the edge of coverage, after the layer 1/2 negotiation for the phone to establish the link, the WiFi client on the phone briefly shows "authenticating", and then the connection is established (without user interaction) and immediately the phone emits the default notification sound. So my phone is irregularly and frequently chirping Android 13's default "popcorn" sound. It's super annoying.
I've looked at Settings -> Notifications -> Apps, show System -> Android System - it's not any of those. I turned off all Android System notifications and it still does this.
What is the actual notification class and specific notification type on (Android 13 on) the Pixel 6 series (I have a 6a) which causes the default notification sound to play every time WiFi (re)connects please, so I can turn off this torture without silencing the whole phone?
(My one last test, ongoing at present, was to change the hotel WiFi network Privacy configuration from "randomized MAC" to "device MAC"; I don't see why that should change anything, because it's my device that is audibly notifying me that it's (re)connected; the network to which it's (re)connecting is not a new network every time - for that I might expect a notification).
thanks,
You could temporarily enable Do Not Disturb with exceptions for your usual apps? Otherwise I'm not sure if there's a way to disable that. It'd make sense if your change from randomized -> device MAC fixed this, though, as the network should remember your device rather than make you log in again every time, but that's a big should that's not in your control.
Well, damnedest thing. Looks like turning off privacy/random-MAC mode for this WiFi stopped the notification. Doesn't make any sense at all, since my phone knows that the hotel WiFi is the same one to which it had connected before, even if the hotel WiFi might think my phone is new every few minutes...