When sensor readings are noisy, the usual fix is to add filtering.
Moving averages, first-order low-pass filters, median filters, and consecutive confirmations all make curves smoother. The display looks calmer, and alarms are triggered by fewer spikes.
In closed-loop control, filtering is not free.
While filtering suppresses noise, it also makes the controller see an older state. For display, slightly old data is often acceptable. For control, late feedback can become overcorrection.
stronger filtering
-> smoother measurement
-> later feedback
-> control action arrives late
-> response becomes slower, or overshoot and oscillation increase
Filtering can be used, but it must be treated as part of the loop timing.
Stable Display Value Does Not Mean Better Control Value
Many devices use the same sensor data for display, alarms, and closed-loop control.
Displays dislike jitter. A user seeing temperature jump between 24.9°C and 25.1°C may think the device is unstable. Alarms also should not trigger on one instantaneous spike.
Closed-loop control cares less about a pretty curve and more about whether the controller sees plant changes in time.
Data used for display can be heavily filtered. Alarm logic can use hysteresis and confirmation. Control data cannot only chase smoothness. The smoother the controller’s input is, the later it usually is.
The problem is in this chain:
real physical variable changes
-> sensor response
-> sampling
-> filtering
-> controller sees the change
-> actuator corrects
Filtering sits in the middle and pushes the moment of detection later.
Moving Average Spreads New Changes Across Old Data
A moving average is intuitive: average the latest samples.
With an 8-sample window, a new measurement is only part of the result. The real temperature, speed, or pressure may already have changed, while the filtered value catches up gradually.
new data enters the window
-> old data remains in the window
-> average moves slowly
-> controller sees a delayed change
The longer the window, the smoother the output and the larger the delay.
Sampling period amplifies this. An 8-point moving average covers about 80 ms at a 10 ms sampling period, but about 800 ms at a 100 ms period. The point count is the same, but the loop sees a very different delay.
The display curve looks nicer, while the controller may be acting on the past.
First-Order Low-Pass Filters Also Lag
A first-order low-pass filter is often written like this:
filtered = filtered + alpha * (raw - filtered)
Smaller alpha means stronger filtering and a smoother output. Larger alpha makes the output closer to the raw value.
It does not keep a fixed window like a moving average, but it still lags. When the real value changes suddenly, the filtered value approaches it step by step.
That matters in closed-loop control.
If temperature is already near the target while the filtered value is behind, the controller thinks temperature is still low and keeps heating. By the time the filtered value catches up, the real temperature may have crossed the target.
The same applies to motor speed, pressure, and level control. Low-pass filtering reduces noise, but it turns feedback into feedback that is late.
Median Filters Are for Spikes, Not Time Judgment
Median filters are useful for rejecting isolated spikes.
If one value in a 5-sample window is abnormally high, taking the median can remove that spike. This is useful for glitches, occasional communication errors, or rare ADC outliers.
But median filters also have a cost.
With a larger window, a real fast change may be confirmed late. As long as old values still dominate the window, the median will not immediately follow the real change.
Using a median filter as a general noise solution can create two problems:
- real changes are delayed as if they were outliers
- the state seen by the controller changes discontinuously
Median filtering is good for isolated abnormal samples. It should not replace judgment about sensor response time, sampling period, and control bandwidth.
Filtering Changes Phase, Not Only Amplitude
Engineering intuition often treats filtering as reducing jitter amplitude. In a closed loop, filtering also changes timing.
After the input changes, the filtered output changes later. That lateness is phase lag in the time domain.
Closed loops are sensitive to control action arriving late.
plant has started changing
-> filtered value has not moved much
-> controller continues using the old state
-> plant crosses the target
-> filtered value finally reflects the change
-> controller corrects in the opposite direction
If the plant already has inertia, and the actuator also has response delay, filter delay consumes more stability margin. A loop that was merely slow may start overshooting. A loop that was barely stable may start oscillating.
Derivative Action Is Caught Between Filtering and Noise
The derivative term in PID responds to rate of change.
With noisy raw measurements, derivative action amplifies noise and creates output spikes. Many implementations therefore filter the measurement or the derivative term.
This creates a conflict:
- without filtering, derivative action is noisy
- with too much filtering, derivative action sees changes late
Derivative action is meant to sense changes early and reduce fast movement toward the target. If filtering delays the change, derivative action is weakened. Worse, the filtered signal shape may make derivative correction happen at the wrong time.
Derivative action is not simply an add-on that suppresses overshoot. It depends on measurement quality, sampling period, and filtering method.
Filter Location Changes Control Meaning
Filters can be placed in different parts of the loop, and each location means something different.
Common locations include:
- filtering raw sensor values
- filtering error
- filtering the derivative term
- filtering or ramping the control output
- filtering display values separately
Filtering raw values changes the state seen by the controller. Filtering error changes the combined effect of setpoint changes and measurement changes. Filtering derivative mainly suppresses derivative noise. Filtering or ramping output limits actuator command speed.
All of these can look like “make it smoother,” but their closed-loop meaning differs.
For example, if the setpoint changes suddenly, filtering error may delay the setpoint change too. Filtering the measurement mainly delays feedback. Ramping the output limits how fast the actuator command changes.
During debugging, specify where filtering is applied, or the problem can be assigned to the wrong layer.
Different Signals Can Use Different Filtering
A common improvement is to separate display, alarm, and control data paths.
Display values can be smoother. Alarm logic can use hysteresis, confirmation, and state machines. Control values should keep feedback timely and apply only necessary noise reduction.
For example:
raw sampling
-> lightly filtered control value
-> heavily filtered display value
-> alarm state with hysteresis and confirmation
This avoids forcing one filter parameter to satisfy three goals: stable display, reliable alarms, and timely control.
In a closed loop, less filtering is not always better, and more filtering is not always more stable. Each data path needs a clear job.
Debug Filtering by Looking at Time and Response
When control becomes worse after filtering, do not only look at noise amplitude.
Record at least:
- Raw measurement.
- Filtered control value.
- Display value and alarm state.
- Sampling period.
- Real time length of filter windows.
- Control output.
- Actuator response.
- Setpoint change and real plant response.
Then check:
- how long after raw value changes the control value changes
- whether control output keeps pushing based on old feedback
- whether overshoot increases after filtering
- whether stronger filtering makes the same gains more oscillatory
- whether display stability and control stability were treated as the same goal
If filtering makes the controller know about plant changes later, it is not only reducing noise. It is changing closed-loop dynamics.
Filtering can make numbers steadier, but closed-loop control needs feedback that is timely, credible, and clean enough.
Consider filter delay, sampling period, PID gains, and actuator response together. That is the difference between filtering helping the loop and filtering dragging the controller into the past.