No decimal, so 99.5% will read as 100% and topping up is a slow process
My issue is with the “Fully charged” discrepancy due to Windows decision to round up. (Fully charged is a lie during that period)
1 Like
I see this constant flipping too, with 12th gen running openSUSE Tumbleweed Linux. It’s pretty annoying. Surely there’s nothing magic about Framework power management which would be so different to other laptops to require this?
1 Like
I have the same constant flipping issue on Fedora 37 with 12th generation.
Never experienced this myself on multiple Framework laptops. But I have heard others have seen this occasionally.
Test a live usb of Ubuntu or Fedora. If it happens there, likely need to open a ticket so we can take a look at the logs, etc.
How much flipping? Is this just an internal notification or a clear LED like power switching observation?
There is also this related thread
Actually both. I turned off the notification, because it’s annoying every time to see it. But I see how the charge icon flipping at the tray and LED slightly changes the color as well.
1 Like
Try to load CPU at least 30% for a while.
Not able to replicate it here on Fedora 37, left it running under a decent load.
This feels like a bad battery or something related to hardware. I say this as:
Please open a support ticket and let them know what you’re seeing with the LED lighting.
Is the issue here that when it’s plugged in and nearly at full or full capacity it switches constantly between AC power and recharging the battery? I’m on windows 10 and this has happened to me a bit (11th gen).
How often and to what degree does it discharge?
So I might have recently experienced this too, it was brief and caught me by surprise so I didn’t check if the charge indicator LED changed colour and the battery is always reported as charging in the UI so I didn’t think to check that. I have a 75% charge limit, 11th gen i5 3.10 BIOS.
I was watching a 1080p/60 youtube video (normally I would watch at 720p/30) when out of nowhere I started to see battery drain. I happened to be looking at battery voltage using GTKStressTesting during this time:
I then checked Gnome power statistics which normally shows “There is no data to display” when running solely of mains.
I also happened to be running s-tui during the video playback which reported 15W psys so well within the 60W available from the adapter.
I will see if I can replicate it.
I just received my Framework laptop last week and immediately noticed that the battery never gets to the fully charged state. It’s always either “charging” or “discharging”. I’m on BIOS 3.04 and running Fedora 37.
This occurs no matter what value the battery charging threshold is set to. Testing with battery threshold at 100, upower reports the following when fully-charged and plugged in:
$ upower -i /org/freedesktop/UPower/devices/battery_BAT1
native-path: BAT1
vendor: NVT
model: Framewo
serial: 000F
power supply: yes
updated: Sun 19 Mar 2023 07:53:22 AM EDT (0 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: discharging
warning-level: none
energy: 54.593 Wh
energy-empty: 0 Wh
energy-full: 54.593 Wh
energy-full-design: 55.0088 Wh
energy-rate: 3.542 W
voltage: 17.608 V
charge-cycles: 1
time to empty: 15.4 hours
percentage: 100%
capacity: 99.2441%
technology: lithium-ion
icon-name: 'battery-full-symbolic'
History (rate):
1679226802 3.542 discharging
1679226772 3.573 discharging
1679226742 3.634 discharging
1679226712 3.696 discharging
Note the state is “discharging”, when it should be “fully-charged”. In other words, from the perspective of sysfs, there is no condition in which /sys/class/power_supply/BAT1/status will report “Full”.
Is this a limitation of the embedded controller or am I dealing with a hardware issue?
Possibly-related threads:
1 Like
Personally I think the charger being used has something to do with it. Are you using the “Framework Charger”? If so I recommend getting something with a higher rated power delivery. When charging off of my Anker 737 this behavior went away, also in some situations updating to the latest UEFI helped as well. Simply the 60w charger cannot and will not provide all the needed power on a 12th gen board. I measure up to just over 74w of draw with an inline power tester, you wont get that on a 60w charger. Basically my suspicion is anytime it turboboosts for more than 5 seconds or so it switches over to battery to make up the difference.
2 Likes
I do not believe this is the cause even limiting the CPU to 15W and keeping total system consumption well within the 60W output this behaviour is still occurring.
@Usernames maybe not in your case but with 12th gen boards I have to disagree i.e. the post I was responding to from @Stephen_Panicho . I regularly experienced the same behavior until I switched to a stronger charger. Also I definitely recommend being on the latest UEFI/BIOS it clears up a lot of thunderbolt/usb-c issues and these may include power negotiation. I have not experienced this behavior since performing the actiions I recommended.
@nadb I don’t think that’s the issue. It’s on a dock capable of 90W and the laptop is certainly not exceeding that while it sits idle.
If never reaching the fully-charged state happens for everyone, then it’s a deficiency in the EC programming. I’m trying to verify that before calling it bad hardware.
As far as I’m aware, there is no other BIOS release for 12th Gen aside from a beta. I’ll check that out and report back.
1 Like
The 3.06 beta is the one I am on. It is where I would start since you already have a charger that should satisfy…however I did test a number of docks claiming to deliver in the 85w range and were in fact topping out at 62-65w so if the update does not fix the issue, I would at least verify. I also noticed that in some situations prior to finding a charger that actually delivered and updating the UEFI stress testing would cause a state where the battery would not charge at all until discharged, or disconnected in the UEFI and reconnected, after which it would charge again.
Regardless buggy UEFI or EC is likely the root cause.
2 Likes
That beta bios thread looks mighty concerning. Seems like it introduces more issues than it fixes! On second thought, I’ll wait for an official release.
@nadb Yes, I am also referring to the same post you are. My previous reply is another issue so I can see your reason for confusion.
I am disagreeing with your reasoning, as the post you are replying to indicated this occurs all the time not under heavy load just like rest of the thread describes.
All the best