How a moving average filter smooths a noisy sensor

A moving average smooths a noisy sensor by replacing each reading with the average of the last N readings. Random noise pushes each reading a different way, so in a sum the ups and downs partly cancel while the real value adds up in full. Averaging N readings shrinks the noise by about √N: 16 readings leave a quarter of it. The cost is time.

Why averaging works

Say a sensor reads 511 with noise of up to ±30. One reading might say 538, the next 494. Add 16 readings together and the true 511 adds up 16 times, but the noise, pointing every which way, grows only about √16 = 4 times as much. Divide by 16 and the noise has shrunk to a quarter:

So ±30 becomes about ±7.5 with 16 readings, and about ±3.75 with 64. Each halving of the noise needs four times the readings.

A running average in code

A moving average keeps the last N readings in a ring buffer and a running total. Each new reading replaces the oldest, so there's an average on every sample, not just every N:

const int N = 16;
int buf[N];
int idx = 0;
long total = 0;

int smoothed(int reading) {
  total = total - buf[idx] + reading;   // drop the oldest, add the newest
  buf[idx] = reading;
  idx = (idx + 1) % N;
  return total / N;
}

The total is a long because 64 readings near 1023 add up to more than an Uno's int can hold. The buffer starts full of zeros, so the first N outputs climb up from 0; fill it with real readings in setup() if that matters.

What it costs

Averaging only removes random noise. A steady offset, a wrong calibration, survives any amount of averaging. And a single wild spike, from a loose wire, gets smeared into several outputs instead of removed; a median filter handles those better.

Where you'll meet it

Thermometers, scales, battery gauges and light meters all average their readings, because people would rather see a steady number than a flickering one. When memory is tight, an exponential moving average gives a similar result with one variable instead of a buffer.