Transfer functions and response time

"By the time I finish reporting the temperature, the temperature has moved on. I spend my whole life describing a world that no longer exists."

A Perpetually Late AI Agent

Static and dynamic transfer functions are two different questions

The word transfer function is overloaded, and separating its two meanings is the first job. The static transfer function is the input-output relationship after everything has settled: hold the stimulus fixed, wait, and record the reading. This is the calibration curve from Section 2.2, ideally the straight line \(y = k\,x + b\) with sensitivity \(k\) and offset \(b\). It answers where the reading lands. It says nothing about when.

The dynamic transfer function answers the "when." It describes how the output evolves in time when the input changes, and it exists because every sensor stores energy somewhere: heat in a thermal mass, charge on a capacitance, momentum in a proof mass. That storage cannot change instantly, so the output cannot either. Why does this deserve its own section rather than a footnote? Because for any signal that moves, the dynamic behavior dominates the error budget. A thermometer with a perfect calibration curve is still useless for catching a two-second temperature spike if it takes thirty seconds to respond. The static curve is a portrait; the dynamic transfer function is the sensor caught mid-stride.

The first-order model and its time constant

The overwhelming majority of sensors, at least to first approximation, behave as first-order linear systems. One number, the time constant \(\tau\), captures their entire dynamic personality. The governing rule is intuitive: the output chases the input, and its rate of catch-up is proportional to how far behind it is. Writing \(y(t)\) for the reading and \(u(t)\) for the true stimulus,

Now subject it to the experiment engineers actually run, a step input: at \(t = 0\) plunge the sensor from a value it had settled at into a new constant stimulus. The solution is the exponential approach every practitioner should have memorized,

where \(y_0\) is the starting reading and \(y_\infty\) the final one. The time constant \(\tau\) is the moment the sensor has closed \(1 - e^{-1} \approx 63.2\%\) of the gap. After \(3\tau\) it has covered \(95\%\); after \(5\tau\), \(99.3\%\), which is why "settled" is conventionally quoted as \(5\tau\). That single parameter also fixes the derived timings vendors like to advertise: the rise time from 10% to 90% of the step is \(t_{10\text{-}90} = \tau \ln 9 \approx 2.2\,\tau\).

How do you find \(\tau\) for a sensor you hold in your hand? You do not need a lab. Apply a step, log the response, and fit the exponential. The code below simulates a first-order thermal sensor with \(\tau = 4\) seconds, then recovers that value from the noisy trace, exactly the round trip you would perform on real hardware.

import numpy as np
from scipy.optimize import curve_fit

tau_true = 4.0                      # seconds; unknown in real life
t = np.arange(0, 25, 0.1)
step = 100.0 * (1 - np.exp(-t / tau_true))          # 0 -> 100 degree step
noisy = step + np.random.normal(0, 1.5, t.size)     # add sensor noise

model = lambda t, tau, y_inf: y_inf * (1 - np.exp(-t / tau))
(tau_hat, y_inf_hat), _ = curve_fit(model, t, noisy, p0=[1.0, 90.0])

print(f"recovered tau = {tau_hat:.2f} s  (true 4.00)")
print(f"rise time 10-90% = {tau_hat * np.log(9):.2f} s")

As Listing 2.5.1 shows, characterizing a sensor's speed is a two-line fit once you have a clean step. The harder part is arranging a genuinely instantaneous step in the physical world, which is often the real experimental challenge.

Frequency response: bandwidth is response time in disguise

Step response tells you how a sensor reacts to a sudden jump. But many real signals oscillate: a vibrating bearing, a beating heart, a swaying bridge. For these, the more natural description is the frequency response, and it turns out to be the same information wearing different clothes. Feed a first-order sensor a sinusoid, and it faithfully reproduces slow oscillations but progressively attenuates and delays fast ones. The dividing line is the cutoff frequency, tied directly to the time constant:

At \(f_c\), the sensor's output amplitude has dropped to \(1/\sqrt{2} \approx 0.707\) of the true amplitude, the famous -3 dB point, and the signal lags by 45 degrees. Above it, response falls off further; the sensor simply cannot see fast wiggles. This is why a slow sensor and a low-bandwidth sensor are the same object: our reflow thermocouple with \(\tau = 6\) s has a cutoff of only \(f_c \approx 0.027\) Hz, so it is blind to anything faster than a slow half-minute swell. The reciprocal relationship \(f_c \tau\) being fixed is one of the most useful sanity checks in sensing: quote either the time constant or the bandwidth, and you have implicitly quoted the other.

This connects forward to two later ideas. First, a sensor's bandwidth sets the maximum meaningful sample rate; sampling a \(0.027\) Hz sensor at 1 kHz just captures the same slow curve a thousand times over, a waste that Chapter 3 makes precise through the Nyquist limit. Second, a sensor is a low-pass filter you did not choose, and understanding it as one is the mental bridge to the filters you do choose in Chapter 6.

from scipy.signal import TransferFunction, lsim
import numpy as np

tau = 4.0
sensor = TransferFunction([1], [tau, 1])     # first-order low-pass, gain 1
t = np.arange(0, 25, 0.1)
u = (t > 2).astype(float)                     # a step at t = 2 s
t_out, y, _ = lsim(sensor, U=u, T=t)         # sensor's response to u

When one time constant is not enough: overshoot and latency

Not every sensor settles politely. Add mass and a restoring spring, as in an accelerometer or a pressure diaphragm, and you get a second-order system that can overshoot: swing past the true value, ring, and settle only after a few oscillations. Its behavior is governed by two numbers, a natural frequency \(\omega_n\) and a damping ratio \(\zeta\). When \(\zeta < 1\) the sensor is underdamped and rings; a lightly damped MEMS accelerometer near its resonance can report a transient spike far larger than the real acceleration, which a naive threshold detector will happily flag as an impact. Sensor designers usually target \(\zeta \approx 0.7\), the sweet spot that reaches the final value fastest without appreciable overshoot.

Separate from this smearing is pure latency, a fixed transport delay from processing, wireless transmission, or digital filtering inside the sensor package. Smoothing and lag are different sins: smoothing blurs a change, latency shifts it wholesale in time. Both matter enormously for anything in a control loop. An estimator such as the Kalman filter in Chapter 9 can be told a sensor's time constant and delay and will compensate for them, effectively running the transfer function backward to recover a sharper estimate of the true state. But it can only undo lag it knows about, which is the entire reason this section insists you measure \(\tau\) and the delay before you trust the number.

Response time, in the end, is where the tidy static picture of Sections 2.2 through 2.4 collides with a moving world. A sensor is not a snapshot device; it is a filter with memory, and the transfer function is the exact contract stating how much of the present it will let through and how much of the past it is still reporting. Read that contract before you build on the numbers.

What's Next

In Section 2.6, we confront the fact that a sensor's transfer function is rarely a function of one input alone. A humidity sensor drifts with temperature; a gas sensor responds to the wrong gas; a strain gauge answers to heat as readily as to force. That unwanted coupling, cross-sensitivity, is the next crack in the clean measurement model, and learning to model it is the last step before we assemble the full sensor equation that bridges physics to AI.