[Kernel][EB13/EC05][Battery][Experimental] Tweaked Battery Charging Kernel - Epic 4G Android Development

:[Disclaimer]:
Use this at your own risk!
:[Extra Disclaimer]:
This alters the way the Epic charges the battery.
Precaution has been taken to not exceed "normal" values, but when dealing with batteries (and their various sources and quality) there is always a chance something could go horribly wrong.
If you are in any way worried about this, then please move on, as this is not for you.
If you bought an extended battery off ebay and are worried your battery might explode, then please move on, as this is not for you.
This should be considered experimental, and only people who wish to experiment should use it.
There may come a time this will be incorporated into more (all?) kernels, but until then, you have been warned!
:[Requirements]:
Built for and tested on EB13 / EC05 EXT4.
:[Description]:
This is a tweak of the values that are used by the Epic to determine when the battery is at it's fully charged state, and when it should begin it's recharge state.
This is built on Bonsai 3.0.1
It includes the following: tun support, cifs support, 1.2GHz Overclock, autogroup scheduling, keyboard fix (thanks mkasick), video mode fix (thanks again mkasick), etc.
Thank you to all the devs who have contributed and I haven't listed (pm me).
I have also implemented nullghost's Idle timer from 2.6.34 thanks to ACS and nullghost.
[update]
I have also implemented the changes from the EC05 kernel, thanks to Rodderik.
And the scaling_available_frequencies sysfs interface thanks again to nullghost.
[update]
Attached source files for those who want them.
:[Features]:
Alters the "fully charged notification" to be more accurate.
Charges the battery to near full capacity.
Allows for less drain before the "recharge" kicks in.
Gives you a better chance at having a full charge when unplugging.
[update]
Provides over charge protection in the form of a max voltage cut-off.
Increased charge rates (mA) in both USB and AC modes.
There is a chance this change could cause fire or explosion!
Understand this is trial and error!
Even tho I've tested this for the past couple days, there is still a chance you will have a problem where I have not!
Especially if you use a charger other than a stock charger (rated at 0.7A)!
!!Again, you have been warned!!
Adjusted calculations for the fuel gauge (battery level percentage).
I have added a few kernel debug messages that can be seen using dmesg.
"OS Monitor" free in the market will allow you to view them (filter tag = [BATT).
:[What this does not do]:
This does not alter any of the following built in protections:
Max total charge time of 5 hours.
Max total recharge time of 2 hours.
Low battery voltage condition of 3400 (used for auto shutdown).
Low battery level condition of 0 (used for auto shutdown).​This does not change the charge rate (current coming from the charger).
So no, it wont charge your phone faster (well technically it does, but only during the higher voltages where you would normally be "recharging" on a stock kernel).
:[Recommendations]:
Go download the free app "Battery Monitor Widget". Go into the settings and make sure that "Monitor without widget" is enabled (checked).
The app has a really nice history feature that I find useful, and can be used to help track things with this kernel.
:[Details]:
From the code (original and older values commented out)::
(Some line numbers might be a little off, as I have added some debug messages.)
[Full charge and Recharge adjustments]
Kernel/drivers/power/victory/s5pc110_battery.h: Line 166
Code:
#define BATT_RECHARGE_COUNT [COLOR="Blue"]15[/COLOR]//20
Kernel/drivers/power/victory/s5pc110_battery.h: Lines 170 ~ 173
Code:
#define OVER_CHARGE_COND_VOLTAGE [COLOR="Blue"]4210[/COLOR]// nubecoder
#define FULL_CHARGE_COND_VOLTAGE [COLOR="Blue"]4190[/COLOR]//4170//4000
#define RECHARGE_COND_VOLTAGE [COLOR="Blue"]4150[/COLOR]//4140//4110 // 2010.05.08.
#define RECHARGE_COND_VOLTAGE_BACKUP [COLOR="Blue"]4090[/COLOR]//4110//4000
Kernel/drivers/power/victory/s5pc110_battery.h: Lines 184 ~ 185
Code:
#define CURRENT_OF_FULL_CHG [COLOR="Blue"]60[/COLOR]//90//91 // 2010.05.08.
#define CHG_CURRENT_COUNT [COLOR="Blue"]15[/COLOR]//20
Which means:
When voltage is greater than or equal to 4190(mV) and current is less than or equal to 60(mA), full charge has been achieved.
When voltage is below 4150(mV) or 4090(mV), recharge activates (what determines if "backup" is used a Samsung mystery).
The current and recharge count values are also somewhat of a mystery, I decreased them to have a bit more consistent charge behavior.
[Over charge protection]
Kernel/drivers/power/victory/s5pc110_battery.c: Lines 438 ~ 444 and 458 ~ 464
Code:
if (s3c_bat_info.bat_info.batt_vol >= OVER_CHARGE_COND_VOLTAGE) {
s3c_set_chg_en(0);//Set charge off
s3c_bat_info.bat_info.batt_is_full = 1;
force_update = 1;
}
Which means:
If voltage is greater than or equal to 4210mV stop charging.
[Increased charge rate]
Kernel/drivers/regulator/victory/max9889_function.c: Line 3092
Code:
reg_buff[0] = (0x0 <<5) |(0x3 << 3) | /*(0x5<<0)*/ [COLOR="Blue"](0x6<<0)[/COLOR] ; // CHG_TOPOFF_TH=10%, CHG_RST_HYS=Disable, AC_FCGH=600mA // ???mA
Kernel/drivers/regulator/victory/max9889_function.c: Line 3106
Code:
reg_buff[0] = (0x0 <<5) |(0x3 << 3) |/*(0x1<<0)*/ [COLOR="Blue"](0x3<<0)[/COLOR] ; // CHG_TOPOFF_TH=10%, CHG_RST_HYS=Disable, AC_FCGH=380mA // ???mA
Based on some rudimentary calculations this translates to:
Code:
AC: @320mA which translates to @704mA
USB: @249mA which translates to @548mA
Note:: This was tested with a stock cable and charger for AC, and a stock cable and a direct laptop port for USB.
For more information read this post.
[Adjusted fuel gauge (battery level percentage)]
Kernel/drivers/power/victory/fuel_gauge.c: Line 159
Code:
adj_soc = (((data[0]*10) - 15) * 100) / (/*950*/ [COLOR="Blue"]980[/COLOR] - 15); // hanapark_Atlas
Which means:
Instead of rounding 95% up to 100% round 98% up to 100%.
:[WishList]:
Fixing the battery percentage output to be more accurate. (Partially done, we'll see how it goes.)
Adjusting the values to what I feel is the best charging experience (while still remaining "safe").
Possibly(?) increasing the charge rate to enable faster charging.
:[Testing]:
This has been tested on an Epic 4G running Bonsai 4.0.0b2 with a stock battery.
This build has not been tested on an extended battery (yet).
:[Feedback]:
Please post your feedback, I'd like to know some of the values reported when full charge occurs, when recharge starts / stops, if you've noticed your battery keeps charge longer / less, etc...
[Download HERE]
Download no longer available...
:[Special thanks]:
jaronow, for initial testing.
:[ChangeLog]:
Code:
v0.0.2 (03-22-2011)
Attached current source files to this post.
v0.0.2 (03-22-2011)
Added over charge protection cut-off of 4210mV.
Increased full charge voltage to 4190mV.
Increased recharge cond voltage to 4150mV.
Decreased recharge backup cond voltage to 4090mV.
Decreased full charge current condition to 60mA.
Decreased charge current count to 15.
Decreased recharge count to 15
Increased charge rate for AC from an estimated 600mA to @ 704mA.
Increased charge rate for USB from an estimated 380mA to @ 548mA.
Adjusted fuel gauge to be more accurate.
v0.0.1 (03-16-2011)
Initial Release
=]

Guinea Pig Number #1 reporting for duty!!! My phone booted up ok and did not explode!
I am using the Midnight Rom 4.2 Byor Edition so far my phone has booted up ok. I am charging my phone right now as we speak. I will do benchmark speeds when my phone is done charge up fully. I wiped my partination cache and the Dilvke cache too. I am trying to get a full charge.

Sweet Awesome work bro 8)

is this just a kernal flash? can't see what the file is from work. also, is it still the bonsai kernal? so smart ass governor still an option?
is it relatively simple to jack up the charge rate? my friends iphone charges in like an hour or less. mine takes at least 3 hours. annoying to say the least.

removed root for me

What makes the smartass governor special.
Can I keep my phone on 1.2 GHZ and the smartass governor will only use as much power it needs to complete the task at hand or would I save battery life by putting my phone on 800 MHz or it does not matter? Great Rom Kernal fast and efficient. The first time I flashed it I go slow benchmark scores but the score kept on improving and now they are pretty close to the score on the Bonsai Rom Kernal and this Rom gives you a fuller battery charge. I am loving this Kernal I highly recommend it. It is the best kernal I have tried so far and I have tried a lot of kernals in my day. This experimental kernal is the best kernal I have put in my phone this could be my daily driver. I have to give it a full day's test. So far so good not problems to report yet.

thank you! loved this kernels on my evo! will try today/tonight!
ms79723 said:
removed root for me
Click to expand...
Click to collapse
you running syndicate? i think i read the other day that root is in the kernel in syndicate. just run the 1 click root again

The other day I was looking at how to get a little more "umph" from the USB port charging. Do you think that we could tinker with this
Code:
static void s3c_set_chg_en(int enable)
{
int chg_en_val = maxim_chg_status();
if (enable) {
if (chg_en_val) {
if(curent_device_type==PM_CHARGER_TA)
maxim_charging_control(PM_CHARGER_TA, TRUE);
else if (curent_device_type==PM_CHARGER_USB_INSERT)
maxim_charging_control(PM_CHARGER_USB_INSERT, TRUE);
else{
maxim_charging_control(PM_CHARGER_DEFAULT, FALSE);
}
s3c_set_time_for_charging(1);
}
} else {
maxim_charging_control(PM_CHARGER_DEFAULT, FALSE);
s3c_set_time_for_charging(0);
s3c_bat_info.bat_info.batt_is_recharging = 0;
s3c_bat_info.bat_info.batt_current = 0; // hanapark_Victory
}
s3c_bat_info.bat_info.charging_enabled = enable;
}
Making it think that is never is plugged into anything but the wall charger would cause a little more current to be pushed through, and since we only pull like 600 mah from the wall, I think a could USB port/ Cord could handle it.
If none of that makes since, just tell me. I haven't spent more than a few minutes reading through the code that is there, and I really don't know too much about this stuff anyways.

Is this similar to the evo's sbc kernal where it will allow to fully (Trickle) charge an extended battery?

