Related
Hey everyone,
I'm kind of a noob when it comes to all things XDA (but I'm learning.) Anyways, I was wondering what kind of battery life you all get from the different ROMs you've flashed.
So far I've only flashed Nero, Bionix, and Flagship. I had pretty good battery life from Nero, but I was wondering what kind of battery life that you've experienced with other ROMs like Axura and Trigger (because with Bionix and Flagship, my battery life has been fugazi.)
Thanks in advance, y'all.
Sorry if this topic comes up often.
With axura my battery lasts 16 hours with possibly 600+ texts and youtube alot music about 1 hour a few phone calls alot of web.
I only need it to last 12 hours because I charge overnight so I'm good.
I reconditioned too btw
Does reconditioning actually improve battery life or does it simply make the battery indicator more accurate?
It makes it more accurate. Which in terms helps battery because it reads it perfect so ull last longer
Axura is widely considered to have the best battery life. After flashing a new rom you should let your phone charge to 100% and then wipe battery stats in CWM recovery. It can take several days for reading to be taken from the battery so your battery life will usually improve over time.
Hey, I just wanted to thank you all for your input. I decided to go with the latest version of Axura, and so far I've been loving it. I'm not even a day in and I've noticed a difference.
Thanks once again.
+1 On Axura best battery life........
soltheman said:
Hey everyone,
I'm kind of a noob when it comes to all things XDA (but I'm learning.) Anyways, I was wondering what kind of battery life you all get from the different ROMs you've flashed.
So far I've only flashed Nero, Bionix, and Flagship. I had pretty good battery life from Nero, but I was wondering what kind of battery life that you've experienced with other ROMs like Axura and Trigger (because with Bionix and Flagship, my battery life has been fugazi.)
Thanks in advance, y'all.
Sorry if this topic comes up often.
Click to expand...
Click to collapse
first thing to do is
Charge Until 100%
choose rom
Run The Phone All Day, Let It Die
Charge Until 100%
Reboot Into Recovery
Select Reinstall Packages (Do it again if needed)
Select Advanced
Select Wipe Battery Stats
Laazyboy said:
Does reconditioning actually improve battery life or does it simply make the battery indicator more accurate?
Click to expand...
Click to collapse
Neither. "Conditioning" skews the discharge curve from which the battery indicator indexes it percentages. As a result, the battery appears to discharge at slower rate ("better battery life") over the first two-thirds or so of the discharge cycle and then craters like a lead balloon at the end of the discharge cycle. (You really need to have a battery indicator that shows discharge in 1% increments, such as "blue segmented battery mod" to see this.)
To understand this requires a light understanding of the so-called "battery stat tables." There is an entry in the battery stat tables for each percentage of remaining battery charge, in increments of 1%. So, the table contains entries 100%, 99%,... down to 1%. Associated with each percent of remaining charge entry in the table is a battery terminal voltage and a timestamp. Unfortunately, the smart phone cannot measure actual remaining battery charge. All the system knows is a series of battery terminal voltage measurement taken at even periodic intervals. The algorithm builds the battery stat table to relate each measured voltage to a corresponding “percentage of remaining charge” entry in the table. In normal operation, the system accumulates these measurements over several charge/discharge cycles and analyzes the rates of changes of voltages to refine the discharge curve. After several charge/discharge cycles the percentages, which are displayed on the screen as a battery indicator, become more refined and accurate.
At some point someone apparently thought that it would be a good idea to attempt to manipulate the process of building the battery stat tables. This resulted in the so-called "conditioning procedure." The conditioning procedure consists of fully charging the battery, then deleting the battery stats, and then draining the battery quickly and completely using heavy loads, perhaps in 1 to 2 hours.
What this accomplishes is that the battery stat mechanism builds a new, steep discharge curve based upon the rapid discharge operation. This crude, initial discharge curve has "learned" that the battery should discharge quickly, because it did so during its "training” discharge. More specifically, each "percentage discharge" entry for the first 1/2 to 2/3 of the discharge curve (corresponding to the first 50-75 table entries) will be associated with an abnormally lower voltage (due to the faster rate of decrease in voltage during the "training" discharge cycle) than would be the case if the table had been built normally, over time.
Now, let us think about what happens during the subsequent discharge cycle. We charge the battery to full. Now we begin to use the phone normally, discharging the unit over a period of 12-18 hours, for example. Now the phone experiences a slower rate of change of battery voltage over time, because the load is much lower than that of the forced "training" discharge. Now the algorithm measures a voltage and then attempts to map that voltage to a corresponding percentage discharge table entry. The result is that the battery indicator on the phone shows a very low rate of discharge over many hours. This leads people to erroneously conclude that the "battery conditioning" procedure results in improved battery life. However, this is merely an illusion. The battery indicator is, at this point, simply displaying an incorrect number for the remaining battery life. As a consequence, the battery indicator must "catch up with reality" later in the discharge cycle. This is manifested toward the end of the discharge cycle as the battery indicator drops precipitously from perhaps 35% to zero in a very small amount of time. In any case, fortunately, the weirdness done by "battery conditioning" goes away within a few days as the battery stat algorithm tunes the discharge curve each discharge cycle to bring it ever further in line with the actual average usage of the phone owner. It is a myth that the battery stats become inaccurate over time. To the contrary, the algorithm continuously tunes the tables based upon usage patterns so that the battery indicator becomes more and more accurate.
I do not know where this practice originated, but I do have a cynical hypothesis. The ROM cookers typically mix-and-match code elements from different software releases and otherwise change up the timing, sequencing, etc. of various processes. Doing so may have battery life consequences, because the resulting mish-mash of components may hinder or prevent sleep mode operation, cause processes to run for more time than they should, etc. You can see how "battery conditioning" could mask an acute battery performance problem during the first few hours after a person has flashed a ROM and is watching performance characteristics especially closely. ‘Nuf said on this subject.
Sample battery discharge chart and accompanying notes attached below.
soltheman said:
Hey everyone,
I'm kind of a noob when it comes to all things XDA (but I'm learning.) Anyways, I was wondering what kind of battery life you all get from the different ROMs you've flashed.
So far I've only flashed Nero, Bionix, and Flagship. I had pretty good battery life from Nero, but I was wondering what kind of battery life that you've experienced with other ROMs like Axura and Trigger (because with Bionix and Flagship, my battery life has been fugazi.)
Thanks in advance, y'all.
Sorry if this topic comes up often.
Click to expand...
Click to collapse
Tutorial for tuning system to increase battery life here:
http://forum.xda-developers.com/showthread.php?t=823025&page=4
xriderx66 said:
With axura my battery lasts 16 hours with possibly 600+ texts and youtube alot music about 1 hour a few phone calls alot of web.
I only need it to last 12 hours because I charge overnight so I'm good.
I reconditioned too btw
Click to expand...
Click to collapse
600 texts in 16 hours is nearly 38 texts an hour, 4,200 texts a week, 18,000 texts every month. WTFBBQ?
I've read this thread started by JamesBarnes and it got me thinking. The setup he has done is good, but we actually have all those things in our phones. We've got a multimeter (current widget), we've got a power draining load (the phone itself) and the major drawback in his setup is eliminated. He is actually measuring the capacity of the battery to be compared with other batteries, but our phones protect the batteries by switching off with some charge left in the battery because LiIon batteries should not be drained completely. This means a/ you can't damage your battery by full cycling and b/ the phone does not use all the battery capacity. So HTC says 1230mAh, but what is the actual usable capacity of the battery? The most precise measurement should be with a constant minimal drain, but this will take too much time. The next best thing is the charge cycle. So I drained my battery untill shutdown. Then I powered on (I have fastboot enabled, so the phone turns off at 1% to have some energy left to power the memory while "off"), set the current widged to update at 30 sec, cleared the log and plugged in the charger. Then I turned off the screen and left the phone to fully charge overnight. In the morning I downloaded the log and calculated the energy that was pumped in the battery. The result is 1121 mAh. You can calculate yours too. You just have to sum the results of the charge current and then multiply the result to the time interval measured in hours (for 30 sec interval you should actually divide by 120). There is a small bug with current widget and it doesn't really log every period. Sometimes it's a bit more and sometimes it skips. So I wrote a small matlab program to calculate the exact capacity and if you want, you can send me your log of a full charge, or you can calculate it yourselves - just set a higher interval because this way the error will be smaller.
If anyone has a spare DHD (not likely) can leave the phone at airplane mode with 300 sec log interval and in a few days we'll have an exact value of the battery capacity.
tkolev said:
If anyone has a spare DHD (not likely) can leave the phone at airplane mode with 300 sec log interval and in a few days we'll have an exact value of the battery capacity.
Click to expand...
Click to collapse
No, what you will have is the exact capacity of one particular battery. LI-ion batteries vary in the charge they hold depending on how they have been used and for how long they have been used, so IMHO the above data would not be applicable to the community at large, also don't forget it's the DHD that decides when the battery is fully charged so that would add another uncertainty to the pot.
ghostofcain said:
No, what you will have is the exact capacity of one particular battery. LI-ion batteries vary in the charge they hold depending on how they have been used and for how long they have been used, so IMHO the above data would not be applicable to the community at large, also don't forget it's the DHD that decides when the battery is fully charged so that would add another uncertainty to the pot.
Click to expand...
Click to collapse
The purpose of my post was to explain how can anyone measure their own batteries. I don't care about yours, you don't care about mine - that's for sure. But how can you know when buying a replacement battery that the xxxx mAh written on the back is true (and it usualy isn't)? "Lasting longer" is subjective and my method gives you an objective measurement. My battery is five month's old. 1121mAh is a plausable value proving that the method works. If you don't want to bother to do the math yourself, you can send me the log, so I'll do it for you. If you want to know about the current capacity of your battery - fine. If you don't want to know - it's also fine. Also if we can gather some precise measurements (minimizing the error by using constant drain over a longer period) on the capacity we can eliminate the error introduced by the different units and we'll know what to expect from stock batteries and thus we can compare the non-OEM ones to them.
plus, Li-ions usable capacitys change with the batterys temperature and current. How is knowing that my battery could give me 1100mAh @ 5mA/300K of any value to me if I usually need my phone @200mA/280K? Measuring while charging ain't the best idea either, because heat dissipated by the battery during the process will show up in your reading. (and dissipated heat is not the kind of energy that you'd call 'usable')
Also, I am not really sure, how bumping the interval up, thus generating less discrete measurements, is going to increase accuracy...
llama-power said:
plus, Li-ions usable capacitys change with the batterys temperature and current. How is knowing that my battery could give me 1100mAh @ 5mA/300K of any value to me if I usually need my phone @200mA/280K? Measuring while charging ain't the best idea either, because heat dissipated by the battery during the process will show up in your reading. (and dissipated heat is not the kind of energy that you'd call 'usable')
Also, I am not really sure, how bumping the interval up, thus generating less discrete measurements, is going to increase accuracy...
Click to expand...
Click to collapse
As I have said in the first post, it's best to measure the drain, not the charge, but unfortunately I can't spare the time needed without using my phone to take that measurement. The fact is that I don't know how current widget logs the current. Is it measured at the beggining of the interval, the end, is it a mean value over the whole interval, the max, the min? So we should have as constant drain as possible. That way we will eliminate the effect of different measuring methods.
The longer period is just for ease of use. Have you seen a current widget log with interval of 30 seconds? There are many missing intervals, others are 40 sec, 50 sec and the simpler method (summing up the values and multiplying by the time) doesn't work, so it won't be suitable for everyone to calculate the capacity by their own. And with a constant drain the longer period won't introduce that much of an error in the calculation.
You can't have a precise measurement for all the situations you might think of. Some days I talk over the phone for 30 minutes, some days I talk for over an hour. Some days I read e-books, other days I watch videos. The different drain causes different usable capacity as you know. The only thing that's common with the phone day-to-day usage is the stand-by periods. This might have a negative impact on the accuracy because with digital reading you have quantization which introduces bigger error on small values, but this remains to be seen. If you can have constant drain at say... 50 mAh (roughly 1:2 usage pattern), it will introduce max 2% error (depending on the value reading method by the phone). And I don't know about you, but I think 2% is nothing when dealing with something so variable like the battery capacity.
hi there!i am new to XDA. can anyone of you guys help me out with my battery problems.
I have a asus P320 windows phone . it shuts down itself when the power is still 70% . is there anyway to change the registry settings to prevent the auto shutdown due to low battery. i would'nt have bothered with this shutdown if the battery was old but i bought a brand new battery , and no matter what the ROM is it still switches off . I would really appreciate if someone could help me on this.
is there any way to change any of the registry values to disable the lowbattery warning and the autoshutdown.
The battery is not truly measured by "capacity". The capacity is derived from measurable data, mainly the voltage. The voltage for new batteries is very little depending on the load which is applied to battery. Over time (and charge cycles) however the chemistry in the battery is aging so that the load on the battery lets the voltage drop when load is applied. Load is anything like the CPU demand, lights on and so on.
So for your case it is highly probable that idle the battery shows 70% but when load is applied, the voltage drops below the shut off point and the device is off. There is no option to adjust this - it is hard-coded in the battery driver.
Have a look at my battery measurement thread linked from my signature to get some background and find a method to track this.
To give you a rough hint: fully charged, the device should be able to stay on with LCD light (fully lit) on for several hours. With what you report it should go off within less than 2 hours from my estimate.
tobbbie said:
The battery is not truly measured by "capacity". The capacity is derived from measurable data, mainly the voltage. The voltage for new batteries is very little depending on the load which is applied to battery. Over time (and charge cycles) however the chemistry in the battery is aging so that the load on the battery lets the voltage drop when load is applied. Load is anything like the CPU demand, lights on and so on.
So for your case it is highly probable that idle the battery shows 70% but when load is applied, the voltage drops below the shut off point and the device is off. There is no option to adjust this - it is hard-coded in the battery driver.
Have a look at my battery measurement thread linked from my signature to get some background and find a method to track this.
To give you a rough hint: fully charged, the device should be able to stay on with LCD light (fully lit) on for several hours. With what you report it should go off within less than 2 hours from my estimate.
Click to expand...
Click to collapse
Thank you for the quick reply. well, the battery does'nt last much time though . i tried to discharge the old battery (which i still have) to 0% and when i charge it for some time and switchoff the charger it shows some % of batter left and after sometime it shutsdown showing lowbattery warning.
I can understand this happening @ 5% or even 15%but @ 60%- 70% on a brand new battery is a bit much.
if only i could just prevent the autoshutdown, in the mean time i have to check on your battery measurement thread/
From my battery thread I have linked some info on battery chemistry. Bottom line is that LiIon batteries are aging from the day they are produced and the dependency on charge cycles or discharge depth is minimal (different to older type NiMH batteries). So even if you buy a "new" battery in the shop it may be 5 years old from its production date already.
My experience with after-market batteries (so non-original) is very bad. You almost never get good quality and usually old original batteries perform better. I have lots of batteries checked on the Typhoon/Hurricane/Tornado and several on Vox/Excalibur. Especially the true original branded like Sanyo, Celxpert or Samsung have sometimes exceptional performance. I have some of these that already have 5 years (of little to modest use) and still have their nominal capacity. Recently I bought an original packed battery for the Qtek 8310 (Celxpert) which should be 5 years old - and this one has its original capacity! On the other hand I have also bought cheap Chinese that have only 30% of the labeled capacity.
I am new to this forum
Just wanna ask if i switch on my nexus7 wifi 24*7 then will it affect its wifi??
Just curious to know becoz i rarely switch off my wifi and i am scared will itt damage it after sometime??
Heat accelerates almost all aging & failure mechanisms.
Temperature cycling accelerates some types of failure mechanisms (fracture/rupture type failures)
So leave it on or turn it off every night, which is worse?
So long as you aren't streaming data at full bore 24x7 you will probably be fine leaving it on.
Note I said *probably*. That's because I certainly do not have accelerated life-test data for the N7 sitting in front of me; but even if I did, those statistics would only predict what fraction of units would fail over yeah-many hours/years of service... not which individual units will fail.
So unless someone from Asus comes in here and divulges what their MTBF design goal for the N7 was, or what the first 18 months of the repair stream has indicated about their reliability models, you're not going to get much of an answer to your inquiry.
FWIW, I leave mine on the charger & with the WiFi on when I am not using it, and I have the expectation of using it for a couple more years to come.
bftb0 said:
Heat accelerates almost all aging & failure mechanisms.
Temperature cycling accelerates some types of failure mechanisms (fracture/rupture type failures)
So leave it on or turn it off every night, which is worse?
So long as you aren't streaming data at full bore 24x7 you will probably be fine leaving it on.
Note I said *probably*. That's because I certainly do not have accelerated life-test data for the N7 sitting in front of me; but even if I did, those statistics would only predict what fraction of units would fail over yeah-many hours/years of service... not which individual units will fail.
So unless someone from Asus comes in here and divulges what their MTBF design goal for the N7 was, or what the first 18 months of the repair stream has indicated about their reliability models, you're not going to get much of an answer to your inquiry.
FWIW, I leave mine on the charger & with the WiFi on when I am not using it, and I have the expectation of using it for a couple more years to come.
Click to expand...
Click to collapse
recently i played hd movie on my nexus 7
(Movie-300 blue ray version
Frame width-1280
Frame height- 544
frame rate - 23 frames per sec )
and found playback time of 5hrs only
I didn't played entire movie jst calculated in the form that my battery level reduced from 93 to 92 in exact 3 min
Like this i calculate entire playback time ,....
But on internet it says nexus 7 support 9 hrs of hd playback
Plz tell 5 hrs playback is fine for bluray version or I'm having some sought of a battery issue
And if it's a battery issue then what shall i do for its replacement because its been only 1 months
Plz do reply asap.
Regards.
nitu12345 said:
recently i played hd movie on my nexus 7
(Movie-300 blue ray version
Frame width-1280
Frame height- 544
frame rate - 23 frames per sec )
and found playback time of 5hrs only
I didn't played entire movie jst calculated in the form that my battery level reduced from 93 to 92 in exact 3 min
Like this i calculate entire playback time ,....
But on internet it says nexus 7 support 9 hrs of hd playback
Plz tell 5 hrs playback is fine for bluray version or I'm having some sought of a battery issue
And if it's a battery issue then what shall i do for its replacement because its been only 1 months
Plz do reply asap.
Regards.
Click to expand...
Click to collapse
Three minutes (or a 1% change) in battery "percent charge state" is way way too small of an interval to extrapolate from - the sampled data is just way too noisy to be meaningful. A 10% change would be a better measurement. And, those types of measurements should be made in the "middle" of the battery charge state (in the 30% - 70% range, not near the ends).
But - to answer your question - quite a long time ago, @bcvictory ran many battery drain tests - using a video loop test - with a bunch of different kernels, and most of the results tended to be between 5 and 7 hours or so.
I made some very detailed battery drain measurements playing a video loop about 4 weeks ago on my N7 (MX Player), and without tweaking anything (stock kernel, KitKat 4.4.2) I got about 6.25 hrs for a full discharge (100% - 4%).
So, I guess that means that if you saw an Asus/Google claim of 9 hours, that would probably be a significant exaggeration.
(BTW, keep in mind that for *movies* the GPU isn't doing all that much work, as the scenes are not being rendered from a model - they are just being decompressed from a file (or byte stream). So... that means that you should probably expect even worse battery drain times for playing video games continuously).
.
nexus 7 overcharging
bftb0 said:
Three minutes (or a 1% change) in battery "percent charge state" is way way too small of an interval to extrapolate from - the sampled data is just way too noisy to be meaningful. A 10% change would be a better measurement. And, those types of measurements should be made in the "middle" of the battery charge state (in the 30% - 70% range, not near the ends).
But - to answer your question - quite a long time ago, @bcvictory ran many battery drain tests - using a video loop test - with a bunch of different kernels, and most of the results tended to be between 5 and 7 hours or so.
I made some very detailed battery drain measurements playing a video loop about 4 weeks ago on my N7 (MX Player), and without tweaking anything (stock kernel, KitKat 4.4.2) I got about 6.25 hrs for a full discharge (100% - 4%).
So, I guess that means that if you saw an Asus/Google claim of 9 hours, that would probably be a significant exaggeration.
(BTW, keep in mind that for *movies* the GPU isn't doing all that much work, as the scenes are not being rendered from a model - they are just being decompressed from a file (or byte stream). So... that means that you should probably expect even worse battery drain times for playing video games continuously).
.
Click to expand...
Click to collapse
Sir by mistake i overcharged nexus7 tablet for 1 hour and found out that
That it didn't get discharged for next 1 hour ( in which i surf web , watch youtube videos,and played temple run )
Don't you think it get overcharged for i hour because last time i removed the charger at exact 100 % and it started draining within that i hour
And plz do tell even if tablet gets overcharged
Is it safe ?
Becoz i usually charge my tablet at night.
nitu12345 said:
Sir by mistake i overcharged nexus7 tablet for 1 hour and found out that
That it didn't get discharged for next 1 hour ( in which i surf web , watch youtube videos,and played temple run )
Don't you think it get overcharged for i hour because last time i removed the charger at exact 100 % and it started draining within that i hour
And plz do tell even if tablet gets overcharged
Is it safe ?
Becoz i usually charge my tablet at night.
Click to expand...
Click to collapse
I wrote a script to "watch" the battery current and voltage in my N7 once per minute (while it was charging from about 4% - 100%) and log the output to a file. (see attached image). So, I think I know exactly why you saw the results you did.
So here is what happens: as the battery voltage rises during charging, the current slowly gets smaller and smaller. Somewhere around 90% the current suddenly starts to slow down much faster in time, and the battery voltage only rises a tiny bit over the 90% - 100% interval.
Here was the surprise though: when the "% charge" got to 100%, the battery continued to charge (slowly) for another 20 minutes. Over that 20 minutes the battery charging current eventually went to zero.
So - it is safe to let your tablet sit on the charger. It is not the charger that determines how much current the battery receives, it is the SMB347 chip in the N7. There is no such thing as "overcharging" so long as the hardware in the tablet is operating correctly. I leave my tablet on the charger all the time when I am not using it, and don't worry about that one bit.
bftb0 said:
I wrote a script to "watch" the battery current and voltage in my N7 once per minute (while it was charging from about 4% - 100%) and log the output to a file. (see attached image). So, I think I know exactly why you saw the results you did.
So here is what happens: as the battery voltage rises during charging, the current slowly gets smaller and smaller. Somewhere around 90% the current suddenly starts to slow down much faster in time, and the battery voltage only rises a tiny bit over the 90% - 100% interval.
Here was the surprise though: when the "% charge" got to 100%, the battery continued to charge (slowly) for another 20 minutes. Over that 20 minutes the battery charging current eventually went to zero.
So - it is safe to let your tablet sit on the charger. It is not the charger that determines how much current the battery receives, it is the SMB347 chip in the N7. There is no such thing as "overcharging" so long as the hardware in the tablet is operating correctly. I leave my tablet on the charger all the time when I am not using it, and don't worry about that one bit.
Click to expand...
Click to collapse
That means my battery's working fine..na??
Can u suggest me a gud free app to scan battery's performance?
Hws BetterBatteryStats_xdaedition_1.15.0.0 ?
And thanks a lot for clearing my doubts
U r bst
What does "Battery Charge %" Mean?
nitu12345 said:
That means my battery's working fine..na??
Can u suggest me a gud free app to scan battery's performance?
Hws BetterBatteryStats_xdaedition_1.15.0.0 ?
And thanks a lot for clearing my doubts
U r bst
Click to expand...
Click to collapse
@nitu12345 - I don't use battery monitoring apps. I'm not really sure what value they have except in deciding whether or not your battery is sort of "normal". Some of them try to "estimate" current rather than actually take measurements from hardware (which depends on the availability of both system hardware and kernel software, so it makes sense why a generic Android battery app might not even look at current measurements even when they are available on a particular handset/tablet) , so: garbage-in = garbage-out. Basically though, I can't make a recommendation as I haven't used them.
TL;DR - see attached plots at end of post.
I want to take this opportunity to show some more data that I measured in the hopes that it can add to folk's understanding. I made a bunch of measurements of my tablet under both discharge and charging conditions, Originally I was going to make a big long post, but it was simply too much effort to do a good job of it with all the data I had. So here is a mini-report about charging. In particular, it asks and answers the question:
"What exactly does charge percentage mean"?
Is it the measurement of Amp-hours pumped into the battery?
Or is it somehow proportional to battery voltage?
Something else?
Before I begin I should point out just a few key observations. The 2012 N7 has a TI (Texas Instruments) chip - the BQ27541 (iirc), that has the sole purpose of observing the battery - the amount of current going into or out of the battery, and the battery voltage. It does NOT CONTROL ANYTHING - it is just an observer. For that reason, TI calls it a "fuel gauge" chip. It is connected to the processor via an I^2C bus, and the N7's kernel reads the "% charge" directly from this chip. There is no system "battery software" or "calibration software" which alters this number in the N7 - it comes directly from that BQ27541 chip. No doubt there is a tiny amount of firmware in that chip, and the datasheet for that chip indicates it can be factory programmed with different battery curves. But for our purposes it is a black box that we can't easily change - the kernel interface on the N7 does none of that "factory programming", it just reads values from the "black box".
From that chip several things can be read - "% charge", "battery current", "voltage", etc.
Attached at the bottom of this post you will find a curious graph. It shows the behavior of five measurements versus time. "Potential", "Charge", "Current", "Energy", and "Percent". The reason that I said "curious" is that all the raw data were re-scaled so that the min-to-max range of each variable are "normalized" to the range 0.0 to 1.0 (except for the "Percent" variable, since charging here started at 6%).
for any given variable this is done by subtracting the minimum value from the dataset, and then dividing by (max - min), as in:
x' = [ x - min(x) ] / [ max(x) - min(x) ]
Why do things this way? Well, for one, so that all the different variables may be plotted on a single graph running from 0.0 to 1.0.
But more importantly, observing the "shape" of each curve in comparison to others gives you very good physical insight into what is happening under the hood.
A little background in physics:
I Current == Charge/second
Q Charge == Integrate[Current(t), dt] (note this is effectively the same thing as "Amp-hours")
P Power == Voltage*Current
E Energy == Integrate[Power(t), dt]
V Potential (= Battery Voltage)
So from measurements of I(t) and V(t) only - current and voltage, we can use numerical integration to figure out approximate values of Q (charge), and E (energy, or "work" that we put into the battery), starting from only the I(t) and V(t) measurements.
So finally - look at the first JPG image carefully. ("nexus7-2012-Normalized_ChargeCurrentVoltageEnergyPct_vs_Time.jpg")
What you will notice is that three variables: Charge (Q), Energy (E), and Percent all rise quite smoothly in a nearly straight line from 6% to 90% charge state, (or from 0 secs to 9000 secs). So this says that - even though the battery voltage is not smoothly increasing, nor is the current into the battery smoothly decreasing - the charging discipline enforced by the other important chip in the N7 (the SMB347 USB Interface Chip) tries to perform a "constant power input" charging scheme.
A quick diversion: why is the shape of the Energy (E) curve almost identical to the Charge (Q) (or Amp-Hours) curve? It is because of the (apparent) "constant power input" scheme the charger uses: as the battery voltage rises, the amount of current used for charging is adjusted downward. Notice in the graph that even though the "Percent" variable is steadily rising in a straight line, neither the current nor voltage are behaving that way - they are almost inverses of each other so that I(t) * V(t) = Constant.
So - the conclusion, specifically for the N7 hardware - is that "battery percentage" is supposed to represent either Amp-hours input to the battery (charge), or Energy dumped into the battery during charging. For this specific device with it's specific hardware, they happen to be equivalent because of the constant power charging scheme.
Note there are a couple of other interesting tidbits in this graph. The charging cycle spends nearly 25% of the total time charging in the final 90-100% charging range. So if you are carefully watching your tablet charge, it will seem to "slow down" dramatically during that last 10% of charging. (I should also point out that my tablet charges quite a bit faster under normal circumstances - about 2.5 hours instead of 3.5 hours; I believe the script I used prevented the tablet from ever entering deep sleep during charging. A N7 tablet that isn't being held awake with wakelocks should charge in a little over 2.5 hours)
You will also notice that the battery is continuing to charge for about 20 minutes after it reached the "100%" charge state. That's because "100%" doesn't really mean that the battery has stopped charging. In this particular observation, the SMB347 chip was still pushing ~400 mA into the battery after the 100% mark had been reached.
Phew. Finally, I have attached another image ("nexus7-2012-BatteryVoltage_vs_ChargePct.jpg") that shows a display of battery voltage versus percentage charge for two charging cycles and one discharge cycle. Note that when the SMB chip needs to force current into the battery to charge it, it must raise the voltage in order to do that. So it is clear that battery voltage alone can not be used as a proxy for "charge percent", nor can you figure out what the charge is by only looking at battery voltage alone. Not only that, but look at the shape of the curve - it is not a straight line. There is very rapid voltage changes going on at the low end of "% charged" range during charging, very little voltage change occurring in the 90-100% range, and during discharge (red curve) there are are at least 3 different ranges where the slope of the battery voltages change relative to the "% charge" data that the TI chip emits. This is why I suspect that battery apps that only observe voltages probably are not capable of accurately predicting anything other than the ageing algorithms of the BQ27541 chip, and are probably absolutely useless for telling you anything from day to day.
OK, a couple more trivia observations:
- That BQ27541 chip is squirrelly (or perhaps it is the kernel interface, dunno.) There were many sampled data points where the "% charge" reading from the chip suddenly dropped from wherever it had been to *ZERO*. I was sampling the value once every 60 seconds for the data displayed here, but I have also sampled the sysfs (kernel interface) for that chip at much higher speeds, and it frequently produces garbage data. Additionally, the same chip would frequently report *zero current* during discharge condtion - an impossibility. On their website, TI says "Not recommended for new designs". (Usually that is weasel-words that mean "we are aware of some buggy behavior that we are not going to tell you about") Note for instance in the second graph that the battery percentage values 26, 47, 58, 69, 79, and 84% never appear in ANY data set. That means that a battery app - or even an OS "low battery emergency shutdown" trap - could exhibit odd, buggy behavior if they do not use defensive techniques that assume that the data they are getting is partly corrupted. (multiple sample averaging and outlier detection).
- I believe the "sudden steps" in current that I observed during charging (prior post) were real - the tablet had it's WiFi shut off, and the tablet was not in use at all. So while it is certainly possible that random app behavior could have caused some fluctuation in current available to the battery, that would have been much more short lived. Is it possible that the SMB347 chip also has some bugs?
OK, here's the graphs folks. Have fun and good luck with your tablet.
bftb0
Recently i reseted my nexus tablet and found that there was no google earth installed so I downloaded an apk file frm external source and installed google earth from it
but now when i try to uninstall it
There no such button as it shows only disable button
But since it wasn't there before how come now its not uninstalling
N r u using magnetic case .? Is it safe for nexus7?
Like i have heard that it messes with magnetic compass
Plz clear my query.
I've been researching about batteries out of interest of replacement, better charging maintaining and longevity. Being unable to find a recently manufactured Z3C battery anywhere, I'm setting up a Galaxy S8+ replacement battery with a removed Z3C battery's printed circuit board solder connected. I can't find a good source on lithium-ion shelf life through Google but it's commonly mentioned to be 2-3 years to being considered depleted. I've got the mod working but haven't finished cleaning it up. The leftover space in the device got me curious on the actual capacity limit. I started calculating the differences and ended up writing it all up for comparison. I can follow up with some photos.
Notes
Measured by eye using a steel ruler and flat tool on an official warranty replacement 16W13 manufacture dated battery. The capacity feels depleted maybe 80% or so, so it's considered depleted. Being depleted the thickness may have swollen up to 10%. See sources below on these points.
Dimensions in centimeters
All numbers rounded to two decimal places
Nom = Nominal Voltage
Sony's original battery has an energy density of 2008 maximum technology according to this graph http://2.bp.blogspot.com/-NkSg5gn6ePM/VVPBtPLreJI/AAAAAAAAAoI/-KeFe45ky14/s1600/Pix.png found on the source list below.
Using a case without the back panel easily affords an extra millimeter.
For an extra 0.9mm in thickness a Z1C 127 x 64.9 x 9.5 case can be used on a Z3C 127.3 x 64.9 x 8.6.
Original Batteries
Sony Z3C = 9 x 5.1 x 0.4 = 18.36ml = Nom 3.8V 2600mAh 141.61mAh/ml 0.54Wh/L = 2008 density
Samsung S8+, 2017 density = 8.3 x 4.55 x 0.5 = 18.88ml = Nom 3.85V 3500mAh 185.38mAh/ml 0.71Wh/L (or estimated Nom 3.8V 3360mAh 177.96mAh/ml 0.68Wh/L)
Hypothetical higher densitys
Sony Z3C, if matched 2014 maximum density = (estimated using 0.66Wh/L = Nom 3.8V 3189mAh 12.12Wh, 173.69mAh/ml)
Sony Z3C, if Samsung S8+ 2017 density = Nom 3.85V 3387mAh 13.04Wh (or estimated Nom 3.8V 3285mAh 12.48Wh)
Sony Z3C, hypothetical 0.1 thicker
9 x 5.1 x 0.5 = 22.95ml
If Original 2008 density = Nom 3.8V 3250mAh 12.35Wh
If 2014 density = (estimated using 0.66Wh/L = Nom 3.8V 3987mAh 15.15Wh, 173.73mAh/ml)
If 2017 density = Nom 3.85V 4231mAh 16.29Wh (or estimated Nom 3.8V 4106mAh 15.6Wh)
Sources
Good basic sources in general is scarce through basic searching on the topic of lithium-ion batteries. I think it's because the industry is highly competitive with low margins leading to secrecy in interest of intellectual property (got the gist of this from a few different Qnovo blog articles). Also it's got heavily ongoing academic focused research and development but would be funded and therefore guarded by the corporations . Funny though that my main sources are from CEO's of battery related companies. I think it's a case there of smaller companies with an interest and belief in sharing knowledge to create public awareness. Thus here we are on XDA with some relevant useful facts.
At 80% retained capacity a battery is considered depleted. Capacity loss is greatly accelerated after 80% as is the risk of safety measure failure
https://qnovo.com/what-happens-after-80-percent/. The industry leader in support and sales by model volume, Apple's warranty policy follows this guideline https://support.apple.com/en-au/ipho.../battery-power.
About battery thickness swelling.
https://qnovo.blogspot.com.au/2015/08/72_14.html
This article https://qnovo.com/moores-law-and-snails-law/ has a graph for Energy Density Wh/L by year which I used for estimating what Sony's battery could have been if maximum density was used at the time.
I used Table 4 from http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries to presume the capacity of 4.35V and 4.4V which I used for estimated results. Based like this:
4.30 110-115%
4.35 115-120%
4.4 120-125%
Really interesting, I was thinking to do something similiar, but with bigger battery and use z3c without glass back with maybe a moded case, photos would be really interesting, probably now gonna buy s8+ battery to tinker with, considering s8+ battery 7mm is shorter would really help in custom wiring to old z3c battery pcb
Photos with short descriptions https://imgur.com/a/8Ceha.
There's a lot of stuff to cover. I'll cover the basics. If anyone wants more information, just ask.
I was planning to remove the S8+ PCB and attempt to solder it myself. After Banggood didn't package the soldering iron order twice, I got fed up waiting and decided to quote a cheap phone technician. Given the fee was AUD $18 I went ahead.
There was some communication issues as the technician didn't speak English, so I had to discuss with the staff. I'd have preferred the S8+ PCB removed and with shorter wires but it has actually has worked out well. Looking at the broken battery I removed the Z3C PCB from, it's difficult removing the PCB from the spot welding while leaving lots of aluminium tab left over. I've read how aluminium is one of the most difficult materials to solder to and having big fresh tabs is easier and safer.
It all fits well and is still removable quick swappable with my other mod. I'll be monitoring its performance. I already use custom charge threshold rates and limits using Tasker rooted for longevity. I already previously monitor battery temperature, usage rates and voltage by overlay so I should be able to notice differences. Plus i've got two working Z3C's to power test :fingers-crossed:
Should probably add that doing any battery modification goes against safety recommendations. You need to know what you're doing for the involved risks. Follow electrostatic discharge safety for installation and use required measures for handling the battery if using it removable.
Hey, I'm interested in this mod. Can't wait to find out your results. I may be able to help you out a bit, I'm a CNC Machinist and I have my own set of calipers if you wanted a more accurate measurement on the z3c battery sizes. I may (read: may) be able to make a back plate that will hold a slightly different battery.
TheHow7zer said:
Hey, I'm interested in this mod. Can't wait to find out your results. I may be able to help you out a bit, I'm a CNC Machinist and I have my own set of calipers if you wanted a more accurate measurement on the z3c battery sizes. I may (read: may) be able to make a back plate that will hold a slightly different battery.
Click to expand...
Click to collapse
You're welcome to get more accurate measurements for correction. It shouldn't be much of a difference but can be useful for interests sake.
That's an interesting offer suggestion. I'm a little curious how much signal loss there is with a metal case. I prefer a TPU for the sides of my case with a small lip to cover the front, also a hard back to adhere 3M VHB for a Garmin interface. So I tracked down a Z1C Ringke fusion to combine all my hardware mods :laugh:
Wow very nice idea and the mod indeed I am sucker for battery life, so I'm very much interested in actual numbers here, you could provide us some screenshots and further feedback on mod performance.
I've got a question though, since the S8+ battery is 0.1mm thicker, would it be possible to put some double sided tape on the frame + B7000 glue in order to lift the original glass back and still keep it on the phone?
Cirra92 said:
Wow very nice idea and the mod indeed I am sucker for battery life, so I'm very much interested in actual numbers here, you could provide us some screenshots and further feedback on mod performance.
I've got a question though, since the S8+ battery is 0.1mm thicker, would it be possible to put some double sided tape on the frame + B7000 glue in order to lift the original glass back and still keep it on the phone?
Click to expand...
Click to collapse
I might try to compare across two devices with the same Nandroid copy and the less old 2016 battery. I'd probably only test up to 80% to maintain cycle life. May be awhile yet though as I broke a motherboard while transporting for an unrelated replacement screen warranty removal.
B7000 hey, you've done some phone repairs already too? It's 0.1cm, 1mm thicker. B7000 applies as liquid so it won't be raised enough when adhering. Using a case isn't a bad compromise as it affords protection, something I've already always used in the past.
Infy_AsiX said:
I might try to compare across two devices with the same Nandroid copy and the less old 2016 battery. I'd probably only test up to 80% to maintain cycle life. May be awhile yet though as I broke a motherboard while transporting for an unrelated replacement screen warranty removal.
B7000 hey, you've done some phone repairs already too? It's 0.1cm, 1mm thicker. B7000 applies as liquid so it won't be raised enough when adhering. Using a case isn't a bad compromise as it affords protection, something I've already always used in the past.
Click to expand...
Click to collapse
I thought some screenshots with the device that has the mod, you don't need to compare with old one Bad luck for the motherboard, had some mishaps too with broken screens while replacing them myself :/
Yeah I took the phone apart 3 times already (though it was to replace the screen only, didn't remove the motherboard) so I'm familiar enough with Z3C disassembly Right, 0.1cm, I meant that but made a stupid mistake, sorry. I've mentioned B7000 since I used that to avoid notorious issues of screen and back glass separating from frame, but didn't use the double sided tape as I don't know how good is it gonna stick, so thought in this case of using maybe a double layer of the tape and glue on top of it. I have a silicone case on it, but would like to keep the original look
Anyway I hope to see what benefit this gives you, as my battery is 2y old now (still going strong though), so it will likely start to give up on me, and I'm interested in this mod
Thanks, and good job once again :victory:
Cirra92 said:
I thought some screenshots with the device that has the mod, you don't need to compare with old one Bad luck for the motherboard, had some mishaps too with broken screens while replacing them myself :/
Yeah I took the phone apart 3 times already (though it was to replace the screen only, didn't remove the motherboard) so I'm familiar enough with Z3C disassembly Right, 0.1cm, I meant that but made a stupid mistake, sorry. I've mentioned B7000 since I used that to avoid notorious issues of screen and back glass separating from frame, but didn't use the double sided tape as I don't know how good is it gonna stick, so thought in this case of using maybe a double layer of the tape and glue on top of it. I have a silicone case on it, but would like to keep the original look
Anyway I hope to see what benefit this gives you, as my battery is 2y old now (still going strong though), so it will likely start to give up on me, and I'm interested in this mod
Thanks, and good job once again :victory:
Click to expand...
Click to collapse
I think it's hard to demonstrate battery performance based on how different smartphone power usage can be. On a fresh ROM even an old battery lasts a long time. I'd estimate my basic usage averages around 650mA/h based on the system current draw when the screen is on and being used generally. That's with debloated stock and various power saving mods like kernel tweaks, low brightness and Greenify. Though on the other hand I do have a lot of mods and Xposed going on. I prefer to leave mobile data, wifi and sync always on so that's no help either. Though also my old stock rom does seem faulty, running out of ZRAM even with it greatly increased.
Anyway at ~650mA/h that's still only 5 hours SOT with 3325mAh. 4 hours SOT using a max limit of 80%, around the same as a new stock 2600mAh battery. 3 hours SOT for a degraded battery with 80% capacity left or a new stock set to 80% max limit. 2.5 hours SOT for a degraded 80% remaining with a set 80% max limit. If feels like those last scenarios describe my old batteries. With a theoretical 4000mAh an extra hour again would certainly be welcome. Technically you can get close to that with a S8 Active battery that's 4000mAh 4.4V, judging by phone dimensions between the S8, S8 Active, S8+ it will be smaller and thicker again.
It kind of shows why I don't like comparing battery performance with between user setups. There's too many variables to power consumption on a smartphone. I don't know how people get 8 hours screen time in screenshots but physics dictates the limit. To get 8 hours SOT with 3325mAh, current draw would have to average 415mA, something I can't reach on my setup. Not to mention performing a full deep discharge cycle harming longevity. However it's definitely possible on a fresh ROM with only a few apps, noting that's how reviewer benchmarks operate (untrue to real usage). It kind of brings back the fact that a removable battery is still the only solution to extending run time beyond an insufficient limited capacity without complicating charging and requiring tethering.
I'll try to get a screenshot that indicates what I've mentioned here as confirmation. You could try watching your system current draw using an app too, I see Ampere and AccuBattery often mentioned, I prefer DevCheck or Cool Tool. Then estimate your own capacity health, potential run times and screenshot for interest and knowledge sharing's sake .
Infy_AsiX said:
I think it's hard to demonstrate battery performance based on how different smartphone power usage can be. On a fresh ROM even an old battery lasts a long time. I'd estimate my basic usage averages around 650mA/h based on the system current draw when the screen is on and being used generally. That's with debloated stock and various power saving mods like kernel tweaks, low brightness and Greenify. Though on the other hand I do have a lot of mods and Xposed going on. I prefer to leave mobile data, wifi and sync always on so that's no help either. Though also my old stock rom does seem faulty, running out of ZRAM even with it greatly increased.
Anyway at ~650mA/h that's still only 5 hours SOT with 3325mAh. 4 hours SOT using a max limit of 80%, around the same as a new stock 2600mAh battery. 3 hours SOT for a degraded battery with 80% capacity left or a new stock set to 80% max limit. 2.5 hours SOT for a degraded 80% remaining with a set 80% max limit. If feels like those last scenarios describe my old batteries. With a theoretical 4000mAh an extra hour again would certainly be welcome. Technically you can get close to that with a S8 Active battery that's 4000mAh 4.4V, judging by phone dimensions between the S8, S8 Active, S8+ it will be smaller and thicker again.
It kind of shows why I don't like comparing battery performance with between user setups. There's too many variables to power consumption on a smartphone. I don't know how people get 8 hours screen time in screenshots but physics dictates the limit. To get 8 hours SOT with 3325mAh, current draw would have to average 415mA, something I can't reach on my setup. Not to mention performing a full deep discharge cycle harming longevity. However it's definitely possible on a fresh ROM with only a few apps, noting that's how reviewer benchmarks operate (untrue to real usage). It kind of brings back the fact that a removable battery is still the only solution to extending run time beyond an insufficient limited capacity without complicating charging and requiring tethering.
I'll try to get a screenshot that indicates what I've mentioned here as confirmation. You could try watching your system current draw using an app too, I see Ampere and AccuBattery often mentioned, I prefer DevCheck or Cool Tool. Then estimate your own capacity health, potential run times and screenshot for interest and knowledge sharing's sake .
Click to expand...
Click to collapse
Well yeah I agree on that, it's hard to do it precisely, however I asked because you know your typical usage and maybe could make a rough conclusion on the benefit that this mod gives you, if your current usage does not differ much from the one with original battery. I do not rely much on those app calculations no matter how precise the might be, as I don't rely on reviewer's tests as well, because my usage is specific. I can tell I'm one of those who was reaching 8h of SOT, even 9h on 5.1.1 with specific settings (microG instead of Gapps, global UV, interactive governor tweaks, intelliplug, different LMK values and Amplify, though the last one didn't make much difference) and that battery life was pretty consistent until MM came on board. Now I'm on Carbon 7.1.1 (with same settings) and can average 7h of SOT and always 24-36h of total usage with 2y old battery, which is damn good if you consider that and the fact that I had a lot of full discharge cycles, 100% -> 1%.
Based on your calculations even with your current draw you can get extra 1h of SOT, if I understood right what you wrote, not that SOT is sole indicator of how your battery performs, but it does show a lot in same usage scenario
I have AccuBattery installed from last night, will monitor in upcoming days and share here, just for general info as you said, and to see how much is the % of degradation
Cirra92 said:
I can tell I'm one of those who was reaching 8h of SOT, even 9h on 5.1.1 with specific settings (microG instead of Gapps, global UV, interactive governor tweaks, intelliplug, different LMK values and Amplify, though the last one didn't make much difference) and that battery life was pretty consistent until MM came on board. Now I'm on Carbon 7.1.1 (with same settings) and can average 7h of SOT and always 24-36h of total usage with 2y old battery, which is damn good if you consider that and the fact that I had a lot of full discharge cycles, 100% -> 1%.
Based on your calculations even with your current draw you can get extra 1h of SOT, if I understood right what you wrote, not that SOT is sole indicator of how your battery performs, but it does show a lot in same usage scenario
I have AccuBattery installed from last night, will monitor in upcoming days and share here, just for general info as you said, and to see how much is the % of degradation
Click to expand...
Click to collapse
That's certainly some impressive power consumption. Was that on stock before N? I've always been stock ROM until now that I'm migrating transitioning to LOS N across two Z3Cs.
I also started trying AccuBattery a few days ago and found it quite useful in a few ways. How it records charging/discharging sessions with mA and mAh data, provides a way to track energy consumption. It's Process CPU usage overlay helped me realise the live wallpaper I had was using 50% of my CPU generally and that DevCheck's overlay is resource intensive. Though AccuB's CPU usage overlay doesn't work on N properly anymore due to SELinux. I found however capacity health estimates are incorrect on my stock ROM, doing some digging and have come up with a basic understanding.
It gets a little complicated so it's confusing and some more testing or other's checking is needed to confirm some specific things. I only had one phone this week so I tested it on my stock ROM with the S8+ battery. The screenshots confirm AccuB recorded close to the expected capacity of the S8+. Note the device was not used in a way to represent a constant drain, the timing is just to demonstrate separation. The screenshots are scattered in content as I was just grabbing the stats not expecting the below 1% occurrence. To understand just look for what's described above each for explanation.
Showing percentage output "50%" at ~3.8V when it should be 70%, 3:35 (pm ).
https://i.imgur.com/qZwnCDy
At ~3.65V it hit "1%" 4:48pm.
https://i.imgur.com/JQrqwAG
~3.6V below "1%" 6:26pm. Around this voltage holds the most energy, why 0.05V lasted so long from the last screenshot.
https://i.imgur.com/ZQTZU29
~3.45V below "1%" 6:59pm
https://i.imgur.com/8kZaWSm
Last screenshot ~3.25V before cutoff at 3.2V 7:07pm.
https://i.imgur.com/16PysRL
Post session stats screenshots. Note the session started at 99% because I forgot to restore AccuBattery's Titanium data until after booting, meaning some mAh is missing from 100% but as seen AccuB tracked close to the expected capacity of the S8+. In regards to SOT in my last post, there's confirmation my old stock ROM averages 600mA with screen on. Note the screen off mA is high because of playing Google Music on phone speakers the entire cycle. Obviously the %/h is false here due to the missing ~1100mAh below 0%.
{
"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"
}
AccuB's charging health estimates are constantly incorrect at ~2000mAh. I think this is caused by system battery aging calibration that is set on my old stock ROM. Doesn't matter which whether stock 2014, stock '15 or S8+ '17 battery is used. Dividing a discharge session mAh by percent used gives the same approximate low mAh per percentage. This is why the S8+ battery keeps running at 1% remaining for over another 1000mAh. Doing some searching of the symptom takes me back to the days where third party extended batteries were used, meeting the issue. The main issue is the kernel controls the calibrating capacity percentage fuel gauge chip. For example the Note 4 has a kernel mod fuel gauge chip fix for extended batteries. Another example is the Galaxy S2 could reset it's fuel gauge using root. Here's some old Xperia Arc/Pro fuel chip kernel insight.
I've tried deleting /data/system/batterystats-checkin.bin, batterystats-daily.xml, and batterystats.bin. Removing the battery resets the percentage accordingly but charging and discharging is still incorrect.
Looking at /sys/class/power_supply/bms/batt_aging is "1". With /sys/class/power_supply/bms/device/fcc_new_mah "2313". Or fcc_samples "2380/2156/2268/2268/2366". FCC meaning full charge capacity. This could well be evidence.
I just received a replacement Z3C yesterday to load up LOS N again. I haven't opened it up yet, it's device manufacture tag is 15W04. My nandroid restore has batt_aging "0", fcc_new_mah "0", fcc_samples "0/0/0/0/0/". AccuBattery estimates health near 2600 and dividing mAh by percent usage is approximate. I guess a full cycle is in order to confirm some things. If on AOSP, drivers aren't configured to lower the capacity range, that's less the issue of variability. However the range seems to be hard set to 2600, so the S8+ battery will be running for an extra ~700mAh after 0%.
I found the app CaliBattery is a useful basic way to estimate percentage by voltage. This helps with overcoming stock's aging estimator, though it's notification doesn't update for me on LOS14.1. For example if you received a new official replacement battery but restored a Nandroid backup, you'd have the same battery issues mentioned until enough full cycles are run, recorded and used by the system. On the counter side an old battery on AOSP if it's hard set to 2600 (need test confirmation of this) will turn off before 1%.
One possible workaround is to take voltage readings and calculate percentage using Tasker and write that to system percentage with root. The problem there is efficiency and not updating while screen's off in interest of power. A proper fix requires modifying the relevant fuel gauge configuration in the kernel. I'm not a developer nor have any kernel building experience to do that.
Edit: I stumbled across /sys/module/qpnp_bms/parameters/bms_reset which seems to be a generic kernel setting allowing to reset the percentage. This with Tasker helps with getting the level correct before and after charging. If something like CaliBattery can show approximate level when draining, things seem ok as a workaround. Still needs further testing, and to try on AOSP (the file does exist at least). To be continued...
Infy_AsiX said:
That's certainly some impressive power consumption. Was that on stock before N? I've always been stock ROM until now that I'm migrating transitioning to LOS N across two Z3Cs.
I also started trying AccuBattery a few days ago and found it quite useful in a few ways. How it records charging/discharging sessions with mA and mAh data, provides a way to track energy consumption. It's Process CPU usage overlay helped me realise the live wallpaper I had was using 50% of my CPU generally and that DevCheck's overlay is resource intensive. Though AccuB's CPU usage overlay doesn't work on N properly anymore due to SELinux. I found however capacity health estimates are incorrect on my stock ROM, doing some digging and have come up with a basic understanding.
It gets a little complicated so it's confusing and some more testing or other's checking is needed to confirm some specific things. I only had one phone this week so I tested it on my stock ROM with the S8+ battery. The screenshots confirm AccuB recorded close to the expected capacity of the S8+. Note the device was not used in a way to represent a constant drain, the timing is just to demonstrate separation. The screenshots are scattered in content as I was just grabbing the stats not expecting the below 1% occurrence. To understand just look for what's described above each for explanation.
Showing percentage output "50%" at ~3.8V when it should be 70%, 3:35 (pm ).
https://i.imgur.com/qZwnCDy
At ~3.65V it hit "1%" 4:48pm.
https://i.imgur.com/JQrqwAG
~3.6V below "1%" 6:26pm. Around this voltage holds the most energy, why 0.05V lasted so long from the last screenshot.
https://i.imgur.com/ZQTZU29
~3.45V below "1%" 6:59pm
https://i.imgur.com/8kZaWSm
Last screenshot ~3.25V before cutoff at 3.2V 7:07pm.
https://i.imgur.com/16PysRL
Post session stats screenshots. Note the session started at 99% because I forgot to restore AccuBattery's Titanium data until after booting, meaning some mAh is missing from 100% but as seen AccuB tracked close to the expected capacity of the S8+. In regards to SOT in my last post, there's confirmation my old stock ROM averages 600mA with screen on. Note the screen off mA is high because of playing Google Music on phone speakers the entire cycle. Obviously the %/h is false here due to the missing ~1100mAh below 0%.
AccuB's charging health estimates are constantly incorrect at ~2000mAh. I think this is caused by system battery aging calibration that is set on my old stock ROM. Doesn't matter which whether stock 2014, stock '15 or S8+ '17 battery is used. Dividing a discharge session mAh by percent used gives the same approximate low mAh per percentage. This is why the S8+ battery keeps running at 1% remaining for over another 1000mAh. Doing some searching of the symptom takes me back to the days where third party extended batteries were used, meeting the issue. The main issue is the kernel controls the calibrating capacity percentage fuel gauge chip. For example the Note 4 has a kernel mod fuel gauge chip fix for extended batteries. Another example is the Galaxy S2 could reset it's fuel gauge using root. Here's some old Xperia Arc/Pro fuel chip kernel insight.
I've tried deleting /data/system/batterystats-checkin.bin, batterystats-daily.xml, and batterystats.bin. Removing the battery resets the percentage accordingly but charging and discharging is still incorrect.
Looking at /sys/class/power_supply/bms/batt_aging is "1". With /sys/class/power_supply/bms/device/fcc_new_mah "2313". Or fcc_samples "2380/2156/2268/2268/2366". FCC meaning full charge capacity. This could well be evidence.
I just received a replacement Z3C yesterday to load up LOS N again. I haven't opened it up yet, it's device manufacture tag is 15W04. My nandroid restore has batt_aging "0", fcc_new_mah "0", fcc_samples "0/0/0/0/0/". AccuBattery estimates health near 2600 and dividing mAh by percent usage is approximate. I guess a full cycle is in order to confirm some things. If on AOSP, drivers aren't configured to lower the capacity range, that's less the issue of variability. However the range seems to be hard set to 2600, so the S8+ battery will be running for an extra ~700mAh after 0%.
I found the app CaliBattery is a useful basic way to estimate percentage by voltage. This helps with overcoming stock's aging estimator, though it's notification doesn't update for me on LOS14.1. For example if you received a new official replacement battery but restored a Nandroid backup, you'd have the same battery issues mentioned until enough full cycles are run, recorded and used by the system. On the counter side an old battery on AOSP if it's hard set to 2600 (need test confirmation of this) will turn off before 1%.
One possible workaround is to take voltage readings and calculate percentage using Tasker and write that to system percentage with root. The problem there is efficiency and not updating while screen's off in interest of power. A proper fix requires modifying the relevant fuel gauge configuration in the kernel. I'm not a developer nor have any kernel building experience to do that.
Edit: I stumbled across /sys/module/qpnp_bms/parameters/bms_reset which seems to be a Sony kernel setting allowing to reset the percentage. This with Tasker helps with getting the level correct before and after charging. If something like CaliBattery can show approximate level when draining, things seem ok as a workaround. Still needs further testing, and to try on AOSP (the file does exist at least). To be continued...
Click to expand...
Click to collapse
That was on stock, the most efficient one was LP, the last 5.1.1, I got constantly 8+ hours of SOT, and even 9+ in half of those charges probably, but as soon as I flashed the first stable official MM build and then went back to LP (in the same month even) the battery life dropped significantly, and the only thing I remember that could have changed was the bootloader, literally nothing else, but I doubt it has anything to do with battery life.
You can see the screenshots here just after flashing the 5.1.1 back then. -> https://forum.xda-developers.com/showpost.php?p=68155846&postcount=16
And also I have observed the battery stats through AccuB, you can check some on attachment shots, and if measurements are valid my screen power draw is 350-400 mA and the battery health is reported to be at ~2400ma or ~92% which is actually more than I expected And as you can see, the standby drain is unusually high, been that way since I flashed the rom, and I'm sure it has to be lower, but will tackle that when O gets more bugs fixed. All of this is on Carbon N rom by Myself5.
I can see that you've done your homework extensively, which is impressive Now, for the battery capacity coding part, I'm not sure if its hard coded as I've used my phone just a month ago until 1% and it didn't die where it should because the battery capacity is lower. Don't know about the way to reset the battery chip (or gauge) since it has been said that its self regulated, unlike the Galaxy S2 as you've mentioned and I owned it as well and done that. It might level out through a number of successive charging cycles, try to load it with clean rom and give it a go, why would they hard code the capacity, that's weird, but that's beyond my knowledge anyway.
Cirra92 said:
And also I have observed the battery stats through AccuB, you can check some on attachment shots, and if measurements are valid my screen power draw is 350-400 mA and the battery health is reported to be at ~2400ma or ~92% which is actually more than I expected And as you can see, the standby drain is unusually high, been that way since I flashed the rom, and I'm sure it has to be lower, but will tackle that when O gets more bugs fixed. All of this is on Carbon N rom by Myself5.
I can see that you've done your homework extensively, which is impressive Now, for the battery capacity coding part, I'm not sure if its hard coded as I've used my phone just a month ago until 1% and it didn't die where it should because the battery capacity is lower. Don't know about the way to reset the battery chip (or gauge) since it has been said that its self regulated, unlike the Galaxy S2 as you've mentioned and I owned it as well and done that. It might level out through a number of successive charging cycles, try to load it with clean rom and give it a go, why would they hard code the capacity, that's weird, but that's beyond my knowledge anyway.
Click to expand...
Click to collapse
I think AccuBattery's health estimate is unreliable after noticing how it seems to report by the ROM's provided mAh/% rather than usage. It's discharging mA rate and history total discharge however are useful as they seem to track mAh usage current. So I think doing a full cycle noting the history's total mAh thus avoiding any kernel/ROM BMS configuration interference may be the only way to check.
I'll get around to testing the S8+ battery on AOSP soon. I ran this replacement Z3C on LOS almost flat but aging stats in /battery haven't changed. I guess the BMS aging stats are hidden by not linking to output like Sony's stock. I made up my own CaliBattery style notification through Tasker and have BMS reset on every % change when charging. So far it looks to be a workable workaround.
If some close to three year old batteries do still have 90% health, the batteries are actually good after all. My first two Z3C batteries were swollen under a year, but I lacked knowledge on maintaining them back then. Well that and the design problem of overheating during gaming and charging at 100% to keep topped up due to too slow charging without a swappable battery. The reasons why I've ended up learning all this, modding a removable feature with a custom charging profile on Tasker.
@Infy_AsiX Hey man how is your battery mod doing? Is it still in life?
Did you manage to track where is that battery capacity coded, if it is anyway?
Cirra92 said:
@Infy_AsiX Hey man how is your battery mod doing? Is it still in life?
Did you manage to track where is that battery capacity coded, if it is anyway?
Click to expand...
Click to collapse
Hehe are you checking if I experienced a lithium-ion battery fire?
I didn't delve further than previously discussed as by workaround the charging and estimation is functioning well enough. To change the charger and battery functions is kernel code and would require some understanding to work.
The Z1C Ringke Rearth Fusion case fits like a glove with the extra mm for the plastic spacers I install too. Looks nice and cool while working well. The Z3C is still my preferred phone size form factor and I need it as a bike computer with smartphone extras. For multimedia and gaming consumption I picked up a ZTE Axon 7 to complement.
Sent from my ZTE Axon 7 using XDA Labs
Infy_AsiX said:
Hehe are you checking if I experienced a lithium-ion battery fire?
I didn't delve further than previously discussed as by workaround the charging and estimation is functioning well enough. To change the charger and battery functions is kernel code and would require some understanding to work.
The Z1C Ringke Rearth Fusion case fits like a glove with the extra mm for the plastic spacers I install too. Looks nice and cool while working well. The Z3C is still my preferred phone size form factor and I need it as a bike computer with smartphone extras. For multimedia and gaming consumption I picked up a ZTE Axon 7 to complement.
Sent from my ZTE Axon 7 using XDA Labs
Click to expand...
Click to collapse
Haha no, I thought maybe you had any kind of issue with it and just gave it a good swing through the window
So the battery level reading did not level out with certain number of cycles, at least to a certain amount? I thought maybe that it would get recorded by system and the kernel would adapt that accordingly, since my best guess is that it's a dynamic reading, rather than pre-set capacity, as you've mentioned yourself.
Anyway, if I go that road, and I'm considering that seriously as of late, I would like to explore the ways to attach the back panel and keeping a stock look. Where did you put those plastic spacers?
Good choice on that Axon 7
Cirra92 said:
Haha no, I thought maybe you had any kind of issue with it and just gave it a good swing through the window
So the battery level reading did not level out with certain number of cycles, at least to a certain amount? I thought maybe that it would get recorded by system and the kernel would adapt that accordingly, since my best guess is that it's a dynamic reading, rather than pre-set capacity, as you've mentioned yourself.
Anyway, if I go that road, and I'm considering that seriously as of late, I would like to explore the ways to attach the back panel and keeping a stock look. Where did you put those plastic spacers?
Good choice on that Axon 7
Click to expand...
Click to collapse
It may have adjusted the Full Charge Capacity back to what the Z3C considers a full new stock 2600Mah. The purpose of that is just to recalibrate the fuel gauge percentage outputs for accuracy throughout the range to account for degradation I think. I recall something like a couple bits of code mentioning 2600 in the kernel battery somewhere back when I did some peeking. The kernel defines the battery size and the related BMS functions and calculates on that premise.
Anyway it's stock feature. I moved onto AOSP so can't say how stock would've exactly responded except as I speculate above. AOSP doesn't implement the feature, I can assume without it, earlier shutdowns or rapid unsmooth drops in percentages can occur on degraded batteries. Think of Apple's degraded battery CPU throttling controversy, it's a new issue because of greater peak power demand of modern performance and combine that with how battery voltage can spike low due to this. I've learnt more about this by investigating how Axon 7 users with degraded batteries are experiencing throttling too under a Qualcomm BCL enabled feature. I made a thread about it here: https://forum.xda-developers.com/axon-7/how-to/degraded-battery-bcl-device-lag-t3752545
The plastic spacers are in the last photo in the album. I'm talking about the ones to allow an air gap for lowering heat stress without these a normal Z3C case will fit well. I could probably update a photo, I do use a couple plastic spacers to hold the battery alignment too. The battery itself is obviously thicker than stock so straight installing the back panel won't work well. A case is easiest as no back panel is required, if you prefer the look, you could use a clear back case and just place the back panel before it.
To recap the battery itself functions fully and charges fine. Without kernel fixes the percentage will be 0% when there's the extra energy left. Using an alternative app to provide a custom estimated percentage based on voltage is a way to see remaining power. I made my own Tasker profiles to custom calculate displaying a notification that also considers plug state.
Sent from my ZTE Axon 7 using XDA Labs
Infy_AsiX said:
It may have adjusted the Full Charge Capacity back to what the Z3C considers a full new stock 2600Mah. The purpose of that is just to recalibrate the fuel gauge percentage outputs for accuracy throughout the range to account for degradation I think. I recall something like a couple bits of code mentioning 2600 in the kernel battery somewhere back when I did some peeking. The kernel defines the battery size and the related BMS functions and calculates on that premise.
Anyway it's stock feature. I moved onto AOSP so can't say how stock would've exactly responded except as I speculate above. AOSP doesn't implement the feature, I can assume without it, earlier shutdowns or rapid unsmooth drops in percentages can occur on degraded batteries. Think of Apple's degraded battery CPU throttling controversy, it's a new issue because of greater peak power demand of modern performance and combine that with how battery voltage can spike low due to this. I've learnt more about this by investigating how Axon 7 users with degraded batteries are experiencing throttling too under a Qualcomm BCL enabled feature. I made a thread about it here: https://forum.xda-developers.com/axon-7/how-to/degraded-battery-bcl-device-lag-t3752545
The plastic spacers are in the last photo in the album. I'm talking about the ones to allow an air gap for lowering heat stress without these a normal Z3C case will fit well. I could probably update a photo, I do use a couple plastic spacers to hold the battery alignment too. The battery itself is obviously thicker than stock so straight installing the back panel won't work well. A case is easiest as no back panel is required, if you prefer the look, you could use a clear back case and just place the back panel before it.
To recap the battery itself functions fully and charges fine. Without kernel fixes the percentage will be 0% when there's the extra energy left. Using an alternative app to provide a custom estimated percentage based on voltage is a way to see remaining power. I made my own Tasker profiles to custom calculate displaying a notification that also considers plug state.
Sent from my ZTE Axon 7 using XDA Labs
Click to expand...
Click to collapse
Thanks for the always extensive and in-depth reply
Well that does make sense to have it embedded in kernel code somewhere.
I am on AOSP as well, almost a year already, but I haven't noticed any lags or slowdowns on low battery levels (low voltage levels) even down to 1%, and my battery will be 3 years old in June. Either the system has adapted to degradation or my battery didn't degrade much, which I really doubt since I had a lot of 100% -> 0% cycles and the battery was under high CPU and temperature stress in a lot of occasions.
As for the spacers, yes I forgot the pictures, I've seen them again. Now, I want to try and fit the original back panel, I know the GS8+ battery is 1mm thicker, however right now when I glue my back panel so that it has tight fit on the frame, it is actually "intruding" in the back of the phone, and it's not level with edges of the side frame, it's rather inside. The idea is to use let's say two layers of a double sided tape directly on the frame to compensate for that 1mm, apply the B7000 on top of that and on side walls of the frame as much as possible and place the back panel. I hope you understood since my english might not be up to that level
Since it's my only phone atm I would like to keep it decent looking as much as possible
My normal usage of the phone does not involve heavy tasks at all so temperature is not my concern, that's why I want to use the original back panel to close it down.
And yes I remember you are using Tasker to read the actual voltage level, although it would "hurt" my eyes to look at that non-linear stock battery indicator, I would have to do it as well
Please, could somebody share his voltage/percentage curve for tasker? And which system interface did you use to update the battery percentage? And did somebody of you test how effecient tasker does handle events? It would be not so usefull if it is taking additional 200mA during 10h runtime for event handling and system updates.
Did anybody find out how to change the charging overvoltage cutoff and the shutdown voltage? I would like to stress my battery a little bit more to get every thing out of my 44g for the first 50 to 100 cycles until it gets replaced.
A custom charging cutoff voltage and shutdown trigger voltage would be the best solution for a lightweight outdoor navigation device with 30-50 cycles per year. My device is so highly specialized that I did even remove the cameras and exchange the glass backpannel with a 0.25mm thin carbon pannel.
Kind Regards
Falco