[Q] time taken to get full charge - Galaxy S II Q&A, Help & Troubleshooting

[Q] time taken to get full charge - Galaxy S II Q&A, Help & Troubleshooting

i realized that my charging time for my phone is quite slow, i would like to increase the voltages or something on my phone to make it faster, does anyone know how?

zincsnow said:
i realized that my charging time for my phone is quite slow, i would like to increase the voltages or something on my phone to make it faster, does anyone know how?
Click to expand...
Click to collapse
Been a few threads about this, certain phone chargers will charge your phone quicker but not that much quicker maybe 20/30 mins less, 3 hours is pretty much the norm from 0 to 100%.

but i read about it somewhere that there is a certain setting you can tweak to change the voltages or something to make it charge faster, have you come across that?

zincsnow said:
but i read about it somewhere that there is a certain setting you can tweak to change the voltages or something to make it charge faster, have you come across that?
Click to expand...
Click to collapse
I cant say i have mate and id be interested in this myself if it proved to be safe and worked 100%.

Use a kernel that supports increased charging current. Use Siyah kernel for example.
http://forum.xda-developers.com/showthread.php?t=1263838
Then use an init.d script or Voltage Control app from market which has the interface to increase AC,MISC,USB charge current.
Stock values are 650 450 450 [AC:650mA, MISC: 450mA, USB: 450mA]
Try 800 800 450. Charge will be quicker.
note: DO NOT increase USB current beyond 450 and do not increase AC and MISC currents beyond 1000.

Don't screw with it, lithium ion/polymer batteries need proper charging current and voltage, too much will damage or even ignite the battery.

I've been using 800/800/800 ever since siyah put it in his kernel, takes 3 hours to charge an empty battery, 4 hours with stock settings.

droidphile said:
Use a kernel that supports increased charging current. Use Siyah kernel for example.
http://forum.xda-developers.com/showthread.php?t=1263838
Then use an init.d script or Voltage Control app from market which has the interface to increase AC,MISC,USB charge current.
Stock values are 650 450 450 [AC:650mA, MISC: 450mA, USB: 450mA]
Try 800 800 450. Charge will be quicker.
note: DO NOT increase USB current beyond 450 and do not increase AC and MISC currents beyond 1000.
Click to expand...
Click to collapse
thanks man

Related

To undervolt or not to undervolt?

So this is a development idea...
I thought about this the other day and realized that under volting could be causing my battery to die quickly...
Here's why.
V = I * R
Where v = volts, I = amps, R = ohms.
P = V * I
Where P = (power)watts
I know some of you are going to think that this doesn't belong in development, but here me out here.
So if the processor uses 1.5 Watts and we decrease the voltage, this means that the processor needs to increase current to maintain that power. This equates to reduced battery life.
I'm just suggesting that undervolting may be causing the low battery life. If you know better feel free to tell me I'm wrong, but please explain the mechanics of what is going on not just your theory.

This question is over my head so I'll refrain from speculating directly on your theory. But real-world results with my undervolted Stupidfast 1.54 kernel gives me much better battery life than stock. Yes, this may be due also to the unbloated-ness as well so I'm not 100% certain the undervolting is the main help here

Well....I dunno how this applies to CPUs but.... I used to be a car audio installer/buff and when we noticed voltage sagging to an amplifier, the amplifier would compensate by pulling more amperage at the lower voltage. It never seemed to make much different to the batteries, but it did make the amps run much hotter...so....
Again, not sure if it would tie in, but....

Hmm I've never thought about that. From my RC knowledge the most efficient set ups are the ones that use high voltage but low amps.
I may have to try a OV kernel and see if I notice a difference...
Sent from my Samsung Fascinate running BH3.0, DL09, 125mv undervolt Voodoo5 using SwiftKey and Tapatalk

