[TRACKING] Test results for standby battery use of Expansion Cards

I reran the USB-A test with s2idle sleep:

root@angela:/home/anarcat# journalctl -b | grep charge_now | tail -2 ; date ;    rtcwake -m no -s 3600 && systemctl suspend ; date ;    sleep 10 ; date ;    /opt/batterylog/batterylog.py ;     journalctl -b | grep charge_now | tail -2
jan 25 14:36:34 angela systemd-sleep[26685]: /sys/class/power_supply/BAT1/charge_now                     =   3460 [mAh]
jan 25 15:36:34 angela systemd-sleep[26914]: /sys/class/power_supply/BAT1/charge_now                     =   3460 [mAh]
mer 25 jan 2023 15:52:07 EST
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup using /dev/rtc0 at Wed Jan 25 21:52:08 2023
mer 25 jan 2023 15:52:07 EST
mer 25 jan 2023 16:52:16 EST
Slept for 1.00 hours
Used 0.42 Wh, an average rate of 0.42 W
For your 53.28 Wh battery this is 0.78%/hr or 18.73%/day
jan 25 15:52:08 angela systemd-sleep[30145]: /sys/class/power_supply/BAT1/charge_now                     =   3175 [mAh]
jan 25 16:52:08 angela systemd-sleep[30435]: /sys/class/power_supply/BAT1/charge_now                     =   3148 [mAh]

It seems like the power usage is lower in s2idle with a USB-A module! In my earlier tests, I stuck with deep sleep, because previous results seem to show it had better power usage. My baseline tests also confirmed this, but I did not test with expansion cards plugged in. So it could very well be that s2idle is actually more efficient in the general usage case.

Doing the test again shows it’s reproducible:

root@angela:/home/anarcat# /opt/batterylog/batterylog.py ; journalctl -b | grep charge_now | tail -2
Slept for 2.25 hours
Used 0.75 Wh, an average rate of 0.34 W
For your 53.28 Wh battery this is 0.63%/hr or 15.14%/day
jan 25 16:53:26 angela systemd-sleep[31636]: /sys/class/power_supply/BAT1/charge_now                     =   3138 [mAh]
jan 25 19:08:09 angela systemd-sleep[31868]: /sys/class/power_supply/BAT1/charge_now                     =   3089 [mAh]

… in fact, this second test shows a lower wattage use, which is strange. But that test was done in rather exotic conditions: I was traveling home with the laptop, in a bag, in sub-zero temperatures, instead of just leaving it open on my desk… So to take with a grain of salt.

I find this surprising. @Matt_Hartley have you seen anything like this?

I’ll see if the behaviour changes for my general case as well (Ethernet + USB-C + USB-A), stay tuned!

This result about USB-A is indeed super confusing, since like the USB-C modules it’s not an active module?

Ah although perhaps answering my own question, further down that thread:


Well I have done my over night testing and came out with pretty much the same 0.35W on average.
Battery dropped from 55% to 50% in 7 hours and 45 minutes (or 7.75h in useful)
So calculating 5%*55Wh/7.75h=0.35W
This is on s2idle with 3 USB-C cards and without the USB-A card.

charge_now dropped from 1903mAh to 1750mAh → 153mAh used aka 19.7mA on average. Depending on what voltage you want to multiply this by (the voltage changes with temperature, load and state of charge) it does match 0.35W close enough if we assume it was stuck at 16V constantly, which is a reasonable approach. Might just read out energy next time.

Hope this is useful, can’t test DP or HDMI cards since I don’t have any. Could test with Ethernet card though.
So yeah conclusion the USB-A card does not make any measurable difference in my tests so far.

edit: Also should note I am using 2x8GB 3200MHz memory, whatever brand framework send with the laptop.

1 Like

That’s extremely useful results! It seems to mean that the problem with the USB-A device being polled for nothing happens only in deep sleep and not s2idle, which is extremely interesting to me. @Matt_Hartley maybe that’s something you could use?

I’m using a single 16GB stick. I’ve been meaning to compare the power usage with an extra 16GB stick as well…

This might be worth reading to you then

