Acer Aspire fan control — unlocking the hidden Nitro turbo fan mode
TL;DR: The Acer Aspire A515-57 — a non-gaming laptop — ships with the Nitro/Predator gaming fan control fully functional in its firmware. Acer just doesn't expose it in any UI. You can turn the CPU fan to turbo, or pin it to 100%, with two WMI calls and no third-party software.
Verified working on Acer Aspire A515-57, i5-12450H, BIOS V1.33, Windows 11.
Search the web for fan control on an Aspire and you get dead ends. The consistent claim is that fan control is a Nitro/Predator feature.
That claim is wrong, at least for this model.
We went looking before we went measuring. What the obvious searches return:
- "Acer Aspire A515-57 fan control" → eBay listings for replacement fans, and cooling pads. The hardware, not the software.
- "NBFC config for Aspire 5" → a string of community threads asking for a config file, going back years, none of them answered. The NBFC issue tracker has requests for various A515 models that were never resolved. There is still no NBFC config for this laptop, and this repo did not need one.
- "AcerGamingFunction WMI Aspire" → results about Nitro and Predator laptops, plus the reasonable-sounding conclusion that the gaming WMI methods are only on gaming models. That conclusion is what stops people.
- Acer's own support pages and AcerSense → three performance modes behind
Fn+F, with no mention that a turbo fan mode exists underneath.
So the search results actively point away from the answer. They do not say "undocumented"; they say "not available on your machine", which is worse, because it sounds like a settled question.
Two things had to come together:
1. The protocol was never secret — it was just filed somewhere else. The bit
layout is sitting in plain #defines inside the Linux kernel driver
drivers/platform/x86/acer-wmi.c,
reverse-engineered by the Linux community for gaming models. Nobody debugging a
throttling Windows laptop thinks to read kernel source for a driver they are not
running. That is the whole trick: the answer was in a different discipline's
filing cabinet.
2. The part that was genuinely undocumented had to be measured. Nothing anywhere said whether a non-gaming Aspire's firmware would answer those calls. We found out by calling them and reading the result back. It does.
Then the protocol still had to be beaten into working — see the four gotchas below, each of which produced an error message that pointed at the wrong cause.
Before anything else, run this in an elevated PowerShell. It writes nothing.
Get-CimInstance -Namespace root\wmi -ClassName AcerGamingFunctionIf you get an instance back (ACPI\PNP0C14\APGe_0 or similar), your firmware
exposes the interface and it is worth continuing. If you get Access denied,
you are not elevated — the Acer WMI provider refuses even reads. If you get
nothing at all, this repo will not help you.
Reports from other models are welcome in the issues, positive or negative.
Only the A515-57 has been tested. Related machines that share the same chassis and fan assembly — the A515-57G, A515-56, A515-54, A515-43, A517-53G, and other Aspire 5 variants — are plausible candidates and completely unverified. If the command above returns an instance on yours, please open an issue saying which model and whether the setters took effect. That is how this list grows.
Everything needs an elevated PowerShell — the Acer WMI provider denies even reads without elevation.
powershell -NoProfile -ExecutionPolicy Bypass -File .\cooler.ps1 status
powershell -NoProfile -ExecutionPolicy Bypass -File .\cooler.ps1 turbo
powershell -NoProfile -ExecutionPolicy Bypass -File .\cooler.ps1 max
powershell -NoProfile -ExecutionPolicy Bypass -File .\cooler.ps1 auto
The icon colour is the mode, and hovering tells you which one without opening anything. Above: firmware turbo (orange), selected and confirmed against the hardware.
powershell -NoProfile -ExecutionPolicy Bypass -File .\cooler-tray.ps1 -InstalarInstalls a scheduled task that starts a tray icon at logon, already elevated, so you never see a UAC prompt.
| Left click | toggle on ↔ auto |
Ctrl+Alt+F |
same, from any application |
| Right click | pick mode explicitly |
| 🟢 green | on — CPU pinned 100%, GPU channel turbo |
| 🟠 orange | firmware turbo mode |
| ⚪ grey | automatic (Acer's stock curve) |
| 🔴 red | hardware is not in the requested state |
The icon does not cache a flag in a file. It polls GetGamingFanBehavior once
per second and compares against what you asked for. If the mode drifted, it
silently re-applies. If re-applying still doesn't take, it turns red and shows
the actual modes in the tooltip. The green light is therefore a claim about the
hardware, not about the script's intent.
Be clear about what that one-second loop is doing, though. On our machine the mode can revert on its own after a couple of seconds (see Known issue), so the loop is racing whatever is undoing it. Between a revert and the next re-apply the fan is not in the mode you asked for, for up to a second at a time. That is a duty cycle, not a solid state, and the icon cannot show it at that resolution.
In Automatico the tray writes nothing at all — it only reads. Automatic is the
absence of a command, so imposing it every cycle would stomp on anything set
from outside, including Acer's own Fn+F hotkey. An earlier version did exactly
that, and it silently invalidated several of our own measurements.
-Desinstalar removes the scheduled task.
WMI class AcerGamingFunction in namespace root\wmi
(instance ACPI\PNP0C14\APGe_0, GUID 7A4DDFE7-5B5D-40B4-8595-4408E0CC7F56).
| bits | meaning |
|---|---|
| 0–15 | fan bitmap — CPU = bit 0 (0x1), GPU = bit 3 (0x8) |
| 16–17 | CPU fan mode |
| 22–23 | GPU fan mode |
Modes: 1 = AUTO, 2 = TURBO, 3 = CUSTOM.
Input is the fan bitmap you're asking about.
| bits | meaning |
|---|---|
| 0–7 | status — 0 means OK |
| 8–9 | current CPU fan mode |
| 14–15 | current GPU fan mode |
| bits | meaning |
|---|---|
| 0–7 | fan id |
| 8–15 | speed, 0–100 |
| intent | value |
|---|---|
| CPU + GPU turbo | 0x820009 |
| CPU + GPU auto | 0x410009 |
| CPU custom | 0x30001 |
| CPU fan (id 1) at 100% | 0x6401 |
These are the reason this repo is worth more than the bit table above.
1. The setters only work as instance methods.
Calling SetGamingFanBehavior statically returns Invalid method parameter(s),
which reads like a bad payload and sends you off tuning bits for nothing.
# WRONG — fails with "Invalid method parameter(s)"
Invoke-CimMethod -Namespace root\wmi -ClassName AcerGamingFunction `
-MethodName SetGamingFanBehavior -Arguments @{gmInput=[uint64]0x20001}
# RIGHT
$i = Get-CimInstance -Namespace root\wmi -ClassName AcerGamingFunction
Invoke-CimMethod -InputObject $i -MethodName SetGamingFanBehavior `
-Arguments @{gmInput=[uint64]0x20001}The getters tolerate the static form. The setters do not.
2. The getter needs a fan bitmap as input.
Passing gmInput = 0 returns status 2 — an error — which is easy to misread
as "the machine has no fan control".
3. The CPU fan is id 1, not 0.
SetGamingFanSpeed with fan id 0 returns gmOutput = 1 (failure). Id 1
returns 0.
4. Order matters when combining CUSTOM with the GPU channel.
0x30001 has a CPU-only bitmap, so it changes the CPU and leaves the GPU
channel untouched. To get maximum airflow you must set both to turbo first, then
demote only the CPU to custom:
Set 0x820009 # both channels -> TURBO
Set 0x30001 # CPU -> CUSTOM; GPU stays in the inherited TURBO
SetSpeed 0x6401 # CPU fan -> 100%Skipping the first line leaves the GPU channel on the stock curve, and the result is audibly weaker. We found this by ear, then confirmed it by reading both mode fields instead of just the CPU one.
Independent of any of the above, Windows has a System cooling policy setting that is hidden from the power options UI by default. On Passive it drops the CPU clock before speeding the fan up; on Active it does the opposite.
$SUB='54533251-82be-4824-96c1-47b60b740d00'; $COOL='94d3a615-a899-4ac5-ae2b-e4d8f634367f'
powercfg -attributes $SUB $COOL -ATTRIB_HIDE # unhide it
powercfg /setacvalueindex SCHEME_CURRENT $SUB $COOL 1 # 1 = Active, 0 = Passive
powercfg /setdcvalueindex SCHEME_CURRENT $SUB $COOL 1
powercfg /setactive SCHEME_CURRENTBoth installers in this repo apply this for you.
On the development machine, a mode set through WMI is sometimes reverted after roughly two seconds. The write returns success, a read-back immediately after confirms the new mode, and then it silently falls back.
We have not found the cause. Candidates we have not yet ruled out:
- an Acer background service reasserting its own policy (
AcerQAAgentSvis, the Quick Access component behind theFn+Ffan hotkey, andASMSvcare both running by default); - a timeout inside the embedded controller itself for non-
AUTOmodes; - something else entirely.
The tray re-applies once per second, which masks the symptom but does not fix it — and note the arithmetic: if the mode really drops after ~2 s, a 1 s loop only ever restores it after it has already fallen. You get most of the airflow, most of the time, not a mode that holds. Treat this as an open question, not a solved problem. If you own one of these machines and can characterise it, a PR or an issue with a timeline would be genuinely useful.
A note on how we got here: several of our earlier measurements were invalid because the tray icon was running during them and actively re-imposing its own state on the hardware we were trying to measure. If you experiment with this, shut the tray down first.
- Only verified on the A515-57. The
AcerGamingFunctionclass exists on many Acer machines but the firmware behind it varies. Runcooler.ps1 statusfirst: if it reads back the modes you set, your machine backs the interface. If the setters return non-zero, yours doesn't — stop there. max(CUSTOM 100%) is a pinned duty cycle. If the embedded controller resets, it can fall back to the stock curve without telling you. That is exactly why the tray icon verifies against the hardware instead of trusting its own state. Preferturbofor unattended use; it is a declared mode the firmware manages.MSAcpi_ThermalZoneTemperature(TZ00) is a chassis zone, reading around 28 °C. It is not the CPU die and is useless for validating any of this. Use HWiNFO orstatusinstead.- We never needed NBFC, and there is still no NBFC config for this model.
- This turns your fan up. It does not raise power limits or overclock anything — it removes a thermal ceiling so the CPU can hold its own turbo longer. Noise is the trade.
- Use at your own risk. Running a fan at 100% continuously wears the bearing faster than the stock curve does.
MIT — see LICENSE.