I agree, it makes sense. May i ask, is this based on actual information on cycle_count behaviour or just observation? I would just like to confirm.
Both.
(+20 characters)
Oh please, elaborate.
But what?
I already described how it works and that my long time observations on two different phones confirm it. Where I read its documentation, I don’t remember, I guess you can try to google it yourself…
So i guess your assumption is as good as mine. Which is just fine. I just wanted to check.
Can you call Jolla for an update? :>
First of all, i said mine was a guess, and commented your explanation “i agree, it makes sense”, but when i asked for something to back that explanation, it felt like yours is just another guess (like mine). You have to understand that in this kind of situation the burden of proof is undeniably yours.
And second of all, there is no need to be rude. And there is no need for an argument. If you feel like arguing with someone, please keep away from this forum.
I would also like to hear the facts from Jolla devs, since my guess is worth nothing, and @wetab73 is just quoting random stuff about laptop batteries and from Apple support (?) and showing that there are apps.
Do you really talk to people like that face to face?
Do you think that is acceptable behaviour on this forum?
1 Like
It’s amazing but yesterday I did the very same thing (stopped the Battery Buddy service and allowed the phone to recharge to 100%) and guess what… After I went to bed and set the phone as usual (only mobile network for voice calls enabled, mobile data off, wifi off, bluetooth off, gps off, Android support off), when I woke up only 4% were consumed (compared to the usual 8%-9%) and each 1% lasted 1 hour 50 minutes rather than the usual ~ 1h:00m - 1h:15m. Now at 23:00 in the evening I still have 82% battery left, whereas normally at that time of day I only had 55-60%. Of course, I charged it 10% more than the usual 90%, but the difference is much more than that.
I guess that the battery must have re-calibrated itself when it was allowed to fully recharge, and the indicator now uses correct units (1% is now really 1%, i.e. 45 mA) whereas previously the % indicator must have been kind of de-calibrated, and the % units were smaller than in reality so they were decreasing too fast.
Let’s see how long it is going to last so, and what enabling Battery Buddy limits will cause…
2 Likes
Flightmode standby drain with 4.5.0.19 remains the same at 0.7%/hr (not that any difference was expected)
1 Like
… and after 25 hours of normal use I still have 70% left. Power consumption seems to be actually the same, so - as I wrote - the battery level control must have undergone some kind of recalibration. I don’t remember it lasting that long ever. Now even with WiFi and mobile data on, 1% lasts 1h:00 - 1h:05… Magic…
It looks that it is very useful to recharge the battery to 100% once in a while to calibrate it.
I had the following out of sync (much lower than actual power level):
/sys/class/power_supply/battery/charge_counter
and recharging to 100% fixed it.
This counter should reflect the level of charge (in mAh) left in the battery (in case of 10 III it should be eg. ~4500000 for full, ~2250000 for 50%, etc.). If it gets out of sync, I guess that the % indicator gets incorrect, too (decreases faster than the actual power draining).
And meanwhile my old Nexus5 is lying with flightmode on and wifi enabled on my desk. 5 days since the last charge, 55% left, 6 days to go.
Sadly, I was too optimistic. It took just one partial charging for the /sys/class/power_supply/battery/charge_counter to get out of sync again, and everything went back to what it was, e.g. my “bedtime” standby (everything off except cellular network) is again 1h:10m.
charge_counter is a popular counter in Android world, very often shown by diagnostic apps on Android and used to track battery capacity and its health. For instance, AIDA64 (Android version, unlike the SFOS one) shows it.
When the battery is full, its value should be the same as battery capacity. Then, as the battery discharches, its value should reflect the charge (the number of mAh) left in the battery, whereas the battery % level indicator should translate it into a % value.
Yesterday, thanks to charging to 100%, it got in sync (value of the charge_counter was right, and the battery % level was matching it) but today, after partial charging, it is again totally mixed up:
- my current battery level shown is 75%
-
charge_counteris 3079720
It is wrong because 3079720 out of 4525000 (that’s the mAh value shown when full) = 68% not 75%… So, again, the displayed % value is “bigger” than the actual % of charge in the battery, hence the % level indicator decreases faster than it should, giving incorrect, too short times per each %.
In the evening I’ll recharge it again to 100% and see if it gets things in sync again. If it does, I’ll probably say goodbye to partial recharging.
Just a guess, could it be that your battery doesn’t have its full capacity anymore?
On my linux laptop there are the values energy_full and energy_full_design. The first one shows the capacity of the battery when it leaves the factory, the other one the capacity of the last full chsrge, which gets lower when the battery gets older.
Maybe tge charge_counter value shows the real capacity of the battery?
Edit:
The values on a phone are charge_full and charge_full_design.
Well, when fully charged it gets 4529000, which suggests that it still has its full capacity… Only if charged partially, this value gets out of sync - too low compared to the % value.
charge_full is 4529000
charge_full_design is 4529000
Looks OK. Assuming that it works. Maybe in AOSP they just put default values there…
How does it look on your 10 III? And is charge_counter in sync with %?
In the Battery Buddy support thread, I suggested a wholly different approach to battery saving - the one that iOS phones use. They always charge up to 100% but modulate the charging current so that charging is complete shortly before user’s preferred time (e.g. when he wakes up). This way one starts the day with always 100% of charge (rather than some 5-10% already discharged when he was sleeping) and thus also ends the day with more charge left.
I would love some application on SFOS to make it possible to even just manually enter the destination time and then modulate the charging current so that 100% of charge is reached at that time.
On a different note, I’ve just noticed that battery % indicator in Android apps hasn’t been working correctly since 4.5.0.16. It is correct only when the Android Support is launched, but then does not get updated and keeps showing the value it had upon Android support launch.
Has anyone else noticed the same on his 10 III?
(the SFOS side says 46%, Android support stuck at 40%)
EDIT: It’s the same on both my 10 III and XA2U, so it’s a 4.5.x.x bug.
charge_full: 0
charge_full_design: 4529000
charge_counter: 3532620
Homescreen shows 81% left of battery.
4529000 / 3532620 = 78% so there’s a discrepancy vs. 81%. Check again around 60%, probably it’ll be even bigger.
charge_counter: 2853270
Homescreen shows 67% left of battery.
45290000 / 2853270 = 63% so the discrepancy (4%) got slightly bigger. But I guess it’s typical as on my 10 III it is right now 76% vs 73%, i.e. 3%.
The most strange thing is that my XA2 Ultra’s charge_counter when fully charged is 5688458 (i.e. more than 5600 mAh) 