I have looked at the source code:
git show aececb3ae36
git show 18c1d3200f2
git show 947f55095e5
It started at 95%, someone moved it to 85% and then it ended up being moved to 90%
So, there must be a good reason that it is not set to 100%.
I would love to know that reason. (and given the as far as I can tell unreachable over current prochot thing it may not be a good/properly implemented reason)
I can totally see why you can’t go to 100% on the 16 as you don’t know the efficiency of the buck converter in front of the actual charge controller (it has the current sensor but that is not part of the chargers control loop) but the 13 doesn’t have that issue.
Still going to see what happens if I set it to 100%, I can see it maybe causing problems with dodgy power supplies but all of mine that could not supply over 100% of their rated power gone straight to ewaste. The good thing about pd is mandatory charger side ocp so worst case the charger just nopes out. I can still just turn down the cpu power limits if I really want to use a dodgy charger.
commit 18c1d3200f2 raises a few more questions, it allmost looks like it intentionally reduces the limit on the charger while increasing the power limit on the soc.
To clarify, the last video I took was with the custom firmware with the existing logic for setting VSysMax (current battery voltage + voltage step).
If it would useful, I can rerun the same tests and take logs for the patch setting VsysMax to battery desired voltage later today. I am wary of using that patch long-term for now, since system thermal performance anecdotally seemed worse with that change implemented (though amdgpu_top should prove whether that’s actually the case).
1 Like
@mgcarlson
I think we have all we need for now. No need to test with the desired voltage patch.
1 Like
Here is a FL16 7940HS with a 240W adapter under a gaming load. I had to unplug/replug at the start because it was stuck at low clock speed
Disregard WiFi issue. I think I broke it 
1 Like
With the latest ectool update, you can generate a csv file with outputs from chargegetregs with the following command.
sudo ectool chargegetregs 0 output.csv
Change output.csv to whatever you want the file named. Apologies if you knew this already.
2 Likes
I see you have installed my EC firmware as it is reporting the charger status well.
I can see from the video that it has seen the 240W PSU and sets its current limit to about 202W.
The CPU/GPU is happily drawing over 202W at times, so it dips into the battery during the peaks.
If you use my EC firmware, you can set the charge threshold so that it only starts charging when it gets down to 30% and then stops charging when it gets to 80%. That way, you can have good game play all the way down to 30% instead of it starting to try charging again at 75%.
ectool chargecontrol3 1 30 80 255
ectool chargecontrol idle
between games, you can get it to charge with:
ectool chargecontrol normal
1 Like
The benefit of using a 100W charger on the FW13 for battery use stability is one of my main takeaways from running these tests.
The 100W charger is what I’ll be using with the laptop for daily use going forward regardless of what further power management improvements are made by Framework or others.
It would be worth it for Framework to consider selling a power supply larger than 60W with the FW13 going forward. Especially in light of the charger being derated by the stock EC firmware.
Okay, I think maybe I found a weird pattern for my WiFi issue…. If I swap to RW while connected to the charger it doesn’t come back up until I reset EC back to RO with the charger unplugged, but if I swap to RW without the charger connected, my WiFi works fine.
Rebooting after connecting the charger makes my computer start with a cpu speed of .54 GHz
That’s the condition that made me have the WiFi issue earlier and the throttled speed in the video 
Maybe start a new thread for the “cpu speed of .54 Ghz”.
So it seems to mostly boil down to extremely conservative current limits on the input mixed with relatively agressive power limits on the cpu/gpu for both platforms. The other tweakables are details and may have a bit of an impact but if the thing is told it can draw more than the charge controller is allowed to pull from the charger you either dip into battery sometimes or crash.
1 Like
There are one or two questions I still have.
With a 240W PSU, the charger is in bypass mode.
While in bypass mode, I don’t understand how the charger can add power from the battery.
I also don’t understand how the charger can enforce a current limit.
1 Like
That bit is mentioned in the application note (“1.3 Reverse Turbo Boost”), its basically running the converter in reverse like it would in otg mode (which we can’t use cause of the whole 4 charge capable ports thing XD). Theoretically it would also be able to provide power through the body diode of bgate if vsys drops enough but that would be a severe drop and a propper usb pd psu should ocp before drooping that hard.
By grabbing from the battery, not sure how it would deal with running into the limit on both though. Other than switching to another mode all it has left there is input current prochot and just straight up cutting power (and even that not really, the battery would still be able to send through power untill its bms nopes out).
I tested using a 60W charger and I set the current to 100%(3000mA) manually, and gamed in performance power profile. Lots of inconsistent FPS and sound stuttering. Current from charger jumped all over the place, sometimes to all the way to 0.02A. I then set the current back to 90%(2700mA), still jumped but much less
Battery flipped worse in the middle where I set the limit to 3000mA manually.
$ sudo ectool chargestate show
ac = 1
chg_voltage = 15872mV
chg_current = 0mA
chg_input_current = 2700mA
batt_state_of_charge = 56%
$ sudo ectool chargecontrol
Charge mode = IDLE (1)
Battery sustainer = off (-1% ~ -1%)
$ sudo ectool chargestate show
ac = 1
chg_voltage = 17600mV
chg_current = 3912mA
chg_input_current = 2700mA
batt_state_of_charge = 56%
$ sudo ectool chargecontrol
Charge mode = NORMAL (0)
Battery sustainer = off (-1% ~ -1%)
It flipped between NORMAL and IDLE, when in NORMAL the chg_voltage equals to Desired Voltage (17600mV is incorrect but that’s another problem), when in IDLE the chg_voltage equals to the battery’s current actual voltage. I forgot to record this when set to 3000mA but it should look similar
How did you do that?
By increasing the limit to 100% you made it possible for the input current prochot to get hit, that may explain the inconsistent fps and also the very jumpy power readings.
Now that is interresting
I read this article recently that I think explains usb-c power chargers quite well.
https://help.bestware.com/hc/en-gb/articles/18235839379485-What-performance-limitations-may-I-have-to-take-into-account-when-using-USB-C-chargers
Essentially, usb-c was not designed for laptops in mind and generally do not have much peak ability above their stated level. So, laptops have to work around this. I.e. derating the psu by 85% so it can deal with peaks in demand better.
I am not sure using a percent scale is suitable, because on a 240W psu, that is derating it by 38W. I would probably have done a lookup table instead of a percent.
If usb-c had been designed with laptops in mind, it should have the charger tell the laptop the voltages and current limits as it does already, but on top of that also include it’s peak currents/durations so that the laptop can make more educated guess as to how to deal with it.
$ sudo ectool chargestate param 2 3000
A quick summary of this thread so far:
Suggestions to reduce battery flipping:
For FW13:
- use a 100w psu instead of the supplied 60W psu. The CPU can peak draw 80W.
For FW16:
- if without dGPU, the 180W psu is fine. CPU can peak draw 80W
- if with dGPU, the 240W psu is better, but still expect a small amount of flipping when CPU + GPU wishes to peak draw more than 200W.
- Whenever one wishes to play games, prevent it from trying to charge the battery as this reduces the peak ability further. Set chargelimit 0 during game play. You then set it back to a large value after the game has finished, to let the battery charge again.
Here’s another example
A laptop can be powered by either barrel or USB-C. The barrel input has much higher power rating(109.98W) than the USB-C(86W). From my experience of using this computer, it generates much less heat doing the same work if its powered by DC barrel. I think that’s because the DC barrel connects directly to Vsys while USB-C input has another DC-DC converting process
Not sure I read that the same, it still says it can provide the rated power indefinitely so de rating to 85/90% seems like an extreme overreaction.
That or just have it intentionally droop the voltage before ocp, the charge controller supports input voltage based throttling but as far as I can tell the ec doesn’t set it up. But anyway that ship has sailed.
I wonder if that does other stuff than just setting the current limit, neat that that is possible though.
Would be interresting to try something a little below the configured prochot limit to see if that helps with the inconsistent fps thing.
It also is closer to the used vlotages and looking at dc-dc efficiency curves, the closer you got between input and output voltage the better the efficiency gets. At the disadvantage of having more conductor losses but those can be mitigated by using more conductor in the cable and beefier connectors.
I still don’t want to go back to barrel jacks because of that, pd is great even if it has some drawbacks and the manufacturers still need to get used to it.