robl45 said:
is this just a kernal flash? can't see what the file is from work. also, is it still the bonsai kernal? so smart ass governor still an option?
is it relatively simple to jack up the charge rate? my friends iphone charges in like an hour or less. mine takes at least 3 hours. annoying to say the least.
Click to expand...
Click to collapse
Yes this is just a kernel, and yes this is based on the Bonsai kernel, anything that is included in the sources available here is included.
I've also added the 2.6.34 Idle timer that nullghost has given to us (taken from the ACS github, Thanks for your hard work guys!).
ms79723 said:
removed root for me
Click to expand...
Click to collapse
It seems that some Roms have root included in the kernel, which is not the case for Bonsai (and therefore this kernel as well).
ps- Thanks for your work on the SBC kernel for the Evo! This was definitely inspired by it.
vide infra said:
thank you! loved this kernels on my evo! will try today/tonight!
[snipped]
Click to expand...
Click to collapse
asj2583 said:
Is this similar to the evo's sbc kernal where it will allow to fully (Trickle) charge an extended battery?
Click to expand...
Click to collapse
This is not quite the same as the SBC kernel for the Evo (this does not trickle-charge).
It differs in that, the Epic already performs a "bump-charge" by default.
This kernel is a simple modification of the values used to determine when the bump charging occurs, etc.
So this is, more or less, just a modification of the stock charging behavior.
=]

Kcarpenter said:
The other day I was looking at how to get a little more "umph" from the USB port charging. Do you think that we could tinker with this
Code:
[snipped]
Making it think that is never is plugged into anything but the wall charger would cause a little more current to be pushed through, and since we only pull like 600 mah from the wall, I think a could USB port/ Cord could handle it.
If none of that makes since, just tell me. I haven't spent more than a few minutes reading through the code that is there, and I really don't know too much about this stuff anyways.
Click to expand...
Click to collapse
You sir, get a separate reply ;]
You are correct that you could change that code to force the USB into thinking it's being charged via AC, but I feel that would be a bad choice in implementation.
Rather check the code here:
/drivers/regulator/victory/max8998_function.c Lines: 3089 ~ 3118
Code:
else if(dev_type==PM_CHARGER_TA)
{
// hanapark_Victory (2010.05.12)
[COLOR="Blue"]reg_buff[0] = (0x0 <<5) |(0x3 << 3) |(0x5<<0) ; // CHG_TOPOFF_TH=10%, CHG_RST_HYS=Disable, AC_FCGH=600mA[/COLOR]
reg_buff[1] = (0x2<<6) |(0x3<<4) | (0x0<<3) | (0x0<<1) | (0x0<<0); //ESAFEOUT1,2= 10, FCHG_TMR=disable, MBAT_REG_TH=4.2V, MBATT_THERM_REG=105C
#ifdef CONFIG_KERNEL_DEBUG_SEC
kernel_sec_clear_upload_magic_number(); // hanapark_DF01
#endif
Set_MAX8998_PM_ADDR(CHGR1, reg_buff, 2);
//printk("%s TA charging enable \n",__func__);
}
else if(dev_type==PM_CHARGER_USB_INSERT)
{
value = FSA9480_PMIC_CP_USB();
// hanapark_Victory (2010.05.12)
[COLOR="Blue"]reg_buff[0] = (0x0 <<5) |(0x3 << 3) |(0x1<<0) ; // CHG_TOPOFF_TH=10%, CHG_RST_HYS=Disable, AC_FCGH=380mA[/COLOR]
if(value){
if (askonstatus)
reg_buff[1] = (0x1<<6) |(0x3<<4) | (0x0<<3) | (0x0<<1) | (0x0<<0); //ESAFEOUT1,2= 01, FCHG_TMR=disable, MBAT_REG_TH=4.2V, MBATT_THERM_REG=105C
else
reg_buff[1] = (0x3<<6) |(0x3<<4) | (0x0<<3) | (0x0<<1) | (0x0<<0); //ESAFEOUT1,2= 11, FCHG_TMR=disable, MBAT_REG_TH=4.2V, MBATT_THERM_REG=105C
}
else
reg_buff[1] = (0x2<<5) |(0x3<<4) | (0x0<<3) | (0x0<<1) | (0x0<<0); //ESAFEOUT1,2= 01, FCHG_TMR=disable, MBAT_REG_TH=4.2V, MBATT_THERM_REG=105C
#ifdef CONFIG_KERNEL_DEBUG_SEC
kernel_sec_clear_upload_magic_number(); // hanapark_DF01
#endif
Set_MAX8998_PM_ADDR(CHGR1, reg_buff, 2);
//printk("%s USB charging enable \n",__func__);
}
I believe it would be better to adjust the values marked above.
But I'm no good with bit shifting code, and I haven't yet figured out what to change the values to.
Of course we (you?) could simply change the value and see what happens, but I prefer to (at least somewhat) understand what I'm doing when I apply a change.
So that is why I haven't messed with it yet, more research needs to be done IMO.
If you do decide to try this, let me know how it goes.
And remember the USB spec says that it only gives out 500mA max.
=]

Well in that case ill be building tonight..... just needed a little refirmation from someone. Makes me sleep bettr at night.
Sent from my Samsung-SPH-D700 using XDA App