As a disclaimer, I have not performed any formal reading on this topic, these are just my idle ramblings.
My contention has been that you only enjoy the benefits of a UV kernel if you are a certain type of user.
If you are performing CPU intensive tasks, you reap the most benefit from the UV kernel because it needs less power to run at 1 GHz (or whatever the maximum clock speed is set to for that kernel).
If you spend alot of time idling, for instance reading interspersed by web requests, you are spending most of your time at the minimum clock speed. With the stock kernel, that is set to 0.1 GHz. With a UV kernel, the minimum clock needs to be set to something higher to keep the CPU running. You may be able to estimate what this speed needs to be based on the fundamental power calculations in the OP.
The governor quickly changes your clock speed based on your current usage & requirements. To make optimal use of the CPU governor, it should have access to the broadest possible range of speeds (without going higher than is useful/safe). Unfortunately, undervolting a kernel sacrifices some of the lower end of that range. Therefore, many users see much improved battery life, while others (like me) experience noticeably diminished overall performance from UV kernels.
Swyped w/ XDA App. When in doubt, mumble.

P=V*I
The processor does not draw a constant power, but it does have a minimum. The point of undervolting is bringing the power consumption to that minimum within the phones physical environment and user expectations of functionality.
So...
You are right.
However, processor frequency is dependant on current. Thus if you are undervolting to save battery life then you will need to keep your frequency the same or lower to notice a difference. If you are overclocking (increasing current) and undervolting then your P stays the same so the user ends up feeling the battery life to be the same or worse.
Facundo

Are there any standard or over volt kernels available so we can test this theory? It seems as though all the kernels available are UV.
Sent from my SCH-I500 using XDA App

would you like a standard voltage kernel to test?

Personally I see worse battery life on UV kernel. My usage mostly equals to dumb phone, with email sync and moderate web browsing.
I would change formula to I = V/R, which will read as current is directly proportional to voltage and inversely proportional to resistance. That makes obvious that reducing voltage we decrease current. However one point to note here is that this law is for PASSIVE conductor, which is obviously not our case. I would not speculate further, because we do not know what king of power conversion happens. It might simply turn out that conversion is not efficient at lower voltages. Google desktop power block certifications/efficiency to see whet I mean.

I compiled some kernels so you folks can play with it. I SERIOUSLY doubt you will get better life with my stock voltage vs. undervolt, but give her a shot.
Undervolted
Voodoo
http://adrynalyne.us/files/kernels/adryn_test2_0116_fascinate_voodoo5.zip
Nonvoodoo
http://adrynalyne.us/files/kernels/adryn_test2_0116_fascinate_novoodooo.zip
Standard voltage
Voodoo
http://adrynalyne.us/files/kernels/adryn_sv_0116_fascinate_voodoo5.zip
Nonvoodoo
http://adrynalyne.us/files/kernels/adryn_sv_0116_fascinate_novoodoo.zip

I'm giving the SV Voodoo kernel a try right now.
Sent from my Samsung Fascinate running BH3.0, DL09, and Voodoo5 using SwiftKey and Tapatalk

I thought about this as I thought about power lines. They use super high voltages to reduce the amount of power loss through the lines.
Anyways, sounds good, I'll test it out. I'd have to get a baseline. I guess I'll charge my phone right now and test out the regular voltage.
I'll let you guys know tomorrow the differences tomorrow.

In all honesty, I don't ever feel that I get more juice out of unvervolt kernels and I've been using all kinds of kernels since the release of MT3G.

Thanks for the standard voltage kernel!
I do appreciate you efforts in continually optimizing these, having a baseline to compare to just makes it all the more wonderful.
I will give the SV (standard voltage) a day or so of testing and then compare the UV against to make the test fair. With ten minutes of use ^^, it is already a great contender for my daily driver. I had gone back to 11/29 from 12/30. 11/29 was a terrible pairing with DL09; my GPS was unusable.
$ busybox md5sum ad*.zip
aea1047f3b2d33e759064d47cc8cac27 adryn_sv_0116_fascinate_novoodoo.zip
Works great!
Swyped w/ XDA App. When in doubt, mumble.

I wonder if android has battery test application, just to be put everything in the same play field? It's kind of pointless to compare subjectively.

