Still no news, eh? Disappointing.
I’m wondering if they can fix this in the firmware. Typically systems have a BIOS option for whether or not to provide power to USB devices in sleep mode. This would be a blunt instrument, but I’d be happy enabling this as I never charge devices off my laptop in sleep mode. And/or more advanced firmware that knows which USB devices (e.g. active expansion cards) should not get power in sleep mode, if that’s possible.
A lower tech idea could be a hardware switch on the expansion cards themselves to disconnect them, a.la the webcam and microphone switches. Or hardware pressure switches inside the ports so they physically disconnect from the laptop when there’s no cable attached.
Just spitballing ideas here since my current solution is yanking the HDMI and USB-A cards when I need the battery to last
Has there seriously been no communication on this issue in the past several months? Just got my framework the other day but the sleep issue is a major problem for me. I really don’t want to have to return the damn thing.
Windows 10 or 11? and where did you change the hibernation threshold?
For those not familiar with dealing with Windows inner workings, if you input this command in a CMD window:
powercfg /setdcvalueindex scheme_current sub_presence standbybudgetpercent ##
where the ‘##’ is replaced by the percentage you would like to use, you can change the threshold yourself. The default value is 5 for 5%. I get about 2 hours of standby time with s0 with the default 5%. Increasing this threshold to 10% would give me close to 4 hours.
Anyone know how to expose the current value of standbybudgetpercent?
I set mine to 25% and I’d like to just see that the setting took.
Hmm, the power scheme I’m using must not be standard, because I don’t have that GUID entry. (and my system had only one power scheme on it)
However, through my own testing I can confirm that the change worked, because I just woke the laptop from standby after 4 hours, and 7% had drained. I think this sort of thing is great. This is enough for me.
I mean I would like to see an improvement in the power efficiency of standby, but it is just nice being able to sleep the Framework laptop for 12+ hours and not need to rely on hibernation.
When I close the lid, the computer should sleep.
More to the point, when I press the freaking sleep button (power button configured to sleep, or start/power/sleep), it should go to sleep.
Any other laptop I’ve ever owned, this is what it does.
Framework doesn’t. It just blanks the screen and locks the desktop. It’s still consuming power (5-20 watts). It instantly wakes up if I as much as breathe on it, cheerily as if “this is what you want, right?”. No! I want it to be asleep… consuming 1-2 watts… able to stay like that for multiple days on battery at a time.
Instead, if I close it and leave it overnight, the thing goes to hibernate instead… fully powered off, going through POST (5-10 seconds) and reload (2-3 seconds) before login screen. Great, that’s fast for what it’s doing (not sleep as I requested)… slow for what I asked it to do (not what it did). Windows 11 completely hides the fact that it goes to hibernate (there’s no hibernate timer in power options, but at least Windows 10 admits it’s real).
I’ve heard some murmuring that “that’s just how it is now”, and in effect, “it just stays on all the time, and sleep is dead”. The hell kind of funhouse-mirror world is that? Up is down, more power consumption is new?
Please, god, tell me there’s some simple setting I’m missing…
yup. In fact, I did it as the “0th thing I did”. Specifically, Windows 10 Framework Laptop Driver Bundle 12_16_21. All successful. No missing drivers. But there is, still, no driver for the audio device
Unusual for an OEM to rely on the generic HDA driver, but I also didn’t see one getting installed by the installer.
Yup. Modern Standby/s0ix is here to stay, gl with hibernation.
I think you might be mistaking what I’m reporting… I’m basically reporting that “modern standby is a thing that exists”. At the moment it seems like “modern standby” is just software/hardware devs throwing their hands in the air and saying “standby is too hard to program for, so f*ck it, let’s just delete standby”.
Running “powercfg /a”, I get the same thing @feesh reported:
Which basically says the system firmware doesn’t support real standby, it only supports fake sleep.
And my buyer’s remorse continues to build.
Thank god I found a solution, now that I know what to search for (that “this is just your life now, you get to live with excessive sleep power consumption”):
https://www.reddit.com/r/Dell/comments/h0r56s/getting_back_s3_sleep_and_disabling_modern/
Hooray, we can still get real sleep back. I added this one registry entry (dword HKLM\System\CurrentControlSet\Control\Power\PlatformAoAcOverride = 0), rebooted, and et voila. Real sleep (4 watts = topping off battery).
“mW per hour” isn’t a unit… perhaps you mean “mWh per hour”? And in that case, 300mWh/hr = “300mW” or 0.3w. Which I really, deeply, desperately doubt (wattage is an instantaneous measurement, thought of like “MPH”; watt-hours is a measure of consumption over time, thought of like “miles” - see how “MPH per hour” doesn’t make sense?)
All my electronics (except the car) are charged from one of two power banks that I charge from solar juice every day. They both have wattage meters - an Omni 20+ and a Storm2 power bank. I’m only using the OmniCharge so far But it shows real-time wattage… and real-time anxiety when I can’t get the computer to stop chomping down wattage.
Just an FYI I tried this and it was very buggy. Resuming also took much longer than hibernation.
Dunno. In my brief test (close lid… 40-50w for some seconds… then boop to 4w like a rock), it took some moments to wake up, but by the time the lock screen finally appeared, it was about the same time I sit there waiting for hibernate-resume to clear POST and turn the display on. Saves several seconds at least, and tons of SSD wear over time.
Hmm, maybe I’ll give it another try then.
I’ll also at least concede that I’ve only tried it ONCE so far and anything sleep-related is highly random. So, a series of dumpster fires may be in store.
How have we come this far from the relatively well-oiled machines of 2017? Man, I want my Latitude 5580 back so bad right now. (USB-C fried it by sending 20v in while it had briefly switched to 5v output during a brownout. Literal smoke escaped. It made me quite sad, but it was the catalyst for buying a Framework…)
Trying this again and it’s still super buggy for me. Putting it to sleep sometimes takes 40 seconds…
Resuming is also buggy. Sometimes after resuming, the login screen flashes briefly after 12 seconds, then the screen stays black and won’t respond to any inputs.
It also seems to have broken hibernation for me. When I try to hibernate, it will black-screen for a bit, then wake itself back up.
This does work, but if you update system components via windows update it can make this buggy and faulty again. You would have to remove the registry key, reboot, then add the key back and reboot.
I just left s0 active and increased the battery drain threshold before hibernation is active. To me I am getting around the same battery drain, BUT the system resumes immediately, and will never drain dead thanks to hibernation.
Now one thing I would recommend you do if you decide to go that route is that you make s0, network disconnected instead of network connected. That will save you much more power in standby.
One other thing I wanted to mention is that Framework can’t really be blamed for s0. That is an Intel and Microsoft branded issue.
Also tried this back in September and noticed no difference:
https://community.frame.work/t/high-battery-drain-during-suspend-windows-edition/4421/91
https://community.frame.work/t/high-battery-drain-during-suspend-windows-edition/4421/93
Yeah, I didn’t use a watt meter or anything like that. It is just my observations. I noticed when using s3 with Windows that I was seeing about 3-5% battery drain an hour. On s0 this varies as well in about the exact same percentages. (2-5% per hour)
In my mind, a scenario where we have higher standby power drain regardless of the sleep state, it made more sense to use s0, as the hardware was designed for it, and just tweak the battery drain threshold to make it work more like standard s3.
I consider it a temp work around, but one that is predictable and reliable.