If that was the intention, then why on earth would they leave the battery extender enable/disable option in the BIOS settings?
What is that supposed to achieve?
Is it an alternative to the battery extender?
Is it an alternative to a charge limit?
â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.
My understanding is that this doesnât help the battery at all unless something else is wrong, but yes, a small hysteresis could make sense.
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
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%
4 Likes
That is how Lenovo has been doing this for years, urr, I mean decades!
Personally, Iâd be happier without self discharge (while on AC) except for when the battery extender requires it.
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
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?
@Quin_Chou Itâs been about a month since this BIOS was released. When can we expect an update on next steps?
2 Likes
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.
4 Likes
December of what year, though?
1 Like
Whichever comes out of the random number generator 
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.
- Support (see above for how that went)
- Community forums (well, you read this thread
)
By the way, itâs May now.
7 Likes
As much as I want to love this company, and I have a laptop and am invested, you really canât be selling laptops at $1000+ and then giving out multiple broken BIOS updates and going, so far, up to 5 months without a fix.
We can do better. Surely.
12 Likes