A single wild sample, a spike to full scale or a dropout to zero, can wreck a reading, and a moving average makes it worse by smearing the bad value across everything it touches. A median filter handles this differently: it sorts the last few samples and takes the one in the middle, so a lone outlier is simply outvoted and thrown away rather than blended in. This guide explains how a median filter rejects spikes, why it suits impulse noise where an average does not, how it differs from averaging and low-pass filtering, and the small odd-length windows used in controllers.
Median filter in one line: A median filter replaces each reading with the median, the middle value, of the last N samples, rather than their average. Because a single spike or dropout sits at one extreme of the sorted samples, it is never the middle value, so it is rejected outright instead of being blended into the output. This makes the median filter the right tool for isolated impulse noise, and it is typically used with a small odd-length window such as three or five samples in a PLC.
A median filter keeps the last few samples of a signal, sorts them by value, and outputs the one in the middle. With three samples, that is the second-largest; with five, the third. The key property is that the median is the value that has as many samples above it as below it, so it is decided by the bulk of the samples, not by any single one. A lone spike to full scale or a dropout to zero lands at the very top or very bottom of the sorted list, as far from the middle as possible, so it can never be the value chosen. The filter simply passes over it and reports a representative sample instead.
Contrast this with a moving average, which sums the samples and divides. An average gives every sample a vote in the output, including the bad one, so a spike is not rejected but diluted and spread: a single sample that is wildly high pulls the average up for as long as it remains in the window, contaminating several consecutive outputs. The average never fully ignores the outlier; it only shares the damage across the window. The median, by choosing rather than blending, discards the outlier completely, so the moment the spike ages out of the window there is no lingering trace of it in the output.
This is why the median filter is described as nonlinear. An average is a linear combination of its inputs, so scaling or offsetting the inputs scales or offsets the output predictably, and every input contributes proportionally. The median is not a weighted sum at all; its output is always one of the actual input samples, selected by rank. That nonlinearity is precisely what gives it its spike immunity, and it is why a median filter cannot be built from the same summing arithmetic as an average, it needs a sort or a comparison.
The median filter is the right tool for a specific kind of corruption: impulse noise, meaning occasional isolated samples that are grossly wrong while the surrounding samples are fine. Spikes from electrical interference, momentary sensor glitches, communication dropouts that read as zero or full scale, and single-sample outliers are all impulse noise, and the median rejects them cleanly because they are the minority within the window. As long as fewer than half the samples in the window are corrupted, the median remains a good sample, which is a strong guarantee against isolated bad readings.
For continuous, small-amplitude noise, the picture is different. When every sample is jittering slightly around the true value, as with steady Gaussian-like measurement noise, an average is the better tool: summing many noisy samples lets their random errors partly cancel, producing a smoother estimate than any single sample. A median does not average out this kind of noise the way a mean does; it just picks one of the jittery samples, so it reduces the jitter less than an average would. The two filters address different problems, and using the wrong one leaves the actual noise largely untreated.
In practice signals often carry both kinds of noise, an underlying jitter with occasional spikes, and the two filters can be combined. A common pattern is to run a median filter first to knock out the spikes, then a light average or low-pass filter to smooth the remaining jitter, so each stage handles the noise it is suited to. Applying only an average to a spiky signal smears the spikes; applying only a median to a purely jittery signal under-smooths it. Matching the filter to the character of the noise, or staging both, is what gets a clean result.
Median filters in controllers use a small odd-length window, most often three or five samples, and both the smallness and the oddness matter. An odd window has a single unambiguous middle sample, so the median is well defined without averaging the two central values, which would reintroduce a bad sample's influence. A small window keeps the filter responsive: it only needs to remember a few samples, the arithmetic is a quick sort of a short list, and legitimate changes in the signal pass through with little delay. A three-sample median already rejects any single isolated spike, which covers the most common case, while a five-sample median tolerates a couple of nearby bad samples at the cost of a bit more lag.
The trade-off with window size is between robustness and responsiveness. A larger window survives more consecutive bad samples and follows a noisier signal more calmly, but it also lags real changes more, because a genuine step in the signal has to become the majority of the window before the median follows it, and it can slightly round the corners of fast legitimate transitions. This is why controllers favor short windows: they want spike immunity without introducing meaningful delay into a control signal. A median filter that is too long trades away the responsiveness that real-time control depends on.
In a cloud SCADA architecture such as Merobix, spike rejection is most effective at the edge, in the PLC, RTU, or device that sees the raw signal at full cadence, because that is where a glitch first appears and where a short median window can catch it before it propagates into control logic, alarms, or the historian. A spike that is filtered at the source never triggers a false alarm or poisons a totalizer downstream. The platform's contribution is visibility: carrying both the raw and the filtered value lets an analyst confirm the filter is removing genuine glitches rather than masking a real fast event, and it makes the distinction between impulse noise, which a median should be handling, and a real rapid change, which it should be passing, something an operator can actually see rather than guess at.
It keeps the last N samples, sorts them, and outputs the middle one. A single spike or dropout sits at the top or bottom of the sorted list, never in the middle, so it is never chosen and is discarded outright. As long as fewer than half the samples in the window are corrupted, the median stays a good value, and once the spike ages out of the window it leaves no lingering trace in the output.
A moving average gives every sample a vote, so a spike is not rejected but diluted and spread across several consecutive outputs while it remains in the window, contaminating them. A median filter chooses one actual sample by rank rather than blending, so an isolated outlier is discarded completely with no lingering effect. This makes the median the right tool for impulse noise, whereas an average is better for continuous small-amplitude jitter.
A small odd-length window, most often three or five samples. Odd lengths give a single unambiguous middle value, and small windows keep the filter responsive with little lag and a quick sort. A three-sample median already rejects any single isolated spike; a five-sample median tolerates a couple of nearby bad samples at the cost of slightly more delay. Controllers favor short windows to get spike immunity without slowing a control signal.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.