What Is Deadband?
The Zone Where Nothing Happens

Back to Blog

Where Deadband Is Used

On/off control: A tank level controller might start a pump at 80% and stop it at 60%. The 20-point gap is the deadband; without it, a pump sitting right at a single switching level would rapidly cycle on and off as the level jittered, wearing out the pump and its starter. Control valves: Deadband allows the controller to ignore tiny errors so the valve does not constantly reposition (hunt) in response to signal noise, saving wear on the actuator and packing.

Alarms: Alarm deadband keeps an alarm from clearing and re-triggering as the process variable hovers around the alarm limit. If a high-pressure alarm trips at 50 psi, a deadband of 2 psi means it will not clear until pressure drops below 48 psi - preventing a storm of alarm and return-to-normal messages. Reporting by exception: SCADA and RTUs use a deadband so a value is only transmitted when it changes by more than a set amount, cutting needless traffic on cellular and radio links.

Deadband vs Hysteresis

The two terms overlap and are often used interchangeably, but there is a shade of difference. Deadband generally describes a band of no response around a value. Hysteresis specifically describes when the switching point depends on the direction of travel - the point where something turns on differs from the point where it turns off. The pump example above is technically hysteresis: on at 80%, off at 60%.

In everyday plant language, engineers say deadband for both, and configure it as a single number in the controller, RTU, or SCADA point. Choosing the value is a balance: too little and you get chatter and nuisance alarms; too much and the system responds sluggishly or misses meaningful changes.

Choosing the Value: A Symbolic Method

There is a defensible way to pick a deadband that does not involve guessing. Watch the point during quiet, steady operation and measure its noise band - call it N, the peak-to-peak wander when nothing real is happening. Then identify the smallest process change that matters for this point - call it M, the move an operator or a downstream calculation must not miss. The deadband D needs to sit between them: comfortably above N so noise cannot fire it, and comfortably below M so nothing meaningful is swallowed. N below D below M, with margin on both sides.

If no value of D satisfies both conditions - the noise band overlaps the smallest meaningful change - the deadband is not the problem, the measurement is. Fix the installation, the filtering, or the instrument before tuning suppression settings, because any D you pick will either chatter or hide real events. Whether D is expressed in engineering units or percent of span, write down the N and M that justified it; the number will be questioned years later, and a value someone set once, undocumented, is how sites end up with deadbands nobody dares touch.

The Deadband Stack: Four Layers That Multiply

A single value often passes through several suppression layers on its way to a trend or an alarm, each configured independently and each defensible on its own.

Layer	Mechanism	Risk if oversized
Transmitter	Damping (time-based filtering)	Lagged response to real changes
Controller	Error deadband on the loop	Standing offset from setpoint
RTU or gateway	Report-by-exception threshold	Changes never transmitted
Historian	Compression deadband	Recorded history flattens real moves

The trap is stacking: a change can be small enough to be absorbed at two or three layers in sequence, so the control room sees a flat line while the process genuinely moved. Audit the whole path for each critical point - what is the smallest change that survives end to end? - and keep alarm evaluation as close to the raw measurement as the architecture allows. The report by exception threshold and the historian compression settings deserve particular attention, because they are usually configured by different people at different times without reference to each other.

Reading the Symptoms of a Wrong Setting

Too small shows up as noise-driven activity: alarms that trip and clear in bursts, valves that never stop dithering, a comms link busy with updates that carry no information, an event journal that scrolls too fast to read. Too large shows up as suspicious calm: staircase-shaped trends that jump in blocks, alarms that arrive late because the value had to travel the full deadband past the threshold before anyone heard, and totalized values that drift from reality because the increments between reports were lost.

Both directions are visible from the control room without a site visit. Alarm and event frequency statistics expose the too-small cases - the chattering points cluster at the top of the count - while trend inspection exposes the too-large ones. A periodic pass over both, point by point for the critical signals, is cheap insurance; deadbands set at commissioning quietly stop fitting when instruments are replaced or operating ranges move.

Deadband Plus Time: Delays for the Hard Cases

Some signals defeat amplitude-based suppression alone. A level that sloshes across an alarm limit in waves, or a pressure that spikes briefly during routine pump starts, will chatter through any reasonable deadband because the excursions are genuinely larger than it. For those, combine the amplitude test with a time test: the alarm trips only after the value has stayed beyond the limit for a set delay, and clears only after it has stayed back inside for another - the pattern described in alarm on-delay and off-delay.

The combination is stronger than either alone: deadband handles noise, delay handles transients, and each can stay smaller than it would need to be doing the whole job by itself. The cost is latency - a delayed alarm is by definition later - so the delay on any safety-relevant alarm is an alarm-philosophy decision made with the people responsible for response, not a tuning knob for silencing a nuisance.

Frequently Asked Questions