I have noticed the same thing with my FW16 I thought I was the only one. When I type there’s a rare chance that all of the input modules go dark briefly and turn back on. I can never recreate it though. At least intentionally.
Yeah the torx driver arrived on Saturday and I removed the battery straight away. Laptop itself is intact and touchpad and everything is working fine. Replacement battery on the way ![]()
Glad that you seem not to have encountered additional issues. Hopefully all is well when you get the new battery. Was it replaced under warranty?
What will happen if you discharge the battery to 30% then store it in a fridge for a day or two.
Storing in the fridge is good (reduces internal pressure and speed of chemical reactions, i.e. dendrite growth).
Further discharging is not - it may result in additional internal short-circuits, outgassing and fire.
The battery is being shipped under warranty, really happy with Framework so far. Just need to wait for shipping + delivery now, might take another week. I love how light my framework is, just missing working from the terrace ![]()
Glad to hear that it was covered, thanks for the update. Have a good evening!
Any updates on the outcome of the meeting?
Just wanted to chime-in that this exact issue is what prompted me to work on coreboot in the first place. Whether it be flexing lid or whatever, system wakes up in the bag because I2C3 where touchpad is connected to is configured as SCI (meaning it can wake the system up).
I don’t understand why firmware vendors configure it this way as there’s no use-case for it (you can use lid state as wake-up, slam the spacebar or just… press the power button to do so).
Framework folks are reading this, so I would recommend reaching out to InsydeH2O and telling them to disable I2C SCI, that would fix random wake-ups people are experiencing.
Hey! I took your feedback to them. They’ll do some testing and see what they can do. Nothing further yet. Things have been extremely busy the last few weeks, as Im sure you can probably tell. Its still on the radar though. ![]()
Hmm, I wonder if that’s why mine wakes when i pick it up by the corner…
Thank you so much for taking the time to look into our problems and for taking feedback. Also, thank you so much for addressing every community concern and constantly improving your product!
you can still activate the deep sleep option on your windowns throught the old settings panel from win 7.
sadly that’s only for you to activate each time(you have to go windown/power off/deepsleep), not simply clossing the lid.
It is usefull to know in some circles, as for exemple, my work laptop is running so many companie mandated software on it’s weak cpu, that it is always out of battery and the temperature of a star.
i am not allowed to leave it pluged in throught the night for tidyness reasons, (and yes the fans go wild every 30s while it is idling, so it would bother people who work late.
Deep sleep is the only way to have my station ready in the morning without waiting more then 1 standard coffee time for it to get ready. i hate windows and that POS laptop.
I found an interesting blog a while ago. The problem with modern standby is that Windows detects you are away from keyboard so it runs background bloatware at full tilt, this happens even when you are idling, not just on standby. It’s called “away mode” and can be disabled.
Hey @Arcadiy_Ivanov1 Just following up here. I have provided the feedback on this to our Engineering and product teams. They are currently discussing this as a possibility.
Epic! Thank you!!
Is there a way to detect when the air vents are blocked, or otherwise, the cooling system is not working?
If the EC could detect that a laptop is in a bag, it could force it to suspend or power off.
I think this could be achieved by putting two temp sensors, one each end of the heat pipe. The end near the fans should always be cooler than the end near the cpu. Thus detecting if the cooling system has failed.
If both ends are similar temps, the cooling system has failed and the EC should switch off.
Another possibility might be fan feedback. If the fan is struggling to push air around because it is in a bag, that might work also to detect if the laptop is in a bag or not.
The CPU has its own throttling and the next threat to device health is battery overheating. The battery has its own BMS that monitors the cell temperature and tells the EC. The current problem is the battery overheat protection triggers too late. From your earlier finding the EC stop charging the battery at 55C, which is too high, the discharge overheat protection probably kicks in even later. I’m not really sure that it’s the EC’s fault, it could also be the BMS calibration error. Regardless, the EC could be programmed to force shutdown (similar to holding down the power button) when the battery temperature exceeds 60C by reading the BMS data, even if the BMS itself doesn’t send “overheating” signal yet
With the laptop in bag, the fan does nothing and the CPU, working at constant 100C will heat up the other components like any other heat source. The SSD can be damaged by overheating but it happens at a higher temperature than the battery. The fan feedback isn’t accurate because when the exhaust is blocked the fan will slow down but if the intake is blocked the fan will speed up. The two temp sensors add cost so it’s better to use existing sensors such as those on the battery(signal relayed by the BMS).
I think another use case for the temp sensor on the heat pipe could be to measure how efficient the heatpipe and fan actually are.
Various people have experimented with different thermal compound and sandwich.
It would have been good to have a temp sensor on the heat pipe to see how much quicker the heat was removed from the cpu.
Different users could then compare their laptops, and possibly detect failing heat pipes.
The normal cause for failing heat pipes is:
- thermal compound between cpu and heat sink degraded.
- fans not working.
- laptop in bag while switched on.
I guess i am just trying to make the point that it would be useful to have, for fault diagnosis reasons.
Much like, if the ec also had voltage sensors for all the power rails. A repair enginneer would know immediately where to look for a short. At the moment, all the EC knows, is the cpu failed to start up. I think laptops should become more like cars, that tell the engineer which the faulty part is.
Another approach, but I not sure I would risk trying it.
Set on Linux running on the FW16 laptop. Set it to stay awake with the lid closed.
ssh to it via wifi and sit there monitoring the temps with “sensors” or similar. Record the values, so one can graph them later.
Put the laptop in a bag, and see what the temps do.
See if there is some pattern that could be used to detect the “laptop in a bag” scenario, and thus force a power off or force it back to suspend.
Hopefully one could then program the OS, ACPI or the EC to detect the pattern and take safety action.
At a guess, it might be:
- Temp triggers the EC to set PROCHOT.
- EC expects the temps to then drop, but as in bag, the temps do not drop.
- EC could then decide to force power off.