How to Set Deadband and Delay to Stop Chatter
A chattering alarm toggles on and off around its setpoint and buries the operator in repeats of the same alarm. This page is the procedure for tuning it out with deadband and delay, sized from the real signal so you stop the chatter without hiding a genuine event. For the underlying mechanism, see alarm hysteresis; this is how you set the numbers.
Set Deadband to Stop Chatter in one line: To stop a chattering alarm, measure the amplitude of the signal noise around the setpoint, set the deadband wider than that noise so the signal must make a real move to clear and re-alarm, and if chatter persists on brief real excursions add a short on-delay, keeping the delay well within the response time the alarm needs.
Confirm It Is Chatter, Not a Real Cycle
Before tuning, confirm the rapid on-off toggling is noise around the threshold and not the process genuinely cycling across the setpoint. Pull the trend and look at what the measurement is doing when the alarm chatters. If the process is truly oscillating across the limit, the fix is in the control loop, not the alarm.
Distinguish chatter from a chattering versus fleeting alarm too. Chatter is dense on-off toggling in a short span; a fleeting alarm is brief individual hits. They can share a fix but the diagnosis differs, so read the pattern from the timestamps before reaching for deadband.
Measure the Noise Around the Setpoint
Deadband has to be sized against something real, so measure the amplitude of the measurement noise and process ripple near the setpoint from trend data. That noise band is what the signal wanders across when the process sits near the limit, and it is exactly what makes the alarm chatter.
Capture the noise during the conditions where chatter actually happens, which is usually when the process is operating close to the setpoint. Noise measured far from the setpoint may not represent what the alarm sees at the threshold, and sizing deadband off the wrong figure leaves the chatter in place.
Set the Deadband Wider Than the Noise
Set the deadband so the signal has to move clearly beyond the noise band to clear and then move back to re-alarm. This is the primary chatter fix: with adequate deadband, ordinary ripple can no longer bounce the alarm on and off, because clearing now requires a real change in the measurement.
Keep the deadband proportionate. Too narrow and chatter survives; excessively wide and the alarm clears too easily, so a real recovery to just below the noise band is reported as resolved when it is not. The target is wider than the noise and no wider than needed.
Add an On-Delay Only If Needed
If deadband alone does not settle the alarm because the signal makes brief real excursions past the threshold, add a short on-delay so the condition must persist before it annunciates. The delay filters transient spikes that deadband cannot, since deadband acts on amplitude while delay acts on time.
Size the delay conservatively. A long on-delay eats into the response time the operator needs, so it must stay well within the time available to act that the setpoint validation established. Delay is a scalpel for brief transients, not a blanket to quiet a genuinely active alarm.
Verifying the Result
Back-test the new deadband and delay against the trend history that showed the chatter. Overlay the settings and confirm the alarm would now annunciate once for a real excursion instead of chattering, and confirm it still catches the genuine events in the record. The test is that chatter is gone and real events survive.
Watch it live through the conditions that caused the chatter. If it holds steady near the setpoint but still annunciates cleanly on a real breach, the tuning worked. If it now misses a real event, the deadband or delay went too far and you pull it back.
Common Mistakes to Avoid
The core mistake is over-widening deadband or over-lengthening delay until the alarm no longer chatters because it no longer works, masking real events along with the noise. The opposite mistake is sizing deadband off noise measured away from the setpoint, so it is too small and the chatter continues.
Engineers also reach for deadband when the real problem is a control loop genuinely cycling across the limit, which deadband only hides. And they add a long on-delay that quietly consumes the operator's response time, so the alarm arrives too late to act on when it finally does fire.
Frequently Asked Questions
Should I use deadband or on-delay to stop a chattering alarm?
Start with deadband, because chatter is usually noise crossing the threshold and deadband directly addresses amplitude by requiring the signal to make a real move before it clears and re-alarms. Add an on-delay only if brief real excursions still cause repeats that deadband cannot catch, since delay filters in time rather than amplitude. Keep any delay short enough that it does not eat into the response time the alarm needs, so you never trade chatter for a late alarm.
Can too much deadband cause a missed alarm?
Yes. Deadband set far wider than the signal noise means the measurement has to recover well past the setpoint before the alarm clears, and it also means a slowly worsening condition might not re-alarm as expected after a recovery. Excessive deadband can also report a real but shallow recovery as resolved when the process is still near the limit. Size it wider than the noise band and no wider, and verify against history that real events still annunciate.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.