control//feedback control//control loop//loop delay

2025-11-02

Loop delay is the total time between something happening in the plant and the controller's answer to it reaching the plant again, summed over every element on the way round (the sensor's own processing, the filters, the bus, the sampling, the computation, the actuator, the pipe), and it is what limits how fast and how hard any feedback loop can be tuned. Anyone who has showered in a hotel with three seconds of pipe between tap and shoulder knows the mechanism: cold, open the hot tap, nothing happens, open more, scalding water arrives, close hard, ice arrives. The correction keeps landing after the error has already changed sign.

In numbers, a pure delay τ\tauτ shifts a sinusoidal error without changing its size, which is a phase lag growing with frequency, φ(ω)=−ωτ\varphi(\omega)=-\omega\tauφ(ω)=−ωτ. Somewhere the total lag round the loop reaches 180 degrees, the correction arrives in step with the error and pushes it further, and if the loop still amplifies at that frequency each round grows. Where the delay comes from is the first thing to know about a loop that oscillates:

Source Typical delay

Sampling and hold half a period: 0.5 ms at 1 kHz, 50 ms at 10 Hz

First-order low-pass at fcf_cfc about 1/(2πfc)1/(2\pi f_c)1/(2πfc): 8 ms at 20 Hz

Sensor processing a MEMS gyro's internal filter, a few ms; a GNSS fix, around 100 ms

Bus, network, computation an SPI read, a CAN frame, a PLC scan, a radio link

Motor and propeller a lag of 10 to 100 ms, not pure delay but it eats phase as well

Camera and vision 33 ms between frames at 30 per second, plus processing

Pipes and conveyors seconds to minutes

overshoot48 % settling, 2 %10.5 s steady error0.017 A setpoint step from 0 to 1 at 1 s, followed by a plant with two lags and a dead time of 0.40 s. With kp 2.00, ki 1.50 and kd 0.00 the output overshoots the setpoint by 48 %, settles within 2 % in 10.5 s and leaves an error of 0.017.

The PI gains here were tuned for 0.15 s of dead time; at 0.4 s the overshoot is about 48 %. Lower the dead time to 0.15 s and it falls to about 16 %; raise it to 0.7 s and the loop never settles. Then, at 0.4 s, lower KpK_pKp to 1.2 and KiK_iKi to 0.8: the overshoot drops to about 9 %, and the response is slower.

Every millisecond of delay costs degrees of phase margin, and faster loops pay more for each one.

Each loop runs at the rate its dynamics demand, and without more information the only defence against delay is to go slower. With more information there are two others: remove the delay at its source (a faster sensor, lighter filtering, reading, computing and writing in the same interrupt), or predict across it with a model.

The classic trap is to answer noise by filtering more. Every low-pass charges in phase, exactly what the delay already steals; drone firmware such as Betaflight uses notch filters that follow each motor's speed, removing motor noise at its exact frequency with far less lag than an aggressive low-pass (first-order low-pass filter).

Prediction is the second defence. The Smith predictor wraps the controller round a delay-free model, an MPC predicts by construction, and a Kalman filter can carry the state forward over a slow sensor's latency (delayed measurements).

How much delay a loop survives is its delay margin; the half period the hold adds is in zero-order hold; the mathematics of a delay against a lag is delay and lag, and the principle across the whole site is delay as the enemy.