Repository navigation
Conversation
Some EC offsets on newer machines multiplex other data and read as a temperature that leaps tens of degrees back and forth, dragging smart mode with it. Track the endpoints of each sensor's last big leap and drop the sensor after three round trips between the same two values, with a log line naming it. A real sensor never repeats the exact endpoints of a twenty degree jump, load spikes included, so a working cpu sensor cannot get caught. ErraticSensorGuard=0 turns it off.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the sensor guard from #117 ported onto main. A sensor that jumps twenty degrees or more between the same two exact values three times stops driving the fan, and a log line names it. ErraticSensorGuard=0 in the ini turns it off, the config dump in the log shows the setting next to IgnoreSensors.
Same logic as da9d817 and 70d72a9 in my branch, verified there on an X13 Gen 3 where pwr flips between 1 and 66: it gets quarantined after a couple of minutes and the switch temp follows cpu again. Single spikes like the 100 and 110 readings in the issue won't trigger it, those never repeat the same endpoints, but it's easy to extend if a csv capture shows a pattern.
I can't run this exact build on my machine, TVicPort doesn't load with memory integrity on (that's what pushed my branch onto PawnIO), so it's compile checked with the same analysis flags as the workflow, no new warnings, and the runtime proof is from the same code in my branch.