Filter design for real-time, low-latency systems

"The filter had a beautiful frequency response. It also needed the next 200 samples to compute the current one, which is a problem when the current one is what triggers the airbag."

A Suddenly Practical AI Agent

The real-time contract: causal, bounded, on time

What a real-time filter signs up for is a contract with three clauses. It must be causal, so the output at sample \(n\) depends only on inputs up to and including \(n\); a zero-phase filter that runs the data forwards and backwards, or a symmetric FIR that centers its window, both peek into the future and are therefore offline-only. It must be bounded in state, keeping a fixed, small number of past values rather than the whole history. And it must be bounded in time: the work per sample must complete before the next sample lands, which at \(f_s = 1\) kHz means every output is due in one millisecond, no exceptions.

Why the deadline dominates is that sensor loops are usually closed. In a robot's attitude controller (Chapter 24) the filtered gyro drives a motor command that changes the very quantity being measured. A filter that is even one sample late injects extra phase lag into that loop, and phase lag is what turns a stable controller into an oscillating one. How you honor the contract begins with picking a structure whose cost per sample is a small, fixed number of multiply-accumulate operations, and whose latency you can state in samples before you write a line of code.

Latency here has two parts. Algorithmic latency is the group delay the filter imposes by construction: a length-\(M\) linear-phase FIR delays everything by \((M-1)/2\) samples no matter how fast your processor is. Computational latency is the wall-clock time to evaluate the filter each sample. The first is a property of the math and is the subject of Section 6.7; the second is a property of your implementation and hardware, and is what the rest of this section attacks.

Streaming implementations that carry their state

The idea that makes online filtering possible is that both FIR and IIR filters are recursive in their memory: the only thing an output needs from the past is a short vector of previous inputs and outputs, not the samples themselves. A direct-form IIR filter of order \(N\) computes

so its entire dependence on history is \(2N\) stored numbers. Between calls you save that state; on the next sample you use it and update it. This is exactly what lets a batch routine and a sample-by-sample loop produce identical output: you split the stream into blocks and thread the filter's internal state from the end of one block into the start of the next. Skip that threading and you get an audible click or a spurious spike at every block boundary, because the filter silently restarts from zero.

The compute and memory budget

Once the structure is fixed, cost is countable. A direct-form IIR filter of order \(N\) costs about \(2N+1\) multiply-accumulate operations (MACs) per sample; an FIR of length \(M\) costs \(M\). This is the central reason IIR filters dominate low-latency embedded work: an elliptic IIR of order 6 can match the stopband of an FIR of length 100 or more, so it does a twentieth of the arithmetic and stores a handful of state values instead of a hundred. On a microcontroller running your filter at \(f_s\) samples per second, the arithmetic budget is simply \(\text{MACs per sample} \times f_s\), and it competes with everything else the Chapter 61 workload wants to do on the same core.

Two further budgets bite on real hardware. Memory: FIR length \(M\) needs an \(M\)-tap delay line, which for sharp low-frequency filters can dwarf the IIR alternative. Numerics: many embedded targets have no floating-point unit, so filters run in fixed-point integer arithmetic, where a high-order direct-form IIR is dangerously sensitive to coefficient rounding and can drift or even go unstable. The fix is not to abandon IIR but to factor it, which we come to next.

Numerical stability: cascade the filter into biquads

The professional way to implement any IIR filter of order above two is not one big direct-form section but a cascade of second-order sections (SOS), each a biquad handling one pole pair and one zero pair. Mathematically the product of the sections equals the original transfer function; numerically it is a different world. In a single high-order direct form, the poles crowd together and a tiny rounding error in one coefficient can shove a pole outside the unit circle, and the filter blows up. Splitting into biquads keeps each section's coefficients well-conditioned, so fixed-point rounding perturbs the response slightly instead of destabilizing it. Every serious embedded DSP library ships biquad primitives for exactly this reason. The code below shows the streaming pattern that matters: carry the SOS state across blocks so a chunked stream matches a one-shot filtering exactly.

import numpy as np
from scipy.signal import butter, sosfilt, sosfilt_zi

fs = 100.0
# 4th-order Butterworth bandpass, 0.5-4 Hz, as second-order sections:
sos = butter(4, [0.5, 4.0], btype="band", fs=fs, output="sos")

# Initialize the filter's internal state (one state vector per section):
zi = sosfilt_zi(sos)                       # steady-state for a DC input

def stream(chunk, zi):
    """Filter one arriving chunk, returning output and the UPDATED state."""
    y, zi = sosfilt(sos, chunk, zi=zi)     # zi carried across calls
    return y, zi

# Simulate a live stream arriving 10 samples at a time:
signal = np.random.randn(1000)
zi = zi * signal[0]                        # prime state to avoid a startup thump
out = []
for start in range(0, len(signal), 10):    # blocks of 10 -> 100 ms of samples
    y, zi = stream(signal[start:start+10], zi)
    out.append(y)
streamed = np.concatenate(out)

# Identical to filtering the whole array at once (state threading works):
oneshot, _ = sosfilt(sos, signal, zi=sosfilt_zi(sos) * signal[0])
print("max block-vs-oneshot difference:", np.max(np.abs(streamed - oneshot)))

Notice two production details in that loop. State is threaded through zi, so the blocked result equals the one-shot result to machine precision, which is the invariant every streaming filter must preserve. And the state is primed to the first sample rather than left at zero, which suppresses the startup transient that would otherwise take the filter's settling time to decay, a thump that in a control loop reads as a real event.

sos = butter(4, [0.5, 4.0], btype="band", fs=fs, output="sos")
y, zi = sosfilt(sos, chunk, zi=zi)   # design + stable cascade + carried state

When you cannot afford any group delay

Sometimes even a few samples of algorithmic delay is too much, and there are two escape routes. The first is a minimum-phase filter: for a given magnitude response, the minimum-phase realization has the smallest possible group delay, at the cost of a nonlinear phase that distorts waveform shape. Trade it when you care about when an event happens (a threshold crossing, an impact) more than about preserving pulse shape. The second route abandons fixed filters for a recursive estimator, the Kalman filter of Chapter 9, which is strictly causal, updates in fixed cost per sample, and produces an optimal current-time estimate with no look-ahead by using a model of how the signal evolves rather than a fixed frequency template. For many low-latency sensing loops the right answer is not a sharper filter but a model-based estimator, which is precisely why the book pivots to state estimation next.

What's Next

In Section 6.7, we make the tradeoff this section treated as a fixed budget into a design variable, quantifying exactly how much noise reduction each millisecond of delay buys you, and how to choose the operating point deliberately rather than by accident.