Database Info

[KERNEL] data streaming/VOIP in standby, wifi module for HTC's OTA 2.6.35.10 kernel

Edit 31/07/2011
Updated diff files for gingerbread kernels (HTC and AOSP), and a module for the more recent HTC kernel (2.6.35.10-g308ba26) can be found later in the thread Here.
The current issue...
Note: This isn't related to the sleep mode wifi disconnections caused by MAC addresses that don't begin 00, so far as i'm aware that's been patched for a while now. Wifi remains connected fine in standby mode, but the throughput is only suitable for very light traffic.
Since compiling the cifs module for the HTC official 2.2 kernel on monday i hit a pretty massive problem when listening to music over wifi from a network share - when the screen enters standby, bandwidth drops massively, well below 100kbps. This makes music you're playing from a cifs share over wifi stutter and cut out and basically become pointless.
A little googling and searching these forums i came to find this has been a fairly massive bugbear of the nexus one and htc desire? Any kind of normal bandwidth streaming over wifi is practically useless once that screen goes into standby. Ditto for high speed transfer of large files.
That means difficult VOIP calls, and no internet radio at a decent bitrate, or cifs access to your music library.
Finding a solution...
As luck would have it, the HTC Incredible 2.6.32.15 source code was released on tuesday, and as it's basically the non-GSM variant of the Desire, i was fairly certain the HTC customised bcm4329 source code was the same as the Desire's, and it seems like it is. So armed with HTC's customised bcm4329 module sourcecode and the output of dmesg when the phone was in various states, i had a poke around.
First of all i tried editing the DTIM update interval, so the phone would wait fewer beacons to collect incoming packets while the wifi was in sleep mode, and this improved the situation, barely. In the end i just locked out the phone's deepest wifi sleep mode, PM_MAX, in favour of PM_FAST, the low power mode for wifi used when the screen is active but the phone is relying on the battery alone (There is a third mode, PM_OFF, used when the phone is powered by a usb connection, but as the name implies, all power management is disabled by it, so forget that one).
PM_MAX appears to have a very fixed latency depending upon the DTIM update interval (300ms with DTIM as the default 3), and severely limited bandwidth. PM_FAST appears to be a listen mode or active rx mode, with latency scaling to the bandwidth used. An initial ping at idle will be up to 1000ms (or even no reply) before steadying at 100-300ms. During light streaming it's more of a steady 50-70ms, and during a file transfer it's a very low 5ms. So it looks like PM_FAST keeps the wifi receiver powered up to some extent, and only powers up the transmitter when needed.
You can guess the edit i've made: Essentially my new kernel module tells the phone to keep wifi in low power mode when the screen is switched off, rather than in a full sleep mode.
Just give me the damn kernel module...
Downloads are attached to the bottom of this post.
Files are unsigned, and install with clockworkmod recovery's 'Install zip from sd card' option.
Your wifi driver must match your phone's kernel version. To check your kernel version go to Settings - About Phone - Software Information and look at Kernel version.
Files including _N_ in the name have wifi mode N support for HTC kernels (non HTC kernel versions should include mode N by default).
If you don't see a version of the module that matches your kernel version, post a request in this thread.
The results..
Well obviously now the wifi bandwidth when the screen sleeps is the same as when the screen is active, so streaming data during sleep mode is perfect, wonderful even! However, i was a little concerned with the effect on battery usage when the connection is alive but fully or partially idle.
So i just did some practical testing. Note i'm connected using 802.11g, my router doesn't support mode n, and my signal is a less than ideal -80dBm so i'm probably using a little extra power.
With the original HTC wifi module, my phone lost about 1% charge an hour with wifi permanently enabled, push gmail enabled, and sync for weather and contacts every 15 minutes.
With the new wifi module, and the same conditions (wifi always on, gmail push, sync 15 mins), i lose around 1% an hour still. Excellent, no difference.
60 minutes of 200kbit VBR mp3 playback through the speaker with the screen off used about 8% of my battery.
60 minutes of 800kbit FLAC playback through the speaker with the screen off used up 10% of my battery.
volume was set at roughly 75% for both tests.
I didn't do any testing with the earphones, but i suspect they'd be marginally lower on the power usage.
To conclude, from my brief testing this afternoon i couldn't discern a difference in battery usage when the wifi connection is left on but mostly idle, and when data is streaming it doesn't eat the entire battery charge in minutes.
Note to ROM authors
Any rom authors using 2.6.32.15 who would like to include this module in their rom, you're quite welcome to. You don't need to credit me either, although it would be nice.

This looks like it could be interesting, but I downloaded and tried to install the b/g/n version and Clockwork spits it out, aborting it as a bad zip.
Anyone else succeed in applying this mod?

Quist said:
This looks like it could be interesting, but I downloaded and tried to install the b/g/n version and Clockwork spits it out, aborting it as a bad zip.
Anyone else succeed in applying this mod?
Click to expand...
Click to collapse
Disable sign check?

xmoo said:
Disable sign check?
Click to expand...
Click to collapse
Signature check was disabled. I'm running an unsigned version of Paul's v8 WIP rom (lightning fast by the way).
Anyway, double checked and manually toggled the sign check on and off again, still same results:
Can't open...
(bad)
Installation aborted.

I just downloaded the b/g/n file and rebooted to clockworkmod and it applied without error.
Possibly you have a bad download? does the zip file open on your computer?
I'd recommend you download again, open the zip on your pc to check it downloaded properly, then copy it to your phone. Let me know how you get on.
Edit:
Just reuploaded without the signature (and erroneous boot.img stuffed in each zip by Kitchen), i downloaded and installed both versions to be sure they work. Links are updated in first post.

Works great.
I use "Twonky Server" to view pictures on my TV and the connection was lost as soon as the phone went to sleep mode. No problem now!
Thanks.

Anymore information about g or n mode?
Im still unsure if it would be good to enable n mode... there were some reports about significant higher battery drain.
Can someone compare the g and n versions running on a stock-near rom?
Thanks in advance!

