The word deadband gets used for two genuinely different jobs, and conflating them causes confusion. A reporting deadband decides when a value is worth transmitting - it lives on the communication side and controls how much data a device sends. A control deadband decides when an action is worth taking - it lives inside a controller and stops outputs from reacting to trivial changes. Same name, opposite side of the system. This page separates the two so it is clear which deadband a given setting is, and what it actually affects.
Reporting vs Control Deadband in one line: A reporting deadband, also called a transmit or exception deadband, is the amount a value must change before a device sends a new reading - it governs communication and data volume by suppressing insignificant updates. A control deadband is the range around a setpoint or threshold within which a controller takes no action, preventing outputs from hunting or switching on tiny changes. One decides whether to transmit; the other decides whether to act. Both suppress small changes, but they operate on completely different parts of the system.
A reporting deadband is a communication concept. A field device reports its value by exception - it sends an update only when the value has moved by more than a configured amount since the last report. That amount is the reporting deadband. A pressure jittering by a tiny fraction never crosses it and so is never transmitted, while a real change past the deadband is sent immediately. The purpose is to keep the link carrying meaningful changes rather than a constant stream of noise, which is especially valuable on slow or metered cellular and radio links.
The reporting deadband directly trades data volume against fidelity. A wide deadband transmits rarely and keeps traffic low, but small real movements are not reported until they accumulate past the threshold, so the received signal is coarser. A narrow deadband reports fine detail but sends far more messages. Choosing it is about deciding how small a change is worth spending a message on for each point - a critical alarm-driving value might warrant a tight deadband, while a slow diagnostic reading can tolerate a wide one.
It is worth noting how the reporting deadband relates to two neighboring ideas. It is the live, communication-side sibling of historian deadband compression: the reporting deadband decides what leaves the device, while compression decides what the historian keeps once data arrives. And it is the opposite bookend from the control deadband discussed next. All three suppress insignificant change, but the reporting deadband is specifically about the decision to put a value on the wire, which is a different decision from whether to store it or whether to act on it.
A control deadband lives inside a controller or an alarm and governs action, not communication. It is a range around a setpoint or threshold within which the controller deliberately does nothing. A common example is a valve or relay controlled to a target: without a deadband, the tiniest deviation would drive the output back and forth, hunting endlessly and wearing the equipment. With a deadband, the output only responds once the value has drifted outside the tolerance band, so it settles instead of chattering. The same idea separates an alarm's trip and reset points so a value hovering on the limit does not toggle repeatedly.
The control deadband trades responsiveness against stability. A tight control deadband keeps the process close to target but risks nervous, frequent output changes; a wide one gives smooth, stable operation but lets the value wander further before the controller corrects. This is fundamentally a process-control decision about how precisely a variable must be held versus how much output activity and wear is acceptable, and it has nothing to do with how much data crosses a communication link.
The key point is that the control deadband acts on outputs and actions in the field, whereas the reporting deadband acts on messages to the center. A change that is too small to make the controller move might still be large enough to report, or vice versa, depending on how each is set - they are independent settings serving independent goals. Treating them as one thing leads to real mistakes, like widening a reporting deadband to calm a hunting valve, which does nothing for the valve because the valve's behavior is governed by the control deadband, not by what gets transmitted.
In cloud SCADA for remote oil and gas sites, both deadbands are in play but they are tuned by different people for different reasons. The reporting deadband is a telemetry-tuning decision about how much of a well's data to push over a cellular or satellite link and how finely to resolve each value, so it is set with bandwidth, cost, and trend fidelity in mind. The control deadband is a field-control decision baked into how a local device regulates a valve or triggers a status, set with equipment wear and process stability in mind.
A platform such as Merobix is chiefly concerned with the reporting side: how field devices report by exception, what change is significant enough to transmit, and how that keeps remote links efficient while preserving the trends and alarms operators rely on. The control deadband typically lives in the field device or PLC doing local regulation, upstream of what the platform receives. Keeping the two mentally separate is what stops an engineer from adjusting a communication setting to fix a control problem, or the reverse.
The practical discipline is to always ask which decision a deadband governs: transmit or act. When a trend looks too coarse or too chatty, the reporting deadband is the lever, because it controls what the device sends. When a valve hunts or an alarm chatters on tiny movements, the control deadband is the lever, because it controls how the field responds. Naming the two clearly, rather than calling both just deadband, is what makes tuning a remote site a matter of turning the right knob instead of guessing.
A reporting deadband is how much a value must change before a device transmits a new reading, so it governs communication and data volume. A control deadband is the range around a setpoint or threshold within which a controller takes no action, so it governs field behavior and prevents hunting. One decides whether to send a value; the other decides whether to act on it.
They work together: report by exception is the method of only sending updates when a value changes significantly, and the reporting deadband is the threshold that defines significant. A device using report by exception transmits a new value only when it has moved past the reporting deadband since the last report. So the deadband is the tunable number that drives the exception-based transmission.
No, because a hunting valve is governed by the control deadband inside the controller, not by how much data is transmitted. Widening the reporting deadband only reduces how often the value is sent to the center; it does not change how the field device regulates the valve. To calm a hunting valve you adjust the control deadband, which is a separate setting on the control side.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.