Well, I tried to be objective with this test I just did.
Here were my conditions:
Charge to full, write down the time it was at full charge which wasn't 100%.
Let it sit for one hour.
Write down the charge.
SV Conditions
Starting charge 99%
Ending charge 97%
UV Conditions
Starting charge 98%
Ending charge 96%
The results...
SV - 3% discharge / hour
UV - 2% discharge / hour
Errors analysis:
There are several issues with this test because they were not even at the same charge at the start. Batteries have their maximum charge at 100%, and the rate of decrease is not a linear decrease. More testing is needed to compare the results.
Also the duration is not long and other factors have not been considered such as background applications refreshing on their own. I will have to test for 8-10 hours of each at idling tomorrow to get an accurate measurement.
Currently, I'm still on the UV kernel and I'll publish my results tomorrow of the UV over the 10 hour period.
Then I'll try to not use my phone throughout the day and test the SV.
It would be nice if someone could test the SV and UV with moderate usage and write down the initial charge, final charge, and the duration between the measurements. And another using heavy usage.
Thanks.

RacerXFD said:
SV Conditions
Starting charge 99%
Ending charge 97%
UV Conditions
Starting charge 98%
Ending charge 96%
The results...
SV - 3% discharge / hour
UV - 2% discharge / hour
Click to expand...
Click to collapse
Im confused with your math here...

Yeah, your math is off.....
Sent from my SCH-I500 using XDA App

RacerXFD said:
So this is a development idea...
I thought about this the other day and realized that under volting could be causing my battery to die quickly...
Here's why.
V = I * R
Where v = volts, I = amps, R = ohms.
P = V * I
Where P = (power)watts
I know some of you are going to think that this doesn't belong in development, but here me out here.
So if the processor uses 1.5 Watts and we decrease the voltage, this means that the processor needs to increase current to maintain that power. This equates to reduced battery life.
I'm just suggesting that undervolting may be causing the low battery life. If you know better feel free to tell me I'm wrong, but please explain the mechanics of what is going on not just your theory.
Click to expand...
Click to collapse
I'm an electrical engineer, and none of this makes any sense. V=IR is for current and voltage going through/across a constant resistor. Transistors are not constant resistors. The current through a Metal Oxide Semiconductor Field Effect Transistor (MOSFET), the type of transistor that is in basically all ICs, is always in positive relation to the voltage, at least for the purposes of this basic explanation. Decreasing the supply voltage, which is you can consider to be the VGS of a transistor for a simple analysis, is always going to decrease the current as well. Thus, depending on the range of operation of the MOSFET, decreasing the voltage will also decrease the current and thus power will decrease more than linearly. Less current means that the transistors will charge and discharge capacitances slower, and that's why you need voltages for higher clock speeds and overclocking IN GENERAL. Device physics is really weird.
Now, someone else was saying that maybe because you undervolt it less current goes through which means it needs to spend more time in a higher clock state. This is completely false, the current going through it has nothing to do directly with the amount of work done. Yes, you need more current for faster clock speeds, but at a given clock speed, it doesn't matter how much voltage or current there is and how fast the individual parts of the circuit work, as long as the longest delay in any part of the circuit is less than the clock rate. If it's longer than the clock period, then your circuit is no longer going to function and you'll have instability and crashes, but there is a bit of wiggle room designed into these circuits because each chip can be different. That's why you can overclock or undervolt a CPU, because obviously if it was designed to run at the fastest clock speed possible, any little variation in supply voltage, temperature, manufacturing process/lithography (which is very common) would cause your CPU to completely not function. You have to design your circuits to be tolerant of some amount of error from many sources (even cosmic radiation in some cases), otherwise it won't just be slow, it won't function at all. Logic circuits are clocked to synchronize data going through the circuit, and if the timing constraints aren't always obeyed you'll get wrong answers which would probably crash your OS. Undervolting will never cause the CPU to do less work in one clock cycle, unless you undervolt it too much, in which case things will likely blow up in your face.
Sorry for the wall of text, but hopefully this will clear up some stuff. And in the future, please stick to what you're good at and don't try to speculate things based on one formula that you heard sometime in physics while you were half asleep, or something some CSR told you to get you to shut up. Believe it or not, the people who are designing CPUs and writing/modifying kernels and operating systems actually know what they're doing and you're not going to suddenly realize that they're going about their business wrong because of something you learned in high school.
Edit: One other thing. The calculation of percentages of battery life is a bit of guesswork on the side of your phone, trying to determine via statistics what a voltage level means in terms of percentage of battery life. Battery voltages don't drop linearly as you use them, and can be affected by many things, such as whether it's plugged in to the charger in particular. That's why you see a drop immediately when you unplug your phone, and why looking at 2-3% differences is completely meaningless. The better way to test would be to actually see how long you can use it with an equal amount of work being done on each voltage, which is hard to do in real life. Too many variables are present in today's smartphones, what with background tasks and data coming and going and the like. And wireless radios are a huge battery drain, especially when you're receiving a weak signal. I would advise people to just carry a charger or usb cable with them and top up your battery when you need to rather than worry so much about small differences in battery life. You'll save on a lot of stressing .

