Many devices do collect data. The problem is that raw data is often not ready to become a device decision.
Temperature readings drift slowly. Scales jump by a few grams. Water leak probes may toggle because of droplets or contamination. Current sensing picks up switching noise. Ultrasonic ranging occasionally returns a strange distance. If the firmware compares every raw sample directly against a threshold, the device will false-trigger, miss events, or bounce between states.
Filtering is not only about making numbers smoother. A better model is:
Physical world
-> sensor and analog front end
-> ADC or digital output
-> filtering, compensation, calibration
-> thresholds, state machine, product behavior
The raw value, filtered value, and final device state are different things. Filtering sits in the middle and changes stability, latency, and event behavior.
Why Raw Values Jitter
Jitter does not automatically mean the sensor is broken.
It can come from many places:
- The physical quantity is actually changing
- The analog front end or ADC has noise
- Power, grounding, or EMI injects disturbance
- A sample lands on a spike or transient
- The mechanical structure is vibrating
- Coupling between the sensor and target is unstable
- The sensor’s internal algorithm is updating background or compensation data
Temperature and humidity drift may come from enclosure airflow and self-heating. Load-cell jitter may come from vibration and ADC noise. Presence detection may be affected by curtains, fans, and background modeling. These all look like unstable data, but they do not deserve the same fix.
If every unstable curve is treated by increasing the averaging window, real fast changes may disappear too.
Smooth Does Not Mean More Accurate
Filtering often makes a curve look better, but a smoother curve is not automatically closer to truth.
Moving average reduces random noise, but it slows response. A first-order low-pass filter follows changes smoothly, but a step change becomes a gradual ramp. Median filtering removes isolated spikes, but it is not a general answer for continuous variation or periodic interference.
A water leak sensor is a simple example.
If a probe occasionally touches a droplet, immediate alarm may false-trigger. If the firmware requires several consecutive wet samples, false alarms drop. But if the confirmation count is too large, real leak alarms become late.
Filtering is a tradeoff:
More stable
-> fewer false triggers
-> more latency
-> possible missed short events
The same tradeoff appears in temperature sensing, scales, current sensing, distance sensors, PIR sensors, and Hall switches.
Filtering Changes Meaning
The common bug is forgetting that a filtered value is no longer an instant reading.
A temperature value averaged over 60 seconds represents a recent trend, not the temperature at this exact moment. A heavily smoothed scale display should not be used to decide final weight in the first few hundred milliseconds. If current protection uses a long low-pass filter, a short circuit or motor stall may happen before the software reacts.
The same variable name may hide very different meanings:
raw value: direct sample
filtered value: estimated value after filtering
state: business state after thresholds and confirmation
These should be separated in code and logs. Otherwise debugging starts at the wrong layer. A state-machine delay looks like a slow sensor. An oversized filter window looks like a bad threshold.
Start With What You Need To Protect
Filter design should start from product behavior, not from algorithm names.
Ask:
- Should this quantity naturally change fast or slowly?
- Is a false positive or a missed event worse?
- How much latency is acceptable?
- Does a short spike have business meaning?
- Is the data used for display, control, protection, or alarm?
- Can a low-power device afford a higher sampling rate?
A scale display can tolerate a short settling time. Overload protection cannot. Environmental display can be smooth. Condensation-risk detection needs trend information. A water leak alarm should confirm before waking the user, but not wait so long that the event becomes useless.
Filter parameters are not better just because they are larger or smaller. They come from the cost of being wrong.
Debug Three Layers
Field debugging should not look only at the final state.
Useful logs usually include at least three layers:
raw sample
filtered value
device state
If the raw value is already unstable, check power, layout, installation, mechanics, and environment. If the raw value is reasonable but the filtered value is wrong, inspect window size, coefficients, initialization, and overflow. If the filtered value is stable but the state toggles, the issue is likely thresholding, hysteresis, debounce, confirmation, or state-machine design.
That is the practical point of sensor filtering: do not change thresholds just because an alarm is wrong, and do not average harder just because a value jitters. Separate physical input, filtered estimate, and device state first.
Filtering does not make sensor data magically true. It turns noisy observations into decisions the product can live with, while introducing latency and changing meaning.