I think an alternate solution is to make all laptops to use DC5525 barrel input and use only one bench power supply (GaN preferable to reduce size) to charge any of them, just adjust the voltage and current output, plug in and enable output.
@Charlie_6
What do you mean by âmore heatâ. How are you measuring that? In theory a barrel jack goes through a similar amount of DC-DC steps as a usb-c.
I think the problem with FL13 is the laptop draws peak even when battery is draining. If the instantaneous power draw exceeds PD input power it should dip into battery and caps the input current to max(not 90% max). However, even when battery is used for supplementary power, you still cannot use 100% PD without studdering.
The computer is hotter and fan speed is higher when powered by USB-C, compared to powered by barrel
Thatâs not going to happen, but on the bright side pd is evolving and stuff like direct 48+v charge controllers and vrms and stuff are in the pipeline (mostly for datacenter but itâll trickle down eventually) so this stuff for high power is going to get better.
That bit is going to need a bit of investigation.
Given modern boosting algos you would need to keep a lot of variables the same to attribude that to the power system and not the ec just picking more aggressive boosting values with different inputs.
The interesting problem here is that the actual current draw is very spiky. The usb-c psu actually shuts off if the peak current is too high. So itâs a race to get the battery in the loop before the psu notices the peak.
Thus the charger chip needs to detect the peak earlier, say at 85%, giving it time to add the battery in.
Various solutions might be the VRMs etc. in the laptop being larger, and thus Smoothing the peaks a bit before they reach the psu, or just make a psu that can accept higher peaks. I.e. a 100W psu vs a 60W psu.
I guess a test that still needs to be done.
- what is the absolute max instantaneous peak current a FW13 can draw?
- what is the absolute max peak current a FW16 with dGPU can draw.
Then choose a psu to be greater than those maxes, and one will have no battery flipping.
Unfortunately, I suspect those maxes are greater than 100W for the FW13 and greater than 240W for the FW16, thus larger than the charger hardware can handle for each laptop.
Mini calcs:
- FW13 peak 80W + battery charge 61W = 141W
- FW16 peak 220W + battery charge 85W = 305W.
I have a USB-C power meter and during my testing the charger was always supplying 20V, the voltage remained stable even when the current reading went all over the place
Do you have actual numbers for the heat.
I.e. measured input watts vs heat with barrel vs usb-c. Ideally with the same input watts in both cases. My guess is that the hotter case will actually be running more watts and thus the cpu running faster.
The controll loop runs in 400us windows, and at least judging by the 60w csv file provided above reacts pretty quickly overshooting the current limit by tens of ma at mosts so and 10 or 15% threshold is very extreme. Especially since according to the linked xmg blog post even pd supplies can supply more than their rated capacity for 90+ms which is much longer than than the charge controller needs to react according to the csv.
Or adjust the power limits I suppose.
Yeah if it ocpd and renegged that would have been pretty obvious. Would be interresting if you could do a csv recoding using jameses ectool
If this happens again you $ sudo ectool battery immediately and capture the Desired voltage and Desired Current. It appears to be battery entered constant voltage then back into constant current again
Do I need to flash the EC?
Pretty sure yeah, so that may not be practical. Pretty much the best data we were able to get so far though.
Seeing that procot bit get set would answer the flaky performance quiestion pretty quickly. Itâs not something you would likely see with spot checks a the charge controller releases prochot pretty fast (the longest configurable hold after the over current condition cleared is 20ms).
So I did a quick little science experiment, I took a 20W power bank and charger as well as 100W ones and checked on my electronic load how far above the negotiated values ocp kicks in:
- Both 100W did 5.5A (0.5A above negotiated) for at least minutes
- Both 20W did 2A (0.33A above negotiated) for at least minutes
- All of them had voltage droop before ocp
This of course doesnât account for entirely craptastic chargers but at least with semi decent ones (apart from the 100W power bank this wasnât fancy stuff) setting the limit to 100% should not be a problem in this aspect. Of course the input current prochot needs to be raised above the limit (or disabled with available battery).
@Adrian_Joachim
5.5A (0.5 above negotiated) is only 10% more than listed.
Indeed, according to the csv the charge controller has much tighter than 10% control on the input current though. And that 10% over was sustained for minutes not microseconds.
More importantly it is more than 128ma which is the resolution of the input current prochot setting (both for 100W and 20W), so setting that to negotiated(rounded up to the next 128) + 128 should still be fine (at least for a good charger). There is still the option to make a âshitty chargerâ mode that does the -10% thing if that turns out to be necessary.
I am also pretty curious how high I can go with the 2 level max current thing on some of my chargers.
Anyway the parts for my ccd should show up shortly so I can do some real world testing soon.
I guess you can try exceeding the psu input current limits with:
To read it:
ectool chargestate param 2
To write it:
ectool chargestate param 2 <value_in_mA>
I guess the worst that can happen in it breaks/fries the charger, or the laptop crashes due to lack of power.
You donât need the EC CCD for that.
That is what charlie did but you will run into the prochot thing then. Youâd need to change both the current limit and the over current prochot limit (or just disable that one when a battery is available).
If that manages to break the charger, good then the charger was faulty, at worst with a spec compliant charger it should ocp if it doesnât like whatâs going on. My 100W pd charger has done like 20+h of continuous 100W charging a 2.5kWh power bank and didnât break a sweat, I am fairly sure it can survive some blips to 101 from a laptop XD.
I donât but I am not going to start messing with this stuff without the insight a ccd provides.
I agree, the EC CCD does help a lot. You can see what the EC is up to even during a power off or reboot of the laptop.
1 Like
For the FW13 specifically, I want to make sure I am understanding the findings so far.
- The FW13 supports chargers up to 100W. Plugging in any charger larger than that will only utilize max 100W of power.
- While the charger circuit can utilize the full PSU voltage, the PSU current is derated to 90% of the full current by the EC firmware. This can be seen by looking at the output of the AdapterCurrentLimit1 (0x3F) register on the ISL2941.
- Because of the current limit, the ADP power is limited to max 54W with a 60W charger and 90W with a 100W charger.
- The ADP voltage is reduced to the SYS voltage by the charger circuit, up to VsysMax. The EC logic sets VsysMax at the current battery voltage + some offset.
- The SYS voltage is further reduced to whatever lower voltages are required by the laptop components.
- When the combined power draw of the laptop components exceeds the power made available from the charger (54W/90W), the charger circuit discharges the battery to make up the power deficit.
Assuming this is all correct, is the goal now to find what changes reduce how often the system flips between using adapter and adapter + battery power?
Is there still an issue with the battery being charged immediately after discharging, or has that problem been resolved? The 3.09 firmware changelog said something about a 5% charge level float range, which was presumably meant to prevent immediate charging after a CPU spike + battery discharge.
Not sure if itâs been verified that the official change is working as intended, though.
Yes
Also yes
A bit less than that due to voltage drop but around that. The current version sets 90% of the negotiated current limit.
Looks like it yeah
Mostly, I think the display backlight may use it directly but since we donât have actual schematics it is hard to definitely tell.
Jup
The goal of this thread yeah. As far as I can tell from the code dipping into the battery is intended.
Not sure about that but blocking charging is the easiest bit here, just turn off bgate XD