Myshkinbob said:
I just downloaded the b/g/n file and rebooted to clockworkmod and it applied without error.
Possibly you have a bad download? does the zip file open on your computer?
I'd recommend you download again, open the zip on your pc to check it downloaded properly, then copy it to your phone. Let me know how you get on.
Edit:
Just reuploaded without the signature (and erroneous boot.img stuffed in each zip by Kitchen), i downloaded and installed both versions to be sure they work. Links are updated in first post.
Click to expand...
Click to collapse
Before you re-uploaded it, I noticed that when I downloaded it directly to the phone, it was clipping it at 47 kb (both the standard browser and Dolphin). Apparently Rapidshare is doing something strange through the phone browsers.
Anyway, it worked fine even before you re-uploaded. Good one!
Now I just have to figure out why I keep dropping the wifi connection after a while (didn't do that before).

May I ask you such you are using to have those incredible values for battery?
1% with WiFi and Sync (over 3g?)is a dream for me !
Thanks.
Sent from my HTC Desire using XDA App

sjauquet said:
May I ask you such you are using to have those incredible values for battery?
1% with WiFi and Sync (over 3g?)is a dream for me !
Thanks.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
The wifi signal is only -80dBm, but barely used at idle. My cell signal is amazing though (the cell tower is 100 yards from my flat), and i run the phone in 2G mode with no mobile data. My sync is done over the wifi, not the cell network.

Nice. This is exactly what I want.
Have you looked at 2.6.34.1 kernel by the way? It is the one that most AOSP ROMs in this forum build on and I do not think I have met the latency problems with those ROMs.

tested and works great my friend

A bit more info on the battery usage in this wifi power mode...
I've been out all day and took my other phone, i left the Desire on the desk, 2G 5 bar signal, wifi always on, sync enabled for gmail and weather. Battery was charged to 100 then unplugged.
After 16 hours, battery is at 93, and battery usage breaks down to:
cell standby: 34%
wifi: 33%
phone idle: 33%
That's roughly 2.5% battery usage over 16 hours, from an idling wifi always on connection just doing 15 minute syncs all day, on a fairly poor -80dBm wireless-g network.
I think it's safe to say the power usage differences are negligable compared to the stock wifi module.
Regarding the 2.6.34.2 kernels, i'm not entirely sure if i'd look at them, since they don't include HTC's own kernel changes, i'm a little wary of them working properly with all the features. Part of it is i like the sense-ui too, it seems responsive, and i'm not lacking for free ram, so i'm not sure why people dislike it so much?

I just tried to reproduce the initial effect with the original WiFi module and some music streams. Switching off the screen actually sets my ROM into powersave mode at 245MHz only. Still, I did get smooth streaming without any problems.
Is there any good way to recreate and test this issue? I simply seem not to have it.
Thanks!

I don't suppose this will work on 2.6.34 kernels, will it? I'm trying to find a fix for OpenDesire (CM6 based)...

bemymonkey said:
I don't suppose this will work on 2.6.34 kernels, will it? I'm trying to find a fix for OpenDesire (CM6 based)...
Click to expand...
Click to collapse
I'm afraid not, since the module kernel version has to match the running kernel version.
The HTC roms also use a modified wifi driver with some of their own custom code added for VoIP and a few other things, so i'm not entirely sure the sleep functions are the same in the stock bcm4329 (wifi chipset) driver.
I'll check out the opendesire kernel source and post a patch file to apply to the source if it's possible though.

Myshkinbob said:
I'll check out the opendesire kernel source and post a patch file to apply to the source if it's possible though.
Click to expand...
Click to collapse
That would be AWESOME. Might as well patch Cyanogenmod as you're at it, as all the other AOSP ROMs (including OpenDesire) will receive those changes down the line
I should warn you though: My request has already been met with resistance... some people seem to think that this is actually the way WiFi should work in standby (i.e. it should be connected, but shouldn't actually be able to do anything ). Is a toggle setting (between PSP and CAM) in any way possible?

I thought about a toggle when i first made the patch, but then i'd have to learn to add a /proc interface to the driver to do that. I'm far from a kernel guru, and hadn't touched kernel code in years till i got my Desire last month.
I had trouble locating the new git for opendesire, the old one appears to be closed. So i got hold of the teamdesire 2.6.34.5 CM6 source instead, i expect the two are identical or very close to being so.
While i was looking for the opendesire kernel source git in the rom thread, i noticed the hostility toward altering the wifi power management mode, but at least for the HTC-modified driver it's not a problem. I leave my wifi connected whenever i'm at home, and my results for overnight standby are hard to tell apart. I lose between 5-8% battery over 12 hours of standby depending on txts and pushed emails received.
Here's a patch for the CM6 stock bcm4329 driver. It's power management code is a little different to the HTC-written driver, but it should work fine. I don't really want to wipe my phone to test it on opendesire, so one thing you'll want to test is standby battery usage. I get 6-8mA standby according to CurrentWidget.
To apply it, cd into <kernel source root dir>/drivers/net/wireless/ and copy the .diff there, then do
Code:
patch -p0 < bcm4329_pmfast.diff
then it just needs a make modules with the crosscompile toolchain etc.
Let me know how you get on.

Myshkinbob said:
Here's a patch for the CM6 stock bcm4329 driver. It's power management code is a little different to the HTC-written driver, but it should work fine. I don't really want to wipe my phone to test it on opendesire, so one thing you'll want to test is standby battery usage. I get 6-8mA standby according to CurrentWidget.
To apply it, cd into <kernel source root dir>/drivers/net/wireless/ and copy the .diff there, then do
Code:
patch -p0 < bcm4329_pmfast.diff
then it just needs a make modules with the crosscompile toolchain etc.
Let me know how you get on.
Click to expand...
Click to collapse
I guess I didn't read your previous post carefully enough - thought you were talking about just posting a patch in the form of an update.zip, or a replacement driver file to push via ADB in Recovery...
I think this is a bit over my head . You may not be a kernel guru, but you're talking to an average Windows user here
Let's see if I understood this correctly: This actually patches the source code of the wireless driver by adding/removing code, before compilation? Hmmm, I'd need to learn how to compile Android first, I guess (my experience with compilation is limited to hitting the "Compile & Run" button in Visual Studio)...
Thanks for the hard work though. I'll hit up AdamG and Kali and see if they feel like integrating this...

Oh, sorry
if you're familiar with adb, do an adb shell and then in the console do...
Code:
cat /proc/config.gz > /sdcard/config.gz
then attach that to a reply here. I need the 2.6.34 config to build the module here, then i can just post a zip to apply in the recovery console.

4G LTE Rapid Power Burn Issue

High Level Symptoms:
- I notice battery has drained very quickly in a short time even when I have not been using phone (i.e. idle with display off)
- Phone feels noticeably warm/hot even when I have not been using phone (e.g. like it does while charging)
- Issue only seems to happen when running in 4G LTE mode
- I have gathered detailed usage statistics and do not believe there are any miss-behaving apps or system processes responsible
- I have noticed issue start most often near my office (in midtown NYC)
Note: This is where I use the phone on battery the most, so it may just be sampling bias
- I can temporarily stop the rapid power burn by switching out of 4G LTE mode (i.e. to 3G mode, or disabling radio)
- I have not found a way to stop the issue in 4G LTE mode once it starts except by restarting phone
(things I tried without success: toggling airplane mode, switching to 3G and back to 4G, radio off/on, and moving to different location/tower; rapid burn starts back up again as soon as 4G LTE mode is re-enabled)
Power Burn Rate:
- Data captured using Battery Monitor Widget which I have set to sample/log battery available % and usage every minute (this is a great app!)
- Available % dropping at a rate of about 20% / hour while phone is idle w/ screen off (my normal is about 5% / hour)
- Usage shows a very flat baseline of about 1000 mW / 250 mA (normal baseline is more like 100 mW / 40 mA)
(by baseline I mean many samples are equal to that baseline value with the rest being spikes up to greater values; no observed values are less than the baseline)
Background Info:
- My phone is unrooted and running stock firmware w/ the Verizon OTA upgrade (installed ~2011-05-19)
- I have noticed this issue many times since first getting the phone (~2011-04-12), and this issue is still present even with the newest LTE radio FW in the OTA update
- I am new to Android (~2 months in) but I am diving in deep with all the amazing tools both built-in and via add-on apps; I have collected a range of data/observations from numerous sources that are detailed in this post
My hypothesis is that the LTE radio hardware is responsible for this power burn. Most likely due to a software/firmware bug, but I'm not sure how to confirm that.
I wonder how common this issue is. I remember reading other posts on the forum that sound like the same thing. For example: http://forum.xda-developers.com/showthread.php?t=1008761
Can anyone else confirm they have seen this issue? If this issue is wide spread, I think it may be a contributing factor to the wide spread reports of 4G LTE a lot of battery.
I do not think this is the only factor that causes 4G LTE to use more power than 3G. I have read the reports, and personaly seen, higher 4G LTE power consumption when in low signal areas. However, I belive that to be independant from the burn issue I am describing here. The worst case power consumption I've seen that I think was "low LTE signal" related was only about 500 mW / 130 mA. The burn issue I'm refering too consumes power at about twice that rate and happened when I had strong signal. I had three to four of four possible bars. Also, I grabbed more detailed information:
----------
Phone info
reached using "LTE OnOff" app, "Network" app, or by dialing *#*#4636#*#* -> Phone information
Signal strength: -67 dBm to -80 dBm, 3 to 4 asu
Location: BID = 39b SID = 16 NID = 4
LAT = 7fffffff LONG = 7fffffff
Network Type: CDMA + LTE/EvDo auto
I believe this is good signal (e.g. issue not due to a low signal condition)
==================
Usage Data Capture
I briefly connected to power to reset the statistics after noticing the issue had started and and captured about an hours worth of data. My understanding of the data is that the display was off for almost all the time, and no apps or system processes are listed as using any significant amount of CPU/sensors in comparison to the hour data collection window.
-----------
Battery Use
reached using Settings -> About Phone -> Battery Use, or Battery Monitor Widget -> Usage
When last unplugged for 57m 12s
Display 30%
* Time on 1m 11s
* Auto Brightness
Cell Standby 21%
* Time on 57m 12s
Phone idle 19%
* Time on 56m 1s
Foursquare 11%
* CPU total 8s
* CPU foreground 6s
* GPS 26s
* Data sent 13.59 KB
* Data received 379.93 KB
Android System 7%
* CPU total 41s
* CPU foreground 2s
* Data sent 12.09 KB
* Data received 20.27 KB
Android OS 6%
* CPU total 39s
* Data sent 20.11 KB
* Data received 136.25 KB
Pandora 6%
* CPU total 35s
* Data sent 1.83 KB
* Data received 27.16 KB
---------------
Battery History
reached using Battery Monitor Widget -> Statistics, or by dialing *#*#4636#*#* -> Battery history
since last unplugged
CPU usage
* Android System (Total time:39s)
* Pandora (Total time:35s)
* suspend (Total time:31s)
* Foursquare (Total time:7s)
... (Note: more apps listed but with smaller total times)
Sensor usage
* Android System 29m 47s
* AccuWeather.com 28m 36s
(Note: after this capture I uninstalled AccuWeather.com app and retested. It wasn't listed anymore, but power drain behavior was unaltered)
Partial wake usage
* K-9 Mail 7m14s
* Android System 5m 4s
* Seesmic 9s
... (Note: more apps listed but with smaller times)
Other Usage
* Running (27.6%)
* Screen on (2.1%)
-------------------
CPU Spy v0.3.0 beta
Note: timers reset at begining of measurement interval
Time in state
1024 MHz 4:21 7%
768 MHz 0:54 1%
368 MHz 0:35 0%
245 MHz 12:11 20%
Deep Sleep 41:34 69%
This is a typical distribution I see when the phone is mostly idle (CPU sleeping for most of the time).
=================
Variation testing
After the data capture I systematicly tried several methods to see what it took to stop the abnormal drain in 4G LTE mode. In the end only rebooting the phone did it.
Set preferred network type: "CDMA auto (PRL)" (i.e. 3G mode) -> normal power usage (5:00pm-5:18pm)
Set preferred network type: "CDMA + LTE/EvDo auto" (i.e. 4G mode) -> abnormally high power usage (5:18pm to 5:43pm)
Set airplane mode (i.e. radio off) -> very low power usage (5:43pm to 6:54pm)
Turned off airplane mode (i.e. 4G mode) -> abnormally high power usage
Set preferred network type: "LTE mode" (i.e. ONLY 4G mode) -> abnormally high power usage
Set preferred network type: "CDMA + LTE/EvDo auto" (i.e. 4G mode) -> abnormally high power usage
Moved to a new place:
Signal strength: -65 dBm 4 asu
Location: BID = 23c SID = 16 NID = 4
LAT = 7fffffff LONG = 7fffffff
-> abnormally high power usage
Phone info "Turn off radio" button -> very low power usage
Phone info "Turn on radio" button -> abnormally high power usage
Restart phone -> normal power usage

I experience the same problem. My guess is that the radio firmware gets into a bad state when you are in an area with bad coverage.
I have been in a state where disabling data didn't stp the battery drain, only entering airplane mode would stop it.

crpalmer said:
I experience the same problem. My guess is that the radio firmware gets into a bad state when you are in an area with bad coverage.
I have been in a state where disabling data didn't stp the battery drain, only
entering airplane mode would stop it.
Click to expand...
Click to collapse
I originally thought the same thing about the issue starting while in poor coverage, but since I have seen it occur multiple times in a good coverage area I began to doubt that was the case. The extra power consumption I usually get while in poor coverage is less in magnitude, and varies much more, and goes away when I have good coverage again. This issue feels distinctly different to me.
When you say disabling data didn't stop the drain you experienced, do you mean turning off Settings -> Wireless & networks -> Mobile networks? I haven't tried playing with that option. I'll give it a try next time I see the issue too.
You said entering airplane mode would stop it. Did you have the same experience that when you turned airplane mode off that the drain started back up again until you restarted?
Thanks

Excellent post, I would venture a guess that your background is in one the sciences.
One thing I noticed you didn't try was connecting through wifi. I believe this will render the 4g radio on but not in use. If the issue persists, it could help narrow down the cause.
As far as attempting to fix it, you can factory reset it or go to verizon for a replacement.. but that doesn't do much for others with this problem.

I have been having the same issue, both on stock and BAMF 1.6. Thanks for looking so thoroughly at this problem. It appears not everyone is affected. Can someone confirm? If so, exchanging the could be the solution.
Sent from my ADR6400L using XDA App

To test your hypothesis, I'd recommend turning off LTE somehow. My suggestion for non-rooted phone:
Dial ##778#
Chose edit mode, password: 000000
You should be able to turn off LTE in Modem Settings->Preferred Mode
Please let us know your finding.

Nice work on the research!
The scenario you described happened to me yesterday.
I was in a building where I didn't get any reception at all. I noticed the phone started to warm up. By the time I got outside and the phone re-established a connection with the 4g network, it was extremely warm and the phone was at 7% life begging to be charged.
This has happened to me on two other occasions but I don't recall being in an area of zero to poor reception.
My bolt is also rooted running the BAMF Remix 1.6.

agdaniels said:
Excellent post, I would venture a guess that your background is in one the sciences.
One thing I noticed you didn't try was connecting through wifi. I believe this will render the 4g radio on but not in use. If the issue persists, it could help narrow down the cause.
As far as attempting to fix it, you can factory reset it or go to verizon for a replacement.. but that doesn't do much for others with this problem.
Click to expand...
Click to collapse
Thank you. Your guess is spot on; I did my Ph. D. in computer science.
I have not tried switching to WiFi. Next time I see the issue I will put that to the test. I find I haven't been using WiFi much with this phone since I have lower standby power consumption in 3G mode when I don't need the speed. When I do want more speed, I find here in NYC 4G LTE is actually significantly faster than either my home or work Internet connection (Cable and DSL respectively) (Crazy!). Also, here in NYC the 2.4 GHz band is VERY crowded so WiFi can slow down at times even on a good wired Internet connection. I wish this phone was 5 GHz WiFi capable to help avoid this particular issue.
My intuition is that this is a radio firmware issue so I have my doubts that a factory reset or even a replacement would fix anything. Factory reset would help if there were misbehaving apps or screwed up settings on my phone, but this seems unlikely. I'll probably need to root my phone so I can back it up before I try a factory reset. A replacement would only help if there was a hardware fault. Part of the purpose of this thread is to help gauge if many other people have this problem. The more that do, the less likely it is an abnormal HW fault with only my phone, and more likely a bug or other HW errata issue that hasn't been worked around correctly.
I think it is still too early in the game to make the call that it is not fixable in FW. I was aware that this LTE network/chipset is quite new and this phone was likely to have some rough spots at the start. Verizon/HTC/Qualcomm have only made one OTA release so far, and even that release has major bugs that were not present in the original stock FW (e.g. the frequent spontaneous rebooting when in 3G mode). Forums like this seem like great places for us users to publicly characterize issues we encounter. I hope it helps the engineers involved in making fixes and that we get updates not too far down the line.

cuguy said:
To test your hypothesis, I'd recommend turning off LTE somehow. My suggestion for non-rooted phone:
Dial ##778#
Chose edit mode, password: 000000
You should be able to turn off LTE in Modem Settings->Preferred Mode
Please let us know your finding.
Click to expand...
Click to collapse
Thanks for the suggestion.
If you look at the last part of my post under the "Variation Testing" heading, I believe I did try a number of configurations with LTE off. Each case where LTE was off I saw normal or low power consumption. This is why I grew to suspect the LTE radio in the first place.
The technique I used for switching between 3G and 4G modes was actually the "Set prefered network type" drop down on the "Phone info" menu that can be reached using "LTE OnOff" app, "Network" app, or by dialing *#*#4636#*#* and selecting "Phone Information".
I have used the dial ##778# to get the ESPT menu before, but that was to modify the "Rev. A" setting from "eHRPD" to "Enable" as a work around to re-enable 3G EVDO during the few days of nation wide 4G LTE & 3G SVDO outage we had a month or so ago. BTW, it looks like I had by phone set to the non-stock "Enable" setting rather than "eHRPD" for the original data capture. I switched this back to "eHRPD" and I'll report if I have the issue again. I was last playing with this setting to see if had any effect on the random reboots after the OTA while on 3G, but it did not.
In the ESPT -> Modem Settings -> Preferred Mode drop down I only see the options for:
- Automatic
- HDR Only
- Digital Only
- CDMA Only (selected by default)
- CDMA HDR Only
There is also a a Preferred Mode(9k) drop down that has these options:
- Automatic
- HDR Only
- LTE Only
- HDR LTE only (selected by default)
I believe that these are settings for the voice radio and the data radio respectively. See the third page of the excellent Anandtech review of the HTC Thunderbolt: <Sorry, I am a new xda-developers forum member so it won't let me post external links yet.>
Do you have suggestions on how to set these? I am unfamiliar with the HDR acronym and haven't turned up anything that seems relevant in my Google searches.

I had another instance of the 4G LTE power burn issue today. I tried a few of the above suggestions.
I enabled WiFi and logged on to an access point. This did not stop the abnormally high power burn. Instead it went up slightly; I assume this was the extra power for the WiFi radio.
I also tried turning off Settings -> Wireless & networks -> Mobile networks. That resulted in the 4G LTE icon going away but the signal bars were still showing. I couldn't use the Internet but a SMS came through in this mode. This mode did not stop the power burn either.
The burn stopped only when I rebooted.
The reboot happened when I dialed ##778# to get the ESPT menu and switched the "Rev. A" setting from "Enable" to "eHRPD" and this time remembered to commit the changes (forgot to when I posted above). Committing the changes auto-rebooted the phone, which returned me to normal power consumption. I will report if I have the problem again now that I have confirmed I am back in the stock eHRPD mode.
Most of today I was in very good signal conditions, judging by the time the drain started, I could have been out on a errand in the neighborhood. So I can't 100% guarantee that the 4G signal was high the whole time.
Does anyone know of an app that works on the Thunderbolt that can log signal strength over time and preferably graph it too (e.g. similar to Battery Monitor Widget). I have tried to download and use a few without success including: Open Signal Maps, Network Signal Info, RF Signal Tracker, and Signal Finder. Some of these apps didn't work at all (I suspect 4G signal is reported a bit differently and this confuses some of them). Some work in general but I can't seem to get the logging I'm looking for.
Thanks!

OdinGuru said:
I originally thought the same thing about the issue starting while in poor coverage, but since I have seen it occur multiple times in a good coverage area I began to doubt that was the case. The extra power consumption I usually get while in poor coverage is less in magnitude, and varies much more, and goes away when I have good coverage again. This issue feels distinctly different to me.
When you say disabling data didn't stop the drain you experienced, do you mean turning off Settings -> Wireless & networks -> Mobile networks? I haven't tried playing with that option. I'll give it a try next time I see the issue too.
You said entering airplane mode would stop it. Did you have the same experience that when you turned airplane mode off that the drain started back up again until you restarted?
Thanks
Click to expand...
Click to collapse
By disabling data, I was actually using the notification tools in most rooted roms. That should be equivalent to what you said.
Toggling airplane mode toggled the battery drain problem until it failed to enter airplane mode and I had to reboot.

I see the same thing
Where I live at home we only have 3G at work I have 4G. The phone will get itself into some kind of mode at work and burn through the battery in 4-5 hours. So I keep it charging on my desk all day. If I didn't, some days it wouldn't make it till lunch.

OdinGuru said:
Thank you. Your guess is spot on; I did my Ph. D. in computer science.
I have not tried switching to WiFi. Next time I see the issue I will put that to the test. I find I haven't been using WiFi much with this phone since I have lower standby power consumption in 3G mode when I don't need the speed. When I do want more speed, I find here in NYC 4G LTE is actually significantly faster than either my home or work Internet connection (Cable and DSL respectively) (Crazy!). Also, here in NYC the 2.4 GHz band is VERY crowded so WiFi can slow down at times even on a good wired Internet connection. I wish this phone was 5 GHz WiFi capable to help avoid this particular issue.
My intuition is that this is a radio firmware issue so I have my doubts that a factory reset or even a replacement would fix anything. Factory reset would help if there were misbehaving apps or screwed up settings on my phone, but this seems unlikely. I'll probably need to root my phone so I can back it up before I try a factory reset. A replacement would only help if there was a hardware fault. Part of the purpose of this thread is to help gauge if many other people have this problem. The more that do, the less likely it is an abnormal HW fault with only my phone, and more likely a bug or other HW errata issue that hasn't been worked around correctly.
I think it is still too early in the game to make the call that it is not fixable in FW. I was aware that this LTE network/chipset is quite new and this phone was likely to have some rough spots at the start. Verizon/HTC/Qualcomm have only made one OTA release so far, and even that release has major bugs that were not present in the original stock FW (e.g. the frequent spontaneous rebooting when in 3G mode). Forums like this seem like great places for us users to publicly characterize issues we encounter. I hope it helps the engineers involved in making fixes and that we get updates not too far down the line.
Click to expand...
Click to collapse
You are absolutely correct on all three points, my main focus with the two suggestions were background data for the factory reset and faulty hardware for the replacement.
If you have the ability to disable all background data syncing while on 4g- on the application side, sense ui side, and the android side you could completely rule out software being the cause. My thoughts with this are some background service is keeping the radio active, causing the burn.
The replacement device would help to narrow down whether the issue lies on the device side, or if its more related to the towers/the way lte functions. The latter is bad news for you. My thoughts on this are that some people report no issues running lte, while others are having similar problems as you have reported; I doubt that it is faulty phone hardware, but its possible.
I share your conclusion that this is a firmware(baseband) issue. Actually going in and manipulating it would require root, a considerable understanding of how the interaction between hardware and software works, and the abilty to make tweaks and test them. I will also contact some people more knowledgable then myself and see if they want to chime in on the matter.

crpalmer said:
By disabling data, I was actually using the notification tools in most rooted roms. That should be equivalent to what you said.
Toggling airplane mode toggled the battery drain problem until it failed to enter airplane mode and I had to reboot.
Click to expand...
Click to collapse
Excellent idea. I then I was able to execute the test you suggested yesterday when I re-encountered the issue. I saw the exact same behavior you reported: even though I disable applications data over LTE, the drain did not stop. This is strong supporting evidence that it is not an issue with some kind of rouge app / sync settings.
Drain toggling with airplane mode is the exactly consistent with my observations as well. Sounds like we have confirmed you having the exact same burn issue.
Thank you for the feedback and confirmation.

mcargil05 said:
Where I live at home we only have 3G at work I have 4G. The phone will get itself into some kind of mode at work and burn through the battery in 4-5 hours. So I keep it charging on my desk all day. If I didn't, some days it wouldn't make it till lunch.
Click to expand...
Click to collapse
This is consistent with my observations of the burn issue. The baseline power consumption I observed is about 20% of the battery per hour while phone is idle with screen off. That would correspond to the phone burning through a full charge in 5 hours even if you didn't use it at all. Add any extra actual usage on top of that and 4-5 hours of life sounds very plausible. That assumes you have the problem right away though (the worst case).
I typically see a variable amount of time of normal consumption before the issue starts. For instance, let's say I've been running normally for 3 hours and am at 80% before the issue starts. Then I'd quickly burn through the last 80% in 4 hours or less. In that case I'd get less than 7 hours of total battery life (e.g. not making it through the day). If my normal usage had continued, it should be more like 15 hours (e.g. more than enough for a long day and needs charging every night).
There is still the question if this issue is related or not to 4G signal levels. What do you normally see in the office? Number of bars is useful, and also the more detailed dBm number can be found in Settings -> About Phone -> Network.
Thank you for your report.

agdaniels said:
You are absolutely correct on all three points, my main focus with the two suggestions were background data for the factory reset and faulty hardware for the replacement.
If you have the ability to disable all background data syncing while on 4g- on the application side, sense ui side, and the android side you could completely rule out software being the cause. My thoughts with this are some background service is keeping the radio active, causing the burn.
The replacement device would help to narrow down whether the issue lies on the device side, or if its more related to the towers/the way lte functions. The latter is bad news for you. My thoughts on this are that some people report no issues running lte, while others are having similar problems as you have reported; I doubt that it is faulty phone hardware, but its possible.
I share your conclusion that this is a firmware(baseband) issue. Actually going in and manipulating it would require root, a considerable understanding of how the interaction between hardware and software works, and the abilty to make tweaks and test them. I will also contact some people more knowledgable then myself and see if they want to chime in on the matter.
Click to expand...
Click to collapse
In the most recent test I disabled "Mobile Networks" which effectively shutdown data service. I also tested switching to WiFi which should have redirected all data away from the 4G LTE radio. Neither one of these stopped the power burn. Do you agree this is sufficient enough to rule out apps/services?
I noticed on the Phone info screen there are some counters for number of bytes sent over the radio. Next time I have the issue perhaps I'll keep track of how those change when I'm having the issue vs not.
I agree that trying replacement HW would be a useful data point to help identify if the issue is inherent or tower related. I'm not quite ready to jump through all the hoops with Verizon to do it myself yet. I'd want to root first to create a backup of my current setup first to reduce the pain of the procedure. And I'll probably give them the benefit of the doubt and wait for the next OTA to give them another shot at fixing the issue with FW.
Part of our questions would be answered if there was indeed a user out there that runs 4G LTE and can document that they do not have this issue. Does anyone out there run Battery Monitor Widget or similar and can say they have never seen the tell-tail pattern of power burn I am talking about?
I really wish Android had a built in screen capture feature. I need to get adb installed and setup on my computer so I can post examples of what the graphs look like; I think that would help other users to identify the issue as it happens so they know when to re-boot to save what is left of their battery.
I agree there is very little we as users can do to fix the issue if it is in the radio FW. As you say, it would indeed take very detailed knowledge of the HW. Also, I think it would be impossible without the radio FW source code. Although I haven't looked through the HTC released code, I would be very surprised if this was included. It wouldn't be covered under the Android or Linux open source licenses as it likely originally came from Qualcomm and is considered proprietary. Without that, we can only hope that Qualcomm/HTC/Verizon work together to get it figured out. The good news is that they all have a good business case to do so. This LTE chipset is likely to be used in several phones so they need these issues resolved before it affects their whole lineup.
Anyone know if the new Samsung Droid Charge has this issue too?

After experiencing all the same issues myself, I have noticed that this seems to have been addressed in the leaked Gingerbread radio. Might be worthwhile to repeat testing using that radio and then somehow compare code.
Sent from my ADR6400L using XDA Premium App

I would have to agree you've sufficiently ruled out software, the point about the gingerbread build not having issues is worth noting though. Can someone confirm the 2.3 release has new radio firmware? It wouldn't be difficult at all to pull it out and flash it if it does
My thunderbolt will be in hand Monday, I don't have the phd you have in c.s (mines just a bs) but I've been in the business long enough to throw some graphs together. We'll compare notes then if we don't find resolution sooner.

I experience the same problem in North Phoenix when running 4GLTE in a weak 4g signal area. It doesn't happen too often if I'm in a heavily blanketed 4g area.
EDIT. I'm running rooted. OC to usually 1400 mhz. I'm constantly being synced with the Exchange Server. My phone gets super hot when running navigation plus 4GLTE. Temperature gets up to around 110 degrees Fahrenheit.
When I notice my phone heating up, I'll switch to CDMA prl and immediately my battery temperature starts dropping to normal levels, ie. 86 degrees Fahrenheit.
At the time I was running on different radio combinations. Such as, CDMA. 6 and lte. 7 radio combo. I have recently switched to Gingerbread so more testing is needed.

Had a spare minute to look up the radio, looks like its bricking certain devices after flashing. Not completely ruling it out, maybe you can flash it, test it, then flash it back, but there is some risk involved.
Whatever the case, its reassuring to know updates are coming eventually.
Here is a link for reference:
http://forum.xda-developers.com/showthread.php?t=1098363&page=70

[Q] not sure about an idea, posting it cause I'm curious

I noticed that on pretty much any phone, no matter the strength of the data or wifi connection, transfers on the playstore are usually always speedy. I dont know what particular part of code, or driver command, or even what exactly makes that happen, but i wonder if it could somehow be implemented or activated (or however it would be used) system wide to speed up any data or wifi communication. I obviously dont understand enough about this area of phones and would like some education on it if anyone has the time, thanks!

CM11 M7 Wifi dead? here's a potential fix

OK, so I know M7 isn't the latest CM build, but it's the latest one without issues with GPS, so that's what I'm on since I use GPS a lot.
So last week I replaced my home router. This of course means reconfiguring all the wifi devices around the house, including my wifi thermostat. The unique thing about the thermostat is that to configure it, you connect a laptop/phone/tablet to the thermostat's ad-hoc wifi network, tell it which infrastructure ssid to connect to, verify a pin from the thermostat's screen (so nobody can hijack your t-stat from outside the house), and that's it.
thing is, when you use Cyanogenmod (at least on the relay) to connect to an adhoc network, it breaks wifi. what happens is you can't connect to any other wifi networks, and can't even scan to see available networks till you reboot. sometimes it doesn't work even after a reboot. strangely, the tethering/hotspot still works fine. you just can't connect the phone to a hotspot whether it's at home or work or anywhere.
i'd been having other issues and general slowness with the phone, so i decided to backup a few apps with TiBu and do a factory reset. that worked... till i tried connecting to the thermostat again, and it broke wifi completely this time.
solution? go to /data/misc/wifi/ and rename wpa_supplicant.conf to wpa_supplicant.conf.old (or whatever, as long as it's a different name) and reboot. the system will automatically create a new conf file. boom - wifi fixed.
obviously this requires root, but that's not an issue in CM. I doubt it matters, but i used ES file explorer since it's got a good root filesystem browser and mounting / or system as RW is a simple matter of a checkbox in the settings.
when i compared the newly created wpa_supplicant.conf with the one i'd renamed (.old) the only real difference i could see was the saved networks at the bottom. so you might be able to get away with simply deleting the offending network={ blah blah } section instead of completely renaming the conf file. the advantage here would be if you have a bunch of saved networks that you don't want to get rid of, it will keep those saved networks. the conf file is a plaintext file so it's easy enough to understand what you're looking at, and modify appropriately.
MODS: I apologize if this is in the wrong forum. I figured since it probably only applies to CM, I should post it in the dev forum rather than the general one. If it needs to be moved, I don't be offended.

Gibson99 said:
OK, so I know M7 isn't the latest CM build, but it's the latest one without issues with GPS, so that's what I'm on since I use GPS a lot.
So last week I replaced my home router. This of course means reconfiguring all the wifi devices around the house, including my wifi thermostat. The unique thing about the thermostat is that to configure it, you connect a laptop/phone/tablet to the thermostat's ad-hoc wifi network, tell it which infrastructure ssid to connect to, verify a pin from the thermostat's screen (so nobody can hijack your t-stat from outside the house), and that's it.
thing is, when you use Cyanogenmod (at least on the relay) to connect to an adhoc network, it breaks wifi. what happens is you can't connect to any other wifi networks, and can't even scan to see available networks till you reboot. sometimes it doesn't work even after a reboot. strangely, the tethering/hotspot still works fine. you just can't connect the phone to a hotspot whether it's at home or work or anywhere.
i'd been having other issues and general slowness with the phone, so i decided to backup a few apps with TiBu and do a factory reset. that worked... till i tried connecting to the thermostat again, and it broke wifi completely this time.
solution? go to /data/misc/wifi/ and rename wpa_supplicant.conf to wpa_supplicant.conf.old (or whatever, as long as it's a different name) and reboot. the system will automatically create a new conf file. boom - wifi fixed.
obviously this requires root, but that's not an issue in CM. I doubt it matters, but i used ES file explorer since it's got a good root filesystem browser and mounting / or system as RW is a simple matter of a checkbox in the settings.
when i compared the newly created wpa_supplicant.conf with the one i'd renamed (.old) the only real difference i could see was the saved networks at the bottom. so you might be able to get away with simply deleting the offending network={ blah blah } section instead of completely renaming the conf file. the advantage here would be if you have a bunch of saved networks that you don't want to get rid of, it will keep those saved networks. the conf file is a plaintext file so it's easy enough to understand what you're looking at, and modify appropriately.
MODS: I apologize if this is in the wrong forum. I figured since it probably only applies to CM, I should post it in the dev forum rather than the general one. If it needs to be moved, I don't be offended.
Click to expand...
Click to collapse
It does belong in q&a...but my lollipop validus has working gps

REV3NT3CH said:
It does belong in q&a...but my lollipop validus has working gps
Click to expand...
Click to collapse
As does FatToad. However, I do know that the privacy bit in the GPS can be flipped with the drivers we're using in FT. There's an old thread with a post from nard about how to fix that.

Magamo said:
As does FatToad. However, I do know that the privacy bit in the GPS can be flipped with the drivers we're using in FT. There's an old thread with a post from nard about how to fix that.
Click to expand...
Click to collapse
Do you understand more about this "privacy bit", what call in the API flips it, or can give me any other pointers about it? The poster previous to you indicates that GPS works with M7. I thought I had it working with M8, but can't really guarantee that, any more. The post from nard was quite an onerous process, including what looked like reflashing the baseband.
It seems to me that if we really understood this problem, the fix would be quite simple, and could be done by a root-access app. I've done more digging, and see that it seems to be common to many models of Samsung Galaxy phones, and some of the fixes involve doing potentially horrible things to the NVRAM. (like clearing it completely - what could possibly go wrong?)
It seems that the GPS is done in the baseband processor, along with the other radio stuff, but so far I haven't been able to find it. The transceiver chip is just a transceiver, no baseband processor. It looks like the baseband processor might be on the Snapdragon main processor chip, though they don't enumerate it well. In addition they mention a "gpsOne engine" without describing exactly what it is.
I'm still relatively ignorant about Android, a year after getting one. (not enough time) I'm better versed on hardware, but this problem seems to be in the cracks between.
Come to think of it, a simple question... Is there documentation on the communications between Android and the baseband processor?

Gibson99 said:
OK, so I know M7 isn't the latest CM build, but it's the latest one without issues with GPS, so that's what I'm on since I use GPS a lot.
Click to expand...
Click to collapse
I just took my wife's phone outside and tested it. GPS works on M8 from last summer, as does wifi. AFAIK the only thing that doesn't work on M8 is the video camera. (Stills on the camera work.)
This was an older phone than mine, purchased after mine. With mine I didn't need the radio or bootloader updates, my wife's did. I bought the phone for her, used it briefly with my PureTalkUSA SIM card to make sure it was really unlocked. Then I put CM11 on it.

phred14 said:
I just took my wife's phone outside and tested it. GPS works on M8 from last summer, as does wifi. AFAIK the only thing that doesn't work on M8 is the video camera. (Stills on the camera work.)
This was an older phone than mine, purchased after mine. With mine I didn't need the radio or bootloader updates, my wife's did. I bought the phone for her, used it briefly with my PureTalkUSA SIM card to make sure it was really unlocked. Then I put CM11 on it.
Click to expand...
Click to collapse
no idea how old mine actually is; i bought it "like new" from a tmobile reseller here in town and i actually use tmobile for service.
right now i'm on fattoad and once i stepped down my paranoia (i turned on privacy guard for everything including all system apps. hint: don't do that ) it seems good so far. nova launcher has an issue with flickering or disappearing icons, and everything is huge (i need to adjust the dpi) but so far no issues with gps or wifi (though i havent needed to connect to an adhoc network yet).

Do be careful with Privacy Guard. I didn't mention, but although Privacy Guard out of the box tends to make it so that most system apps are unable to be tuned, TeamApexQ likes the option of being able to tune everything in that regard, so we removed the safeguard. (For example, when PG was first ported to CM12, you could tune the settings of the 'Settings' app. Then at our next internal testing build, it was suddenly coming up empty, because CM made a change to exclude tuning for it. We restored full capability because we liked it. But that does mean you can more easily 'shoot yourself in the foot'.

Magamo said:
Do be careful with Privacy Guard. I didn't mention, but although Privacy Guard out of the box tends to make it so that most system apps are unable to be tuned, TeamApexQ likes the option of being able to tune everything in that regard, so we removed the safeguard. (For example, when PG was first ported to CM12, you could tune the settings of the 'Settings' app. Then at our next internal testing build, it was suddenly coming up empty, because CM made a change to exclude tuning for it. We restored full capability because we liked it. But that does mean you can more easily 'shoot yourself in the foot'.
Click to expand...
Click to collapse
I've recently begun to wonder if Privacy Guard might be partially responsible for reduced battery life. I'm under the impression that it lies to apps, providing false information when they have insufficient authority for the real information. Some of those permissions in Privacy Guard are to turn radios on and off. If an app thinks it's turned a radio on, and is trying to communicate based on faked (Really, it's going to look like a failure, at this point.) returns, it may spend more time continuing to try instead of just staying asleep. My battery life comes an goes, but I've noticed that on a "bad day" there are quite a few wakeups in the middle of nowhen, when the phone was sitting there in airplane mode with all radios off.
Of course I may be all wet on this - radio control may be one area where it can say, "You're in Airplane Mode, no program can turn the radio on."

good theory, and like you said, it depends on the app and how pg implements each block.
personally i'm having great battery life in L. i have a 5000mah battery, but usually by this point in the day i'm at about 60%. right now i'm still at 83%. i like how it projects your estimated remaining battery time. first time i looked at the battery chart, i lol'd - it was projecting 4.5 days before it died. i can probably get 2 no sweat even with regular usage, but i'd have to turn off sync and really cut back to make it 4 days.

I've had very good results with some simple rules with Privacy Guard. Generally the only thing I've turned off is the ability for Google Play Services and the Google App (Google Now) to wake up my device and to keep it awake. With those turned off, my battery life has gotten to be pretty damned nice... Though it makes Google Play Services FC once maybe every 24 hours. It restarts just fine, no harm no foul.

My battery life seems to be "bimodal". It either barely makes it 24 hours - basically needs recharging every night, or it lasts on the order of three or four days on a charge.
It seems to be somehow wifi-related, if I were guessing, and in an odd way. If wifi is largely off, but occasionally on, the battery life seems shorter. After wifi has been left off for "a while" (quantity not yet determined) it seems to go into long-battery-life mode. If I keep wifi largely on, and occasionally off (basically between known/trusted wifi places) the battery life comes out somewhere in between, consistent with wifi itself taking some power.
It's been really tough to detect any sort of pattern, but this is the best I've been able to come up with so far. I haven't done rigorous testing, or at least attempts at rigor so far have yielded inconsistent results. I've looked at what the Settings->Battery has available for power diagnostics, and one thing I noted was a lot of spurious wakeups when all radios were turned off. That's what led me to tentatively finger Privacy Guard.
I just saw the setting to show "built-in" apps on PG. I see two different entries for google.services and google.services.framework. The former has scads of wakeups - thanks for the tip. The latter has many, but a much smaller number. Did you block wakeups for both? I presume "built-in" are also "system" that others have said shouldn't be bulk-denied in PG. Are there guidelines anywhere about which are OK, which are useful, etc? (Like this case, and perhaps battery life.)

phred14 said:
My battery life seems to be "bimodal". It either barely makes it 24 hours - basically needs recharging every night, or it lasts on the order of three or four days on a charge.
It seems to be somehow wifi-related, if I were guessing, and in an odd way. If wifi is largely off, but occasionally on, the battery life seems shorter. After wifi has been left off for "a while" (quantity not yet determined) it seems to go into long-battery-life mode. If I keep wifi largely on, and occasionally off (basically between known/trusted wifi places) the battery life comes out somewhere in between, consistent with wifi itself taking some power.
It's been really tough to detect any sort of pattern, but this is the best I've been able to come up with so far. I haven't done rigorous testing, or at least attempts at rigor so far have yielded inconsistent results. I've looked at what the Settings->Battery has available for power diagnostics, and one thing I noted was a lot of spurious wakeups when all radios were turned off. That's what led me to tentatively finger Privacy Guard.
I just saw the setting to show "built-in" apps on PG. I see two different entries for google.services and google.services.framework. The former has scads of wakeups - thanks for the tip. The latter has many, but a much smaller number. Did you block wakeups for both? I presume "built-in" are also "system" that others have said shouldn't be bulk-denied in PG. Are there guidelines anywhere about which are OK, which are useful, etc? (Like this case, and perhaps battery life.)
Click to expand...
Click to collapse
It's difficult to give tips for this, because everyones' usage is different. Get 'WakeLock Detector' and keep an eye on that when your power drain seems more intense. Disable things that make sense to disable based on that.

I know this isn't really the topic, but just because you get a new router doesn't mean you have to reconfigure everything. Why couldn't you just configure the new router with the SSID and password from the old one?

slartibartfast42 said:
I know this isn't really the topic, but just because you get a new router doesn't mean you have to reconfigure everything. Why couldn't you just configure the new router with the SSID and password from the old one?
Click to expand...
Click to collapse
believe me, i tried that. it's stupidly tedious to enter a long keyphrase via the remote control on our tivos and only slightly less tedious on the roku (its remote is much more responsive). laptops and phones aren't as bad since they have keyboards. apparently the devices are smart enough to notice a different MAC behind the BSSID. which if you think about it, is actually a GOOD thing in terms of security, since it makes spoofing a little more difficult. granted, you'd also have to know the wpa key to successfully spoof, but it's a simple check to implement for security's sake, and i'm glad they did.
by the way, do you like fjords?

Magamo said:
It's difficult to give tips for this, because everyones' usage is different. Get 'WakeLock Detector' and keep an eye on that when your power drain seems more intense. Disable things that make sense to disable based on that.
Click to expand...
Click to collapse
"Wakelock Detector" has certainly been enlightening. "Google Fit", which makes sense, once you think about it. But the other aspect that was even more important, I just happened to see when one of the other forums popped up on some sort of search result or other.
You have to boot your Android device on battery. If the kernel starts up on charger, it never gets into the deepest power-saving states. When I first started using Wakelock Detector, my phone showed up as being awake something like 97% of the time. Google Fit was the biggest user, but not that big. After seeing that advice I've been careful to boot on battery, and now most of the time is spent asleep. Google Fit still uses wakes as much, but when it's not, the phone is really sleeping. My normal battery life has moved out to two or three days, sometimes into a fourth. As long as I consider Google Fit worth having around, this battery life is good enough for me - there is always a decent window to recharge.

phred14 said:
You have to boot your Android device on battery. If the kernel starts up on charger, it never gets into the deepest power-saving states.
Click to expand...
Click to collapse
So much for that theory. A day or two back, after good battery life since this post, I noticed it draining faster. Today I looked, and sure enough, it's not going into deep sleep. I tried rebooting with all four states of wifi and cell service, and nothing has gotten deep sleep back. I think I'm going to try charging tonight, booting while charging, then rebooting after disconnecting. It would be good to have an exact and repeatable set of circumstances that cause both good and bad battery life.

[ROOT] A simple guide to block/Reduce qcom_rx_wakelock and some other wifi wakelocks

Two weeks felt like two years when my phone suddenly started acting odd. High CPU usage, 2x battery drain compared to before, phone heating up while doing simple tasks drove me insane. I thought there might be something wrong with the phone but couldn't find anything so I sent it to the customer service center. All they did was factory reset, installed the latest stock OS, and sent it back which didn't solve my issue.
So I rooted the phone, installed a custom ROM and the problem was still there. I lost the tiny bit of hope I had left and concluded that it's a hardware issue and I might have to buy a new device. Two days later I installed the Better Battery Stats app and kept my phone idle overnight with wifi on.
The next day I finally found out what's been eating my battery. In BBS under Kernel wake-locks, I saw qcom_rx_wakelock was on for 8 straight hours, as long as my wifi was on. Checked the CPU states on the FK Kernel manager and found out the phone never went to deep sleep, not for a second! Also, there was that idle wifi usage.
So I downloaded the Network Log app and kept logging on the next night. 9 hours passed, none of my apps used the internet but the kernel used almost 500 mbs in 9 hours! So that's where my wakelock was coming from.
I went to my friend's house and used his wifi for a few hours to identify what's going on and I was surprised to see there was no battery drain, low CPU usage, and zero idle wifi usage. For a moment there everything seemed to went back to normal. When I came back to the school dormitory the nightmare started again.
I started scouring on the internet and I found this which led me to this terrific post!
This comment explains everything!
To summarize, the phone was going crazy because of wifi multicast, and arp flooding. I couldn't do anything about it as I was in the university's public wifi. You can disable multicast by going to the router page and turning off wifi multicast from IGMP snooping setting. But it was impossible for me cause school won't allow me to change anything and even if I complain they won't care.
So I decided to fix it by adding some of the Pixel 3's WCNSS_qcom_cfg.ini properties to my phone's WCNSS_qcom_cfg.ini which I located in the vendor/etc/wifi/ as r/skanadian recommended in the second post which took my qcom_rx wakelock to 19%, way less compared to 86% before.
This is a step-by-step guide to reducing battery drain -
• Backup your phone's WCNSS_qcom_cfg.ini in case something go wrong. I found it in system/vendor/etc/wifi/here
It might be different for you depending on what Rom or device you are using. The filename will be the same but the location might be different.
• Get a text editor. Mixplorer is recommended as it helps to search properties quickly with its find feature.
• Open your devices WCNSS_qcom_cfg.ini using Mixplorer and keep it open. Alternatively, you can copy it to a different folder on your phone. I suggest the second one cause it's better than directly editing the file from the system.
• Go to this page
• Go to your browser option and select find in page to search. Search for the word "offload" on that page.
• Copy all the lines related to offload one by one and replace them on your devices WCNSS_qcom_cfg.ini that you opened using Mixplorer.
• If there isn't anything to replace simply add those lines. Don't forget to hit the save button while doing that.
• After that, search for these properties on your WCNSS_qcom_cfg.ini and set them as I did below
RoamRssiDiff=3
g11dSupportEnabled=0
gEnablePowerSaveOffload=5
gRuntimePM=1
RTSThreshold=1048576
gMCAddrListEnable=1
gActiveMaxChannelTime=40
gActiveMinChannelTime=20
gMaxConcurrentActiveSessions=2
If you don't see one of these to replace in your WCNSS_qcom_cfg.ini you should add it.
• Now reboot your phone, give it some time and see if the battery improves. If everything remains the same then go to WCNSS_qcom_cfg.ini using Mixplorer again, find BandCapability, and set it like this -
BandCapability=1
It will disable 5ghz from your phone. I found out most companies release their phones with bad wifi drivers which don't handle the 5ghz wifi band appropriately. Lack of power-saving and not blocking multicast requests properly leads to higher CPU usage and bad battery life.
Again you can set the BandCapability=2 if you want to use 5ghz mode only. If you have a good wifi driver, the battery drain might come from switching between 2.5 and 5ghz so keeping on one of them helps.
• Why qcom_rx wakelock and what is the best fix?
It can occur for several reasons.
- Wifi multicasting. Multicasting can be disabled from IGMP snooping on router settings. You don't need multicasting in your home network at all. But when you're on office wifi or school wifi, it does improve the speed slightly by reducing data loss and interference. It also can be solved the same way but if your school management is like mine, then they might not care if your laptop or phone burns.
- DHCP timers
- A software bug from server-side
- Band switching
- Even interference, if you have a public network with a lot of phones and PCs
There are some more reasons I can not remember now. The best way to fix it is to build a custom kernel with WLAN and qcom_rx blockers/limiters e.g. Franko Kernel.
But sadly a lot of us will never have that unless we make a kernel for ourselves. So as of now, this is the solution I could come up with.
My knowledge of this sector is very little. It would be great if you all could help me get rid of this problem.
I would love it if there was a feature built-in on Android OS to block some kernel wake-locks.
OnePlus phones allow you to turn off multicasting from Developer Options but that makes little to no difference depending on what wifi you are using.
• Very Important :
Depending on you wifi, you can try setting hostArpOffload=0 and hostNsOffload=0
or you can try setting both to 1. Use whichever improves the battery backup. Don't forget to reboot after changing anything.
If you are an expert, please help us. Cause these wakelocks aren't going anywhere. They will give some of us many more sleepless nights.
Thank you for reading. Have a good day!

For those who don't want to change settings they don't understand:
RoamRssiDiff: The difference in signal strength required before phone will switch to a new Access Point. Measured in -dbs. 3 means it will switch APs if the signal strength is 3dbs better than the one in use.
g11dSupportEnabled: WIFI 802.11d
gEnablePowerSaveOffload: Level of Powersave
gRuntimePM: Runtime Powermanagement
RTSThreshold: How long to wait before asking to send wifi packets. Should be as high as possible, only lowered if you have wifi dropouts.
gMCAddrListEnable=1: Drops all Multicast frames except for ARP. You don't want to disable ARP entirely or your internet will break, so don't lower this to 0.
gActiveMaxChannelTime: Time spent scanning.
gActiveMinChannelTime: Ditto
gMaxConcurrentActiveSessions: Self-explanatory
While looking this up I also found gNeighborLookupThreshold or RoamLowRssiThreshold: The signal strength at which the phone starts looking for a new AP (the step before RoamRssiDiff becomes relevant). Typical values are 65-80. Changing this might help too if your phone is switching AP too often or not often enough.

Thanks for this, my device was also affected by this (though not as badly as yours) I've just disabled Multicast from my router.

TrenchFullOfSlime said:
For those who don't want to change settings they don't understand:
RoamRssiDiff: The difference in signal strength required before phone will switch to a new Access Point. Measured in -dbs. 3 means it will switch APs if the signal strength is 3dbs better than the one in use.
g11dSupportEnabled: WIFI 802.11d
gEnablePowerSaveOffload: Level of Powersave
gRuntimePM: Runtime Powermanagement
RTSThreshold: How long to wait before asking to send wifi packets. Should be as high as possible, only lowered if you have wifi dropouts.
gMCAddrListEnable=1: Drops all Multicast frames except for ARP. You don't want to disable ARP entirely or your internet will break, so don't lower this to 0.
gActiveMaxChannelTime: Time spent scanning.
gActiveMinChannelTime: Ditto
gMaxConcurrentActiveSessions: Self-explanatory
While looking this up I also found gNeighborLookupThreshold or RoamLowRssiThreshold: The signal strength at which the phone starts looking for a new AP (the step before RoamRssiDiff becomes relevant). Typical values are 65-80. Changing this might help too if your phone is switching AP too often or not often enough.
Click to expand...
Click to collapse
Cool!
There are some other wakelocks that's bothering me more than qcom_rx and I have no idea what they are!
Could you please tell?

Mario3DS said:
Thanks for this, my device was also affected by this (though not as badly as yours) I've just disabled Multicast from my router.
Click to expand...
Click to collapse
Sadly I'm on school wifi and can't do anything about it!

lpass is a Qualcomm audio subsystem for things like voice based wakeup, and IPCRTR (inter-process communication router) is just how different processes on your phone communicate with each other.
Others have reported these wakelocks too, almost always when they have a wifi/cell connection. Maybe it has to do with voice assistants communicating with their home servers?

TrenchFullOfSlime said:
lpass is a Qualcomm audio subsystem for things like voice based wakeup, and IPCRTR (inter-process communication router) is just how different processes on your phone communicate with each other.
Others have reported these wakelocks too, almost always when they have a wifi/cell connection. Maybe it has to do with voice assistants communicating with their home servers?
Click to expand...
Click to collapse
Well
I asked a kernel dev and he gave exactly the same explanation you gave me. He also said these are necessary and doesn't drain battery too much.
I am on a custom kernel now and wlan, qcom_rx wls are gone.
Thanks for the help
With the new kernel, I'm not seeing Lpass wakelocks much. They are there but limited.

TrenchFullOfSlime said:
lpass is a Qualcomm audio subsystem for things like voice based wakeup, and IPCRTR (inter-process communication router) is just how different processes on your phone communicate with each other.
Others have reported these wakelocks too, almost always when they have a wifi/cell connection. Maybe it has to do with voice assistants communicating with their home servers?
Click to expand...
Click to collapse
I see you've gained quite some knowledge regarding wakelocks. Your explanation was simple and easy to grasp. Could you please guide me to a thread where I can learn more about it?
Thank you so much

I just googled all the terms. Qualcomm publishes some of its stuff (source code and .ini files) with comments, others were referenced in AOSP sources.

Thanks for posting this, with my pixel 4a setting "hostArpOffload" to 0 solved it. NETLINK wakelok are much less and no battery drain.
Although on onePlus 7 pro which I've rooted few days ago none of this is working and NETLINK wakelok is draining battery at 2-3% per hr.
I'll try flashing a different ROM and If found any fix will post it here.
Device1 : Pixel 4a | LineageOS 18.1 | microG
Device2 : OnePlus 7pro | LineageOS 18.1 | microG
Edit : There are many multicast requests and NETBIOS requests too and looks like NETBIOS requests are coming from all the windows machines which are connected via Access point.
Edit:
Tried packet capture and Router is just flooding network with Multicast and ARP traffic.
I'm in the same situation as you since I live in University Campus so no router access, Have no idea how to solve this now.
A viable option is maybe buy your own router then use it as an extender and block all these garbage requests but no idea in extender mode will you be able to block stuff or not.

seated_singer said:
Thanks for posting this, with my pixel 4a setting "hostArpOffload" to 0 solved it. NETLINK wakelok are much less and no battery drain.
Although on onePlus 7 pro which I've rooted few days ago none of this is working and NETLINK wakelok is draining battery at 2-3% per hr.
I'll try flashing a different ROM and If found any fix will post it here.
Device1 : Pixel 4a | LineageOS 18.1 | microG
Device2 : OnePlus 7pro | LineageOS 18.1 | microG
Edit : There are many multicast requests and NETBIOS requests too and looks like NETBIOS requests are coming from all the windows machines which are connected via Access point.
Edit:
Tried packet capture and Router is just flooding network with Multicast and ARP traffic.
I'm in the same situation as you since I live in University Campus so no router access, Have no idea how to solve this now.
A viable option is maybe buy your own router then use it as an extender and block all these garbage requests but no idea in extender mode will you be able to block stuff or not.
Click to expand...
Click to collapse
OP 7 pro is the device you mentioned? I think it has custom kernels with bult in wakelock blockers that automatically blocks wlan, netlink and qcom rx.

Edit: Netlink can be blocked by using Custom kernel others wakelocks are due to ARP network flood. Turning it off from WCNSS_qcom_cfg or blocking introduces another problem of few seconds delay in connection ( due to ARP Resolving issue ) when switching from one access point to another ( only when automatic ) and since I do it quite often when roaming my University campus it's a hassle.
One way to mitigate this ( if you need to keep ARP offloading off ) is by using static IP, worked for me and my roommate too, but not viable since you need root. Finally I have set up my own router, checked and there were no wakelock.
Few of my friends are also facing this battery drain issue not on all Access points but some maybe after complaining authority will fix this.
Note : Netlink is only showing on Android 11/12 with other versions there are other wakelocks.

seated_singer said:
Netlink can't be blocked nor does it show since It's a part of kernel itself, here now about other two they are due to ARP network flood. Turning it off from WCNSS_qcom_cfg or blocking introduces another problem of few seconds delay in connection ( due to ARP Resolving issue ) when switching from one access point to another ( only when automatic ) and since I do it quite often when roaming my University campus it's a hassle.
One way to mitigate this ( if you need to keep ARP offloading off ) is by using static IP, worked for me and my roommate too, but not viable since you need root. Finally I have set up my own router, checked and there were no wakelock.
Few of my friends are also facing this battery drain issue not on all Access points but some maybe after complaining authority will fix this.
Note : Netlink is only showing on Android 11/12 with other versions there are other wakelocks.
Click to expand...
Click to collapse
I have NetLink blocked from kernel.
Some of this problems are impossible to fix from phone. So I contacted school management. They didn't believe me at first then I went to the head office and showed them with Network Log app that records every single packet.
A week later they fixed it. Contact your authority and see if it helps.

Thanks for the info mate, edited. Never thought I have to deal with this stupid WiFi problem.

RyanCr7 said:
Two weeks felt like two years when my phone suddenly started acting odd. High CPU usage, 2x battery drain compared to before, phone heating up while doing simple tasks drove me insane. I thought there might be something wrong with the phone but couldn't find anything so I sent it to the customer service center. All they did was factory reset, installed the latest stock OS, and sent it back which didn't solve my issue.
Thank you for reading. Have a good day!
Click to expand...
Click to collapse
Thanks for sharing, same thing happened to me..
Reading this post and turning off Multicast on both my wifi APs worked!

Just wanted to say that following this advice with all the Offload parameters, my wifi wakelocks have pretty much vanished so far on my nexus 4, i was getting something like 14000 wakelocks in battery guru. Thank you.
I can't understand why they don't specify what commands work for what Qualcomm chipset, since even though that is a newer phone, they still work on an older WiFi chipset, I've been mixing and matching for years.

KitsuneFoxy said:
Just wanted to say that following this advice with all the Offload parameters, my wifi wakelocks have pretty much vanished so far on my nexus 4, i was getting something like 14000 wakelocks in battery guru. Thank you.
I can't understand why they don't specify what commands work for what Qualcomm chipset, since even though that is a newer phone, they still work on an older WiFi chipset, I've been mixing and matching for years.
Click to expand...
Click to collapse
I'm glad it worked for you.