FWIW, we used something from no2chem called "Fast Charge" on WinMo, back when I used a Diamond.
It would charge around 900 maH(much less than Diamond's 1340 MaH battery) on USB and AC and drop down(trickle charge) once it reached 90 percent.
"A quick test from a usb2 port shows the following approx values:
At 50% charge, charges at 918mA
50 minutes later, battery is at 90% and charging at 462mA"
Batteries can accept up to their mA in charging, and since the batteries aren't usually spot on to their rated mA, I'd say we'd be safe up until about 1200 mA charging.
If all that makes sense, it's been a while since I've devved and had to learn all that good stuff.
EDIT: @Kcarp: I've got like 4 OEM batteries here, I'm willing to put at least one of them towards testing, assuming it's not going to harm the phone and would be a battery only affair.

mA and mAh are completely different units, one measures current and one measures capacity.
Sent from my Samsung-SPH-D700 using Tapatalk

My Battery has been charging for 4 hours and it is at 60%
My battery has been charging for 4 hours and it is only at 60% what gives? It is at taking a long time to recharge my battery.

intx said:
FWIW, we used something from no2chem called "Fast Charge" on WinMo, back when I used a Diamond.
It would charge around 900 maH(much less than Diamond's 1340 MaH battery) on USB and AC and drop down(trickle charge) once it reached 90 percent.
"A quick test from a usb2 port shows the following approx values:
At 50% charge, charges at 918mA
50 minutes later, battery is at 90% and charging at 462mA"
Batteries can accept up to their mA in charging, and since the batteries aren't usually spot on to their rated mA, I'd say we'd be safe up until about 1200 mA charging.
If all that makes sense, it's been a while since I've devved and had to learn all that good stuff.
EDIT: @Kcarp: I've got like 4 OEM batteries here, I'm willing to put at least one of them towards testing, assuming it's not going to harm the phone and would be a battery only affair.
Click to expand...
Click to collapse
Yep, I always loaded the fast charger drivers from no2chem on my TP1 and TP2. Enjoyed the increased charging rate from the car charger, usb, and other chargers.
That's the one thing I missed when I moved from the TP2 to the Epic...the Epic was god awful slow at charging!

Well, forgot that the hdd on my laptop has become "unstable" gotta go buy one, probably be tomorrow night before I can build I might try building anyways...it still boots, just locks up and makes god awful noises...we shall see I guess.
Sent from my Samsung-SPH-D700 using XDA App

jamice4u said:
My battery has been charging for 4 hours and it is only at 60% what gives? It is at taking a long time to recharge my battery.
Click to expand...
Click to collapse
What you have reported is not normal behavior.
Did you get the battery monitor widget? Could you post some of the history?
I would suggest you unplug from the charger, reboot into CWM, clear the battery stats, and reboot.
Sometimes the percentage readout behaves strangely, some people have reported that rebooting the phone drastically changes their reported percentages.
(Not on this kernel, but it's been mentioned at least a couple times in the Bonsai thread.)
Maybe you are experiencing this?
If you battery has been charging for 4hrs+ and isn't increasing it's percentage, then something is going wrong and needs to be investigated.
This is where the monitor widget comes in handy, what voltage is being reported, what current (mA) is being pumped into the phone, etc.
=]

i tried the kernal, took like 3 1/2 hours to charge up from 35% or so. but i dont know that we are really gaining much, what are we getting,another 2%?
if we could increase the charge rate, that would be something.

Here are 2 bugs I would like to report you loose root, the superuser icon is there, but you can't let special apps ask for permission. 2nd, the kernel is not supported for wirless tether, I am using the snydicate rom if that makes a difference.
Thanks for the kernel, I see great promise in it

Related

[BATT Fix][GB SENSE Kernel] Get your phone charged to 100% when you pick it up

Like you guys, I was fed-up with the HTC battery charging policy. Picking-up my phone charged to 90% after an overnight was really annoying.
Basically, the Desire stops charging when the battery is fully charged and waits for the level to drop to 90% before recharging to 100% again.
I went for a deeper look at sources. I wanted to have a trickle charge on my phone, even at the cost of a battery wear (not even sure about that tho, because it's the way the battery is charging when the phone is turned OFF - not in standby).
With a very minor tweak in the HTC DS2784 driver, it is possible to change this behaviour in a way that the charge doesn't stop @ 100% but a very small current (close to 0mA) keeps your battery @ 4.2v. I have experimented my little hack on my own desire and I can tell you that it's working perfectly well! I monitored for hours the charging process and the current slowly dropped to very small numbers. HTC_BATT was reporting 0 to 2mA charge and was even letting the battery discharging (-2 to -4mA) to keep it at 4.2v
What you get with this is a normal charge, and when the battery is close to 4.2v, the charging current slowly drops to 0mA. I haven't changed anything else so the battery is still overtemp or overcharge protected.
The file involved is drivers/power/ds2784_battery.c
I attached a patched file below (for GB sense kernel)
Here is the diff (the magic bit ;-) ):
Code:
965c965
< charge_mode = CHARGE_OFF;
---
> charge_mode = CHARGE_SLOW;
972c972
< charge_mode = CHARGE_OFF;
---
> charge_mode = CHARGE_SLOW;
The full code now looks like this:
Code:
} else {
if (htc_batt_info.rep.level <= 99)
htc_batt_info.rep.battery_full = 0;
if (htc_batt_info.rep.battery_full) {
charge_mode = CHARGE_SLOW;
}
else if ((htc_batt_info.rep.guage_status_reg & 0x80) &&
(htc_batt_info.rep.batt_current <= 80) &&
(htc_batt_info.rep.level == 100)) {
if (More_Charge_Extend_Time()) {
htc_batt_info.rep.battery_full = 1;
charge_mode = CHARGE_SLOW;
}
}
Cut& paste this thread to your favourite kernel developer (For HTC SENSE ROMS / KERNELS ONLY. Others seems to be not affected)
I would like to thank RichardTrip for his kernel and his github.
I would like to thank Mekrel as well, as he showed me the path with his post.
I built a Froyo V5e kernel for you guys just here
Last updated kernel is also attached (GingerBread SENSE kernel) based on bananacakes's patches.
An APP to tweak SVS/HAVS settings: IncrediControl (Thanks to sebastiaan15 who mentioned it). The settings in the general tab are only functional in kernels that have implemented the simple sysfs interfaces for usb fast charging and audio boost.
If your phone is unstable with those kernels, try those stable kernels.
I thought there would be a download link
Jagdish84 said:
I thought there would be a download link
Click to expand...
Click to collapse
edit:
Added links
Suggested it to Neo to integrate on his next release
Thx for that btw!
Posted a link in the leedroid thread, hopefully it will be picked up. Thanks for your solution.
My MacBook does the same thing (i.e. allows the charge level to drop off before resuming) and I'm guessing there's a reason for that, not that I know about LiIon/Poly chemistry other than that they supposedly don't have a memory effect and only tend to degrade in terms of the number of charge cycles all added together, part cycles don't cause loads of harm like they do with NiMh/NiCd... At least Desire batteries are cheap if this knackers them in the medium term.
Azurael said:
My MacBook does the same thing (i.e. allows the charge level to drop off before resuming) and I'm guessing there's a reason for that, not that I know about LiIon/Poly chemistry other than that they supposedly don't have a memory effect and only tend to degrade in terms of the number of charge cycles all added together, part cycles don't cause loads of harm like they do with NiMh/NiCd... At least Desire batteries are cheap if this knackers them in the medium term.
Click to expand...
Click to collapse
Yep . Actually the charge doesn't really stops. The current slowly drops to 0mA or 1mA.
I've been told that it might not be very healthy for the battery to be maintained at a high voltage for a long period of time, but that's the cost of an always fully charged phone
Unfortunately yes when you hold the battery at 4. 2v it hurts it. Instead of getting closer to 18-24 months out of the battery you'll get around 12 months doing this every night. It doesn't matter tho. I already run mine to 4. 2 v overnight I got my 3000mah extended battery for only 22 dollars so why care?
Sent from my HTC Desire using XDA App
Visentinel said:
Unfortunately yes when you hold the battery at 4. 2v it hurts it. Instead of getting closer to 18-24 months out of the battery you'll get around 12 months doing this every night. It doesn't matter tho. I already run mine to 4. 2 v overnight I got my 3000mah extended battery for only 22 dollars so why care?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
because the battery is fully charged, I recharge it only one night out of two now
We can expect the batteries to be even cheaper in a year from now!
Is it possible to get the battery to 100 % and let drop to 98% or so and then recarche to 100%? Think this would be better for the battery!?
Sent from my brain using telepathy
sibere said:
Nope, it's just a hack to be integrated in any (at least sense) kernel.
I build my own but it's not made for public release as it's tuned to my own Desire and desires
Click to expand...
Click to collapse
Can you please share it because I really don't know how to implement this into my Desire..
Thanks in advance..
Ninolina said:
Can you please share it because I really don't know how to implement this into my Desire..
Thanks in advance..
Click to expand...
Click to collapse
Basically, if you don't know how to compile a kernel , forget about it. Just wait for an "official" kernel builder on this forum to apply this hack and post an update.
remember that you have to be root to flash a new kernel
sibere said:
Like you guys, I was fed-up with the HTC battery charging policy. Picking-up my phone charged to 90% after an overnight was really annoying.
Thanks to the RichardTrip Kernel and Thread, I went for a deeper look at sources. I wanted to have a trickle charge of my phone, even at the cost of a battery wear (not even sure about that tho).
Basically, the Desire stops charging when the battery is fully charged and waits for the level to drop to 90% before recharging to 100% again.
With a very minor tweak in the DS2784 driver, it is possible to change this behaviour in a way that the charge doesn't stop @ 100% but a very small current (close to 0mA) keeps your battery @ 4.2v. I have experimented my little hack on my own desire and I can tell you that it's working perfectly well!
What you get with this is a normal charge, and when the battery is close to 4.2v, the charging current slowly drops to 0mA. I haven't changed anything else so the battery is still overtemp or overcharge protected.
The file involved is /bravo-2.6.32/drivers/power/ds2784_battery.c (HTC sense 2.6.32.15 kernel)
Here is the diff (the magic bit ;-) ):
Code:
965c965
< charge_mode = CHARGE_OFF;
---
> charge_mode = CHARGE_SLOW;
972c972
< charge_mode = CHARGE_OFF;
---
> charge_mode = CHARGE_SLOW;
The full code now looks like this:
Code:
} else {
if (htc_batt_info.rep.level <= 99)
htc_batt_info.rep.battery_full = 0;
if (htc_batt_info.rep.battery_full) {
charge_mode = CHARGE_SLOW;
}
else if ((htc_batt_info.rep.guage_status_reg & 0x80) &&
(htc_batt_info.rep.batt_current <= 80) &&
(htc_batt_info.rep.level == 100)) {
if (More_Charge_Extend_Time()) {
htc_batt_info.rep.battery_full = 1;
charge_mode = CHARGE_SLOW;
}
}
Cut& paste this thread to your favourite kernel developer
I would like to thank Richard for is kernel and is github. (http://forum.xda-developers.com/showthread.php?t=801435)
I would like to thank Mekrel as well, as he showed me the path with his post (http://forum.xda-developers.com/showpost.php?p=8695549&postcount=464).
Click to expand...
Click to collapse
the battery fix is already in the new kernels isnt it? correct me if im wrong anyone, but richard kernel the battery charges itself again when it drops to 99% and in previous kernel it use to start chargin again at 95% not 90%!!!!
Really? I was using v5e and my battery was dropping to 90% before recharging...
The only change made to the driver was a few definitions about critical temps and charging voltage.
From Richard Github:
Code:
#define CHARGE_SLOW 1
#define CHARGE_FAST 2
-#define TEMP_CRITICAL 600 /* no charging at all */
-#define TEMP_HOT 500 /* no fast charge, no charge > 4.1v */
-#define TEMP_WARM 450 /* no fast charge above this */
+#define TEMP_CRITICAL 800 /* no charging at all */
+#define TEMP_HOT 700 /* no fast charge, no charge > 4.1v */
+#define TEMP_WARM 650 /* no fast charge above this */
-#define TEMP_HOT_MAX_MV 4100 /* stop charging here when hot */
-#define TEMP_HOT_MIN_MV 3800 /* resume charging here when hot */
+#define TEMP_HOT_MAX_MV 4500 /* stop charging here when hot */
+#define TEMP_HOT_MIN_MV 4200 /* resume charging here when hot */
#define TEMP_CRITICAL_BC 570 /* no charging at all */
#define TEMP_CRITICAL_RECHG_BC 550 /* recharge at 1.temp <= 55C and 2. Vb < 3.8V */
Here in this case it's a battery mod, not a fix
sibere said:
Basically, if you don't know how to compile a kernel , forget about it. Just wait for an "official" kernel builder on this forum to apply this hack and post an update.
remember that you have to be root to flash a new kernel
Click to expand...
Click to collapse
Can you at least then share your Kernel? Thanks in advance...
Just to add... I have a Rooted and an S-OFF Desire...
Ninolina said:
Can you at least then share your Kernel? Thanks in advance...
Click to expand...
Click to collapse
Year, that's doable.
Be carefull don't use it if you have app2SD because ext2/3/4 are compiled as modules.
I will NOT provide any kind of support, so try it at your own risks (disclaimer done! )
it has:
HAVS (@925mV min)
UV/OC (1152mHz)
UC (128mHz min for screen-off power save, to be tuned with SetCPU)
CFQ Sched
All CPU governors, Interactive as default
SDfix
Battery fix for trickle charge (but not the v5f battery mod)
GPU+ (Enhanced GPU performances)
SWAP enabled
ext2/3/4 CIFS, etc... as modules (not good for App2SD users)
http://www.multiupload.com/789P9VYN1C
It is booting perfectly well on my phone. If it is not booting on yours, try to remove all the modules of you old kernel (in /system/lib/modules in recovery mode with ADB) and flash it again. If it still doesn't work, don't ask me why!
More updates within the next pages. (EXT2/3/4 and GROUP_SCHED)
Ninolina said:
Just to add... I have a Rooted and an S-OFF Desire...
Click to expand...
Click to collapse
Well that's perfect and it shows that you know what you're doing
sibere said:
Year, that's doable.
Be carefull don't use it if you have app2SD because ext2/3/4 are compiled as modules.
Click to expand...
Click to collapse
hope soon coming more kernels with APP2SD+ support and this mod
P.S found 1 btw if someone interested also http://forum.xda-developers.com/showpost.php?p=9242727&postcount=912
I am on Defrost 6 and battery doesn't drops under 100%
stoske said:
I am on Defrost 6 and battery doesn't drops under 100%
Click to expand...
Click to collapse
This problem only on SENSE roms, all CM(Defrost, OD etc..) roms dont have this problem.

[KERNEL][GB][EXPERIMENTAL] Entropy's Daily Driver (Video Fix 3/4/2012)

OK, since up to now few custom kernels have been released for Gingerbread, much of it due to fear of having to deal with the same stuff gtg465x has had to deal with for Infusion 2.0, I've had enough people ask what kernel I'm running to decide I'll post a compiled binary.
This kernel is my daily driver, it is what I have used for the past few days. I am posting it as-is with no support given. Flash it at your own risk, the only endorsement I give it is that I'm happy with its current state.
I'm on business travel at the moment so don't have time to do any support. Don't PM me with questions on how to flash this or bug reports. If you don't know how to flash a backup made with SGS Kernel Flasher, this kernel is not for you.
This kernel was built by taking the following three branches from my git repo and merging them into each other:
charginghacks
voodoo_sound
uv_only
As such, it has most mainline kernel fixes listed in my git repo thread.
It also has a preliminary implementation of Voodoo Sound initially committed by Bedwa. Based on talking with Supercurio, the apparently missing feature "speaker tuning" is only applicable to the Nexus S - if anything, some other devices may have this enabled when it shouldn't be. However, I have seen one or two reports that dock audio redirection may have issues which I need to investigate.
It has voltage control implemented but no overclocking. Be careful, this implementation from Netarchy allows you to overvolt in addition to undervolting. You could really fry something.
It also has an experimental battery charging algorithm. It should charge a battery faster from deep discharge (but slowing down near topoff, and in fact topping off slower than stock), and has so far successfully held my battery at around 85-90% state of charge when running Navigation in a car dock at full brightness. (It adjusts charge current downwards as battery voltage increases, to avoid worrying about whether charge termination will work properly when under load.) It's experimental, it could fry your battery, it might be wearing mine extra fast (but I doubt it personally) - if I've screwed up I get a significant discount on accessories.
So again - this is as-is, with no support provided as I don't have anywhere close to the amount of free time gtg has for supporting Infused.
Some time down the line I may formally release a supported kernel, but right now is not the time.
Two things to note that applies to all kernels with working CurrentWidget support at this time:
1) We have no way of measuring battery discharge current that I know of, just charge current. If you know of a GalaxyS device with working discharge reporting, please point me to a kernel that implements it.
2) On our device, the values reported by the kernel are 1.83 times the real charge current. I've debated fixing this, but it would break anyone who has already implemented scaling in userland, and it's behaving just like stock Froyo did.
Updates, see post at
http://forum.xda-developers.com/showpost.php?p=17890956&postcount=108 for 9/26,
and http://forum.xda-developers.com/showpost.php?p=18665215&postcount=225 for 10/22,
and http://forum.xda-developers.com/showpost.php?p=18997360&postcount=242 for 11/2,
and http://forum.xda-developers.com/showpost.php?p=19832752&postcount=306 for 11/27 (created 11/27 but posted 11/29)
3/4/2012 is just a fix for video decoding in newer firmwares
Edit: Also, if coming to this kernel from Infusion, reset all your voltage and OC settings back to stock. The voltage control mechanism in Netarchy-style kernels like this one is different from that in Infusion, the difference could cause weird things to happen. For this matter, you should reset voltage/OC settings back to stock before flashing ANY new kernel unless the kernel dev specifically instructs you to do something before flashing.
This kernel, like any kernel for Samsung-stock-derived ROMs, is NOT compatible with CM7/MIUI. (I just realized I say this on my GSII thread, but not here.) Flash this on CM7/MIUI and you'll softbrick. The only thing this has that CM7/MIUI kernels don't is charginghacks anyway...
No HDMI support - It will crash if you plug in an MHL adapter when running a UCKI3 or later leak, will do nothing on UXKG3
Entropy512 said:
OK, since up to now few custom kernels have been released for Gingerbread, much of it due to fear of having to deal with the same stuff gtg465x has had to deal with for Infusion 2.0, I've had enough people ask what kernel I'm running to decide I'll post a compiled binary.
This kernel is my daily driver, it is what I have used for the past few days. I am posting it as-is with no support given. Flash it at your own risk, the only endorsement I give it is that I'm happy with its current state.
I'm on business travel at the moment so don't have time to do any support. Don't PM me with questions on how to flash this or bug reports. If you don't know how to flash a backup made with SGS Kernel Flasher, this kernel is not for you.
This kernel was built by taking the following three branches from my git repo and merging them into each other:
charginghacks
voodoo_sound
uv_only
As such, it has most mainline kernel fixes listed in my git repo thread.
It also has a preliminary implementation of Voodoo Sound initially committed by Bedwa. LinuxBozo has identified some likely code deficiencies so it is likely not fully working. I never used VS heavily enough to judge this properly.
It has voltage control implemented but no overclocking. Be careful, this implementation from Netarchy allows you to overvolt in addition to undervolting. You could really fry something.
It also has an experimental battery charging algorithm. It should charge a battery faster from deep discharge (but slowing down near topoff, and in fact topping off slower than stock), and has so far successfully held my battery at around 85-90% state of charge when running Navigation in a car dock at full brightness. (It adjusts charge current downwards as battery voltage increases, to avoid worrying about whether charge termination will work properly when under load.) It's experimental, it could fry your battery, it might be wearing mine extra fast (but I doubt it personally) - if I've screwed up I get a significant discount on accessories.
So again - this is as-is, with no support provided as I don't have anywhere close to the amount of free time gtg has for supporting Infused.
Some time down the line I may formally release a supported kernel, but right now is not the time.
Click to expand...
Click to collapse
Ty much entropy
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
Options! im going to give this a run for a few days thanks brah.
Sent from my SAMSUNG-SGH-I997R using XDA App
This is great. I love seeing development pick up again. I'll have to give this a shot as well as bedwas kernel. And I hope for the sake of all you devs that the noobs start to learn how to treat the forum. Keep up the great work!
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
Very nice. Will give it a shot. I am in the car 8 hours a day streaming music via bt.. talking on the phone and using navigation. Battery is always an issue this may do the trick.
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
thanks entropy - gonna try it out.
waiting to hear some feedback from some of u that have downloaded this, would really love to try this out but i want to make sure everything seems A-ok. I'll be coming from bionix infinity if that makes any difference.
It does make a diff being that bionix infinity is a froyo based rom. i havent released the gingerbread. version yet.
Great? No: GREATEST!
I have installed it yesterday, and I noticed the phone more fast and responsive than usual. I also noticed the battery consumption now looks lighter: much better than before. And no rainbow at all.
You and GTG should work for Samsung development. If you do, we can say we're in good hands.
Your work is much appreciated.
Greetings from Rio.
P.S.: My phone uses Infused V2 Beta 3, And there's no rainbow, no freezing, thanks to you, Bozo and our friend GTG. Owe you!
Probably a dumb question but can a Gingerbread based Kernel work on a Froyo O/S such as the Froyo version of Infused?
I am unable to use GB due to the issues many people have with the compass in GB.
http://code.google.com/p/android/issues/detail?id=16741
http://forum.xda-developers.com/showthread.php?t=1109921
and thousands of other hits on this issue in Google.
The charging stuff would be awesome. I was rather disappointed to see that navigation +screen with a car charger would drain the battery. That seems like a basic problem with using it as on-dash navigation. (And they sell a freaking car dock for that.)
There should not be any significant differences in terms of battery life compared to other gingerbread kernels - undervolting will give you a slight improvement. Undervolting buys you a little bit but not too much (unless you're lucky and have a CPU that can undervolt by 100 mV at more at the lower voltages)
My battery tweaks ONLY affect charging on AC, and don't do anything when off the charger
I'd really like to claim super-awesome-battery-improvements, but the reality is that when kernel devs claim this, 95% of the time they're BSing. (Exception: Gingerbread vs. Froyo, but that's the whole kernel + userland package)
Did another long drive today - again, held at around 85-90%. I'll try to dig up a currentwidget screenshot from last week.
Attaching some screenshots of CurrentWidget logs.
One is a log taken while driving with nav on full brightness. Look at how it periodically bumps charge current up to 700 mA - it looks like nav with full brightness needs just a shade over 600 mA. The voltages that trigger state changes are such that this translates to around 85-90% battery.
One is a log taken while charging my new 3500 mAh extended battery from 59%. (I forgot to log the voltages... Sorry.)
You'll see that it starts at 800 mA, then drops to 700 as voltage rises, then 600 (stock), then 550 (below stock, be nice to the battery), then it exits constant-current mode and enters constant voltage mode (battery voltage stays just under 4.2 volts, and current drops until charge terminates.) If you look at the spikes during the CV phase of charging you'll see why I worry about charge termination under load - those spikes are because CPU usage counts against the charge current limit.
So far I can confirm similar results after 1 day of usage. Entropy your work with the battery tweaks is amazing. Ty so much. BTW where did you get your extended Battery?
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
2sl0w said:
So far I can confirm similar results after 1 day of usage. Entropy your work with the battery tweaks is amazing. Ty so much. BTW where did you get your extended Battery?
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
Click to expand...
Click to collapse
eBay - check the Accessories forum, there's a discussion on it there.
The battery cover that comes with it is pretty weak. Two people have received ones that were cracked on arrival including myself. I'm going to try and get a replacement from the vendor, otherwise figure out how to fix/strengthen the cracks.
Entropy will this work with cm7?
Sent from my SGH-I997 using XDA App
bryanb86 said:
Entropy will this work with cm7?
Sent from my SGH-I997 using XDA App
Click to expand...
Click to collapse
No
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
Entropy512 said:
Attaching some screenshots of CurrentWidget logs.
One is a log taken while driving with nav on full brightness. Look at how it periodically bumps charge current up to 700 mA - it looks like nav with full brightness needs just a shade over 600 mA. The voltages that trigger state changes are such that this translates to around 85-90% battery.
One is a log taken while charging my new 3500 mAh extended battery from 59%. (I forgot to log the voltages... Sorry.)
You'll see that it starts at 800 mA, then drops to 700 as voltage rises, then 600 (stock), then 550 (below stock, be nice to the battery), then it exits constant-current mode and enters constant voltage mode (battery voltage stays just under 4.2 volts, and current drops until charge terminates.) If you look at the spikes during the CV phase of charging you'll see why I worry about charge termination under load - those spikes are because CPU usage counts against the charge current limit.
Click to expand...
Click to collapse
Where do I get a battery like your 3500 one?
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
WeezyFBaby17 said:
Where do I get a battery like your 3500 one?
Sent from my SAMSUNG-SGH-I997R using XDA Premium App
Click to expand...
Click to collapse
Ebay.
Sent from my SAMSUNG-SGH-I997R using XDA App
00mred00 said:
Ebay.
Sent from my SAMSUNG-SGH-I997R using XDA App
Click to expand...
Click to collapse
Specifically, go over to http://forum.xda-developers.com/showthread.php?t=1175568

need a bright flash light mod.

Hello guys!
in my previous phone (xperia z2) i downloaded and replaced a file called flashled.calc.parameters.cfg and it made the flashlight very bright. i dont know what values to change in the file for xz premium. can someone help me pls?
here's the original file: https://drive.google.com/file/d/1m3sRtciBH1vCMQInty7R9TJwjPP74TDj/view?usp=sharing
many thanks in advance.
I was wondering about that.
I know that using the LED as a flashlight beyond its intended purpose (a camera flash) may deteriorate its performance, but in its current form it is pretty poor.
4rz0 said:
I was wondering about that.
I know that using the LED as a flashlight beyond its intended purpose (a camera flash) may deteriorate its performance, but in its current form it is pretty poor.
Click to expand...
Click to collapse
Indeed, we dont use it all the time. only when needed like night time or someplace dark. but i used the mod on z2 and the flashlight was equal to other smartphones like s7/8 and/or lenovo. flash used to get hot so i never used it for more than 1/2 minutes.
lets see if someone can help with that .cfg file
I'm also looking for a solution.
The light is tremendously low, indeed I can do virtually more light with display than with the led. I had the same problem with Z5 Compact and Xz Premium, while when I had Sony M4acqua I had no problems, it worked perfectly.
The same problem with led notifications, values ​​should also be increased there, they are too low...
Nobody knows a solution?
up
enige1993 said:
up
Click to expand...
Click to collapse
still waiting for someone to help
Saadkhalid786 said:
still waiting for someone to help
Click to expand...
Click to collapse
To me, those parameters seem to be fairly simple to parse.
So lets break it down:
v_batt_thres_num = 5 <- Means there are 5 different brightness values.
v_batt_0 = 4200,4100,1000000 <- Means the first value is valid when the battery voltage is between 4.2V and 4.1V and supplies 1,000,000uA (or 1 Amp) to the LED.
v_batt_1 = 4100,3700,900000 <- Same as above, only for battery between 4.1V and 3.7V with the LED getting 900mA.
v_batt_2 = 3700,3500,800000 <- Next level down. When the battery voltage has sagged to 3.7V-3.5V, only supply 800mA to the LED.
And so on.
If you want to increase the brightness, then change the last number, which appears to be measured in micro-Amps (uA).
I really wouldn't go much over 1 Amp though. The LED will generate a lot of heat, which could cause a number of problems, including melting the solder joints making it non-functional, burning out due to an overcurrent situation, having its brightness reduced over time due to premature phosphor degradation, and even heat induced problems in nearby components.
The problem you're seeing is likely due to the LED current being reduced when the phone's battery is low.
So, if you aren't concerned about battery life, then as a starting point, you could change all the final values to 1000000.
From there, if you still want it brighter, then move up in 100mA increments. Like 1100000, then 1200000.
Bear in mind that LEDs tend to be more efficient at lower current levels.
So going from 1000mA to 1100mA is going to have less of an increase in brightness than the jump from 900mA to 1000mA.
There comes a point where more power does not equal more brightness, and at 1000mA, you're already dumping around 3.5W of heat into the phone (White LED at 3.5Vf * 1Amp = 3.5 Watts).
pbarrette said:
To me, those parameters seem to be fairly simple to parse.
So lets break it down:
v_batt_thres_num = 5 <- Means there are 5 different brightness values.
v_batt_0 = 4200,4100,1000000 <- Means the first value is valid when the battery voltage is between 4.2V and 4.1V and supplies 1,000,000uA (or 1 Amp) to the LED.
v_batt_1 = 4100,3700,900000 <- Same as above, only for battery between 4.1V and 3.7V with the LED getting 900mA.
v_batt_2 = 3700,3500,800000 <- Next level down. When the battery voltage has sagged to 3.7V-3.5V, only supply 800mA to the LED.
And so on.
If you want to increase the brightness, then change the last number, which appears to be measured in micro-Amps (uA).
I really wouldn't go much over 1 Amp though. The LED will generate a lot of heat, which could cause a number of problems, including melting the solder joints making it non-functional, burning out due to an overcurrent situation, having its brightness reduced over time due to premature phosphor degradation, and even heat induced problems in nearby components.
The problem you're seeing is likely due to the LED current being reduced when the phone's battery is low.
So, if you aren't concerned about battery life, then as a starting point, you could change all the final values to 1000000.
From there, if you still want it brighter, then move up in 100mA increments. Like 1100000, then 1200000.
Bear in mind that LEDs tend to be more efficient at lower current levels.
So going from 1000mA to 1100mA is going to have less of an increase in brightness than the jump from 900mA to 1000mA.
There comes a point where more power does not equal more brightness, and at 1000mA, you're already dumping around 3.5W of heat into the phone (White LED at 3.5Vf * 1Amp = 3.5 Watts).
Click to expand...
Click to collapse
im sorry but im a complete noob in this. the flash is same in full battery or low .i dont want it to be too bright, just want it to be equal to all other phones with very good brightness. can u edit and upload the file pls?
much thanks for your response.
It's entirely possible that they just use a pretty poor LED in the phone.
I may try to figure that out.
Also, how can we make sure the torch toggle is using the highest possible battery threshold and not just always the lowest one?
4rz0 said:
It's entirely possible that they just use a pretty poor LED in the phone.
I may try to figure that out.
Also, how can we make sure the torch toggle is using the highest possible battery threshold and not just always the lowest one?
Click to expand...
Click to collapse
i realized the flash is brighter than when toggled with torch button. for example take a picture with flash and look at flash. the first flash (focusing) will be lower, and the second flash (capturing) will be very bright.
on my previous xperia z2 i downloaded a modded file and the flash was way brighter. and i think it has the same flash as previous flagship models.
but where is the file?
enige1993 said:
but where is the file?
Click to expand...
Click to collapse
I already deleted the firmware image I extracted, but if I recall correctly, it's in /system/vendor/etc/.
Here is the original file if someone will lost it.
Anyway I've just tried to set all the parameters to 1,5A (1500000value), but I can not see significant changes...
Infact it's really so less bright than other devices ever with just one led, but WHY?
Do you think that increasing those value to 2A or little more is too mutch the risk?

Samsung galaxy on8

Working mods
https://forum.xda-developers.com/galaxy-j5/themes/s8-mod-touchwizhome2017-nougat-t3660875
Sent from my SM-J710FN using XDA-Developers Legacy app
ALSO
Nougat Stock Rom deodexed
Link is here
https://forum.xda-developers.com/showthread.php?p=74557284
Sent from my SM-J710FN using XDA-Developers Legacy app
BOOST BATTERY 10% IN GALAXY ON8
I was able to find a workaround for the battery percentage:
1. FIRST Get your battery capacity!!!
$ adb shell cat /sys/class/power_supply/battery/batt_capacity_max
942
2. Calculate your 100%
942** 1.1 = 1036
MAX=1070
DON'T PUT IT
PUT BELOW 1050 OR 1050
3a. Charge battery fully (UI will say 80%):
Use your new 100% value in place of my 1036!!
adb shell
$ su
# echo 1036 > /sys/class/power_supply/battery/batt_capacity_max
3b. To revert back (and see actual %):
put your old value in place of my 800 here
adb shell
$ su
# echo 942 > /sys/class/power_supply/battery/batt_capacity_max
Warning:This is not persistent across reboots (but could be implemented as such)This does not change the fact that your battery meter will say 80%This confuses your phone into thinking the 80% limit is higher than it actually isThis could be harmful to your battery life, battery condition, and battery operationThe Control Chip on the battery itself should prevent any unnecessary charging from occurringI'm just a guy on the internet, don't mess with your phone unless your are willing to pay for any mistakes.
How this works:The Kernel reads the battery percentage from /sys/class/power_supply/battery/capacityWe make the maximum battery capacity increase by 20% /sys/class/power_supply/battery/batt_capacity_max (the commands above)Kernel reads the battery percentage from /sys/class/power_supply/battery/capacity again and its now 20% lower because of capacity calculations (percentage = used capacity / batt_capacity_max)Kernel lets the charging continue to 80% which is in actuality 100%
FAQDoes this work?
Yes this works. The explanation is above. Succinctly, these commands trick your kernel into thinking the 80% limit is at 100% of the battery.
Shouldn't we be adding 25% to reach 100% of the battery?
While this is correct, I tested a few percentages and noted that 20% increase will reach 99% battery on my phone. This does not mean it will for everyone.*PLEASE BE COGNIZANT OF OVERCHARGING
This isn't working for me, why do the values change?
You*must*be a superuser in the terminal for these commands to stick. They do not stick across reboots.
This still doesn't work, wah wah wah. I wan't 100%...
I am trying to help the community. If you don't want help you can keep the 80% charge. Multiple people have said it works. If you don't want to try it don't. Blindly saying it doesn't work is only poisoning the well.
Video Guide:
Setting Battery Maximum Past 80%
https://youtu.be/dEdmIDEKYtA
Setting Battery Maximum Back to Original
https://youtu.be/TDirEoSsSkk

Haldi's Benchmark Thread for Testing&Fiddling with the Xperia XZ2

Howdy,
You might remember me from the Xperia Z2 or the Xperia Z. I've started playing around with Android on my old Sony Xperia X10i and i've always liked fiddling around with too much data and thoroughly testing what i own in order to fully understand it.
Lately i've been active in the HTC 10 Subforums but since the Battery started going bad i've become afraid of the phone dying on me and i got this really good deal on the XZ2. So here i am back at Sonys.
So... this thread is mainly for me to keep my findings sorted but you might also find some interesting things here.
If you take a look at my older threads you'll know what to expect
What's new with the Xperia XZ2?
Well.... Android 8.0 with SD845 and 4.9 Kernel... no more Interactive governor. We got EAS built in an use SchedUtil. While it is possible to modify the behaviour of SchedUtil via SchedTune it's nowhere nearly as complex as Interactive or different governors.
Trepn Profiler doesn't report Battery Power anymore... while Trepn Profiler has been partially broken since Android 6.0 it did work kinda fine on the SD820 devices even with Android 8.1 and custom Kernels. (except Load%) Even though it was limited one poll per 30sec. While on the XZ2 only estimated Power is available. Which does not work due to missing CPU load.
Benchmarking:
Powerdrain: Find out how much the Phone is using under specific circumstances.
Charging: How fast does the Device charge from 1% to 100%
Throttling: Analyzing Thermal and Powerlimit Throttling
Benchmarking Apps:
Repetitouch: To create custom Benchmarks that simulate normal everyday usage.
BatteryLog: For Charging Benchmark, Voltage and Battery% per Minute
GameBench: For FPS in games. (Make sure you deactivate Screenshot function for HTC10)
Benchmarking Hardware:
YZX Powermonitor: USB 3.0 QC3.0 4-13V 0-3A USB A Male-> USB A Female Powermonitor that measures Voltage and Current passing trough.
I'll update this Post when new infos are available...
Index:
Charging Stock ROM with Stock Charger Post NR3
Thermal Throttling and Taks Migration / Load Balancing Post NR6
Powerdrain & Thermal Throttling on GPU & CPU Post NR7
Thermal Throttling on Android P | 5% Battery Limit Post NR9
Charging Android P no Qnovo.... Post NR10
Charging Android 10 Post NR15
Aftermarket Batteries Tested Post NR16
OFFICIAL Battery Tested.... not better -.- Post NR19
Charging Sony Xperia XZ Stock ROM with Stock Charger
Qnovo in Action!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
First thing we see is the max Voltage.... this phone is fully charged at 4,331V Okay? Guess that's the new kind of Battery. I'm used to see 4,4V
After 40 Minutes when the battery reached 40°C and 60% there is Thermal Throttling. If you take a look at the HTC10 Charging you can see the CCCV breaking point this does not happen here, it's simply reduced from 11W to 8W which does indicate throttling. It's only after 117 Minutes when the Battery reaches 4,33V that you can see the expected curve...
This has to do with the new Qnovo Charging Technology. Nice read on Qnovo Charging Technology...
In the far future when my phone found out when i charge it over night i'm also gonna measure the Battery Care in action i wonder how slow it charges if it has the time.
Oh, and i'll have to Try with Another QC3.0 Charger. While the UCH12 is QC3.0 and PD2.0 compatible even the Old Sony Chargers said 1.5A but only charged the phone with 1A....
just some ramblings to not forget....
H8216:/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_governors
conservative ondemand userspace powersave performance schedutil
H8216:/sys/devices/system/cpu/cpu0/cpufreq $ cat scaling_available_frequencies
300000 403200 480000 576000 652800 748800 825600 902400 979200 1056000 1132800 1228800 1324800 1420800 1516800 1612800 1689600 1766400
H8216:/sys/devices/system/cpu/cpu0/cpufreq/schedutil $ cat hispeed_freq
1209600
H8216:/sys/devices/system/cpu/cpu0/cpufreq/schedutil $ cat hispeed_load
90
H8216:/sys/devices/system/cpu/cpu0/cpufreq/schedutil $ cat pl
1
H8216:/sys/devices/system/cpu/cpu0/cpufreq/schedutil $ cat rate_limit_us
0
Click to expand...
Click to collapse
H8216:/sys/devices/system/cpu/cpu4/cpufreq $ cat scaling_available_governors
conservative ondemand userspace powersave performance schedutil
H8216:/sys/devices/system/cpu/cpu4/cpufreq $ cat scaling_available_frequencies
825600 902400 979200 1056000 1209600 1286400 1363200 1459200 1536000 1612800 1689600 1766400 1843200 1920000 1996800 2092800 2169600 2246400 2323200 2400000 2476800 2553600 2649600
H8216:/sys/devices/system/cpu/cpu4/cpufreq $ cat scaling_boost_frequencies
2803200
H8216:/sys/devices/system/cpu/cpu4/cpufreq/schedutil $ cat hispeed_freq
1574400
H8216:/sys/devices/system/cpu/cpu4/cpufreq/schedutil $ cat hispeed_load
90
H8216:/sys/devices/system/cpu/cpu4/cpufreq/schedutil $ cat pl
1
H8216:/sys/devices/system/cpu/cpu4/cpufreq/schedutil $ cat rate_limit_us
0
Click to expand...
Click to collapse
/dev/stune doesn't really show much.... schedtune.boost always seems to be 0.
Some Sensor paths... might need them later on.
H8216:/ $ for file in sys/class/thermal/thermal_zone*/type; do echo "$file"; cat "$file"; done
sys/class/thermal/thermal_zone0/type
aoss0-usr
sys/class/thermal/thermal_zone1/type
cpu0-silver-usr
sys/class/thermal/thermal_zone2/type
cpu1-silver-usr
sys/class/thermal/thermal_zone3/type
cpu2-silver-usr
sys/class/thermal/thermal_zone4/type
cpu3-silver-usr
sys/class/thermal/thermal_zone5/type
kryo-l3-0-usr
sys/class/thermal/thermal_zone6/type
kryo-l3-1-usr
sys/class/thermal/thermal_zone7/type
cpu0-gold-usr
sys/class/thermal/thermal_zone8/type
cpu1-gold-usr
sys/class/thermal/thermal_zone9/type
cpu2-gold-usr
sys/class/thermal/thermal_zone10/type
cpu3-gold-usr
sys/class/thermal/thermal_zone11/type
gpu0-usr
sys/class/thermal/thermal_zone12/type
gpu1-usr
sys/class/thermal/thermal_zone13/type
aoss1-usr
sys/class/thermal/thermal_zone14/type
mdm-dsp-usr
sys/class/thermal/thermal_zone15/type
ddr-usr
sys/class/thermal/thermal_zone16/type
wlan-usr
sys/class/thermal/thermal_zone17/type
compute-hvx-usr
sys/class/thermal/thermal_zone18/type
camera-usr
sys/class/thermal/thermal_zone19/type
mmss-usr
sys/class/thermal/thermal_zone20/type
mdm-core-usr
sys/class/thermal/thermal_zone21/type
gpu-virt-max-step
sys/class/thermal/thermal_zone22/type
silv-virt-max-step
sys/class/thermal/thermal_zone23/type
gold-virt-max-step
sys/class/thermal/thermal_zone24/type
pop-mem-step
sys/class/thermal/thermal_zone25/type
cpu0-silver-step
sys/class/thermal/thermal_zone26/type
cpu1-silver-step
sys/class/thermal/thermal_zone27/type
cpu2-silver-step
sys/class/thermal/thermal_zone28/type
cpu3-silver-step
sys/class/thermal/thermal_zone29/type
cpu0-gold-step
sys/class/thermal/thermal_zone30/type
cpu1-gold-step
sys/class/thermal/thermal_zone31/type
cpu2-gold-step
sys/class/thermal/thermal_zone32/type
cpu3-gold-step
sys/class/thermal/thermal_zone33/type
lmh-dcvs-01 Stuck at 75000 no matter what...
sys/class/thermal/thermal_zone34/type
lmh-dcvs-00 Stuck at 75000 no matter what...
sys/class/thermal/thermal_zone35/type
pm8998_tz 20° Colder than cores at load, idle is same
sys/class/thermal/thermal_zone36/type
aoss0-lowf
sys/class/thermal/thermal_zone37/type
cpu0-silver-lowf
sys/class/thermal/thermal_zone38/type
cpu1-silver-lowf
sys/class/thermal/thermal_zone39/type
cpu2-silver-lowf
sys/class/thermal/thermal_zone40/type
cpu3-silver-lowf
sys/class/thermal/thermal_zone41/type
kryo-l3-0-lowf
sys/class/thermal/thermal_zone42/type
kryo-l3-1-lowf
sys/class/thermal/thermal_zone43/type
cpu0-gold-lowf
sys/class/thermal/thermal_zone44/type
cpu1-gold-lowf
sys/class/thermal/thermal_zone45/type
cpu2-gold-lowf
sys/class/thermal/thermal_zone46/type
cpu3-gold-lowf
sys/class/thermal/thermal_zone47/type
gpu0-lowf
sys/class/thermal/thermal_zone48/type
gpu1-lowf
sys/class/thermal/thermal_zone49/type
aoss1-lowf
sys/class/thermal/thermal_zone50/type
mdm-dsp-lowf
sys/class/thermal/thermal_zone51/type
ddr-lowf
sys/class/thermal/thermal_zone52/type
wlan-lowf
sys/class/thermal/thermal_zone53/type
compute-hvx-lowf
sys/class/thermal/thermal_zone54/type
camera-lowf
sys/class/thermal/thermal_zone55/type
mmss-lowf
sys/class/thermal/thermal_zone56/type
mdm-core-lowf
sys/class/thermal/thermal_zone57/type
ibat-high from 500 idle to 2200 load, dropping with throttling to 1120
sys/class/thermal/thermal_zone58/type
ibat-vhigh same as above
sys/class/thermal/thermal_zone59/type
vbat 3744 at idle 3666 at load.... wtf is this voltage?
sys/class/thermal/thermal_zone60/type
vbat_low same as above
sys/class/thermal/thermal_zone61/type
vbat_too_low same as above
sys/class/thermal/thermal_zone62/type
soc idles at 44, drops to 42 and 42 at load...
sys/class/thermal/thermal_zone63/type
pmi8998_tz Broken "No Data available"
sys/class/thermal/thermal_zone64/type
xo-therm-adc
sys/class/thermal/thermal_zone65/type
msm-therm-adc
sys/class/thermal/thermal_zone66/type
pa-therm1-adc
sys/class/thermal/thermal_zone67/type
quiet-therm-adc
sys/class/thermal/thermal_zone68/type
ufs_therm idles at 37656 drops to 33672 at load
sys/class/thermal/thermal_zone69/type
pa_therm2
sys/class/thermal/thermal_zone70/type
flash_therm
sys/class/thermal/thermal_zone71/type
battery you guessed it... battery!
sys/class/thermal/thermal_zone72/type
wireless broken "no such device"
sys/class/thermal/thermal_zone73/type
bms same as battery at idle, 6°C colder at load. Shis should be interesting while charging
sys/class/thermal/thermal_zone74/type
sony_camera_0 broken "no such device"
sys/class/thermal/thermal_zone75/type
sony_camera_1 broken "no such device"
sys/class/thermal/thermal_zone76/type
wsatz.14 either around 34 to 55
sys/class/thermal/thermal_zone77/type
wsatz.13 idles at 38, goes to 53 at load
Edit: i did a test while Loaded and saw how the temperatures changed... Oh... and i also wrote a little script, to run on your phone, which writes all temperatures down as .csv
Yeah..... there is a lot of sensors... so let's try to cut some...
the normal difference between usr step and lowf is almost nonexistent... so one should be enough.
H8216:/ $ for file in sys/class/thermal/cooling_device*/type; do echo "$file"; cat "$file"; done
sys/class/thermal/cooling_device0/type
panel0-backlight
sys/class/thermal/cooling_device1/type
thermal-devfreq-0
sys/class/thermal/cooling_device2/type
thermal-cpufreq-0
sys/class/thermal/cooling_device3/type
thermal-cpufreq-1
sys/class/thermal/cooling_device4/type
thermal-cpufreq-2
sys/class/thermal/cooling_device5/type
thermal-cpufreq-3
sys/class/thermal/cooling_device6/type
thermal-cpufreq-4 #Throttling is happening here: shows value 10
sys/class/thermal/cooling_device7/type
thermal-cpufreq-5
sys/class/thermal/cooling_device8/type
thermal-cpufreq-6
sys/class/thermal/cooling_device9/type
thermal-cpufreq-7 #Throttling is happening here: shows value 24
sys/class/thermal/cooling_device10/type
ebi
sys/class/thermal/cooling_device11/type
cx
sys/class/thermal/cooling_device12/type
mx-cdev-lvl
sys/class/thermal/cooling_device13/type
cdsp_vdd
sys/class/thermal/cooling_device14/type
adsp_vdd
sys/class/thermal/cooling_device15/type
slpi_vdd
sys/class/thermal/cooling_device16/type
modem_pa
sys/class/thermal/cooling_device17/type
modem_proc
sys/class/thermal/cooling_device18/type
modem_vdd
sys/class/thermal/cooling_device19/type
modem_current
sys/class/thermal/cooling_device20/type
modem_skin
EDIT: P Dev Preview 2
oooh Fûck this shít they changed quite a bit in P dev Preview 2 -.-
C:\ADB>adb shell for file in sys/class/thermal/thermal_zone*/type; do echo "$file"; cat "$file"; done
sys/class/thermal/thermal_zone0/type
aoss0-usr
sys/class/thermal/thermal_zone1/type
cpu0-silver-usr
sys/class/thermal/thermal_zone10/type
cpu3-gold-usr
sys/class/thermal/thermal_zone11/type
gpu0-usr
sys/class/thermal/thermal_zone12/type
gpu1-usr
sys/class/thermal/thermal_zone13/type
aoss1-usr
sys/class/thermal/thermal_zone14/type
mdm-dsp-usr
sys/class/thermal/thermal_zone15/type
ddr-usr
sys/class/thermal/thermal_zone16/type
wlan-usr
sys/class/thermal/thermal_zone17/type
compute-hvx-usr
sys/class/thermal/thermal_zone18/type
camera-usr
sys/class/thermal/thermal_zone19/type
mmss-usr
sys/class/thermal/thermal_zone2/type
cpu1-silver-usr
sys/class/thermal/thermal_zone20/type
mdm-core-usr
sys/class/thermal/thermal_zone21/type
gpu-virt-max-step
sys/class/thermal/thermal_zone22/type
silv-virt-max-step
sys/class/thermal/thermal_zone23/type
gold-virt-max-step
sys/class/thermal/thermal_zone24/type
pop-mem-step
sys/class/thermal/thermal_zone25/type
cpu0-silver-step
sys/class/thermal/thermal_zone26/type
cpu1-silver-step
sys/class/thermal/thermal_zone27/type
cpu2-silver-step
sys/class/thermal/thermal_zone28/type
cpu3-silver-step
sys/class/thermal/thermal_zone29/type
cpu0-gold-step
sys/class/thermal/thermal_zone3/type
cpu2-silver-usr
sys/class/thermal/thermal_zone30/type
cpu1-gold-step
sys/class/thermal/thermal_zone31/type
cpu2-gold-step
sys/class/thermal/thermal_zone32/type
cpu3-gold-step
sys/class/thermal/thermal_zone33/type
lmh-dcvs-01
sys/class/thermal/thermal_zone34/type
lmh-dcvs-00
sys/class/thermal/thermal_zone35/type
pm8998_tz
sys/class/thermal/thermal_zone36/type
pm8005_tz
sys/class/thermal/thermal_zone37/type
aoss0-lowf
sys/class/thermal/thermal_zone38/type
cpu0-silver-lowf
sys/class/thermal/thermal_zone39/type
cpu1-silver-lowf
sys/class/thermal/thermal_zone4/type
cpu3-silver-usr
sys/class/thermal/thermal_zone40/type
cpu2-silver-lowf
sys/class/thermal/thermal_zone41/type
cpu3-silver-lowf
sys/class/thermal/thermal_zone42/type
kryo-l3-0-lowf
sys/class/thermal/thermal_zone43/type
kryo-l3-1-lowf
sys/class/thermal/thermal_zone44/type
cpu0-gold-lowf
sys/class/thermal/thermal_zone45/type
cpu1-gold-lowf
sys/class/thermal/thermal_zone46/type
cpu2-gold-lowf
sys/class/thermal/thermal_zone47/type
cpu3-gold-lowf
sys/class/thermal/thermal_zone48/type
gpu0-lowf
sys/class/thermal/thermal_zone49/type
gpu1-lowf
sys/class/thermal/thermal_zone5/type
kryo-l3-0-usr
sys/class/thermal/thermal_zone50/type
aoss1-lowf
sys/class/thermal/thermal_zone51/type
mdm-dsp-lowf
sys/class/thermal/thermal_zone52/type
ddr-lowf
sys/class/thermal/thermal_zone53/type
wlan-lowf
sys/class/thermal/thermal_zone54/type
compute-hvx-lowf
sys/class/thermal/thermal_zone55/type
camera-lowf
sys/class/thermal/thermal_zone56/type
mmss-lowf
sys/class/thermal/thermal_zone57/type
mdm-core-lowf
sys/class/thermal/thermal_zone58/type
ibat-high
sys/class/thermal/thermal_zone59/type
ibat-vhigh
sys/class/thermal/thermal_zone6/type
kryo-l3-1-usr
sys/class/thermal/thermal_zone60/type
vbat
sys/class/thermal/thermal_zone61/type
vbat_low
sys/class/thermal/thermal_zone62/type
vbat_too_low
sys/class/thermal/thermal_zone63/type
soc
sys/class/thermal/thermal_zone64/type
pmi8998_tz
sys/class/thermal/thermal_zone65/type
xo-therm-adc
sys/class/thermal/thermal_zone66/type
msm-therm-adc
sys/class/thermal/thermal_zone67/type
pa-therm1-adc
sys/class/thermal/thermal_zone68/type
quiet-therm-adc
sys/class/thermal/thermal_zone69/type
ufs_therm
sys/class/thermal/thermal_zone7/type
cpu0-gold-usr
sys/class/thermal/thermal_zone70/type
pa_therm2
sys/class/thermal/thermal_zone71/type
flash_therm
sys/class/thermal/thermal_zone72/type
battery
sys/class/thermal/thermal_zone73/type
wireless
sys/class/thermal/thermal_zone74/type
bms
sys/class/thermal/thermal_zone75/type
sony_camera_0
sys/class/thermal/thermal_zone76/type
sony_camera_1
sys/class/thermal/thermal_zone77/type
wsatz.14
sys/class/thermal/thermal_zone78/type
wsatz.13
sys/class/thermal/thermal_zone8/type
cpu1-gold-usr
sys/class/thermal/thermal_zone9/type
cpu2-gold-usr
Thermal/cooling_device is still the same...
akari:/ $ for file in sys/class/thermal/cooling_device*/type; do echo "$file"; cat "$file"; done |MAX|MIN|
sys/class/thermal/cooling_device0/type
panel0-backlight |4095|error|
sys/class/thermal/cooling_device1/type
thermal-devfreq-0 |6|6|
sys/class/thermal/cooling_device10/type
ebi |1|1|
sys/class/thermal/cooling_device11/type
cx |1|1|
sys/class/thermal/cooling_device12/type
mx-cdev-lvl |1|1|
sys/class/thermal/cooling_device13/type
cdsp_vdd |1|1|
sys/class/thermal/cooling_device14/type
slpi_vdd |1|1|
sys/class/thermal/cooling_device15/type
adsp_vdd |1|1|
sys/class/thermal/cooling_device16/type
modem_pa |3|0|
sys/class/thermal/cooling_device17/type
modem_proc |3|0|
sys/class/thermal/cooling_device18/type
modem_vdd |1|1|
sys/class/thermal/cooling_device19/type
modem_current |3|0|
sys/class/thermal/cooling_device2/type
thermal-cpufreq-0 |18|18|
sys/class/thermal/cooling_device20/type
modem_skin |3|0|
sys/class/thermal/cooling_device3/type
thermal-cpufreq-1 |18|18|
sys/class/thermal/cooling_device4/type
thermal-cpufreq-2 |18|18|
sys/class/thermal/cooling_device5/type
thermal-cpufreq-3 |18|18|
sys/class/thermal/cooling_device6/type
thermal-cpufreq-4 |24|24|
sys/class/thermal/cooling_device7/type
thermal-cpufreq-5 |24|24|
sys/class/thermal/cooling_device8/type
thermal-cpufreq-6 |24|24|
sys/class/thermal/cooling_device9/type
thermal-cpufreq-7 |24|24|
To Properly show these Values i've modified the adb reading scripts i've found somewhere else on XDA...
You simply start the .bat file when connected via ADB... either trough USB, or connect phone via USB type "ADB tcpip 5555" unplug, when in WiFi use adb connect 192.168.1.XX:5555
Welcome back! ^^
Thermal Throttling & Task Migration / Load Balancing
When i first used this phone i tought i'd have Endless power in my hands, so i couldn't resist using it ALL. Started CPU Load Generator app and saw that even with 8 Threads fully loaded the phone does not throttle down CPU....
Sound awesome huh? Even the Temperature wasn't getting that hot. Coooool... (pun intended)
But i was a tiny wee bit Skeptical. Could it really be? So i've decided to use my USB Powermeter and charge my phone to 100%. After a while the phone kept using the same current. 0.255W to be accurate. (With Screen Off and WiFi connected)
using a Full Load i could see all CPU cores staying at the max Frequency.
But.... the wallcharger did say something different!
Not even a Full Minute! While it does peak at 8W it falls down to a sustaineable 4W rapidly. (Even drops to 3.5W Later on...)
So What's going on here?
Using Snapdragon Profiler with ADB over WiFi i've tried different Load Scenarios, 1-9 threads and 16 threads.
1 Thread:
You can see the Thread jumping between core 5, 6 and 7
2 Threads:
With 2 Threads core 4 is also used this time
3 Threads:
with 3 Threads Core 7 is not being used anymore... throttling? The phone is trying to reach a sustaineable temperature of 60°C by limiting Big cores to 2.4ghz
4 Threads:
While core 7 stays offline we see the small cores being used, and a throttling to 2.4ghz on big cores.
5 Threads:
While it did cool down enough to go back to the big cores previously, now it stays on small cores. Also 2.17ghz on big cores.
6 Threads:
7 Threads:
Dropping to 1.84ghz on big cores
8 Threads:
Aaaannndd... here is the magic! 2.8ghz on big cores! Somehow the phone switched to another throttling method than frequency.
9 Threads:
While we did see some slight CPU frequency drops with 8 threads, they're all gone with 9.
16 Threads:
Exactly the same as with 9 threads.
Sadly Snapdragon Profiler does not show BatteryPower on the XZ2 So it seems plugging to the WallCharger is the only way to figure this out.
I'll have to redo tests when my phone is fully charged and see if i can get a consistent powerdrain.
Edit: Update: Android P Beta.... Dev Preview 2
Starting with 4 Threads...
Core 7 does NOT get turned off anymore.... But you do see a small task migration as soon as 68°C are hit. Small cores get more load.
Looking at the Performance you see a gradual degradation, and not big spikes like before.
With 7 Threads:
We can see Thermal Limit has been increased to 72°C
The Performance drops really fast to 85%-90% but manages to stay there for a long long time. i'm really impressed.
Edit:
Absolutly nothing new with Android 10 (Again 8 Threads)
Powerdrain & Thermal Throttling
Okay... here we go... Wallcharger + Snapdragon Profiler...
First i've charged my phone fully to check Idle drain. Around 0.3W check.
About GPU testing:
You see the Idle 1.2W Powerdrain at the beginning? That's because Snapdragon Profiler is connected via ADB over WiFi. Quite a lot compared to the 0.3W Idle...
The first few Peaks until 12 Minutes are a failure because i've accidently started the sublevel Benchmarks^^
The first real Peak to 5.4W is a CarChase OnScreen.
The 1.7G on Clocks/Second is a reading error, normal Max is 710Mhz.
You can see the Temperature reaching 66°C and throttling starts, GPU going to 600Mhz, also Big Cores limiting to 2.17ghz.
The 2nd Peak is CarChase OffScreen.
You can see the big cores dropping in Frequency pretty early. GPU maxed out at 710mhz, until the phone reaches 68°C. GPU throttles heavily, and Big cores are going Offline putting the Load on small cores.
Which caused a drop in Powerusage from 5W to 3.7W
The last Peak is Manhatten OffScreen.
When Throttling starts at 68°C GPU drops from 710mhz to 600mhz and task migration from big to small cores.
The Powerdrain is reduced from 4.4W to 3.9W
About CPU testing:
Well.... that didn't work as well as expected... In the Powermonitor graph you can see i've used CPU Load Generator started with 1 Thread, and added 1 more after 1 Minute, until i had 4 threads.
Admittely the phone was already 45°C when i started this test... therefore i've already had throttling before i even started.... But well.... i've expected more...
The same peaks that are visible in the Powermonitor graph are also clearly visible in the temperature graph on Snapdragon Profiler.
So even if the phone is throttling, it allows Burstpower/increased thermal limit for new tasks, to reduce lag. Pretty neat.
Edit: Here we go... on a cold device:
As always, until Minute 1.2 is pure IDLE, from 2-2.7 is whit ADB over WiFi and Snapdragon Profiler connected.
At Minute 3 you see the start of the first Task. Using around 3.3W
At 4.2 you see the 2nd Task starting, generating 4.4W load
At 5.2 the 3rd Task starts, using up to 6.3W but shortly after (timestamp 225s in the graph below) the phone reaches 68°C and starts throttling. Load drops to 5W. because the continous Load of 5W is not sustaineable the phone throttles down to 4.1W (timestamp 245s)
Tt 6.2 Minutes the 4th Task is started, which generates 5.2W, this causes the phone to get almost 68°C again (timestamp 275s) and drops powerdrain to 3.3W, the phone cools down to about 60°C (timestamp 295s) and stop throttling, therefore peaking to 6.1W and rising to 68°C again in 10 seconds. Trying to limit powerdrain to 5.2W for the next 5 seconds fails, and task migration kicks in turning core7 offline and pushing load onto little cores. Limiting Big cores to 2.4ghz and using 3.9W
(timestamp 0s equals 2 Minutes on the other graph)
Edit2:
So what does that mean for Performance?
I've used the App CPU Throttling Test to create a workload and also Display it's performance. Here you can see 3 threads at work. Full Performance 125.9GIPS
The 2 Minute run does not throttle, Snapdragon Profiler proofs that
Using the app with 7 Threads causes throttling twice. But again, all cores are shown at full frequency.
Using Snapdragon Profiler we can see the phone throttling at 64°C (timestamp 447s) and later on at 60°C (timestamp 490s)
The performance drops from 125.9Gips to 104.9Gips. Nothing in Snapdragon profiler would indicate that.... CPU frequency stays the same and Load is also equal.
These graphs are such a pain
I have no clue where the Thermal Limit is on the P Beta.... but it seems to be quite high!
(click on Image to get redirected to interactive Chart from Google Sheets)
(The Drops are when i stopped testing and changed from 8 to 7 to 6 threads)
panel0-backlight thermal-devfreq-0 thermal-cpufreq-0 thermal-cpufreq-1 thermal-cpufreq-2 thermal-cpufreq-3 thermal-cpufreq-4 thermal-cpufreq-5 thermal-cpufreq-6 thermal-cpufreq-7
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
There is NO throttling due to Task Migration, thats what Snapdragon profiler said, and the value in sys/class/thermal/cooling_device0/cur_state proofs this. As you can see in the example above, they stayed at 0 during the whole test.
Which is nice to know, since now we're certain Performance throttling does not happen due to a value in thermal/cooling_device*
Edit:
Oh.... not sure if this is a P feature or happens on Oreo too... gotta test...
But when you reach 5% Battery big cores shovel all Tasks to small cores, therefore frequency drops to 800mhz and performance takes a HUGE hit.
This time we see all 4 big cores reach a value of 24 on sys/class/thermal/cooling_device* for thermal-cpufreq-4, 5, 6 and 7.
Edit 2: Thermal Throttling on Android P (dev preview 2)
Yeah... i need way more patience.... Did another test, this time while charging, so we have power Measurement!
We already knew Thermal limit was WAY higher on P.....
(interactive Chart...)
Because this was using External Power from Wallcharger the battery did not heat up as fast because it was not used. Took 10 minutes for the battery to reach 43°C while the starting point was about 32°C
What we did not know... the PowerLimit is different too!
on Oreo it peaks at 8W and then rapidly drops to 6W and even lower to 4W when the Limit kicks in.
Thanks to the bigger Thermal Headroom we have in P it only peaks to 6.5W and drops to 5.8W in 1 minute but after that it continuously falls from 5.8W to 5W in 10 Minutes! Seems like it manages to stay at 5W. Oreo couldn't handle that.
You Remember Qnovo Charging on the XZ2 ?
Haldi4803 said:
Qnovo in Action!
Click to expand...
Click to collapse
Well... it's not present in Android P Dev Preview 2.
We still have the typical CCCV point
But instead QuickCharge 3.0 is doing a good job in scaling Voltage.
Charging is fast, 105 minutes to 130 Minutes... but with Qnovo you have 93% at 105 Minutes, who cares about 7% If you have way better battery live.
Sadly Bluetooth Broke down after 70 Minutes.... oh well you can probably imagine what happens from minutes 70 to 130 right? ^^
Haldi4803 said:
You Remember Qnovo Charging on the XZ2 ?
Well... it's not present in Android P Dev Preview 2.
We still have the typical CCCV point
But instead QuickCharge 3.0 is doing a good job in scaling Voltage.
Charging is fast, 105 minutes to 130 Minutes... but with Qnovo you have 93% at 105 Minutes, who cares about 7% If you have way better battery live.
Sadly Bluetooth Broke down after 70 Minutes.... oh well you can probably imagine what happens from minutes 70 to 130 right? ^^
Click to expand...
Click to collapse
Coming from OnePlus, I'm not impressed at all. My 5T could do 0-93% in only 60 mins. Almost twice as fast... Old OnePlus phones didn't seem to suffer from battery degradation after more than a year either.
davidletterboyz said:
Coming from OnePlus, I'm not impressed at all. My 5T could do 0-93% in only 60 mins. Almost twice as fast... Old OnePlus phones didn't seem to suffer from battery degradation after more than a year either.
Click to expand...
Click to collapse
Firstly Sony is limiting itself to QC 3.0. Secondly seeing as higher end phones all pack high quality batteries, they all suffer little degradation in the first place. Sony's method might make them last even longer. Come back in 2 to 3 years time and compare the battery health before saying you are not impressed. Not everyone is rich like you people to change phones every year or less. There are people who think about really long term usage and this should benefit them considering how batteries are non user replaceable nowadays.
hotcakes_shinku said:
Firstly Sony is limiting itself to QC 3.0. Secondly seeing as higher end phones all pack high quality batteries, they all suffer little degradation in the first place. Sony's method might make them last even longer. Come back in 2 to 3 years time and compare the battery health before saying you are not impressed. Not everyone is rich like you people to change phones every year or less. There are people who think about really long term usage and this should benefit them considering how batteries are non user replaceable nowadays.
Click to expand...
Click to collapse
I said that because my friend is still using his OP3 and it's been two years. His SOT is still largely similar and he use Dash charge all the time.
And no I am not rich. Rich people buy iPhone.
hotcakes_shinku said:
Firstly Sony is limiting itself to QC 3.0. Secondly seeing as higher end phones all pack high quality batteries, they all suffer little degradation in the first place. Sony's method might make them last even longer. Come back in 2 to 3 years time and compare the battery health before saying you are not impressed. Not everyone is rich like you people to change phones every year or less. There are people who think about really long term usage and this should benefit them considering how batteries are non user replaceable nowadays.
Click to expand...
Click to collapse
one thing worth noting when it comes to battery life
What killed my battery on my Z1 (I replaced it twice) was doing nandroid backups with TWRP, I believe part of the problem is that all the OS battery control and protection is not running when you boot into recovery and it causes extreme overheating, it is definitely something to be aware of and IMO destroys batteries
Charging Android 10
Nothing much changed For the good or the bad ^^
Aftermarket Battery Tests
Aftermarket Battery Tests
Because i was unhappy with the Batterylife of my XZ2, it was nowhere near where it has been 2 years before, i decided to open my phone and replace the battery!
Opening your phone seems kinda easy, so no big issue. In theory... in practice you need to be aware of 2 important details.
You need new Glue to close it again. Afaik Witrigs is the only seller of that.
Be verry carefull on the bottom part. If you go too dep you will cut your Display cable and need to buy a new LCD for 35$. I'm speaking from experience....
How to test the battery?
Because the connector of the battery is proprietary and extremely compact you can't plug the battery directly, so i had to make use of the USB Power Delivery function to draw 5V out of the phone.
The Phone was in Flight mode with screen off, to make sure no other services use the battery. Then i connected a Load Generator i bought from aliexpress. Drawing 5V 1A my 2.5 year old battery lasted 1h33 min and gave out 7.6Wh
Original Battery:
Which has been in use for more than 2 years.
7.6Wh - 7.8Wh Obviously i did 2-3 Tests to see if i get the same every time. And it was always around that.
Hsabat 4300mAh Battery:
Bought from Aliexpress for 13.- Looks pretty decent. Is utter crap. As one expects.
First charge gave 7.3Wh, Second charge gave 5.6Wh and third charge gave 6.5Wh Not something you want to put in your phone.
Witrigs Battery:
Since i bought the glue there anway, why not just get a battery for 9$ and test that!
It looks bland (black) but hey... who cares as long as it works.... right? it works?.... well yeah...
First charge gave 7.3Wh and the others were also around that. "New" Battery? i Don't think so...
Phonedepot
Because i was disapointed that my old 2.5years harshly used battery has better capacity than **** i bought online i went to a swiss shop which has quality batteries... well yeah... at least is supposed to: Phonedepot.ch
It's more expensive but has faster shipping (as its close by) and the quality of the battery looks way better from the ouside.
I managed to draw 7.4Wh - 7.5Wh
Conclusion
Well... it was obvious before i even started.... i just didn't want to believe it.
Aftermarket batteries sucks. All of them!
Simply replacing your battery to get better batterylife is a dream. If youre battery broke down completly a replacement can help out, yes. But not if the battery is ageing normally.
This is extremely useful info, thank you for the tests.
Yeah, so this is a problem. As I mentioned earlier, I didn't bought any of those "new" batteries or aftermarket ones. All of them are a low quality piece of garbage so unless your battery is dead, literally, I wouldn't really buy these. This isn't any help from me and I am aware of that. The problem is, you can't really buy any genuine battery from anywhere. LG has a lot of genuine replacement parts and you even can buy from them directly, or from samsung. I tried looking on aliexpress but there are "replacement" batteries that are obviously fake or "original" that have the same serial numbers printed on them.
Official Battery Test!​Because i really couldn't let it be i wen't and bought an official Sony Battery.
Where do you get a Official Battery you ask? There is an Official Sony Homepage that lists Repair Centers. Here in Switzerland Sertronics is the official Repair center. Mailed them with the Part number and Foto of my Battery and got a quick answer.
28.- is an extremely fair price. the 16.- shipping are somewhat annoying.
So i got an Official Battery which Looks WAY better than the other ones.
Looks pretty much the same as my Original one right?
So let's get into Testing...
As Before I've used my Discharging Tool via USB Type-C with 1A draw the 5V dropped to something like 4.85V so 4.85W draw was used. Phone in Flightmode with Screen off to have almost no internal power usage.
Sadly i had issues with some kinda power Saver which killed the USB Power drawing at 10% Battery sometimes....
Run:Time to 10%Wh at 10%Time to 0%Wh at 0%Stock Run 11h 28min7.1Wh--Stock Run 21h 29min-1h37min7.8WhStock Run 31h 29min7.2Wh--New Battery Run 11h 22min (16%)6.6Wh (16%)--New Battery Run 21h 27min-1h 38min7.9WhNew Battery Run 31h 29min-1h 38min7.9Wh
Works pretty much the same. You can see the Voltage Drop at the end is not THAT bad as with the Original Battery. (Yes, both of them we're used until the phone did an Emergency Shutdown due to low battery, shows 0% in the Log)
Because these Results aren't really that good (And Yes, i've plugged the new battery and used my phone for one week to let it acclimate, i also did two Full resets with the new battery, one with newflasher) i've checked the Battery test in the Service Menu.
It truly is no good. I've bought a "Typical 3180mAh" battery that has a minimum of 3060mAh and then it offers 2654. My old battery was showing something around 2700mAh the last time i checked.
So yeah... it is a fully working as intended Battery without any flaws... BUT the capacity is WAY to low.
I will contact the repair center from Sony and ask what the think of this.
Judging by the marked numbers on the replacement Sony battery, it was manufactured between April 4th and 10th 2020 (20W18 - year 2020, week 18). So you received a one year old battery. I also have some experiences with batteries manufactured around that date (20W32). Very poor results: 2200 mAh at first charge, then goes down to a consistent 2000 mAh for all other ones. XZ1 Compact here.
Haldi4803 said:
I will contact the repair center from Sony and ask what the think of this.
Click to expand...
Click to collapse
What did they say? Did they at least accept it back?

Categories

Resources