Signal Debouncer And Hysteresis

A raw boolean condition evaluated every tick - price above a level, RSI above 70, spread under a cap - flips every time the underlying value crosses back and forth across its threshold by a fraction of a pip, and every one of those flips looks like a fresh signal to code reacting to it, even though nothing has actually changed regime. The same problem shows up in continuous form: a value oscillating a point either side of a single threshold turns a comparison on and off every tick. DebounceState/DebounceInit/DebounceUpdate fix the boolean case by requiring N consecutive readings to agree before the debounced output actually flips. A single stray reading in the middle of a run resets that run rather than quietly accumulating towards a flip anyway - the difference between a genuine debounce and a leaky majority filter that would still flip early on a borderline sequence. HysteresisState/HysteresisInit/HysteresisUpdate fix the continuous case with two thresholds instead of one: the output only turns on once the value reaches HighThreshold, and only turns off once it falls all the way back to LowThreshold. Anywhere strictly between the two thresholds, the output holds whatever it already was - a value that rises above High, dips back down to just below High but not down to Low, and rises again stays ON throughout, which is exactly the behaviour a single-threshold comparison cannot provide. Both variants are plain state structs with no hidden globals, so a program tracking several independent signals keeps one instance of the relevant struct per signal and updates each independently. Notes and limitations - DebounceUpdate resets its consecutive-match counter whenever a reading disagrees with the value currently being confirmed, including a reading that matches the CURRENT stable output - this is deliberate (a single reading back at the stable value is not "progress towards a flip"), but means a rapidly alternating sequence with RequiredCount set high may never flip at all, which is usually exactly what should happen to a genuinely noisy input. - Passing RequiredCount = 1 to DebounceInit makes DebounceUpdate a plain pass-through - a valid, sometimes useful configuration, not a special case that needs handling separately. - HysteresisInit takes the two thresholds in either order and sorts them internally, so callers do not need to remember which parameter is which if the band is computed dynamically (e.g. from ATR) and could end up either way round. - Neither struct is thread-safe or tick-count-aware on its own - each DebounceUpdate/HysteresisUpdate call is assumed to represent one logical reading (typically one per OnTick), not a fixed time interval.

Script · MT5 · v1.0 · Free

Tags: RSI · Buy/Sell Arrows · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria