Flickering low-order digits keep drawing attention away from the trend those digits belong to
Aliases: numeric jitter · signal smoothing · chattering readout
What it is
Numeric jitter is the visible flicker produced by high-frequency measurement noise or an overly aggressive display refresh rate — the low-order digits of a readout keep changing. It keeps pulling attention to the fact that the number is moving at all, which makes it harder, not easier, to tell which direction the variable is actually heading, how fast, and whether it is settling — a distinct failure mode from either of its sibling cues.
Why it happens
People are highly sensitive to discrete numeric change; almost every flip of a low-order digit gets noticed. But working memory cannot reconstruct a continuous trajectory from a stream of values that keep replacing each other — noticing that something changed and perceiving where it is heading and how fast are two different acts, and the first is nearly effortless while the second requires stitching several moments together in the mind, a task that gets harder the more violently the display jitters.
Rounding, low-pass filtering, or reducing the refresh rate can all make a display look calmer, but there is a reversal condition that has to be resolved first: whether smoothing is the right move depends entirely on what is causing the jitter, not on how large it looks. If the jitter is uncorrelated measurement noise — electrical interference, quantization error — smoothing it away is reasonable. If the "jitter" is itself the signal of a real mechanical state — cavitation, vibration, an intermittent electrical contact — smoothing it away erases the diagnostic evidence along with the noise. Telling the two apart usually means checking whether the fluctuation correlates with a known mechanical frequency (rotation speed, a vibration band), not just eyeballing its amplitude.
Smoothing also has an engineering cost: filtering and refresh-throttling trade time for stability, hiding genuinely small transients and introducing phase delay. That means the value shown on the display, the value driving alarm logic, and the value archived for post-incident review cannot safely be the same number — mixing them means "calm" on screen can just mean the filter has not caught up yet.
Studying it
A systematic design varies noise amplitude, display refresh rate, and smoothing window independently, and compares operators' trend-direction judgments, their estimates of when the signal settles, and their detection of genuine transients across conditions. Both the underlying sensor sampling rate and the interface's own refresh rate need to be recorded separately — they are often conflated, but one is the time resolution of the data itself and the other is a presentation-layer throttle, and reporting them together is what makes the result reproducible.
Where it stops holding
Tasks that need precise adjustment or fast recognition of a transient cannot tolerate heavy smoothing — over-smoothing actively discards the information the task depends on. Before deciding a given fluctuation can be smoothed, it has to be ruled out as a symptom of cavitation, vibration, or a poor contact; skipping that check risks treating a developing mechanical fault as a display nuisance.
Calming a display must never rewrite the raw data that alarm logic and post-incident records rely on: if alarm evaluation consumes a smoothed display value instead of the raw signal, the alarm's response time is silently stretched by the filter's phase delay, and once that delay approaches the safety response-time budget, smoothing has stopped being a comfort feature and become a hazard in its own right.
Applying it
Round the displayed value to the precision the decision actually needs rather than showing every significant digit available; place a small trend or direction indicator beside the number so "which way it's going" is conveyed separately from the digits themselves; label the smoothing window explicitly and keep an on-demand path to the raw, unsmoothed samples rather than making the smoothed view the only one available.
Base alarm evaluation on logic that is independent of display smoothing — debounce or hysteresis applied to the raw signal, not to the already-smoothed display value — so the same noise event is not processed twice into two inconsistent outcomes.
How to check: replay historical data that includes a slow-drift segment, an isolated genuine spike, and a real high-frequency mechanical fault together, and check whether the smoothed display still lets an operator read the drift direction, still shows the isolated spike, and does not filter out the fault's characteristic frequency. Passing on all three confirms the smoothing parameters are right; losing any one of them means the noise reduction has gone too far.