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%
Almost nobody would want cycling all the way down to 0% with the AC power connected.
I would have thought 5 little 10% cycles from say 50% to 60% would be slightly better for the battery than 1 bigger 50% cycle from say 45% to 95%.
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%
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).
Well I dont use the battery features much. but I have to add that the fan sensors are reporting wrong info. (Using aurora, they report they are going full blast all the time even when no noise). Installed the update due to the security fixes.
I talked to support about the flipping issues the other week, and they recommended I install 3.08 (once it is fully released) to fix it.
From the original post, they have updated the charge limit logic to prevent micro cycles.
As an example, if the user sets the battery charge limit to 80%, the battery will maintain a state of charge between 80% and 75%. And will not charge up to 80% until it has discharged to 75% while the system is on.
Is that what you are describing? (It would be really nice if theyâd open source the 3.08 EC firmware so we could see what they were doing)
Also, anyone following this thread using 3.08, can you confirm that this is now the behavior on charger under load?
Come December we might actually get a proper stable BIOS updateâŚ
I will also add that fwupdmgr continues to want to upgrade to the now pulled 3.07 BIOS, including after fwupdmgr refresh --force. Unless this is an issue due to some weird cache behaviour, can FW please pull the broken update from LVFS so that people donât accidentally upgrade to a BIOS version that has been officially withdrawn?
Edit: Yes, one can permanently mark the update as âto be ignoredâ with fwupdmgr block-firmware <checksum> where <checksum> comes from the âChecksumâ property in the summary of the update ( fwupdmgr get-updates). But thatâs not the point, if it has been marked as âheldâ it should also have been pulled from LVFS.
I reached out to Framework support through the ticket I have open about the battery flipping.
Currently we are not able to provide further details of the exact ETA of the proper stable BIOS update.
When I asked if it would be weeks or months:
As much as we want to provide how many weeks, months it will take to release the BIOS update however, we still donât have any update yet.
Please be advised that we are always trying our best to deploy the latest BIOS updates as soon as possible for our customers who are experiencing issues with the current BIOS.
And to the employees that (I really, really hope) are watching this thread, yes, I know that thereâs no way support has access to these details, but I have a broken $1400 laptop and two courses of action for trying to get it fixed.
)