This is the behavior I am seeing as well. Are the upower folks aware of this?
1 Like
I donât think the flapping charging/discharging has anything to do with upower. Thatâs reporting directly from the battery in /sys/class/power_supply/BAT1/status. Only the flapping AC disconnect & plugged in events were upower related. And it did come up on the GitLab issueâs comments.
Itâs Frameworkâs charging logic and/or the fact that the 60W canât deliver the necessary power all the time IMO
upower was just trying to use a heuristic & time threshold to go âhmm, the battery has been reporting as discharging for X number of seconds, we can assume this must mean AC has been disconnected, letâs switch upowerâs state to on-battery: yes and send a d-bus event for AC unplugged.â
This heuristic & assumption was inaccurate for cases where laptop was plugged in AND discharging, and it is what was fixed/removed in 1.90.9. Because there are cases where itâs normal for this to occur, notably gaming laptops. Dell Hybrid Power, Lenovo Hybrid Power (paragraph under image)
I donât know if discharge while on AC power is normal for the FW13. And it doesnât happen when I charge my FW13 with a Satechi 100W charger. The battery status will remain solidly at âChargingâ (with a charge rate of 0W) when I use the Satechi charger and Iâm at the battery charge limit. Iâm still on 3.05.
2 Likes
Iâm still on 3.07 beta and started experiencing the occasional charge/discharge loop (made even more annoying by the connect/disconnect system sound) regardless of charge limit setting.
It started occurring after I updated to the latest Bluefin image which included upower being updated from 1.90.7-1 to 1.90.8-1.
1 Like
Iâve seen such behavior too sometimes battery status was incorrect (charging instead of not actually being in charge but it wasnât very impactful for usage)
1 Like
Respectfully to everyone discussing, I think going down the rabbit hole of why the FW13 battery seems to flip-flop between charging & discharging might be outside the scope of this particular thread since it is also happening on BIOS versions earlier than 3.08. So it wasnât introduced by the 3.08 BETA.
My apologies if I contributed to going down this rabbit hole in this thread.
@Quin_Chou do you have any idea what the next steps are to promote 3.08 from BETA to stable release?
4 Likes
Unfortunately, the first post in this thread says they found another issue with the battery charge limits and this release will not be promoted to stable.
It sounds like itâs only an issue when both the battery charge limit and battery extender are used and they are working to fix it.
2 Likes
oh I had no idea battery extender and charge limit are designed to work together.. I always think it is one or the other.
1 Like
Fedora 42 has updated upower ânaturallyâ so my orchestral charging noises are now supressed.
The nuances of the other issues with the firmeware and linux it way over my head.
upower.x86_64 1.90.9-1.fc42
1 Like
Was going to share this as well. Upgraded to Fedora 42 today and upower has gone up to 1.90.9. So far I havenât observed any regressions with 42, so for Fedora folk this might be an alternative option to excluding 1.90.8 through DNF.
FWIW 1.90.9 has also made it to stable in F41 so no need to rush to F42, unless you want to upgrade anyway of course.
1 Like
Yep, looks like this release has been held 
To framework engineers, is there any chance we could incorporate @James3 's excellent work fixing bugs in the charging logic (and elsewhere) in 3.09?
2 Likes
The only way I see that would make sense for the two to be used together is if the battery charge limit is used to inform what â100%â means to the battery extender. If the charge limit is set to 80% then the battery extender should use 80% as the reference point, and go as low as 65% after 7 days.
For example, if the charge limit were 100%, then, as per Frameworkâs first post in this thread we should have have:
| Battery Extender Duration | Battery State of Charge |
|---|---|
| 0-5< Days | 99% â 100% |
| 5-7 Days | 90% â 95% |
| >7+ Days | 85% â 87% |
If, however, the charge limit was set to 80% then the above would translate to:
| Battery Extender Duration | Battery State of Charge |
|---|---|
| 0-5< Days | 79% â 80% |
| 5-7 Days | 70% â 75% |
| >7+ Days | 65% â 67% |
From what people have reported so far this doesnât appear to be the case and I donât think Framework ever commented on the interaction between the two. Even then, with the addition of the 5% floating range, the benefits of the above scenario would be questionable, though still ânice to haveâ feature.
I agree. If the above outlined scenario is not how they are intended to work when enabled together, then the BIOS should be designed such that enabling one disables the other.
At the very least a note should be added to whichever one takes precedence.
Since the charge limit clearly allows for a concrete, and presumably with any sense more conservative setting, IMO enabling it (i.e. setting it to anything < 100) should take precedence and disable + grey out the battery extender.
The latest BIOS for the FW13 tried to fix it like this:
- If the charge limit == 100%, enable the Battery Extender.
- If the charge limit != 100%, disable the Battery Extender.
Except that the case (2) failed to disable the Battery Extender in all edge cases.
The battery extender mitigates the issue of leaving the battery at 100% for extended periods of time. It stress and ages the battery prematurely.
If you have limited the battery to say 80% and leave it at 80% for extended periods of time, it is unlikely to stress and age the battery prematurely, so the battery externder is not needed.
Another feature that is used is the âBattery sustainâ.
It takes a sustain.lower and sustain.upper parameter.
I think the âBattery sustainâ should have three parameters:
sustain.lower
sustain.upper
sustain.discharge.
This would then provide a charge hysteresis between sustain.lower and sustain.upper and a discharge hysteresis between sustain.upper and sustain.discharge.
If one is like me, and donât want the forced discharge to happen at all, I could set the sustain.discharge to > 100% so it would never be activated.
But if you needed force discharge to happen, say for âbattery extenderâ one could set the sustain.discharge to some value below 100%.
âBattery sustainâ just adds some hysteresis. It charges up to the âupperâ and will not try to charge until it drops to âlowerâ. It reduces the amount of charge/idle cycles.
âBattery limitâ has no hysteresis.
I was suggesting to add hysteresis to charge/discharge cycles, as even the sustain option does not have.
Hysteresis at lower % doesnât really do much, but itâll help to save a lot at 99% charge as a cycle from 80% to 100% wears down the battery faster than a cycle from 0% to 80%
is there a way to update upower in linux mint without breaking things?
1 Like
For clarity, the Hysteresis I was thinking about was something like
lower == 55%
upper == 60%
If the charge goes below 55% charge up until 60% and then IDLE.
If the PSU is plugged in, it will stay around 59%-61%.
As it wonât go below 55%, the battery is saved from any charge/discharge cycles while plugged in.
If you unplug the PSU and the charge goes below 55%, the next time you plug the PSU in, it will charge up to 60% again.
The reason it stays around 59% - 61% is due to the BMS re-calibrating, so the 60% might turn into 61% or 59% with the battery still in IDLE.
The problem with the current EC code, without hysteresis, is that if it see 59% it will start charging to 60%, and if it sees 61% it will force discharge.
Those mini charge and forced discharge cycles probably shorten the life of the battery.
If those mini-cycles happen all the time around 100% charge, it will do considerable damage to the battery.
So, implementing the hysteresis is to prevent the mini-cycles.
I was not suggesting the lower == 0% and the upper == 60%
4 Likes
That is how Lenovo has been doing this for years, urr, I mean decades!
Iâm getting a blank screen on reboot when connected to my docking station, and all evidence so far points to this BIOS update. Has anyone else experienced similar issues since upgrading to 03.08? If you have a docking station but havenât used it since upgrading, it might be worth giving it a shot.
Any help trying to troubleshoot would be appreciated (plz consider directing such help to the linked question, or post it here if related to BIOS).
1 Like
Iâve never used ectool but I assume it uses a separate mechanism.
1 Like