Related
Hi,
First of all, I want to thanks all people that helped me testing the battery driver last time.
I'm starting a new thread for those tests as I seen many "users" of xdandroid were using my zImage as if it was an official one and claims having troubles with them.
As it's some still at devel level, I prefet to have a separate thread, this will avoid any confusion between official releases and development release.
As you may know, the first images I've released didn't not contains the modules, thus, wifi was not working. Also, I did broke the rodhium boot because of the battery temperature reporting false temperature for this model.
For those who wants to help me by testing this driver, the important thing is to clearly describe the problem you have (I.E : don't tell that the battery level is wrong only, tell me how you do know that, by comparison to winmo or else...). Second important thing is to make a "dmesg log" :
How-to make a dmesg log :
1/ Go to the "Dev tools" menu and launch the "Terminal Emulator"
2/ type "cd sdcard" (without the quote)
3/ type "dmesg >dmesg.log" (without the quotes)
4/ Send/Post me the dmesg file that will be made on the root of the SD card (either you can get it using android - don't work on my diamond - or you can get the file by rebooting the phone under winmo.
You can also do this using adb if you know how it works.
Shell script method :
1/ Make a txt file with "dmesg > /sdcard/dmesg.txt" on the root of your sdcard name it dumpdmesg.sh
2/ Under xdandroid, browse to the sdcard folder and execute the dumpdmesg.sh file
P.S : yu may have to make the dumpdmesg.sh executable using the followinf method : under a terminal (see above), type "cd sdcard" and then type "chmod +x dumpdmesg.sh".
If you need some special help or want to contact me, just send me a pm.
Here is a new set of zImages INCLUDING modules (hope it will work this time !). It have been build with the most recent kernel changes (Friday 10th September). The packages include the zImage+module in the folder zImage. Modified source files are available in the folder src.
1/ Only battery driver changes :
http://www.mediafire.com/?02qlq504pihhnnp
2/ Battery driver + Diamond panel on/off "improvement" (some people reports the screen does not powers up with this zImage. If you are experiencing same problem, please restore a working zImage (from your previous version or the last official build) and send me a dmesg log after having power on/off the screen at least 3 times. Thanks)
http://www.mediafire.com/?55qb3xpbrajivya
i think you may have the download links mixed up
hamagc said:
i think you may have the download links mixed up
Click to expand...
Click to collapse
Hard working day...thanks, I've fixed it.
Jerome
How to use?
viruscrazy said:
Hi,
First of all, I want to thanks all people that helped me testing the battery driver last time.
I'm starting a new thread for those tests as I seen many "users" of xdandroid were using my zImage as if it was an official one and claims having troubles with them.
As it's some still at devel level, I prefet to have a separate thread, this will avoid any confusion between official releases and development release.
As you may know, the first images I've released didn't not contains the modules, thus, wifi was not working. Also, I did broke the rodhium boot because of the battery temperature reporting false temperature for this model.
For those who wants to help me by testing this driver, the important thing is to clearly describe the problem you have (I.E : don't tell that the battery level is wrong only, tell me how you do know that, by comparison to winmo or else...). Second important thing is to make a "dmesg log" :
How-to make a dmesg log :
1/ Go to the "Dev tools" menu and launch the "Terminal Emulator"
2/ type "cd sdcard" (without the quote)
3/ type "dmesg >dmesg.log" (without the quotes)
4/ Send/Post me the dmesg file that will be made on the root of the SD card (either you can get it using android - don't work on my diamond - or you can get the file by rebooting the phone under winmo.
You can also do this using adb if you know how it works.
If you need some special help or want to contact me, just send me a pm.
Click to expand...
Click to collapse
another way to get the dmesg log that was advised to me some time ago was to make a txt file with "dmesg > /sdcard/dmesg.txt" inside of it and name it dumpdmesg.sh. when in android (using a file manager) execute the dmesg.sh file and it will create a dmesg log for you on the root of your sdcard. may be easier than typing it in terminal.
here is my log: http://pastebin.com/dPeEwFYr
winmo showed 80% when i booted android, android showed 77. this is on a siedio 1500mah battery. hopefully it will help with something. let me know if you need more info from me.
hamagc said:
another way to get the dmesg log that was advised to me some time ago was to make a txt file with "dmesg > /sdcard/dmesg.txt" inside of it and name it dumpdmesg.sh. when in android (using a file manager) execute the dmesg.sh file and it will create a dmesg log for you on the root of your sdcard. may be easier than typing it in terminal.
here is my log: http://pastebin.com/dPeEwFYr
winmo showed 80% when i booted android, android showed 77. this is on a siedio 1500mah battery. hopefully it will help with something. let me know if you need more info from me.
Click to expand...
Click to collapse
Thanks for the script thing, I will put it in my first post.
Thanks also for your log. Will have a look at it.
Jerome
still have wifi error
I used both fixes: battery driver and Battery driver + Diamond panel on/off "improvement" and with both of them I have Wifi error.
I attached dmesg for the first fix - battery driver
My device is DIAM100 with standard 900 mah battery
i can confirm this too. wifi still shows error.
Is the patch for Diamond only (reason to have "Diamond" on the name?)
I found it easier to just dump the file by doing this:
1. Open "cmd", type in "adb shell".
2. Type in "cd sdcard", then type "dmesg > dmesg.log"
3. Type "exit", then type "adb pull /sdcard/dmesg.log C:\Users\UserNameHere\Desktop\dmesg.log".
Also, check this post for my dmesg log. It's a whole day of me using my phone including charging and not, etc, etc..
http://forum.xda-developers.com/showpost.php?p=8097023&postcount=2281 <<
The only issues I've found so far are...
Sometimes the screen does not come back on. (Known issue, been about for a long time)
Touchpad seems to stop working randomly. I have to hit the up arrow on the "trackball" to re-enable the capacitive touchpad.
When plugging the phone into charge, it immediately reads 100% battery.
The good part is that my phone doesn't heat up to dangerous temperatures as it used to! It's a little warm, but definitely a huge improvement over the older revisions. I'm running the kernel with the Diamond patch, and I'm using an HTC Fuze with 3G Data turned on, Facebook, Handscent, Pandora, and GMail all running. I made a few phone calls in the process, too. The phone held together through all of that .
im'going to test it on my diam100!
edit: the battery seems to work better but wifi doesn't work and when i set the screen off the led start to blink like diamond is charging....this mean a battery consumption...!but this is the good way bro!!!!
edit2: android shows me 55% winMo 58%!!!
hey viruscrazy, are you working to get better battery life also?? I used your kernel update, kept the phone on standby (95% batt) throughout the night and saw low batt in the morning
But i got the correct battery %age and the panel worked well too
I just grabbed this tonight, and will DEFINITELY help to give feedback, it's one of 2 reason's I don't already use it daily (other being camera, i use alot), i know we got the fakecharge option, but it doesn't help to use and just have it go dead from actually being dead cause of no way to monitor it. This will be great to tweak it in time to be close to accurate as WM is. And get the patches officially added!!!
I am a little confused though, i over wrote my zimage, but the module's file was only like 400-500KB, versus the daily one i grab (when ever a new one is thrown up to DL.) is like 5MB in size. (current one i got is named "modules-2.6.27.46-01163-ge008466.tar.gz" and has 61 files, but on the site i got it from, it says "Kernels are built without debugging, for increase of speed." which i take it to mean a lot more compiled files are included to help speed.) I get them from http://balsat.hopto.org/.
I am still learning, but each time a new module file comes out, you DO delete the old one and use the new one right? Versus just ADDING the new one in your android directory (adding more and more doing this.)
I want to test, but don't want to mess up things that might make testing worse for you doing this'
EDIT- Ok, i havent's had time YET to follow the log instructions for info, BUT for now I ran it (didn't look at the battery level unfortunately, and will properly test more, but JUST wanted to give quick feedback since i already noticed a MMAASSIIVVEE difference in the metering of battery ALREADY.),
USUALLY ALWAYS after about 20-30 minutes (at most) it shows about 10-15% left. With new patches here provided on my CDMA Touch Pro, i was ACTIVELY was downloading and installing new games and utilities from the marketplace for over 3 HOURS, and it was showing battery power level pretty well, it showed 18% battery power left, i then rebooted into WM and battery power showed 34%, which isn't right, HOWEVER is WAY closer to showing proper battery levels compared to normal Android 2.2 builds by themselves. I will offer active helping support (using the shown proper proceedures.) in giving feedback with the rest of the helper here to help get us to the point where the battery level % is as closest to accurate as WM is. That is the 2nd only reason i don't use Android as my PRIMARY OS (forgetting about WM completely), Battery accurate level meter (TONS closer with current patches linked here), and CAMERA (as i use it a lot for normal images and family photo's and nephew
Hi there.
Fisrt of all, sorry for the wifi problem, I will have a closer look to the building process as it seems there is a problem with it. I don't use wifi myself so I don't test it but I will do for the next releases.
@m4f1050 : The diamond patch is for all phones but changes only affect the diamond phone. I made a different archive because maybe the panel stuff is not working correctly on all diamonds and people still want to test the battery stuff.
@gm112 : Thanks for the tip. I didn't put the adb method because on my diamond, the adb is not working all time. sometimes it will work (even using the Mass Storage profile under windows) and sometimes it won't work (even using the actyvesync profile)... Anywya, it's an easier way for people that have usb working on their phone.
@imrock : I'm not currently working on battery life but during my tests, I've seen a big difference between sleep mode using winmo (around 50mA drained over the usb cable) and android (arout 130mA drained over the usb cable). I've not yet measured the current drained from battery as I will have to make a small isolation between battery and contact.
@djdafreund : My modules are having problems because wifi won't work. When you download a new zImage, you should get the module that is provided with and you can delete the old one.
Thanks all for tests. I will at first try to figure out why I can't get the modules to compile properly.
Small questions : Do someone experienced problem letting the phone on charger all night ? I had a problem with one of my charger that will show charging but after a night, the battery is not fully charged, like if the charger stopped during the night. The other one charger works without any problem and the battery is fully charged. Maybe a problem with my charger but I want to be sure the problem is not coming from the android 2.2 (I just updated to 2.2 this week end, never had this problem before).
Hi,
I found the magic script that generates the modules correctly. I've updated the second post links to the new builded images + modules. Modules are not the smalles one without debug but I will make them withut debug for the next time.
Now, it's time for me to work on the rhodium temperature.
Please, continue testing,*especially for diamonds users that have problems with their screen.
Thanks
viruscrazy said:
Hi,
I found the magic script that generates the modules correctly. I've updated the second post links to the new builded images + modules. Modules are not the smalles one without debug but I will make them withut debug for the next time.
Now, it's time for me to work on the rhodium temperature.
Please, continue testing,*especially for diamonds users that have problems with their screen.
Thanks
Click to expand...
Click to collapse
Good job on the work, man! ..Question. Do you need a Fuze? I have one with a broken touchscreen, lol.
EDIT: After charging the phone a bit, it seems the battery level drops 1% every 8 seconds.
EDIT #2: It seems to get back in-sync with what Windows Mobile reports after dropping down to the accurate amount . After rebooting, the reported battery life was lower tahn what it actually was, and added up till it was fairly close to the actual value. It may jump around a few percentiles off, but it's much more accurate than ever before, it seems. My panel doesn't seem to "freeze" up like it did before, too. Waking up from sleep seems a bit more responsive, but that could be related to other things. I'd like to report that my HTC Fuze(RAPH110) does not get very much hot when it's charging and discharging ;P. I'll post a dmesg log in a few hours.
EDIT #3: Figured I'd mirror your kernel images!
http://gd-u.com/files/Android/HtcBatterySmem_1.tar.gz
http://gd-u.com/files/Android/BoardDiamondPanel_FullPatch.tar.gz
I to have the wifi error but at least 3g is still there. Im on rhod400, though as for the battery work that has been implemented at least so far seems to be a vast improvement. So far though its making me feel more like I know how much juice I got. Love the charging animation. Can tell for sure it's getting some charge. Thanks for the hard work you guys do.
Ok now I can confirm wifi working with newest update.
Sent from my MSM using Tapatalk
very exciting. thanks, the battery driver works fine on my diam100.
it's full charged when I charge it all night. I'd like to try it more ,I'll post it later if i find some problems
NOTE: I don't post kernels here anymore: look for my changes in the standard kernel now.
This thread is still useful for battery discussion, if you like.
I have gotten tired of seeing my battery go from 90% to 15%.
Why can't it go smoothly from 100% down to 5% or less, and back up again?
Why does nbheditor have to apply a 1.6 multiplier for battery capacity?
Can we get the temperature sensor working?
I'd like to get this fixed, and would welcome discussion.
First, in the new or old kernel, the battery status is managed by the file:
kernel/arch/arm/mach-msm/board-kaiser-battery.c.
I have several proposals:
a) Change the default KAISER_BATTERY_RATING to 1350, since the equations really do work out correctly, that the rating should match in mAh. Note: in the kernel, that's 2160 = 1350 * 1.6.
b) Add a thirty second maximum for voltage and current, before using them to guess the battery level. At first I used averaging, but maximum works better for old batteries.
c) When booting from HaRET, scale the battery level because Windows does it different. I don't understand how Windows does it, but I have figured out a scale factor that works.
d) When the ds2746 reports that it has lost power, assume that the battery may have been changed, and do a coarse recalibration based on voltage and charge current.
e) Eliminate the minimum of 15%: let the meter go all the way to zero.
f) Allow battery level to be set to any value at any time.
g) Report what the kernel thinks the capacity should really be.
h) Use ds2746 units directly since nbh-editor already scales mAh to units.
Also, questions:
1) How to convert the thermistor resistance (I think it is aux0r) to temperature?
2) Would be nice if the dynamically-adjusted capacity could be stored in flash. I don't know how to do that, but I know how to report it.
3) Should we have an option on the boot menu to manually set the battery level?
I have edited the new 2.6.34 kernel to act as I propose.
Since the modules must match the kernel version you are using, I have included modules separately.
Warning though that, although it seems to work properly for me, it might do bad things for you, especially to your phone's battery. In particular, the Polaris needs to be tested since I don't have one.
NBH file: for NAND install. Use nbheditor to edit, but put your battery's capacity under "advanced settings". For attempt #6, you can use the standard setting.
ZIMAGE: for HaRET install. Edit your default.txt to contain:
board-kaiser-battery.battery_capacity=2160 (your true battery capacity in mAh * 1.6)
board-kaiser-battery.haret_divisor=2200 (use a WinMo -> android scale factor of 1000/2200)
CAUTION: The 2.6.25 NBH images probably don't work. I'll have to learn how to make them!
NOTE: Attempt #7 and later are in the standard kernel, so are no longer posted here.
just setting this up on Incubus26Jc's Super FroYo 2.2 [Deodexed] [RLS15] [9/3/10]. I will let you know how it goes.
WOW, I´m glad somebody finally took this matter as serious as it is I´m not saying that others guy in here haven´t provided advice on this, it is just that nobody, afaIk hadn´t come with a "downloadable" solution, the only thing close to a real fix to me was to use the nbh editor and put the recommended capacity for my battery, it helped a lot to be honest cuz I used to get no more than 15 minutes of battery life, and after that I can use it for a few hours, unless I turn wifi and bluetooth of course, then it gets down to 15%, well I hope this really works cuz I´v been strugling with this for more than a month and I love android so much that I flashed on nand even though I knew about this problem, and I was about to give up on this, (was I?), thanks for this, I hope we get good results!!!
Isn't it that the latest kernel for froyo is 2.6.32? Is that your own build?
I wanna try your version. So far, how does all features? How is it compared to DZO's kernel?
More power!
Ok so I had lockups with Incubus26Jc's Super FroYo 2.2 [Deodexed] [RLS15] [9/3/10], I am loading up dzo's current Froyo and his 9-9-10 kernel for some base testing then I will install your kernel and updates and test again.
So, how do I install this? i mean, do I:
1- flash the new nbh.
2- install theandroidupdate.tar
done? I mean, do I have to do the whole "calibration dance" with it again or something? Or after i do this it will (in theory) perform as normal as it should? btw my battery is about a month old, so I guess if i put 2000 in advance mode, (not mah) it would be ok, right?
ps: I have donut installed, so I guess it might not work, but heck I´ve got to try this anyways, so I´ll go ahead and install it, in case it works, would you be able to tweak a donut kernel for us?. thanks in advance.
zack, how is it?
so far with dzo's latest froyo build and the attached kernel and update things have been very stable, however the battery is at 100% constantly. hopefully this will change as the battery is drained and recharged.
The kernel is dzo's with the experimental battery file.
Not ready for prime time. If your configured capacity is wrong, it gets calibrated as you run, but the calibration is not remembered when you reboot.
Sent from my Full Android on Vogue using XDA App
I'm looking for opinions on the individual questions in the first post. Especially, does anyone know how the kernel can store battery_capacity s it remains persistent after reboot?
If you search dmesg output for ds2746 you can see what the current capacity is.
Sent from my Full Android on Vogue using XDA App
I´ve installed it and after a while of letting both wifi and bluetooth on, it finally died and showed me 1% left and powered down all by itself, I had never seen 1% left on android, so that´s a good thing I guess, but after I connected the charger it started charging just fine, but in the console after typing dmesg it tells me that the battery has 4079mv and 54/3200 units, but I think that if the battery has 4079mv, it means it is fully charged, am I wrong? if anybody reads this please confirm this because I put it is still charging I don´t want my kaiser to blow up on me, lol. thanks.
ps: while charging it isn´t showing the amber led, but it has a red blinking led as when the battery is completely empty and not charger is connected (but in android the battery icon has the charging animation).
elander said:
I´ve installed it and after a while of letting both wifi and bluetooth on, it finally died and showed me 1% left and powered down all by itself, I had never seen 1% left on android, so that´s a good thing I guess, but after I connected the charger it started charging just fine, but in the console after typing dmesg it tells me that the battery has 4079mv and 54/3200 units, but I think that if the battery has 4079mv, it means it is fully charged, am I wrong? if anybody reads this please confirm this because I put it is still charging I don´t want my kaiser to blow up on me, lol. thanks.
ps: while charging it isn´t showing the amber led, but it has a red blinking led as when the battery is completely empty and not charger is connected (but in android the battery icon has the charging animation).
Click to expand...
Click to collapse
Do not worry. Nothing will happen to your phone. Electronic circuits inside the battery takes care of it. You have to repent attention to the current charge (mAh). When the value falls below 200mA, then the battery is full.
I've had two crashes (phone totally frozen, unresponsive) when on charger and full battery. Probably a coding error somewhere in this experimental file.
I'm also wondering which phone models use this source file?
Do some of them perhaps have different resistor values?
Do we have any historical information about why 10M Ohm was chosen as a resistor value, rather than 15 or some other value?
Millence said:
Do not worry. Nothing will happen to your phone. Electronic circuits inside the battery takes care of it. You have to repent attention to the current charge (mAh). When the value falls below 200mA, then the battery is full.
Click to expand...
Click to collapse
Thanks for replying, I know that the battery has some sort of sensor built in that tells the OS when it is full, but since we are dealing with calibration here (a.k.a I don't know when it is full or empty) I kinda freaked out a bit there, but thanks to your answer I feel (a little) relieve, the thing is that it's been plugged for more than two hours (I had to unplugged it cuz I had to return home from work) and dmesg still says something like: 4180 mv 145mah 50/100 (1604/3200 units) so when you told me about the current charge below 200mah you meant the number that appears on dmesg right after the (4180)mv? in this case it is 145mah, if so, does that means that the battery is already fully charged? cuz according to android it is only like 52% full. should I leave connected or should I unplug it (it is already unplugged just in case,lol). thanks.
It depends. It looks like your battery currently has 1002 mAh of charge, out of 2000 mAh. I doubt that you have a 2000 mAh battery. If you really have a 1350 mAh battery, you are more like 75% full.
I chose a lower limit than 200 mA for when the kernel thinks you are 100% full based on charge, since my phone charges at under 200 mA when connected to a computer, regardless of how full it is.
Please include what kind of phone you have. Otherwise I will assume you have a Kaiser.
n2rjt said:
It depends. It looks like your battery currently has 1002 mAh of charge, out of 2000 mAh. I doubt that you have a 2000 mAh battery. If you really have a 1350 mAh battery, you are more like 75% full.
I chose a lower limit than 200 mA for when the kernel thinks you are 100% full based on charge, since my phone charges at under 200 mA when connected to a computer, regardless of how full it is.
Please include what kind of phone you have. Otherwise I will assume you have a Kaiser.
Click to expand...
Click to collapse
I do have a Kaiser, and I do have a 1350mah battery, and as you said on the first post I edited the nbh to 2000 capacity using the nbh editor, so did I misunderstand first post and instead of 2000 capacity in advance mode I should have put 1350mah in simple mode, or should I have put 1350mah in advance mode in order to make android recognize the capacity of my battery? cuz as I see it now it seems it is the other way around now, cuz before android used to think that the battery was full when in fact it wasn't and now even when full android thinks it is not.
Put the battery rated capacity (1350) in the advanced setting, so it won't be multiplied by 1.6.
The conversion from dmesg units to mAh is: 625 x units / 1000 = mAh. Probably dmesg should show mAh so we don't have to calculate.
Sent from my Full Android on Vogue using XDA App
I am trying to use this kernel with cyanogen build, but it does not boot.
When I start haret it hangs. It moves the staus bar to the bottom of the screen and then freezes. (I can only reset via stylus os sim card cover)
The files I have in andboot are:
zImage-2.6.32-froyo-06-09-10_22 - the original zImage
initrd.lzma
zImage - the zimage with the battery fix
androidinstall.tgz - cyanogen install pack
androidupdate.tgz - update for the battery fix
startup.txt - modified for the battery test (zImage name and battery capacity)
haret-for-kernel-2-6-32.exe - haret
my startup.txt file is:
Code:
#alloctest 0x2000
set RAMSIZE 0x08000000
set RAMADDR 0x10000000
set FBDURINGBOOT 0
set MTYPE 1553
set KERNEL zImage
set initrd initrd.lzma
#
# The following kernel parameters are useful
# ppp.nostart - Set ppp.nostart=1 to disable starting the ppp connection on boot
# msm_sdcc.msmsdcc_fmax - The maximum frequency (in Hz) used by the SD controller
# pm.sleep_mode - The mode used when the phone is off
# 0=Power Collapse Suspend, 1=Power Collapse, 2=Apps Sleep,
# 3=Slow Clock and Wait for Interrupt 4=Wait for Interrupt
# Default is 1, use 1 for best power savings
# board-htckaiser.panel_type - Panel type used to power the panel off and on
# 0=Don't power off the panel (Default)
# 1=Sony 2=Topoly 3=Topoly (probably just the same as 2)
# lcd.density - Defaults to 160, 128 shows more on screen
#
set cmdline "ppp.nostart=0 pm.sleep_mode=1 mddi.width=240 mddi.height=320 no_console_suspend board-kaiser-keypad.atttilt=2 board-htckaiser.panel_type=1 hw3d.version=1 board-kaiser-battery.battery_capacity=1350 board_htckaiser.pmem_size=4 board_htckaiser.pmem_adsp_size=1 clock-7x00.a11=500"
boot
do I need to use another haret or initrd?
yesterday I left the phone connected to the charger all night and when I woke up (about 5hours and 30 minutes later) it had the green light turned on so it means that it got charged full, and dmesg gave something like this: 4180mv 28mAh and 100/100 (2076/2076 units) I gotta tell you, I had never seen such "low" values on units, its kinda strange, anyways I unpluggued it and went to work, so here I am, I´ll report back in a few hours after I stress this thing a bit to see if it really got all the "juice" the battery can take.
ps: I haven´t tried putting the 1350 (MAh) in advance setting, because since it says that it is charged (I know it may still be wrong) I decided to give it a go to see how it works with the current settings, after finishing testing this, I´ll try with 1350.
I don't know the HARET problem, sorry. Everything you are doing looks right to me. Perhaps you need to wait until this experiment is mature enough to be in a dzo kernel. Sorry!
Sent from my Full Android on Vogue using XDA App
The problem
I've been using CM10 on a Defy+ for a few days now. I've quickly noticed that I'm not getting exactly stellar battery life. Checking BetterBatteryStats indicated zero deep sleep, and "wifi_wake" as king of the wakelocks.
I realise that it's probably not wifi's fault but rather inconsiderate apps using wakelocks badly, still, something needs to be done.
Who is this for
People who, when their Defy+ has wifi on and connected, get absolutely no deep sleep in BetterBatteryStats, and wifi_wake or similar tops the kernel wakelock chart.
Does this work when wifi is on but not connected to an AP?
No idea. Theoretically, wherever you come near an AP there will be beacons and DTIM's flying around so it might work. But if you're not going to be connected you might as well turn wifi off, either manually or with an app. I can recommend Wi-Fi Matic, it uses a clever trick (uses GSM cell IDs to detect proximity to a known AP).
Possible solution (*ROOT* needed. This was ONLY tested on Defy+ with CM10.)
After some research I came to the configuration files for the TI wifi module, which are located in /system/etc/wifi and called tiwlan.ini and tiwlan_ap.ini. After some digging around and reading the Texas Instruments doc for the module (sprugt8.pdf), I'm prepared to offer a hack:
In tiwlan.ini change DtimListenInterval from 1 to 30.
In tiwlan_ap.ini change BeaconListenInterval from 1 to 10.
Reboot and see if BetterBatteryStats reports better (or any) deep sleep with wifi on and connected.
This combination gives me up to 85% deep sleep. YMMV because you probably don't have the same apps & background services installed as I do, usage patterns etc.
Increasing these values even further is possible (valid range is 1-50) but with only marginal improvements to deep sleep time and increasing issues with wifi (frequent disconnects in the case of weak signal). In other words, the connectivity problems aren't worth the extra 5% of deep sleep. Even so, if you manage to increase them (beacon in particular, I haven't tested large values as thorough as I did DTIM) and still keep wifi stable, please let us know.
Here's my findings for DtimListenInterval (on its own): 10 gives 25-30% deep sleep, 20 gives 42-50%, 30 goes up to 60%. Increasing it any further is pretty much useless, 50 (max) will get you to ~67% but expect heavy disconnects.
For BeaconListenInterval: 10 seems to be an upper limit when Dtim is around 25-30. Going over will cause disconnects even with very strong APs.
I haven't documented BeaconListenInterval on its own very rigurously, OR various combinations of the two, because I got bored of rebooting. Plus the fact I don't know when which of the two ini files will be used, so it's kinda like shooting in the dark. You're welcome to contribute your own findings.
But how do I edit those files?
You need root and any file manager worth its salt that lets you see the system files and edit them.
Is this dangerous?
I have no idea and I take no responsability. It's probably a good idea to make a backup of those files, and, even better, slap the backups into a flashable zip on the root of your sdcard. In case something bad happens you can reboot in recovery and install the good versions back. Example flashable zip and tutorial here. Remember, they go into system/etc/wifi/.
Warning: I used this on CM10 and Defy+
If you attempt it on anything else all bets are off. If the files are not there, you can't find the keywords and so on, you're on your own. Still, you can read the explanations below and try to see if anything helps.
Explanations
tiwlan.ini and tiwlan_ap.ini control the behavior of the wifi module. I have no idea why there's two of them (or more, on some devices), but after poking around I've determined they must all be modified because they are used in different cases. (Different apps? Different circumstances? Different hardware parts? If anybody can enlighten us it would be super.)
These config files are similar, but different in some key aspects. Both my files have dot11PowerMode=0 which means "auto", which means that it looks at AutoPowerModeDozeMode to determine if it uses short (2) or long (3) doze mode for power saving. tiwlan.ini has short mode, tiwlan_ap.ini has long mode. This in turn means they use different listen intervals: short mode (tiwlan.ini) observes BeaconListenInterval, long doze (tiwlan_ap.ini) observes DtimListenInterval. Which is why we modify different properties in each file.
What are beacons and DTIMs? Simply put, beacons are a signal broadcasted by wifi access points periodically to let wifi clients they're there, and DTIMs are packages of special information about the AP. The most typical setup for most wifi APs is to send a beacon every 100ms i.e. 10 times a second, and a DTIM after every beacon, or at most every other beacon.
The default settings of "1" for BeaconListenInterval and DtimListenInterval means that the phone watches for these signals 5-10 times a second and, well, it's no wonder it doesn't get any sleep. Mind you, this does make for superb wifi connectivity, at the expense of battery life.
BTW, you can probably achieve similar effects by tweaking your wifi router to send beacons/DTIMs less often – all the wifi devices around your home will probably thank you. But of course you cannot control wifi APs everywhere you go, and it might backfire! Read below.
So why didn't "they" put better values on these settings?
For exactly the reason in the above paragraph: because you don't know what settings a particular AP you're trying to use has.
Here's an example. Say somebody tweaked their AP and put 10 beacons a second and a DTIM every 10 beacons. This means a DTIM once a second, then you come along and tweak your phone to only wake up the wifi connection every 30 DTIMs. That means 30 seconds, time in which the connection will most likely time out.
You cannot predict this kind of stuff so there's no safe default values other than "1", which mean "react as quickly as possible to any beacons/DTIMs we get because we don't know when we're getting another". My tweak is based on the assumption that the AP emits 10 beacons a second and DTIM with every beacon (beacon interval 100ms and DTIM interval 1). If the AP you use has been tweaked for more relaxed values these ini tweaks may backfire and cause disconnects!
Other potentially relevant ini settings
Here are some more interesting settings which could be further tweaked to get even better results:
PowerMgmtHangOverPeriod
AutoPowerModeActiveTh
AutoPowerModeDozeTh
BeaconReceiveTime
See the TI pdf for details.
That's all folks
Thanks for reading this far. Please contribute if you have insights, if I said stupid things or if you find settings that seem to work better.
Hello,
My phone began to get hot since 1 week and the battery drains very quickly. I investigated and found out that it's the ksm deamon that is causing that (30% + cpu usage all time). The ksm deamon scans all the memory at an interval to do things with it... It is a normal linux process but :
The problem is that the interval is set to 20ms ! And that the run value is at 1. The files are here : /sys/kernel/mm/ksm/run
I changed run from 1 to 0 with the terminal emulator, it fixes the problem, but then it goes back to 1 after some minutes. Same for the interval, I set it manually to 10000000000000000000 and then it goes back to 20.
It's like there's a virus changing the value or something like that.
Help me please, I can't use my phone anymore, it lags, gets hot and the battery drains very quickly :crying:
Thanks.
I'm having the same damn problem on my oneplus. It get's so hot it causes the touchpad to stop working and the phone becomes unresponsive and I have to force shutdown. Did you find a solution to this problem? I might try a custom ROM on here, I didn't have this problem with my last oneplus so not sure if it was a recent kernel update to CM11 that did this or what.
skini26 said:
Hello,
My phone began to get hot since 1 week and the battery drains very quickly. I investigated and found out that it's the ksm deamon that is causing that (30% + cpu usage all time). The ksm deamon scans all the memory at an interval to do things with it... It is a normal linux process but :
The problem is that the interval is set to 20ms ! And that the run value is at 1. The files are here : /sys/kernel/mm/ksm/run
I changed run from 1 to 0 with the terminal emulator, it fixes the problem, but then it goes back to 1 after some minutes. Same for the interval, I set it manually to 10000000000000000000 and then it goes back to 20.
It's like there's a virus changing the value or something like that.
Help me please, I can't use my phone anymore, it lags, gets hot and the battery drains very quickly :crying:
Thanks.
Click to expand...
Click to collapse
into_311 said:
I'm having the same damn problem on my oneplus. It get's so hot it causes the touchpad to stop working and the phone becomes unresponsive and I have to force shutdown. Did you find a solution to this problem? I might try a custom ROM on here, I didn't have this problem with my last oneplus so not sure if it was a recent kernel update to CM11 that did this or what.
Click to expand...
Click to collapse
I kept disabling it manually with the terminal and was monitoring my phone with a process manager. Then it stopped by itself I don't know how....
But it may come back one day I really don't know why, I didn't even uninstalled an application. This is very weird and it's a core functionnality of linux, why is it designed like that ?
skini26 said:
I kept disabling it manually with the terminal and was monitoring my phone with a process manager. Then it stopped by itself I don't know how....
But it may come back one day I really don't know why, I didn't even uninstalled an application. This is very weird and it's a core functionnality of linux, why is it designed like that ?
Click to expand...
Click to collapse
I've noticed KSMD only pegs out like crazy on my phone when it's active. While the phone is asleep it does nothing.
I can tell it's not at all related to running the TOP process either to monitor things because if you do a ps -ef --sort +time, you can see KSMD process constantly climbing a few seconds of a time of CPU use the longer your phone uptime\Screen-on-time goes on. It's not growing at a massive rate, but like 1 second of CPU time for every 30 seconds of screen on time.
I did a little digging and apparently this is an issue on many Linux distributions and is generally seen as a bug from the user community(unsure how the dev community feels about it, but it's pretty old.. you'd think they would address it by now). It's possible that the Gamma kernel is based on a Linux kernel distro that has that bug in it.
[Edited 07/01/2021]
The issue is inconsisten, and so the solution as I've been unable to repeat -consistently- the failure of the RT.
It's been described as "brightness control breaks if you do not se it manually right after boot, before suspension/sleep", but this is not accurate, as I've been able to use it normally even without tweaks or manually changing after boot. And sometimes the same (repeated and confirmed) steps produce the issue. So, it's not clear, not consistent, not repeateable 100% each time.
The brightness issue IS NOT SPECIFIC OF Windows 10 on ARM32 (Surface RT), as it's been present since Windows 8.1 on diff computer brands. While it affects desktop computers as well, it seems to hit harder on laptops, specially if the "sleep when you close the lid" is activated.
After reading quite a bit, many users report solving this issue on their computers (non Surface RT) removing the sleep when you close the lid, removing the stock display drivers and updating them, remove dimming the display to save power, and removing the automatic brightness adjustment. However none of this seems to work on the Surface.
I created some scripts / instructions for powershell (below) to change the brightness at startup, but it doesn't work 100% as expected, not all the times. So there is a difference between changing the brightness manually, VS doing the same with a script.
I managed to clear this issue after restarting the display driver manually, it works. It's a simple "disable / enable" display (NVIDIA Tegra 3), and you will hear the beep of detected hardware, that's it. Also created some script/instructions to do this and it works, but it shuts down the audio. I removed the -like on the device get to avoid affecting similarly named devices, but it's not that... as I also used -eq (equal), getting the device that exactly matches the name given, and it also shuts down the audio. It shouldn't but it does.
That's all I know for now, it's some strange issue.
************************************
[solution found, the first post keeps the first attempt. If the following doesn't work for you, then try the new one at the end.]
I managed to upgrade my Surface RT 1 to Windows 10 and yes, things work better this way, BUT the brightness control has some issues.
Problem:
The tablet starts from off state with brightness at 100% regardless of the last state.
While this has happened on most cases, I noticed sometimes it starts at 0% without user intervention.
Yes you can perform brightness adjustments BUT, if you don't do so, it breaks when the devices goes to sleep and you won't be able to change the brightness until restart.
Your experience might be different, I asked here and there, and it seems some users had a diff experience, but they seem to be just rare exceptions.
Runaround: right after first boot from off state, perform whatever adjustment and you will keep the freedom of changing the brightness at any time even after sleep. This is what I was told and tested myself, it works, but I'm not fully sure about this as I would need more time to test my tablet.
My fix:
Create a powershell script with this code inside:
Code:
$tempov = Get-Ciminstance -Namespace root/WMI -ClassName WmiMonitorBrightness;
$original = $tempov.CurrentBrightness *1
$valt=11
if($original -gt 30){
$blink=$original-$valt
}else{
$blink=$original+$valt
}
(Get-WmiObject -Namespace root/WMI -Class WmiMonitorBrightnessMethods).WmiSetBrightness(1,$blink)
(Get-WmiObject -Namespace root/WMI -Class WmiMonitorBrightnessMethods).WmiSetBrightness(1,$original)
You will have to enable running powershell scripts, in my case I opened a window, tried and was asked to enable it or not, I said yes, that's it. And you can run this script at any time. But the idea is adding it to the Task Scheduler and set it to run right after booting, this mean "at startup".
Originally I made the script set the brightness to 30% this way:
Code:
(Get-WmiObject -Namespace root/WMI -Class WmiMonitorBrightnessMethods).WmiSetBrightness(1,30)
But if the tablet wakes up at 100% or 0%, it won't be pretty. So I changed it to the code posted at the beginning of the thread. What it does is...
It gets the current brightness value
Then perform a simple calculation to know if it can add or substract
Then applies the new value (thus a change in brightness)
And then goes back to the original value applying the original percentage
This provides a more pleasant visual experience, a slight blink, almost unnoticeable.
Why those values on the code? long story, I don't think you want to know the details, what? ok, 10 doesn't always work, 1, 2, 3, 4, 5, etc don't work, on some ranges changes of 1, 2 values don't work (I don't know why), and the most safe way is to do so using 10 as the base units for change in brightness (don't ask me why, I tested over and over), so 11 is the safest value. I could explain more about my tests but I don't want too, it's too long and boring and wouldn't make a difference, the code above works, if you want something different then you are free to play with the code yourself.
IMPORTANT: to avoid seeing a window opening while running the script, set the task scheduler to "Run wether user is logged on or not". This would require your password, if you don't have one on your account then I don't know what to do, I tried but the thing insisted so there you go.
I'm not an expert on Task Scheduler so please don't ask, research yourself, don't want to be rude, I just don't know enough details to guide you, what I posted here WORKS.
Already tested (and will continue testing) and it works, the tablet does a light and almost unnoticeable fade-blink and the brightness control is preserved after sleep.
IF... you manage to add this feature to your Surface RT without errors, then report how the code helps or not your brightness control. My case = perfect. Will continue testing.
I think this is THE BEST method because even if you modify the brightness yourself, the code will be executed and it would be just slightly noticeable, so it's the best option regardless of the current brightness value.
Previous script works at times, don't blame me, I took my time to read, research and test, it's not that simple as "brightness gets broken after suspension", and it's not as easy to solve as "set your custom brightness level right after first boot", at least testing over and over prooves it.
But this one is bullet proof (PowerShell)
Code:
$d = Get-PnpDevice| where {$_.friendlyname -like "NVIDIA Tegra 3*"};
$d | Disable-PnpDevice -Confirm:$false;$d | Enable-PnpDevice -Confirm:$false
What it does is, it gets the screen device and disabled it and enables it again, the screen will just blink but the brighness control is fully restored, you can run it at any time it gets stuck. Not pretty but efficient. You could even set it on the task scheduler to run after wake up (I prefer not to).
Is this method still work?