I recorded idle temps with P3T set at 90W using the Balanced power mode with VSysMax set at both desired battery voltage and current battery voltage with an offset.
I had the computer in suspend for 15 minutes before logging temperatures. I then ran my csv script and nothing else for 3 minutes immediately after logging in.
I don’t see an appreciable difference in idle temps between the two VSysMax setpoints based on the data. So at least for now, I’ll run the custom firmware with the lower P3T and with VSysMax set to battery desired voltage in daily use.
Not sure if there’s much else to test on the FW13 for now with regards to battery flipping. Perhaps the next step is getting some of the findings from this thread on the Github issues tracker to get feedback from the Framework EC dev team?
Good to hear, I was theorizing there may have been some clock stretching going on with the constant vrm input voltage changes but I am glad that was just a ghost.
This is the reply from Framework stuff about battery voltage thing. From that we can infer the mainboard accepts and listens to the battery.
I think it’s technically possible to use NMC or other chemistry as long as the battery voltage fell within 12.0V to 17.8V(hard-coded according to published EC code on GitHub). Also, since the temperature is also communicated alongside voltage and current (the modified EC code by @James3 makes it possible for the users to observe them, the EC itself acquires the battery information from the BMS is unchanged). Therefore if the battery temperature limit is written correctly, we don’t need to worry about battery overheating.
The only exception is using a special battery that can be safely operated above 55°C. In this case the battery performance is reduced as the EC caps the temperature to 55°C
I did an almost the same experiment this time charge limit set to 100%, and the result is a bit unusual.
Same gaming on performance mode, much less battery power fluctuation compared to the link above
chargecontrol stayed NORMAL consistently instead of flipping between NORMAL and IDLE
$ sudo ectool chargecontrol
Charge mode = NORMAL (0)
Battery sustainer = off (-1% ~ -1%)
chg_voltage 17800mV instead of 17600mV, chg_current 0mA instead of 2740mA
$ sudo ectool chargestate show
ac = 1
chg_voltage = 17800mV
chg_current = 0mA
chg_input_current = 2700mA
batt_state_of_charge = 100%
Both Desired Voltage and Desired Current went zero
$ sudo ectool battery
Battery 0 info:
OEM name: NVT
Model number: FRANGWAT01
Chemistry : LION
Serial number: 0035
Design capacity: 3915 mAh
Last full charge: 3608 mAh
Design output voltage 15480 mV
Cycle count 187
Present voltage 17291 mV
Present current 0 mA
Remaining capacity 3608 mAh
Desired voltage 0 mV
Desired current 0 mA
Flags 0x07 AC_PRESENT BATT_PRESENT DISCHARGING
Present voltage displayed well below 17.6V, normally it went from 17.58V to 17.56V after charging to full.
I opened an issue on the Framework EC Github with some of the battery and charger logic questions that have come up in this thread over the past few months. Will post back here if the FW dev team responds to the questions.
Feel free to add more questions or supporting details in the Github thread if I missed anything important or got any details wrong.
On my FW16, my battery does not charge to 100%.
It gets to 98% and stops.
The “Present voltage” gets to close to 17800mV, matching the “Desired voltage” of 17800mV so it cannot actually charge it any more.
My guess is that the smart battery BMS is just not calibrated correctly any more after spending most of its life at my configured 70% limit.
This is probably the only time I have attempted to charge it to 100%.
Maybe the BMS is not clever enough to realise that it is probably already fully charged.
I did notice a considerable difference between the charger VBAT value and the “Present voltage”.
I assumed they would be the same, but the VBAT was at about 15700 while “Present voltage” said it was at 17800.
So, one of those voltage values is calibrated wrongly.
Charge it for two more hours and see if that helps.
In my computer the battery levels never reaches 99% during charging as it always stayed at 98% for a long time then immediately jumped to 100%. 99% can only be achieved by discharging from 100%
Another way is to use USB PD PPS on page 39. Passthrough the input buck-boost(to reduce conversion loss) and connect the PPS output directly to the computer’s DC rail. Lower the voltage(battery charging at low %) or current(low CPU load while charging). Set to 17.8V 5.0A when charging has finished and BGATE off. I wonder whether a detailed EC reprogramming is going to achieve that or hardware upgrade is needed.
I don’t see how that would help here. But it would certainly need changes in the pd controller firmware which is a somewhat working black box we don’t have much insigt on at this point.
Well using a 60W charger won’t help with 75W(53W on CPU) pulse load, but earlier tests shows a 45W(35W on CPU) sustained load also dips into the battery. The reason, as I suggested earlier, is that the input buck boost(and power muxing as you mentioned) can’t react fast enough to handle load changes. Earlier laptops with barrel DC input doesn’t have this problem because the input voltage goes directly to the rail. By setting the duty to 0% on the boost, 100% on the buck, the buck-boost is bypassed and the input goes directly to the rail, so it could help.
Pretty sure we tracked these issues down to much too agressive power limits. if you just want it to stop throttling input power completely you don’t need pps or some weird messing with the buck converter for that but it also might cause the psu to tap out. The buck converter isn’t the problem (the same one is used in the 16 to do waaay higher power stuff), it’ll happily do way more than that but it is told to only draw x Amps from the input and it is very good at that.
You can just tell it to draw more or it also has the feature to allow it to go over the limit for a limited time period. I played around with that but it didn’t seem to do much and may mess with charger compatibility. Just setting the peak power lower pretty much eliminated dips into battery.
The whole direct ppd thing is neat for phones that can’t put in big enough dc-dc converters to do their fancy fast charging but that is not the case in the fw13 of 16.
Bypass mode would be nice to have on the 13 too but at this point we are pretty sure it isn’t wired for that on the 13. Being wired for it and it going completely unused would be almost more sad than not having it.
One interesting thing I found while reading the ISL9241 datasheet is that the max VBAT voltage you can read from the charger is 16320 mV. Even if the actual battery voltage is above 16320 mV, the charger can only show a VBAT reading of 16320 mV max.
I looked back at one of my previous ectool chargegetregs recordings to verify this, and sure enough, even though ectool battery displays the present voltage at ~16750 mV (80% charge on my FW13), VBAT is capped at 16320 mV.
Interresting catch, I do wonder why they chose to sacrifice range for resolution on this speciffic reading. Maybe because it is mainly used for under-voltage detection and trickle charging and is not directly involved in any of the control loops. Still weird choice though.
Either way, for accurate data about the battery ask the battery I guess XD.
Just a +1 to this issue, have spent the entire day trying to work this out across Fedora 42 Workstation, Bazzite-Gnome and Ubuntu 25 as I was tired of Windows and wanted to put Linux on my HX370 board.
Everytime the CPU is put under a decent load (OCCT stress test, gaming, downloading on steam) it starts discharging from the battery and is no longer considered to be charging.
Never had this problem on Windows 11 and will be going back for the time being until this has been sorted. Interestingly enough though, this wasnt an issue for my 7840u board in the brief time I had Fedora Workstation 41 and 42 Beta installed.
After moving back to Windows 11 I encountered the slow charging and random discharging issue (although, I didn’t receive a performance hit) so I unplugged the charger, booted into BIOS and found the battery disconnect toggle, saved and exited.
From there, the system was off but I held the power button out of habit to flush, plugged the charger back in and booted back up and it was all back to normal. I then reinstalled Fedora and Bazzite (both KDE and GNOME) across the course of the day and tested for the original issue.
Thankfully it was solved BUT the issue did come back on my very last (final) install of Fedora Workstation, not sure what I did but I just repeated the battery disconnect steps and it was fixed yet again.
