While reading a forum thread I came across the following power block diagram for the framework 16:
There is a INA236 reading current going through the +48V_VADP rail, but I couldn’t find any way to actually access that current reading from software. Could we please get a way to do that? (Or some pointers on how it’s currently doable)
From my understanding of the EC code it should be readable with sudo ectool i2cxfer 3 0x41 2, but that only produces Transfer failed with status=0x1 (EC_I2C_STATUS_NAK) for me.
You may know this already, but you should be able to read:
/sys/class/power_supply/BAT1/power_now
/sys/class/power_supply/BAT1/current_now
… to get microwatts and microamps flowing in/out of the battery respectively. IIRC I have that in waybar and it’s working.
That’s not really the same as what’s coming in from the charging cable, but it should be the more important number to be aware of (and when plugged in it should be pretty much equal to the charging cable input minus the system’s power drain which you can estimate). If there is a way to directly access the chracteristics of what’s coming in from the power cable I don’t know it unfortunately.
That’s a slightly different thing: That reading is what’s going in/out of the battery (at least that is my understanding, correct me if i’m wrong!). But I want to see how much power in total is being pulled from the charging brick.
Yeah, you are correct. I don’t know of a way to fetch what you’re looking for precisely. But I think that the charger power should be quite similar to (battery power numbers + laptop power consumption when measured when it’s not plugged in), just because there wouldn’t be any place for power from the charger to go other than into the battery or powering the laptop.
I checked just now while charging, and I don’t seem to have power_now (?). No idea why that is. But current_now is 3815000, 3.8A, and voltage_now is 16864000, 16V, so the battery is charging at 3.8*16 = 60.8 watts, and my system’s power consumption is 15-20W generally, so it would kind of line up for the charger to be giving 75-80W. Why that’s not 180W, I don’t know, but maybe it’s just the difference between the charger’s capacity and how fast the battery can actually practically charge.
I don’t think that’s the point, there is a current sensor they deliberately put into the device, op would like to get readings from that and I think that is pretty reasonable.
Yes, that’s exactly what I want. While a external meter may work there are a few reasons i’d prefer a internal variant:
Meters that are capable UB PD 3.1 are not super cheap (50€+shipping)
Based on the meter the e-ID tags in the cables can be unreadable (two usb cables chained isn’t a in-spec configuration and no tag means only 65w charging)
I don’t have to carry around an additional device and cable
It works for charging through the expansion shell
Meters may interfere with Thunderbolt etc. going over the same cable (be it by not connecting the high speed pairs or simply not handling such high frequencies)
It’s available with little hassle for everyone: No setup or external hardware needed
Has anyone checked if it is actually populated? It is possible they designed it in and then decided not to use it and maybe not even populate it on the board.
I would not be surprised if they intended to do power limiting based on that before just using the charge controller on the output and praying they added enough margins to their math XD.
I checked the open source firmware and at least from what I found there it should exist (at least the firmware polls it like every 10ms). According to my current understanding the EC logs live data to the debug serial. Maybe anyone here has a debug serial adapter and can look at the EC logs to verify that it exists? Otherwise i’ll probably build myself an adapter at some point.
I have a ccd but I don’t have a 16 (also don’t want one, laptops above 14" don’t even count to me XD). You can diy a ccd pretty easy or you can just hook an usb to serial adabter to the internal debug header.
Is the debug header populated by default? I don’t feel like soldering on the motherboard of a brand new fw16
Also (at least from looking at the images from thr website) I can’t even find any candidates for ocd headers.
Edit: I think I found the header: bottom right at the front, below memory channel 1 (on the ryzen 300 board). But 0.5mm pin pitch is a little too difficult for me (at least for a perfectly healthy board)
At least for me current drops to zero once the battery is full, which shouldn’t be possible if it’s measuring total charger current (as the system is still pulling power). I’m 99.9% certain what framework_tool shows is what the EC requested from the charger and what the sysfs shows is what the charger is actually currently doing (in this case drawing way less than requested because the battery is already in the CV charging phase). But that’s all just the battery, i’m interested in total system power
While a external meter may work there are a few reasons i’d prefer a internal variant:
Meters that are capable UB PD 3.1 are not super cheap (50€+shipping)
Based on the meter the e-ID tags in the cables can be unreadable (two usb cables chained isn’t a in-spec configuration and no tag means only 65w charging)
I don’t have to carry around an additional device and cable
It works for charging through the expansion shell
Meters may interfere with Thunderbolt etc. going over the same cable (be it by not connecting the high speed pairs or simply not handling such high frequencies)
It’s available with little hassle for everyone: No setup or external hardware needed
Edit: Also that thing is only rated for 30V, 240w pd is 48V
You already payed for the sensor, it’s not unreasonable for the information from it to be accessible, then again not even the data from the charge controller is available without jameses modded ec.
