Introduction
“Stability” in DSP is not a single concept.
A filter can be:
- mathematically stable on paper
- numerically unstable after quantization
- system-unstable when integrated into a control loop
- regression-unstable when small changes produce different outputs
This pillar provides an embedded, production-oriented framework for stability:
- define stability layers
- understand dominant failure modes in IIR
- understand fixed-point-specific pathologies
- choose FIR vs IIR with engineering constraints
- validate stability quantitatively
The Three Layers of Stability
1) Mathematical Stability
Classic definition: poles inside the unit circle.
Necessary, but not sufficient.
2) Numerical Stability
Finite precision moves poles, changes effective Q, and amplifies rounding error.
This is where “stable in simulation” becomes “unstable in firmware”.
3) System Stability
Even a stable filter can destabilize a closed-loop system via delay, phase distortion, or interaction with downstream logic.
Why High-Q IIR Notches Are a Production Risk
High Q implies poles near the unit circle.
This increases sensitivity to coefficient rounding.
Symptoms in production:
- ringing / long transient decay
- oscillation under small numerical perturbation
- frequency response drift between builds
- “it worked in Python but fails on MCU”
High-Q failure mechanisms and guardrails are detailed here:
Why High-Q IIR Notch Filters Become Unstable in Real DSP Systems (And How to Fix It)
Fixed-Point Failure Mode: Limit Cycles
Fixed-point introduces behaviors that do not exist in floating-point:
- quantization of state variables
- rounding of feedback paths
- saturation / wrap-around behavior
Limit cycles are self-sustaining oscillations caused by quantized feedback.
A focused engineering explanation is here:
Limit Cycles in IIR Filters Under Fixed-Point Arithmetic
The practical takeaway:
If you deploy IIR in fixed-point, you must treat limit cycles as a design constraint, not a rare bug.
Structure Matters: Why Implementation Form Changes Risk
Two mathematically equivalent IIRs can behave very differently numerically.
Practical guardrails:
- prefer SOS (biquad cascade) over high-order direct forms
- normalize coefficients consistently (a0 = 1)
- scale to avoid internal overflow in fixed-point
- verify impulse decay and stability margins after quantization
FIR vs IIR in Embedded Systems
FIR and IIR are not “better vs worse”.
They are different stability and cost profiles.
A dedicated comparison is here:
FIR vs IIR Stability in Embedded DSP Systems
FIR Strengths
- inherently stable (no feedback)
- predictable under quantization
- linear-phase possible (if symmetric)
FIR Costs
- more taps → more CPU
- more taps → more delay/latency
- aggressive specs may be expensive
IIR Strengths
- efficient sharp selectivity (e.g., notches)
- fewer operations for similar magnitude response
- good for narrowband suppression
IIR Risks
- numerical fragility under high Q
- fixed-point limit cycles
- sensitivity to coefficient rounding and scaling
Phase, Delay, and System-Level Stability
Even “stable” filters can cause system instability by changing:
- group delay
- phase margin
- transient response shape
Group delay and phase distortion tradeoffs are covered here:
Group Delay and Phase Distortion in Real DSP Pipelines
Latency vs complexity constraints are covered here:
Real-Time DSP: Latency vs Filter Complexity
A Deployable Decision Matrix (Engineer-Friendly)
Use this as a default decision guide:
Choose IIR Notch (SOS) when:
- interference is narrowband tonal
- drift envelope is known and bounded
- you can enforce bounded Q and stability margins
- you can validate coefficients post-quantization
Choose FIR when:
- phase/shape preservation matters
- fixed-point risk is high
- you can afford taps/latency
- you need predictable behavior across builds
Choose Hybrid when:
- use IIR notches for tonals
- use FIR for broadband shaping / passband protection
- verify as a combined system
Stability Verification Checklist (Minimal, Effective)
A stability-safe pipeline should verify:
- impulse response decay (no sustained ringing beyond expectation)
- coefficient sanity (margins away from pathological extremes)
- frequency response robustness (small perturbations do not flip behavior)
- fixed-point simulation (if target is fixed-point)
- regression repeatability (reruns produce consistent results)
Verification metrics as an engineering discipline are covered here:
Engineering Metrics for DSP Filter Verification
Series Map — Stability Pillar and Supporting Articles
- Stability Pillar (this page): embedded stability framework and decision matrix
- Why High-Q IIR Notch Filters Become Unstable (And How to Fix It)
- Limit Cycles in IIR Filters Under Fixed-Point Arithmetic
- FIR vs IIR Stability in Embedded DSP Systems
- Group Delay and Phase Distortion in Real DSP Pipelines
- Real-Time DSP: Latency vs Filter Complexity
Conclusion
Embedded DSP stability is not a checkbox.
It is a system property that emerges from:
- architecture choices (FIR vs IIR)
- numerical constraints (Q bounds, quantization, scaling)
- implementation structure (SOS, normalization)
- system integration effects (delay, phase margin)
- verification discipline (quantitative, repeatable checks)
This is how filters become deployable instead of “works in a notebook”.