A transfer function is a mathematical representation, typically expressed in the Laplace domain (s-domain) for continuous-time systems or the Z-domain for discrete-time systems, that describes the relationship between a system's output and its input, commonly as a ratio of polynomials for rational LTI systems (though non-rational forms exist, such as those involving pure delays). It characterizes how a linear, time-invariant (LTI) system transforms an input signal into an output signal across all frequencies.
In practice
Transfer functions appear prominently in embedded control systems, though they are equally central to digital signal processing, communications, and general control theory. When implementing a PID loop, a digital filter, or a motor driver, the transfer function of the plant (the physical system being controlled) and the controller are derived and analyzed before a single line of firmware is written. The poles and zeros of the transfer function strongly influence stability, bandwidth, and transient response, though these properties also depend on loop gain, damping, and the specific closed-loop configuration. For example, a second-order low-pass filter has two poles in the s-domain; moving those poles closer to the imaginary axis reduces damping and increases ringing in the step response.
In digital embedded systems, continuous-time transfer functions are discretized before implementation. Common methods include Tustin (bilinear) transformation, zero-order hold (ZOH), and matched pole-zero mapping. The choice of discretization method and sample rate affects how faithfully the discrete implementation matches the original analog design. A sample rate that is too low relative to the system bandwidth introduces phase lag, aliasing, and other discretization effects that can destabilize a control loop that was stable in the continuous-time analysis. The blog post "Feedback Controllers - Making Hardware with Firmware. Part 2. Ideal Model Examples" illustrates this workflow with concrete controller designs.
Transfer functions are also central to digital filter design, where the Z-domain transfer function H(z) directly maps to a difference equation that runs on the MCU. In a standard direct-form implementation, the numerator coefficients become the feedforward (FIR-like) taps and the denominator coefficients become the feedback (IIR) taps, though other structures distribute coefficients differently. Coefficient quantization on fixed-point processors (common on DSP cores and low-cost MCUs without an FPU) can shift poles and zeros enough to degrade filter performance or cause instability, so this must be validated after quantization. The blog post "Determination of the transfer function of passive networks with MATLAB Functions" demonstrates how to extract transfer functions from passive circuit topologies before committing to a hardware or firmware design.
For systems with multiple feedback paths, computing the overall transfer function by hand becomes error-prone. Signal flow graph techniques such as Mason's Rule, covered in "Using Mason's Rule to Analyze DSP Networks," provide a systematic method to derive the closed-loop transfer function directly from a block or signal-flow diagram. Multirate systems (where different parts of the signal chain operate at different sample rates) complicate the transfer function picture further; the blog post "Do Multirate Systems Have Transfer Functions?" addresses when and how transfer functions can still be applied in those contexts.
Discussed on DSPRelated
Frequently asked
What is the difference between the s-domain and Z-domain transfer function?
The s-domain (Laplace) transfer function describes continuous-time systems, where the variable s = sigma + j*omega captures both growth/decay (sigma) and oscillation (omega). The Z-domain transfer function describes discrete-time systems, where z = e^(sT) and T is the sample period. In embedded work you typically start with an s-domain model of the analog plant, then apply a discretization method (Tustin, ZOH, etc.) to obtain the Z-domain transfer function that is actually implemented as a difference equation on the processor.
How do I turn a Z-domain transfer function into code?
Express H(z) as a ratio of polynomials in z^(-1) (unit delays), then cross-multiply to get a difference equation. Each z^(-1) term corresponds to one sample of delay, stored in a state variable array. For a second-order
IIR section H(z) = (b0 + b1*z^-1 + b2*z^-2) / (1 + a1*z^-1 + a2*z^-2), the output y[n] = b0*x[n] + b1*x[n-1] + b2*x[n-2] - a1*y[n-1] - a2*y[n-2]. Cascaded biquad (second-order section) structures are generally preferred over high-order direct-form implementations because they tend to limit coefficient sensitivity and offer better numerical behavior on fixed-point hardware, though the actual stability improvement depends on the specific realization and scaling used.
Why do transfer function coefficients cause problems on fixed-point MCUs?
Poles and zeros of a high-order transfer function in direct form can be numerically very sensitive to small changes in coefficients. When coefficients are rounded to fit a fixed-point
Q-format (e.g., Q15 on a 16-bit DSP core), the actual pole locations shift, which can change the
frequency response noticeably or, in the worst case, move a pole outside the unit circle and cause instability. Using cascaded biquad (second-order section) structures limits each section to two poles and two zeros, reducing sensitivity. Always simulate the quantized coefficients before deploying to hardware.
Can transfer functions model nonlinear systems like a switching power supply?
Not directly. Transfer functions apply strictly to linear, time-invariant (LTI) systems. Switching converters and other nonlinear plants are commonly analyzed using small-signal linearization: the system is perturbed around a steady-state operating point and a linear transfer function (e.g., the control-to-output transfer function of a buck converter) is derived for that point. This is valid near the operating point but does not capture large-signal behavior, startup transients, or behavior across a wide range of load or input voltage variation.
What tools are commonly used to derive and validate transfer functions in embedded projects?
MATLAB and its Control System / Signal Processing toolboxes are widely used for deriving, discretizing, and simulating transfer functions before implementation. Python with
scipy.signal provides similar capability as an open-source alternative. For analog front-end circuits, SPICE AC analysis or tools like the MATLAB-based approach described in 'Determination of the transfer function of passive networks with MATLAB Functions' can extract transfer functions directly from the netlist. On hardware, a
frequency response analyzer or a network analyzer (or a software equivalent using injected test signals) is used to measure the actual loop transfer function and compare it against the model.
Differentiators vs similar concepts
Transfer function vs.
impulse response: the impulse response h(t) or h[n] is the time-domain equivalent; the transfer function H(s) or H(z) is its Laplace or
Z-transform. For causal, stable LTI systems under the standard transform assumptions, they carry equivalent information, but practical recoverability depends on the system class and whether the transform conditions are satisfied. The transfer function form makes frequency-domain analysis (pole-zero placement, Bode plots, stability margins) more tractable. Transfer function vs. state-space representation: both describe LTI systems completely, but state-space handles multiple-input multiple-output (MIMO) systems and numerical integration more naturally, which is why modern control toolboxes and embedded model-based design tools (e.g., Simulink Embedded Coder) often use state-space internally even when the designer thinks in transfer function terms.
