Choosing Moving Average, First-Order Low-Pass, and Median Filtering

When sensor data jitters, the first reaction is often: add a filter.

But filtering is not one button. Moving average, first-order low-pass, and median filtering can all make data look more stable, but they handle different problems and introduce different delays.

A useful first model is:

Random small jitter: moving average is common
Smooth tracking: first-order low-pass is common
Isolated spikes: median filtering is common

This is not a complete DSP taxonomy, but it is enough for many IoT sensor designs.

Moving Average Handles Small Random Jitter

Moving average takes the average of the latest N samples:

y = (x1 + x2 + ... + xN) / N

It works well when samples bounce randomly around a real value. Examples include small load-cell ADC jitter, temperature and humidity noise, or random current-sense noise.

A larger window gives a smoother curve, but response becomes slower.

If the window contains 20 samples and the sampling period is 100 ms, the window covers 2 s. When the real value changes suddenly, old samples keep pulling the output back.

Moving average also needs history storage. That may be fine on most systems, but large windows across many channels can matter on small MCUs.

The common misuse is using a large average window to hide a hardware or installation problem. If a scale vibrates or current-sense layout is noisy, averaging harder makes the symptom less visible, but it does not fix the measurement chain.

First-Order Low-Pass Tracks Smoothly

A first-order low-pass filter is often written as:

y = y + alpha * (x - y)

x is the current input, y is the filtered output, and alpha controls tracking speed.

A larger alpha follows the input faster. A smaller alpha gives a smoother output but more delay.

This filter is simple and cheap. It only needs the previous output, not a long buffer. It works well for slow values or display values, such as temperature trends, humidity trends, battery voltage, and power estimates.

It is not universal. A large isolated spike is not ignored; it is only reduced and carried into the output. The larger the spike, the more the output moves.

If a distance sensor occasionally returns a ridiculous value, median filtering or outlier rejection is often a better first step than low-pass filtering alone.

Median Filtering Removes Isolated Spikes

Median filtering sorts a small window of samples and picks the middle value.

For example:

100, 101, 500, 99, 100

Sorted:

99, 100, 100, 101, 500

The median is 100, so the 500 spike disappears.

This is useful for ultrasonic ranging, ToF sensors, some current sampling paths, and contact probes where one bad measurement can appear among normal samples.

The cost is a window and some delay. If the window is too large, real step changes are delayed too. More importantly, median filtering handles a minority of outliers; it does not smooth every kind of noise.

If three out of five samples are wrong, the median will also be wrong. It is robust against a few bad points, not magic.

Look At The Noise Shape First

Before choosing a filter, log the raw data.

Common patterns include:

• Small random jitter around a value
• Occasional large spikes
• Periodic ripple from power or vibration
• A step change followed by settling
• Long-term drift from temperature, self-heating, or zero shift

They require different responses.

Random jitter can be averaged. Isolated spikes can be removed by median filtering or outlier rejection. Periodic noise may require checking sampling rate, synchronization, and hardware interference. Slow drift may need temperature compensation, zero tracking, or recalibration. Step changes require a tradeoff between stability and response speed.

Choosing a filter without raw data often fixes the wrong layer.

Different Uses Need Different Outputs

One system should not always have only one filtered value.

The same current signal may need a smooth value for display and a fast value for overcurrent protection. A scale display can wait for settling, but overload detection should react earlier. Temperature display can be low-pass filtered, while temperature-rise detection needs trend information.

Separate outputs are often cleaner:

raw: debugging and protection
fast filtered: control and quick decisions
slow filtered: display and trend
state: product behavior

This is more reliable than trying to make one perfect filtered value serve every purpose.

A Practical Selection Order

A first implementation can follow this order:

1. Log raw data and identify the abnormal pattern.
2. If it is mostly small random jitter, use moving average or first-order low-pass.
3. If it is mostly isolated spikes, use median filtering or outlier rejection first.
4. If the state bounces, add hysteresis, debounce, and state-machine logic instead of only changing the filter.
5. If response is too slow, reduce window size or increase alpha, then check whether the false-trigger cost is still acceptable.

More complex is not automatically better. For many IoT devices, moving average, first-order low-pass, median filtering, and a good state machine solve most practical problems.

The point is not the filter name. The point is matching the algorithm to the noise shape and product cost.