One of the things I’ve been working on is a way for blocking the dGPU vents for when more CPU cooling is needed and there dGPU is either not in use, or doesn’t need as much airflow. This is version 3 of my attempt at this, and it may be the final version. Their job is simple: block the dGPU vents when I want them to, and stay out of the way (but available) when I don’t. The blockers just slide on the guide track. This also allows full linear control for how much blockage is desired :D.
STL’s:
Note: I recommend printing in at least PETG for the added heat resistance.
supportBar.stl (684 Bytes)
gpuPlugV3.stl (3.0 KB)
gpuEndCapBeta.stl (6.9 KB)
For assembly, I super glued 2 of the support bars together lengthwise, and then glued them into the end caps. I may add adhesive under the support bars just to keep them from moving around too much, but it was designed specifically so that this would not be required. The whole system hooks into the cpu vent as a latching point and is strong enough to hold the weight of my entire FW 16 on that latch. To remove, just unlatch!
Admittedly… after overhauling my cooling solution, there’s really no need for this. I did it anyways.
4 Likes
Out of curiosity is there a reason you have what appears to be 3 small sections for each side rather than 1 large and one small? Was it just easier to print 3 of the same size?
Only reason is that 1 model was simpler than 2 in modeling. A single large one for the center sliders would work just as well. Good question 
1 Like
I’ve added a wedge airflow cover for the bottom vents now, check it out! I messed with many different versions, most of which used the CPU vent ports to hang the wedge from a clip like the dGPU vent blockers do… but this just proved to be kind of miserable in practice. So, I opted to cave and use an adhesive, in this case: Velcro. That approach was an immediate improvement, and looking at the Velcro material specs sheets suggests that the adhesive should be fine with the temperatures at play at the bottom surface of the laptop.
Was cutting out the holes for the bottom vents necessary? No.
Was it recommended? No.
Was it fun? Well, also no.
But does it just scratch an itch I had? YES.
wedge_beta4.stl (11.4 KB)
Here’s a pile of all the other prototypes I made before settling on the version above:
So, I did some rudimentary testing (played an hour of Overwatch) and noticed a couple things.
Temps: they didn’t really change. This is kind of expected though, as I wasn’t maxing out the fans before, so I’d guess the fans just continued to balance out at whatever point they like (for me, that’s around 65c on the GPU and 70c on the CPU).
Noise. On the Performance profile, there wasn’t much of a noticeable difference, at least not one that I can be confident in. But on the balanced profile, holy cow the impact was immediate. Playing Overwatch on balanced had the fans whisper quiet at what I would consider an idling noise level (assuming the fans aren’t off entirely). Only once I switched to Performance profile did the fans begin to sound like a gaming laptop’s fans. It’s possible even on performance they’re quieter, but I can’t say for sure. I don’t have strong data.
In theory, the power draw should also be lessened. Given that I’ve reduced the air resistance, the fans should need less power to move the same amount of air. I’m hoping that this translates into a reduction in the impact of the battery flipping issue under high load, but I’ll need more testing to validate that. Unfortunately, I don’t expect these power efficiency gains to affect battery life in practice, because my battery-operated workloads rarely turn the fans on to begin with anyways. Prior testing tells me though that before cutting out my bottom vents my fans drew 10W total (they’re rated for 12W). I’m not sure if that 2W delta is a result of my removal of the top vent cover or not.
Update. Using framework-control I was able to run a simple test to check if there’s any power savings from opening the bottom ports. It looks like removing that air-restriction dropped my fan’s max-power usage by about 2.25W. If the battery is being drained at a rate of 10W during heavy load, then this translates into an up-to +20% time-delay before the battery flipping issue occurs (in theory) and ever so slightly increases the window within which the battery draw is not needed to begin with. So… I’ll call that a win.