Thanks for the explanation. I'm an aerospace engineer. I did have to take a few courses in EE, but nothing to your level. So please let me know if I'm completely off on my testing.
I am pretty sure that the Devs know what they're doing, but I was getting tired of my low battery life and I was willing to test this theory of mine out for them. Again, seriously if I am completely out of the park in terms of this testing, let me know. And I'm ok with being called stupid as long as you teach me what I did wrong...
Yea, I completely forgot how with transistors, the math regarding voltage is handled differently than through a resistor. Are you telling me that the battery life will not be different between standard voltages and under voltages?
EDIT: I understand what you're saying about lowering voltage lowers current because the current has a linear relationship with the voltage in a MOSFET chip. Thanks, I had to read that like 5 times to understand and remind myself.
This is a complete waste of my time at this point because I know what's going on, but I wish to share my results anyways...
Ok here's where I got with the testing since last night. I realize that battery life is nonlinear. But i figure this is better than nothing.
But I did complete 8 hour test of SV at idle.
Starting charge percentage 94%
Ending charge percentage 82%
Which results in 1.5%/hour discharge rate at idle.
Will do the undervolt today. I'll document that in roughly 8 hours.

[Q] Max CPU temperature?

Anyone have a good estimate of what the max safe temperature for the armv6 cpu is? I have setCPU configured to throttle back at 46 degrees, but could that limit be safely set higher?

STaria said:
Anyone have a good estimate of what the max safe temperature for the armv6 cpu is? I have setCPU configured to throttle back at 46 degrees, but could that limit be safely set higher?
Click to expand...
Click to collapse
Curious about this too, I have mine at the default of 50 °C
Sent from my Liberty using XDA Premium App

What I was able to find out in the past was that a mobile phone cpu could safely reach up to 80-90°C. The motherboard and/or components on the motherboard can start to fail around 65-70°C. And for a lithium-ion battery it's best to keep the temp under 50°C for longevity, 60°C is absolutely going to affect battery life. I was never able to find anything specifically on the armv6 or where exactly the temp sensor is on the Aria. I have setCPU configured to throttle back at 46°C, and I have the charging profile throttled back because of the heat generated when charging.

Just remember that the temps being monitored are the battery temps. The aria doesn't have the ability to measure actual cpu temps.
Sent from my cm7 Aria.

CallMeAria said:
Just remember that the temps being monitored are the battery temps. The aria doesn't have the ability to measure actual cpu temps.
Sent from my cm7 Aria.
Click to expand...
Click to collapse
Right, so the CPU could probably take higher, but it's the battery that's the limiting factor.
I think I'll keep the profile as it is now, by the time the battery hits 46 that's hot enough. Don't need my Aria bursting into flames from thermal runaway.

