The word deadband gets used for two very different jobs, and mixing them up leads to real confusion. One deadband decides when a historian bothers to store a new sample, controlling how much storage a fluctuating signal consumes. The other decides when an alarm is allowed to clear, preventing a value hovering at a limit from chattering on and off. They are tuned separately, for different reasons, and setting one when you meant the other produces surprising results. This guide separates the collection deadband from the alarm deadband, explains how each is tuned in percent of span, and lays out the storage-versus-fidelity trade-off.
Collection vs Alarm Deadband in one line: A collection deadband, also called a logging or storage deadband, controls when a historian records a new sample: the value must move by more than the deadband before a new point is stored. An alarm deadband controls when an alarm is allowed to clear, requiring the value to move back past the limit by a set margin so a signal sitting near the threshold does not chatter. One governs storage, the other governs alarm behavior, and they are tuned independently.
The collection deadband, also known as a logging or storage deadband, is a filter on what a historian bothers to record. Instead of storing every reading it receives, the historian remembers the last value it stored and only records a new sample when the current reading differs from that stored value by more than the deadband. A signal that jitters within the deadband produces no new stored points, because as far as the record is concerned nothing meaningful has changed. Only when the value breaks out of that band does a fresh sample get written and the reference reset.
The purpose is efficiency. A process value almost never sits perfectly still; electrical noise and small physical fluctuations mean it wiggles constantly, and storing every one of those wiggles would fill a historian with points that carry no useful information. The collection deadband suppresses that noise at the source, so the stored history captures genuine movement while ignoring the trembling around it. This is closely related to how exception-based reporting decides which values are worth transmitting at all; the collection deadband applies the same logic to the question of which values are worth keeping.
The consequence to keep in mind is that the collection deadband directly shapes the fidelity of the stored record. Anything smaller than the deadband simply does not appear in history, so a real change that stays within the band is invisible after the fact. Set the deadband too wide and you save storage but lose the fine detail of the signal; set it too narrow and you capture every nuance but store a flood of noise. This is a storage-versus-fidelity trade-off, and it is entirely separate from anything to do with alarms.
The alarm deadband does a completely different job. Its concern is not storage but the on-and-off behavior of an alarm as a value hovers around its limit. Without a deadband, a signal sitting right at an alarm threshold and jittering by a hair would cross the limit repeatedly, raising and clearing the alarm over and over and burying the operator in a storm of identical notifications. The alarm deadband stops this by separating the point where the alarm activates from the point where it is allowed to clear.
It works by requiring the value to move back past the limit by a defined margin before the alarm clears. A high alarm might trip when the value rises above its setpoint, but then refuse to clear until the value falls a meaningful amount below that setpoint, not merely back to it. That gap is the deadband. A value quivering exactly at the limit will trip the alarm once and then hold it steady, because the small wiggles are not large enough to carry the value all the way back through the clearing margin. The result is one clean alarm instead of a chattering stream.
The critical point is that the alarm deadband has nothing to do with whether data is stored. It governs the state of an alarm, the operator's experience, and the alarm log, while leaving the underlying historian untouched. You can have a well-tuned alarm deadband that produces clean, stable alarms while your collection deadband is set entirely separately for storage reasons, or vice versa. Confusing the two, and adjusting the storage filter when what you actually wanted was to calm a chattering alarm, is a common mistake that fixes nothing and can quietly harm your stored data instead.
Both deadbands are commonly expressed as a percent of span, and understanding why makes them far easier to tune. Span is the full measurement range of a point, from the bottom of its scale to the top, and stating a deadband as a percentage of that span makes the setting portable across signals with wildly different units and ranges. A deadband given as a small percent of span means the same relative sensitivity whether the point is a pressure, a temperature, or a level, without anyone having to reason about the raw engineering units of each one. It also keeps the setting sensible if the range is ever rescaled.
For the collection deadband, tuning in percent of span is a direct dial on the storage-versus-fidelity trade-off. A larger percentage stores fewer points and captures only coarser movement, saving space but losing detail; a smaller percentage captures finer movement at the cost of more stored data and more noise. The right value depends on how much the signal genuinely varies, how much of that variation matters for later analysis, and how noisy the measurement is, and it is chosen to keep the meaningful shape of the signal while discarding the trembling around it.
For the alarm deadband, the percent-of-span figure is instead sized to comfortably exceed the normal noise on the signal, so the clearing margin is wider than the jitter that would otherwise cause chatter, but not so wide that a genuine return to normal is masked or delayed. For a cloud SCADA platform such as Merobix, keeping these two settings clearly distinct is what lets an operator tune storage and alarm behavior independently, so a chattering alarm is fixed by adjusting its alarm deadband and storage volume is managed by adjusting the collection deadband, without either change accidentally disturbing the other.
A collection deadband decides when a historian stores a new sample, requiring the value to move by more than the deadband before a fresh point is recorded, which controls storage volume and record fidelity. An alarm deadband decides when an alarm is allowed to clear, requiring the value to move back past the limit by a margin so a signal near the threshold does not chatter. One governs storage, the other governs alarm behavior, and they are tuned separately.
Because a percent of span is a relative setting that means the same thing across signals with different units and ranges. Span is the full measurement range of a point, so a deadband given as a percentage of it applies consistent sensitivity whether the point is a pressure, a temperature, or a level, without anyone reasoning about raw engineering units. It also keeps the setting sensible if the point's range is later rescaled.
You change the alarm deadband, which widens the margin the value must move back through before the alarm clears, so a signal hovering at the limit stops toggling on and off. Adjusting the collection deadband will not calm the alarm at all, because that setting only affects how much data the historian stores. Reaching for the collection deadband to fix chatter is a common mistake that does not solve the problem and can quietly degrade your stored history.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.