I found that the maximum discharge power is limited when on battery so even if you use performance mode the power is lower than 61W. However if you set charge control to discharge and plug in AC you can actually exceed 61W power discharging the battery, but you can’t exceed 85W on FL16
For calibration would probably not want to discharge it too fast, especially towards the end. But the nice thing about a properly implemented autonomous calibration is that you can just let it do it over light or something.
Sorry about the rant XD
The overuse of PROCHOT signal on everywhere makes me feel that the EC controller(s) sounds like a whiner i.e. like those people who scream “trauma” over everyday inconveniences and put “trigger warning” everywhere. Just kidding don’t get me wrong
I have a old computer that has battery calibration, which just drains and charges the battery waiting in BIOS. Unfortunately it can only be initiated on Windows, not Linux or within BIOS menu
This has been the case forever and isn’t specific to framework, in this case we just have the code so we can see it better.
What does a t430 do when it detects a <65W power supply? Reduce the power limit on the cpu? Nahh mate prochot it is XD.
With thinkpads you can initiate it from tlp stright from linux and even keep using the computer.
I wasn’t criticizing Framework specifically, just expressing about my dissatisfaction about this phenomenon
That’s genius. However how to discharge the battery to 0% without affecting normal operation? Will the computer shutdown when the battery reaches critical level recognized by the OS? Will the system crash or locked in PROCHOT condition if an instantaneous burst use of power meets 0% battery?
You set the right bit on the charge controller and it does it all itself, according to the datasheet it’ll seamlessly switch over to pd. We should probably fix the dipping into battery bit first otherwise it’ll potentially crash here XD. The os should not deal with the battery critical stuff while plugged in.
I would say, trying to discharge a lithium battery all the way to 0% is not a wise thing to do.
A lithium ion battery, when charged outside of 30% to 80% is going to shorten the life of the battery more than otherwise.
Discharging a Lithium Ion battery to 0% can and does often result in a dead battery that is unrecoverable.
There is code in the EC software that will literally power everything off if it gets below 2%. I think it requests the OS to shutdown gracefully at 4%, and at 2% it does not ask, it essentially pulls the plug. There are many code paths, but it really fights hard not to fall below 2%.
For example, it prevents the laptop switching on (if psu not connected) below 2%. The only option is to charge it up a bit first, and only then will it turn on.
The laptop also throttles quite considerably even below 30%, encouraging users to keep it above 30%.
So, I recommend that people don’t bother with the full cycle calibration tests.
You can probably cycle tests between 30% and 80% and that will be good enough.
By 0% I don’t mean 0V but 0 state of charge, that is by design something not catastrophic and needs to be done from time to time to calibrate the fuel gauge. It is definitely causing more wear than use between 30 and 80 but it also lets you see the current state of health. bit of a dilemma, causing wear to check for wear XD.
Most of that is likely more because I can’t rely on the battery being there but also doesn’t want to go into standalone mode. At this low percentages it is easy for a load to push the battery voltage below the minimums of the bms and therefore unexpectedly loose power. Which is also why you need to do the lower end of the battery calibration at lower power to not end the discharge early.
Given lenovo had that feature for pretty much ever it can’t be that bad and I have had a lot of very confused batteries recover like that. Just lately I had to do that to an old acer that was left plugged in for a long time and though it only had 30% of the capacity left (figured out it had about 70% left after a few full discharges).
Also since I have set my charge limit to 90% on my fw my battery health has been climbing, don’t think that can be actually true XD.
So true. The battery itself has overdischarge protection. 0% reported by the BMS still [typically] is considered acceptable normal state, and that’s different from absolute 0v on the cell.
I re-calibrate the batteries in my ThinkPads typically around every 4-6 months. I’d say the wear while does exist, it is usually not a point of concern even over a period of 5 years.
Here’s a recent re-calibration, just for reference, thought it was noted that the battery cell package type does make a difference to the longevity of the battery:
With the puffy batteries showing up on the forum, I’m slightly disappointed that we’ve created more e-waste in this regard than would have typically otherwise (with or without warranty replacemnt).
Could anyone summarize the findings in this thread for me so far?
Now that 3.09 is stable, I upgraded 3.05 → 3.09, and at my 90% charge limit, with my 65W Anker Nano II, still see KDE flipping between charging and discharging and sometimes Fully Charged, but I no longer see the battery charging rate be anything except 0.0W. This is an improvement over 3.05, where I saw a range of nonzero charge rates between -5W and 5W. Sucks that the flipping still happens, but (so far) at least it seems like no power is actually being drawn from the battery under load?
Spoke too soon. I see it flipping between -0.1W and 0.1W. Also giving me this goofy jigsaw pattern when under even mildly bursty load.
If it’s helpful, here’s the ectool output:
░▒~/Code/framework/ectool/build▒░ [±heads/main✘]
$ sudo ectool chargestate param 3
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
49168 (0xc010) # chg_status
░▒~/Code/framework/ectool/build▒░ [±heads/main✘]
$ sudo ectool chargestate param 4
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
42926080 (0x28f0000) # chg_option
░▒~▒░
$ sudo ectool chargestate show
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
ac = 1
chg_voltage = 16792mV
chg_current = 0mA
chg_input_current = 2924mA
batt_state_of_charge = 90%
Is there a way to detect and print the BGATE MOSFET on/off status real time?
james3s ec + ectool patches let you dump all the charge controller registers so you can get pretty much the whole state of the charge controller. Vanilla there probably isn’t unless you want to actually attach probes to the board.
I just uploaded another video showing charger and battery outputs with the updated ectool version that fixed ADP scaling. The PSU value outputs are more realistic in the latest program revision.
I ran amdgpu_top along with ectool in this video. I discovered that opening any desktop program while taking a screen recording was enough to cause a power use spike. I decided to use this method of opening and closing a program instead of refreshing a browser tab.
Here are download links for the csv outputs from ectool chargegetregs that I ran in the background while recording the video. Hopefully the csv timestamps can be easily lined up with the video events.
2 Likes
Thx a lot for providing so much data.
Looks like there is something funky with the calculated power/current value in the csv output but the registers are still there so we can probably extrac that from there.
Do you have a list of the fedora equivalent dependencies? I’ll finally get around to installing the new firmware and provide some data for 240W later tonight.
In Fedora, here are the packages you need to compile James3’s custom ectool.
sudo dnf install gcc-c++ cmake ccache libftdi-devel
Here are the additional packages you need for compiling the custom EC firmware. The file and wget packages are included in Fedora by default. Python virtual environments should also work without installing additional packages.
sudo dnf install repo swig python3-devel ninja-build dtc
You may see a “Host tools installation failed” error when running setup.sh in the Zephyr SDK step. Ignore this error, you should still be able to run zmake fine in the next step.
Note that flashing James3’s EC firmware is required for all the functions of the custom ectool to work properly.
You can optionally build ectool.efi by installing the following additional packages. However, an already compiled version is in the ectool.efi/ectool folder of the FW-firmware-tools repo, so this step is unnecessary.
sudo dnf install libuuid-devel nasm
2 Likes
I’ve installed the new firmware and it’s working phenomenally. I was a bit worried because after flashing I sat at a black screen after rebooting (for a couple of minutes.)
All is good though.
I have looked at those CSV files.
The 60W uses an adp (Adapter or Charger) input current limit of 2700mA, that equates to about 52W. So, it will only ever try to take 52W from the 60W charger. I don’t know why that is not set at 60W.
The 100W uses an adp input current limit of 4800mA, that equates to about 88W. So, it will only ever try to take 88W from the 100W charger. Again, I don’t know why that is.
The EC firmware seems to choose this input current limit, purposely below what the charger can deliver.
When it hits this input current limit, it switches to also pull from the battery.
There are also spots where it tries to recharge the battery again.
So, one could conclude that this is all normal behavior.
I would have thought that setting the current limits to 100% of what the charger can do, and setting VsysMax = Battery Desired voltage would cause more of a power buffer, thus not dipping into the battery so much.
One can prevent it charging by setting the user_charge_limit = 0 with an EC command, but the EC Firmware might need a fix in that area, so that if it see user_charge_limit == 0, it never switches to a charge mode, and stays in PSU + Battery top-up mode.
The user can set “user_charge_limit = 10000” to allow charging again. 10000 just be some arbitrary figure that will always be too high, so will never trigger and allow the normal automatic battery controlled charge limits to apply.
As observed, there is a definite benefit in using a 100W charger on the FW13, so that it uses the battery less during normal operations as the 100W charger can absorb more of the current draw peaks from the CPU. The 100W csv shows one instance of the CPU drawing 4529mA, 87W so that triggers a battery discharge for a short time. So this proves the CPU can draw far more than the cpu budget of 54W, for very short instances.
The FW13 cannot use a charger more than 100W. If you use a 180W charger with the FW13, it will limit it to only ever use 100W of it (20V, 5A profile)
The CPU PMF settings could be adjusted by the user so that it never hits the adp input current limits at the expense of lower performance.
So, in conclusion, I think we understand the behavior of the CPU and EC firmware a lot better now.
1 Like
I assume some misunderstanding trying to do input over-current prochot that never happens. In the csv it never goes significantly above the set limit so the prochot never hits. I think I saw them turning off the input current limit in standalone mode so it might work there.
We probably need to play with the cpu power limits too it seems. These are a lot easier to tweak at runtime using ryzenadj though.
Pretty sure that’ll still help a bunch.
Having a balls to the wall and a “make due with the adabter” profile available would seem pretty reasonable. There is a lot going on in cpu_power.c that may benefit from a bit of tweaking.
Definitely