wantabe said:
What I was able to find out in the past was that a mobile phone cpu could safely reach up to 80-90°C. The motherboard and/or components on the motherboard can start to fail around 65-70°C. And for a lithium-ion battery it's best to keep the temp under 50°C for longevity, 60°C is absolutely going to affect battery life. I was never able to find anything specifically on the armv6 or where exactly the temp sensor is on the Aria. I have setCPU configured to throttle back at 46°C, and I have the charging profile throttled back because of the heat generated when charging.
Click to expand...
Click to collapse
Thanks for the info
Sent from my Liberty using XDA Premium App

[Q] Why 480MHz? Can't find original posts

Hello,
It's a well know 'fact' that our P500 draws the same amount of power when clocked at anything below 480MHz, so underclocking it below 480MHz brings no battery benefits.
I have been trying to find the reason for this, but I can't find the thread / post in the search that details the reasons for this and how it was tested. My guess is that it's buried in one of the many bloated development threads... If someone can point me in the right direction that would be great.
Cheers!

I know this thread has a quote of this post and that this is a well known information but, besides this community common knowledge (by which I'm very grateful), I also can't find any specific data on this matter.
I even found this thread that aks the same thing, but it has no answers.
So it would be great if someone could give us a bit more information about this.
Thanks in advance!

480MHz and below use the same voltage. It takes more battery to jump from say 245 to the max freq

InfiniteRisen said:
480MHz and below use the same voltage. It takes more battery to jump from say 245 to the max freq
Click to expand...
Click to collapse
Yes, we all 'know' this but where did this information come from?

This post shows that it is a general MSM7x27 'feature' that all frequencies below 600MHz use the same voltage. This is where we assume this to mean that it uses the exact same amount of power whether it is running at 122, 245, 320 or 480MHz, so we're taking a speed hit for no power benefit.
Does anyone knows of any benchmark tests to confirm this? I might try some tests this week, set the min/max MHz to the same value and run a program to keep the CPU at 100% and see how long it takes to drain the battery (perhaps a huge pi calculation or something).

Which do you value more, source of information or proof now?

InfiniteRisen said:
Which do you value more, source of information or proof now?
Click to expand...
Click to collapse
Surely that's the same thing, a good source should also contain proof of the claims it is making...
I'm not saying it's wrong, but if nobody has tested it we can't be sure, right?

adfad666 said:
Surely that's the same thing, a good source should also contain proof of the claims it is making...
I'm not saying it's wrong, but if nobody has tested it we can't be sure, right?
Click to expand...
Click to collapse
On my personal experience, i would actually say 245mhz consume less battery than 480mhz. But I still prefer the latter as it's a bit more speedy. On battery life, it's just a <1% difference between the two.

as far as what ihve read!!people say it takes infact more power consumption when we underclock very low frequencies like 122 ,since it takes more work for the phone to operate in a laggy state with very less cpu frquency ..and thats the reason i think(not sure) why we are asked to have a minimum of 480mhz frequency though i prefer 320

Test setup suggestion:
Test 1 = Idle
Set to 480/480 set to airplane mode overnight and look at battery drain.
Do the same for 245/245
Compare results
Test 2 = Intermittent load
Set to 480/729- test using on/off series of tests not 100% all the time. You want the governor to scale frequently during the test
Same test above but @ 122/729
Compare results
This will give you 2 conclusions
1 - 480 at idle does/doesn't drain battery as much as 245
2 - Increased scaling does/doesn't increase drain battery.
The longer the phone is awake the more it drains battery. Also take note of how long it takes to complete test 2.
**EDIT**
Intel has done extensive laboratory testing showing the results of Speedstep and the results carry over to ARM and governor scaling.
I'm inclined to follow the crowd on this one, no increase in voltage = no increase in power draw. That's scientific fact.
Increase in frequency will increase heat. Unnecessary scaling will also increase heat. Increased heat leads to shorter battery life, consequently overtime the battery can't hold as much of a charge. So again, nothing decisive here to make me change my mind.
If you still want to, then proceed with the tests above.

Boinc calculation

GT-I9100 International
Is there any rom / kernel you could recommend for top output for 24hour constant calculation. (Specifically the "boinc" app)
I would like max CPU output and i wouldn't want heat throttling since temperature and battery wont matter.
also freezing would suck since i probably wont be looking at it much so i might not notice for a few days.
Also i have a stock battery and stock charger (eu 210). I wouldnt want the drain to overpower the charger leading to downtime.
Ive got neatrom with the roms included kernel but it seems to lower cpu frequencies quite aggressively.
thinking about slimsaber
also with most governors i was getting 800mhz which was kind of annoying. Performance gov would reduce to 200 after a while, i believe because of heating.
Finally slp stays at 1200 and doesnt seem to downclock. Still i feel there is room for improvement.

Remove Thermal Throttling For Good

For you gamers out there
Finally I solved the thermal throttling problem in this lovely device.
BEWARE **YOUR PHONE WILL HEAT MORE**
first using your root explorer go to system/etc, you will find 3 files related to thermal throttling:
1. thermal-engine-8996-normal.conf
2. thermal-engine-8996-perf.conf
3. thermal-engine.conf
These files related to the configuration in the settings->power manager->power plan.
If you chose performance then your phone will use the perf.conf
If you chose Smart power-save your phone will use normal.conf
Edit:
After further investigation it seems that no matter what setting I choose the file that is active always the normal.conf.
perf.conf seems not affecting anything at all. Needs futher investigation.
That is the mechanic, now for the fun part:
Open the file you wish to edit using text editor.
The key is in these two sections
Code:
[SKIN_CPU_MONITOR]
#algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 59000 62000
thresholds_clr 56000 60000
actions cluster0+cluster1 cluster0+cluster1
action_info 1400000+1700000 1500000+1824000
override 5000
[SKIN_GPU_MONITOR]
#algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 41000 42000
thresholds_clr 39000 40000
actions gpu gpu
action_info 510000000 401800000
override 5000
As you can see the values above are a little bit different from yours, it's because I already change a bit.
The parts you should take consideration are thresholds, thresholds_clr, actions, and action_info.
Thresholds means in what temperature the device should throttle
Thresholds_clr means in what temperature the device will stop throttling
Actions mean which item to be throttled
Cluster0 = Little CPU
Cluster1 = Big CPU
GPU = GPU
so for example above
thresholds 59000
thresholds_clr 56000
actions cluster0+cluster1
action_info 1400000+1700000
Means it will start throttling at 59 celcius and stop throttling at56 celcius, the item to be throttled are little CPU which become 1400 mhz and big CPU which become 1700 mhz
You can add many parameters just by using spaces like example above.
Okay, hope it helps. If you confuse, just use my values above and unleash the 60fps beast. Muahahaha
Edit:
This is my current setting
Code:
[SKIN_CPU_MONITOR]
#algo_type monitor
sampling 1000
sensor tsens_tz_sensor11
thresholds 48000 50000
thresholds_clr 45000 49000
actions cluster0+cluster1 cluster0+cluster1
action_info 1500000+1824000 1400000+1700000
override 5000
Instead of emmc thermostat I use tsens_tz_sensor11 which is the temperature of the CPU core itself, I think it is better
Finally someone make magisk module for this (thanks nfsmw_gr), not yet tried it myself though
https://forum.xda-developers.com/showpost.php?p=76793058&postcount=14
I've already moved on to stock b01 oreo rom, now it is located in /system/vendor/etc/thermal-engine.conf
Here is my current config
Code:
[SKIN_CHG_LIMIT]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 39000 41000
thresholds_clr 38000 40000
actions battery battery
action_info 1 2
[SKIN_CPU_MONITOR_NORMAL]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 36000 39000 42000
thresholds_clr 35000 38000 41000
actions cluster0+cluster1 cluster0+cluster1 cluster0+cluster1
action_info 1500000+1824000 1400000+1700000 1300000+1438000
override 5000
[SKIN_GPU_MONITOR_NORMAL]
algo_type monitor
sampling 1000
sensor emmc_therm
thresholds 41000 42000
thresholds_clr 39000 40000
actions gpu gpu
action_info 510000000 401800000
override 5000

Thank you so much.

Is this valid for destroying the phone without voiding the warranty?

aLexzkter said:
Is this valid for destroying the phone without voiding the warranty?
Click to expand...
Click to collapse
Lol, I'm pretty sure there's a failsafe for temps

You'd probably want to also undervolt if you are removing thermal throttling to give yourself a little more headroom. Hellsgate kernel supports undervolting

Been doing similar for months and mentioned about it a few times in various places.
I don't think using the CPU temperature sensor is suitable for throttling as it peaks largely and fluctuates rapidly with corresponding load. The reason emmc_therm (quiet_therm in AOSP ROMs) is probably used for a suitable consistent reading. The related default temperature throttles need to be adjusted to reflect the changed sensor and it's nature. What will happen on your config is sudden throttling on CPU load that will unthrottle rapidly when load is decreased but the battery/device isn't likely any cooler.
Btw on AOSP I can't get any changes to stay after rebooting with disemmcwp system writable too. I'm guessing the kernel or something regenerates the defined values at startup. I found having the file modified through a Magisk module works however.
Sent from my Xperia Z3C using XDA Labs

I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling

dalebaxter01 said:
I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling
Click to expand...
Click to collapse
I would like this as well if it's not much hassle.

dalebaxter01 said:
I know this sounds super lazy but can this possibly be made into a magisk module for convenience for and for ease of enabling/disabling
Click to expand...
Click to collapse
put your changed file into this template https://forum.xda-developers.com/mi-5/how-to/how-to-disable-thermal-throttling-t3636574

Infy_AsiX said:
Been doing similar for months and mentioned about it a few times in various places.
I don't think using the CPU temperature sensor is suitable for throttling as it peaks largely and fluctuates rapidly with corresponding load. The reason emmc_therm (quiet_therm in AOSP ROMs) is probably used for a suitable consistent reading. The related default temperature throttles need to be adjusted to reflect the changed sensor and it's nature. What will happen on your config is sudden throttling on CPU load that will unthrottle rapidly when load is decreased but the battery/device isn't likely any cooler.
Btw on AOSP I can't get any changes to stay after rebooting with disemmcwp system writable too. I'm guessing the kernel or something regenerates the defined values at startup. I found having the file modified through a Magisk module works however.
Sent from my Xperia Z3C using XDA Labs
Click to expand...
Click to collapse
Yeah, this is also what I found. At first I just looked at which temp is the highest and use that sensor for the trigger. But then when I use cpu-z to observe the reading, I found that emmc_therm is the most consistent and not fluctuate drastically so much. Therefore I'm back using emmc_therm right now

Seeing this thread gives me flashback in the Android M days where a xposed module was needed to disable a system task killer that would kill my games if they used too much battery once I turn off screen _-_

Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.

otaconremo said:
Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.
Click to expand...
Click to collapse
You should always keep your eyes on the temp. My rule of thumb is under 55 degree is ok, above that is no no. If your games always reach above 55 then you should re-tweak your thermal config.
Use dev check pro to observe the temp, though it doesn't have widget for emmc_therm only the cpu therm, you can still see what's going on under the screen

Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)

