I've been fighting for a few days with a really severe battery drain issue. After many reflashes, tests and curses, I tracked it down to the SIP client I was using (software itself didn't matter, it seemed like any SIP client - CSipSimple, SipDroid etc - was the same). I was - and am - running baadnewz v1.3 DHD ROM on a HTC Desire, the problem was there regardless of the ROM, kernel and radio. Without SIP running, but 3G on, my battery consumption was normal, in the range of 1-2% / h; with SIP over 3G, it went to 6-8% per hour, rendering the phone useless.
Then I read this article: http://code.google.com/p/sipdroid/wiki/NewStandbyTechnique and it all became much more clear.
Once I switched from the UDP to the TCP registration method, all went back to normal and battery drain is again in the range of 1-2% per hour.
Note this is valid for any SIP provider and software. I am using CSipSimple and some accounts from different SIP providers, connected via pbxes.org. Also note that not all SIP providers offer TCP auth. - in that case, either you switch to one which does or you connect via some "man-in-the-middle" service like pbxes.org or sipsorcery.net. Follow their guides for setting up the extensions, trunks and routes and then configure your SIP client of choice with the virtual PBX account. Again, don't forget to set the registration method to TCP - in CSipSimple, this is in the advanced account properties, field Transport.
airwave88 said:
I've been fighting for a few days with a really severe battery drain issue. After many reflashes, tests and curses, I tracked it down to the SIP client I was using (software itself didn't matter, it seemed like any SIP client - CSipSimple, SipDroid etc - was the same). I was - and am - running baadnewz v1.3 DHD ROM on a HTC Desire, the problem was there regardless of the ROM, kernel and radio. Without SIP running, but 3G on, my battery consumption was normal, in the range of 1-2% / h; with SIP over 3G, it went to 6-8% per hour, rendering the phone useless.
Then I read this article: http://code.google.com/p/sipdroid/wiki/NewStandbyTechnique and it all became much more clear.
Once I switched from the UDP to the TCP registration method, all went back to normal and battery drain is again in the range of 1-2% per hour.
Note this is valid for any SIP provider and software. I am using CSipSimple and some accounts from different SIP providers, connected via pbxes.org. Also note that not all SIP providers offer TCP auth. - in that case, either you switch to one which does or you connect via some "man-in-the-middle" service like pbxes.org or sipsorcery.net. Follow their guides for setting up the extensions, trunks and routes and then configure your SIP client of choice with the virtual PBX account. Again, don't forget to set the registration method to TCP - in CSipSimple, this is in the advanced account properties, field Transport.
Click to expand...
Click to collapse
Thanks for the information. I changed my pbxes.org connection to TCP but still have battery drain issues when it is registered (~150mA = ~12%/hr). I've also extended the keep-alive delay from 40 to 100. There was a very short window where the drain was around 30mA but it soon went back up to 150 and has not come down since. If I set cSipSimple to be available on for outgoing calls and disconnect it, drain is normal at 5-10mA until it reconnects.
Related
I have recenty been trialling a push email solution from Qore.
basically, I set up my email program (in my case outlook) to forward my emails to the T-Mobile email service. This service then sends me a text to indicate I have an email. The pusheffect program intercepts this text (there's no text indication etc) and then connects via GPRS to my T-mobile connection and downloads my email from my server.
works perfectly...EXCEPT, it doesn't close the GPRS connection afterwards.
so, my queston is how much (if any) data is transmitted while I'm connected via GPRS (little G with the two arrows) but not actually using it??
I don't want to find myself with a huge bill at the end of each month
Many thanks
According to GPRS data usage there should not be any data transmision if the connection is not used. No data - no traffic. If you want to be sure I would recomend GPRS Tweak (http://www.gb-soft.cz/XDAII/product_gprs_tweak_en.htm) soft that enables you to close the connection after predefined inactivity time. That should solve your problem.
perfect...that'll be the gadget to have then
many thanks
at least it would have been if it worked!!
set to close connection after 10 mins...left it for 20....still connected!!
looks like I'll just have to keep doing it manually
Sorry, I have been using it a short time only but been more interested in saving battery than the traffic. I'm on unlimited data tarrif so I keep the connection constantly (no major difference in power consumption).
Maybe the author has a solution?
P.S.
Did you try with the device switched off ?
The option implies that it's more the device that needs to be inactive than the connection.
I configured Sipgate using the built-in WM6.1 Sip client on CRC's 12.9 (naked-bs), which works fine on Three UK using the normal packet data connection.
Unfortunately the battery usage is horrible: about 20% in under an hour just to remain "Available" (forget making any calls!). Keeping an eye on the data icon suggests that there is traffic (keepalives?) every 15 seconds or so.
Is there any way to modify this keepalive timer? Even pushing it to 30 seconds would make a significant difference.
Cheers
Geoff
Hi
I'm trying to maximise my battery and have turned my attention to "Wi-Fi Sleep Policy" (under wireless networks / advanced). The option reads: "when to switch from Wi-Fi to mobile data"
There are three options (listed below). I wondered if someone could confirm exactly what function each option has.
To put the question into context, I'm on a limited mobile Data Plan (UK Vodafone - 500Mb per month) which is chargeable when exceeded. So it's important to me that when in range of trusted wi-fi sources (home / work) I using Wi-Fi rather than Mobile Data - i.e. when in wi-fi range, i'm using an uncapped data wi-fi connection for normal phone use and when the phone is idle where implicit data collection is invoked (auto sync of weather, facebook, gmail, etc).
So in summary i need to balance battery life by limiting drain (i.e. limit unnecessary wi-fi scanning when not connected to wi-fi network) and excessive mobile data usage (which costs £/$ when 500Mb is exceeded). I'm wondering which of the following Wi-Fi Policies will help me achieve this.
Available Wi-Fi Policy:
1. After 15 Minutes
2. Never When Plugged in
3. Never
Hope the question makes sense. Thanks!
Phone: Desire HD
ROM: CoreDroid 6.5 (LeeDroid 3.1.1 Kernel)
Radio: 12.54.60.25U_26.09.04.11_M2
OK, there have been plenty said about various devices having issues of random WIFI drops during good signal conditions.
I have learned long ago that there are some devices that do not play well with legacy Draft N routers and modems connecting to newer WIFI devices that have power save functions.
This issue is primarily with the advanced features within the Modem/Router WIFI features.
Here are the two features that can help with connection drop-offs.
DTIM Interval
Beacon Interval
If you set DTIM Interval to low, you risk flow condition drop-offs. Some people find a value set around 6 to be effective for both gaming and file transfer.
The lower the value the less power is consumed in the WIFI connection. Small devices with smaller batteries need a low value, like 1 to 2. If you have a good sized battery 6 to 8 will work well.
Beacon Interval will create a high level of repeated instances of beacon synchronization, if using WPA security. Which can augment the delay between data stream. If you find yourself in an area of about -80db and drops are noticeable, decreasing the time in between beacon intervals will not allow time to recover. Once authentication breaks, you will need to reset your devices WIFI enable to regain authentication. Changing the interval to 200 to 300 ms will help. But when your interval is set at 1000ms intervals, it will make your issues more problematic.
I keep my numbers one the edge much as possible, so peeps outside my house find connecting extremely difficult at -90db
Many have circumvented the above issues by using WEP or open authentication. Which is only a band aid fix.
Channel congestion can make drop-offs. As it slows your data path and can make extra authentication cycles during recovery.
Before making any changes copy down the original settings for restoring them if needed.
Some apps I am using for my WIFI connection.
WIFI Ace (WIFI Advanced Configuration Editor): Will attach to advanced WIFI hotspots, including none broadcasting SID.
WIFI Fixer: Automatically reconnects during any drop-offs, and will restore connections after sleep cycles.
Here is a fix for the crappy slow useless GPS on the ascend mate running 4.2.2 this may work on other Roms too!
you will need https://play.google.com/store/apps/details?id=com.chartcross.gpstest&hl=en_GB
1. Download the app topnt from here http://forum.xda-developers.com/showthread.php?t=2198319 and select settings as follows global -derek gordon- generic- google select install but do not reboot!
2 . open keypad dialler and dial *#*#2846579159#*#* then select 6 background setting, then 7 agps setting, then as follows
LOCATION METHOD= MOBILE STATION BASED
NETWORK USED= ENABLE A-GPS FOR LOCAL NETWORK
DATA CONNECTION .. DONT CHANGE THIS SETTING
SERVICE ADDRESS supl.google.com
service port 7275
Then exit and reboot and enjoy I get a fix in less than 8 seconds now!
MS-assisted mode
Assistance data sent to the mobile for every fix; the only hybrid mode
Has the greatest GPS sensitivity
Supports fall-back, backup position solution types, such as AFLT, thus maximum yield
A data call is needed for each fix
Fix computed by the PDE server
Best suited to applications requiring less frequent fixes, or maximum sensitivity:
Slower tracking applications
Fixes required in challenging locations
MS-based mode
Assistance data sent to the mobile periodically on an as-needed basis
Mobile measures GPS pseudoranges and makes position calculation
Uses only GPS satellites
Shortest latency between fixes enables rapid repetitive fixes for tracking and navigation
Only needs occasional data calls
Fix computed by the handset with occasional PDE server assistance
Best suited to handset-resident applications, particularly those requiring lots of fixes
Turn-by-turn navigation
Fast tracking applications/geofencing
Standalone or autonomous mode
No assistance data at all
Mobile performs all operations with no assistance at all
Increased Time to Fix and battery consumption
Diminished yield and accuracy
No data calls needed
Fix computed by the handset only
Best when out of wireless network coverage