OMG Framework 13 7640U power converters are lossy! It is all good when the PSU can provide 20V 3A, but at 2.1A PSU it becomes uglier, and overall at low load the current consumption is funky (see all those spikes on the photo, they go up to 2.8A) despite the laptop only taking 12W (according to the battery discharge rate report) (6W by RAPL, i think it shouldn’t consume that much, perhaps i didn’t toggle some knobs in Linux idk, but it doesn’t matter now) while ~idling.
And 39W (of them the processor takes only 28W according to the package RAPL report) at full CPU load while getting 39W from a 45W IKEA PSU and additionally discharging the battery at 6W. That makes 87% efficiency plug-to-battery and about 74% plug-to-CPU at best (assuming 100% efficiency during idling, the remaining 6W being consumed by static things like LCD, wifi, RAM refreshes, all them LEDs, EC, my USB hub, mouse, this USB power meter thing and so on). This is quite sad given the near-99% state of the art step-down converters’ efficiency and the fact you can’t just swap the battery and have to use those USB PD power banks with additional double conversion losses.
Mayhaps i’m missing something in the battery-to-CPU side, like sysbench cpu increasing RAM energy consumption a lot; not sure what could be the problem in case of the power input though, would be glad to be corrected.
One thing to keep in mind is the readings from the battery are extremely averaged and the load from the apu is extremely spiky especially at low load (and with the default ec that lets the thing pull ridiculously high peak power). The stock ec also limits the input current to 90% of what was negotiated. Then there is the jumping around vsys voltage that causes small dips into battery and likely makes the input current also look quite jumpy.
There are also some invisible settings that seem to make pretty much everything use a bit more power when plugged in. And some half hidden ones like the peak power and the normal power limits.
There is also somewhat unrelated power like the bit over 2W the fan can pull at full tilt and ddr5 pulls a lot more power under load than at idle so you can’t really go with apu package power = input power. The screen may also be brighter when plugged into a power supply.
99% takes some really narrow circumstances even for the fanciest modern stuff.
The pd input to vsys buck-boost converter is a pretty fancy one, the bigger losses are likely in the vrms.
I do think it is kind of a shame that the pd protocol does not include a “battery” marker so the device can treat a powerbank like it was on battery and not go into “wall power leeroy jenkins”-mode but that is unfortunately not a thing.
The sink just needs to request this info, if it cares (and the source supports giving the answers. Don’t know how prevalent).
There even are modes to use the original battery voltage unregulated as output to not regulate voltage on both sides…
The source can even initiate notifying of some important changes:
Now here I am making an ass out of myself asuming it isn’t part of the spec cause (afaik) noone uses it XD. Great catch.
Well this just makes me even more sad that we don’t have better access to the pd controller.
Do you know if power-banks actually implement this? Being able to detect battery vs mains is already big but being able to read the state of charge would be even cooler.
That would be a slight efficiency increase at the cost of peak power but may be worth it for powerbanks.
I really gotta dig up that software pd sink thing again, I kinda dismissed it cause it can’t do source but it could probably be used to see if any of my powerbanks report those fields.
I have no idea how much this is used. I only have one pretty stupid USB-C power bank. Digging it out to trace right now. I even missed the much simpler “unconstrained power” bit in the PDOs.
I’d bet that the official Dell notebook power bank uses the whole assortment to communicate its charge state, so the notebook can use it like the old proprietary Dell power banks.
But given that the Framework seems to be one of the few notebooks that even likes to renegotiate power effectively I fear even less devices will care for the answers, even if power banks would give it (technically, my brand new HP work laptop does not ignore the power supply notifying of having less power available, so that the power supply resets the connection entirely. But it just reacts by stopping any power draw immediately, which results in letting the system switch to battery-only momentarily, just as dumber devices cause by ignoring the power supplies message. Of my notebooks, only the FW’s react to those changes seamlessly… Same with fast role switch (replacing the power supply of a USB-C hub so quickly, that the hub does not brown out when its external power supply is suddenly unplugged).
Edit: Well, my Nilkin Qi-Charging power bank sure does not.
Ha, the FW actually is desperately sending out Battery Status Change event Alerts for “Fixed Battery 1” to my HP notebook. But its not asking for any of the advanced info about the battery state. FW also reports the power as “constrained”. But also, while FW is sending alerts out seemingly in response to find another power supply, it does not update its bit to “unconstrained power” after that…
Reading the spec there is kinda sounds to me like bit 0 determines if there is a supply at all, bit 1 says if the supply can run out and bit 2 if it is specifically a battery. 110 is likely the default for ac power supplies and the people making the powerbank chipsets didn’t bother to mess with it. I do have a selection of different powerbank boards with different chipsets, hopefully one of them has the proper battery protocol implementation.
I am suspecting dell probably does something a bit weirder with their powerbank pd stuff. Would not be surprised if they had their own proprietary messages to do stuff like this and the neat but cursed dual usp-c power and data thing they do with their docks.
Quite frankly I assume that to be the case for most powerbanks unless data to the contrary is presented.
How do you record pd currently?
I don’t think I have seen anything related to that in the ec code, that’s likely in the black-box pd controller firmware. you just c to c connected the fw and the hp?
So the fw is powering the hp there?
After you plug a power supply into the fw? Same side or different side? I could imagine it working same side because those are on the same pd controller but different side would have to get info through the ec.
And yes, I just connected both of them. FW reliably charges the HP, telling it “constrained power” (HP does not ask for details, keeps on drawing, even with a practically full battery). FW forgets to revise that bit once it has a backing power supply.
When the HP is charging, 1 out of 3 times I got it to charge the FW. Then it lists unconstrained power and promptly sends alerts the exact moment it looses its power supply. I have to use my phone to get the HP to output power, then it actually lists constrained power, so that bit mirrors whether it has a power supply attached or not.
But the phone just responds to the alert with “not supported” and also does not ask for details…
Yes. FW Strix Point just permanently says “constrained power”, no matter what. None of my devices use the Extended Capabilities with the more detailed bits. But given that FW sends out alerts listing a specific battery, I would presume it would give the extended capabilities, as that is where the battery IDs are defined in the first place…
Different. That is actually a point. I’ll retest.
Edit: Nope. Always constrained, no matter if the power supply is on the same side as the consumer. And it takes a few seconds until the alert from plugging in a power supply.
They only seem to give “CPU power consumption”. Which would be way lower than the total system power consumption you would read from the battery.
1.6W for a truly idle CPU is actually rather high.