otaconremo said:
Never again will I use my phone gaming while overheating message comes up.
It almost killed my phone, not turning on and charging. I had to disassemble the phone and remove the battery to make it charge again.
Click to expand...
Click to collapse
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
iyancoolbgt said:
You should always keep your eyes on the temp. My rule of thumb is under 55 degree is ok, above that is no no. If your games always reach above 55 then you should re-tweak your thermal config.
Use dev check pro to observe the temp, though it doesn't have widget for emmc_therm only the cpu therm, you can still see what's going on under the screen
Click to expand...
Click to collapse
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
nfsmw_gr said:
Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)
Click to expand...
Click to collapse
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.

Infy_AsiX said:
No idea how you got that. I've never seen a overheating message on stock N or RR-O. I've gotten the device to overheat shutdown plenty of times after increasing the secondary CPU throttle (hasn't been described here) from 95degC to 105degC. Even on fan with enough load at maximum frequencies the CPU temp can spike to the presumedly 120degC Qualcomm shutdown (dropping one step on big cores is fine). This secondary throttle behaves differently by interrupting performance and unthrottling rapidly. Still boots fine after. I've yet to try if undervolting will allow that final big frequency step, on fan, increased to 105degC, no secondary throttle and no shutdowm.
I'd guess instead your battery voltage dropped too severely low being old degraded and too high a current draw, requiring a reset of the battery PCB or something.
55 isn't high at all for a CPU. You mean floating monitor overlay? It can select two custom temperatures to show on the dashboard and float monitor. The only real concern is battery temp. Other components are designed and rated to handle high temperatures. FWIW I've been running around 100degC CPU, keeping battery <50degC on fan with battery voltage limited to 3.85V for several months playing various high end games at maximum performance without notable ill effect. Well except that constant heat on the battery even at the safe low voltage will cause degradation, unavoidable cost for higher performance on a phone.
That location sounds like how it was when I tried AEX-O. Don't know if anything's changed there but no files could affect ROM thermal throttling on it then. The files there are different too, maybe generic Sd820 config or something, whereas RR-O uses the same sensors, values and config as stock N. I did also try the stock config modded to AEX but still no go. The only file with effect where it works is the -normal.conf.
Click to expand...
Click to collapse
Mind sharing your own config?

nfsmw_gr said:
Mind sharing your own config?
Click to expand...
Click to collapse
I did awhile back but I guess it's a little scattered across posts. I was about to edit in another paragraph with more info but I'll put it here now instead. I'll consider cleaning up the new stuff to share, performance profiles is just a varied collection of performance levels.
I've setup various CPU GPU performance profiles to switch between using Tasker. From testing, the highest I'd go without a fan is 1600/1800 big and 1300 small. With a constant load at these frequencies the battery will still hit up to around 50degC, matching the much higher perf allowed with a fan.
Here's a tidbit to get y'all thinking about environmental impact on heat. Stock Daydream sets a Sustainable Performance mode that uses all cores at 1200MHz. In the Daydream Headset V1, the back of the phone actually has an air gap behind it because of raised nubs inside the headset. Yet with all this the battery can rather easily heat to over 55degC after a few dozen minutes. The headset v2 has a built in heatsink, with minor improvement apparently. Also on an off-topic note, that Sustained Performance mode gets stuck to on after using Daydream on stock N. Things no one notices unless you actually monitor
---------- Post added at 10:12 PM ---------- Previous post was at 10:09 PM ----------
otaconremo said:
I believe my battery is too degraded already. That only happens when my batt is below 20% and I was still gaming. That's why I'm very careful already when I'm getting lowbat. Btw, I'm using stock chinese mf5 version. The overheating message is from the Mi-Assistant app (Power Manager).
Click to expand...
Click to collapse
Yeah sounds like my guess about an undervolted degraded battery. Oh I had that frozen so never got that alert. I'd assume it occurs when battery is 55degC or so, that's when Daydream alerts too for example.

nfsmw_gr said:
Okay, so after reading through the comments I made a magisk module for myself to test, using the template from the Mi 5 thread.
I modified all 3 files to be sure it works (my device boots so yeah, try it and let me know).
Also made a copy of the modded files at /system/etc to cover all scenarios because in the ROM I run the files are located in /system/vendor/etc, not in /system/etc as in the OP .
It shouldn't affect anything I think.
Anyway without stalling you'll find the file attached at the bottom, as always you flash at your own risk, have a nice day!
(P.S. If this is ok I'll put it on my thread with my Jojoc mod.)
Click to expand...
Click to collapse
Thanks, that's so cool. I'll put it on the first post

Better Mobile App

welcome