Still would be worth replicating

Oh wow, thanks! Looks like the idle performance is the same, which is what mostly matters to me… an extra 200mW seems like nothing: the thing is actually in use then.

Nah I’m good, I’d like to start actually using the damn thing now. :slight_smile:

1 Like

For my internal testing, we’re looking at 100% to 0% drain, time elapsed. Other teams are working with the data you’re pointing out to circle back to my own findings with 100% to 0% drain.

So this data matters and improving on it matters, but the customer focal point will be 100% to 0% drain elapsed time.

We’re looking at idle, common use and suspend.

I am not sure I understand… the tests I am doing here are about suspend, are you saying you are not seeing the same results in that deep and s2idle sleep behave the same for you with the USB-A module? Or another team is working on that specifically?

mAh, etc are being tracked, but not by me. However, in their existing state, my job is tracking 100% to 0% drain, time elapsed. We have others also looking at individual drain causes. So basically, it’s a split effort.

My goal is to have raw numbers for 100% to 0% drain, time elapsed. Not the usage, the time elapsed with a given setup that I am testing.

Your tests are far more detailed than what I personally am doing. Hopefully that makes more sense.


I’d love to be in touch with those folks too, but thanks for the clarification, makes sense!


I tested some standby power drain in s2idle with the ethernet card:
first test: 14% over 9 hours → 0.855W
second test: 7% over 4.5 hours → 0.855W

This was with 2 USB-C cards, 1 USB-A card and the ethernet card installed, Linux 6.1.8-200 on Fedora 37. USB Autosuspend disabled for the ethernet card (which also adds about 1.5W power draw in idle)
There was no cable attached to the ethernet card during these tests.

Note that we have a blog post today with more detail around modifications to Expansion Cards to reduce system power consumption: Framework | Getting ready to ship 13th Gen and announcing power saving

The firmware updaters for these are currently only available for Windows from our supplier unfortunately.


That’s great news! I was starting to not quite believe this would happen, but it sure seems you folks did an awesome job with that hardware. I’m also very impressed that there’s a guide to modify existing HDMI cards as well, that’s really nice, and the hack doesn’t seem that involved (just one jumper solder, basically, although it’s on that tiny board of course…)

That, unfortunately, is less great news. You said “currently”, does that mean this could eventually be available through other channels?

Thanks for the heads up! :slight_smile:

1 Like

That is something we would like to have, but don’t have the necessary commitment yet from suppliers. It seems like folks have been able to update through a Windows VM on Linux: DisplayPort Expansion Card firmware update to reduce system power consumption - #53 by jhenson


The post says:

Are you confident that this really happens only if they’re on the same side? I haven’t seen this mentioned in this thread here. (Or maybe that’s the case only on 13th gen?)

edit: Also, is there any news on USB-A cards?

1 Like

There’s one Thunderbolt retimer on each side, controlling 2 ports each, and those remaining active is what caused subsystems to stay powered. Therefore it being localized to the same side. The Type-A power draw issue is supposed to get fixed by bios updates.

1 Like

This should be fixed in the 13th gen and via firmware updates on previous gens:

I commented over there, but I couldn’t confirm such an improvement in my benchmarks.

As someone who has been half-reading this discussion as it developed, certainly not doing any testing myself, it would be very interesting to see this process and discoveries written up in a blog format. The tools used, methodology, etc. would an illuminating read. In combination with the recent blog post by frame.work which said,

To address every scenario, we have to go beyond the black boxes of CPU and retimer behavior that we have limited control over and modify the Expansion Cards instead. We found unexpected CPU and retimer behavior in which placing a HDMI or DisplayPort Expansion Card on the same side of the laptop as any card other than USB-C could keep subsystems powered, whether or not a display was connected. To solve this, we’ve modified these cards to now behave as if they are generic, non-display USB devices when no monitor is connected. This, in combination with our system firmware changes, allows full power saving behavior.

I think there is a lot of insight into ways to determine what closed-source personal computing hardware (low-level chips and buses) is doing without schematics, in the case of this thread, and how to work around it in the case of the blog post.