The Use of PWM in Signal Processing: A Practical Approach

Pulse Width Modulation, or PWM, is one of those topics that engineering students learn early and then spend years discovering just how deep the rabbit hole goes. On the surface, it looks almost trivial: you switch a signal on and off fast enough, and the average value does what you want. But once you start working with real hardware — especially small actuators like the micro servo motor — you realize that PWM is less of a "digital trick" and more of a bridge between the clean, abstract world of digital signal processing and the messy, analog, physical world of motors, sensors, and inertia.

This article takes a practical route through PWM as a signal-processing tool, using the micro servo motor as the running example. Micro servos are everywhere: hobby robotics, camera gimbals, small drones, 3D-printed mechanisms, animatronics, and even desktop automation projects. They are cheap, widely available, and they respond to PWM in a way that exposes nearly every important concept in practical PWM signal processing — resolution, frequency trade-offs, jitter, filtering, and feedback. If you can master PWM for a micro servo, you can handle PWM almost anywhere.

Why the Micro Servo Motor Is the Perfect PWM Case Study

A typical micro servo — something in the SG90 or MG90S family — weighs under 20 grams, runs on 4.8 to 6 volts, and expects a control signal that most people describe as "a 50 Hz PWM signal with a 1 to 2 ms pulse width." That description is technically correct and practically incomplete, and the gap between those two things is where the real learning happens.

The servo's internal control loop compares the commanded pulse width against the actual position reported by a potentiometer connected to the output shaft. The difference drives a small DC motor through an H-bridge until the error shrinks to nearly nothing. From a signal-processing perspective, the servo is a closed-loop system whose setpoint is encoded in the time domain of a digital pulse train. That is a fascinating arrangement: the information isn't in the amplitude, and it isn't in the frequency (as long as you stay in the accepted range). It's in the width of a single high pulse, repeated at a relatively slow rate.

This makes the micro servo a natural stress test for PWM signal processing. You can generate a "correct" 50 Hz signal on paper and still watch the servo twitch, buzz, or jitter because of problems that only show up when you look at the signal as a sampled, quantized, timing-sensitive waveform rather than an ideal mathematical abstraction.

The Anatomy of a Servo PWM Signal

Period, Pulse Width, and the Meaning of Resolution

A standard hobby servo expects a pulse every 20 milliseconds. Within that period, a pulse width of about 1.0 ms commands one extreme of travel, 1.5 ms commands center, and 2.0 ms commands the other extreme. Many micro servos tolerate a slightly wider range, and some respond to 0.5 to 2.5 ms, but the safe practical window is usually narrower than the datasheet suggests.

Here's where signal processing enters the picture. The usable pulse-width range — say 1.0 ms to 2.0 ms — spans 1,000 microseconds. If your PWM generator has a timing resolution of 1 microsecond, you get roughly 1,000 distinct positions across the servo's travel. If your resolution is 10 microseconds, you get about 100 positions, which is often visibly steppy on a small, fast micro servo with a short horn. If your resolution is 0.1 microseconds, you get 10,000 positions, which is far beyond what the servo's internal potentiometer and gear train can actually resolve.

This is the first practical lesson: PWM resolution in signal processing is not the same as actuator resolution. Generating a 16-bit PWM signal for a micro servo is easy on modern microcontrollers, but the mechanical system will not honor that precision. Matching your PWM resolution to the physical actuator's real capability saves processing overhead, reduces jitter sensitivity, and produces smoother motion than blindly maximizing bit depth.

Frequency: The Trade-Off Nobody Warns You About

The classic 50 Hz servo frequency exists for historical reasons tied to old analog servo designs. Modern micro servos often accept 100 Hz, 200 Hz, or even 333 Hz, and higher update rates can produce noticeably smoother and more responsive motion — up to a point. Push too high and the servo's internal control loop can't keep up, causing buzzing, overheating, or erratic behavior.

From a signal-processing standpoint, the control frequency sets the Nyquist limit for your command signal. If you want the servo to track a smooth trajectory, your command updates must be fast enough relative to the dynamics you're asking for. A 50 Hz update rate gives you a command bandwidth of roughly 25 Hz in the ideal case, which is fine for slow panning motions and marginal for fast robotic gestures. Raising the PWM frequency to 200 or 300 Hz widens that window considerably.

The practical approach is empirical: start at the datasheet frequency, increase gradually while monitoring temperature, current draw, and audible noise, and stop when the servo tells you it's unhappy. The micro servo is an excellent teacher here because it fails loudly and cheaply.

Signal Processing Problems That Show Up in Real Servo Systems

Jitter, Quantization, and the Illusion of Smoothness

Anyone who has driven a micro servo from a software PWM loop knows the buzz. Software-generated PWM is subject to scheduling jitter: the pulse you intended to emit at exactly 1,500 microseconds comes out at 1,487 or 1,512 because an interrupt fired late or a higher-priority task ran. The servo interprets every one of those variations as a position command, and the result is a constant low-amplitude oscillation that wastes power and wears the gears.

Hardware timers solve most of this, but not all of it. Even with a dedicated PWM peripheral, you still face quantization: the timer's clock divider determines the smallest pulse-width step you can produce. A 16-bit timer running at 1 MHz gives 1-microsecond steps, which is usually plenty for a micro servo. A timer running at 100 kHz gives 10-microsecond steps, which is marginal.

The practical fix is a combination of hardware timing and command filtering. If your application sends position commands from a higher-level controller, low-pass filtering the command stream before it reaches the PWM register can smooth out quantization steps without adding meaningful lag — provided the filter cutoff is chosen relative to the servo's mechanical response time, not to some arbitrary number.

Dead Band, Hysteresis, and Feedback

Micro servos have a dead band: a small range of pulse widths around the current position that produces no motor movement. This is intentional, and it prevents the servo from hunting constantly. But it complicates precise positioning, because the relationship between commanded pulse width and actual shaft angle is not perfectly repeatable. Hysteresis adds to the problem.

In signal-processing terms, the servo is a nonlinear system with memory. Treating it as a simple linear map from pulse width to angle will produce disappointing results in any application that needs repeatability. The practical approach is to characterize the specific servo you're using — sweep the pulse width slowly, record actual position with an external sensor, and build a calibration curve. For many hobby applications this is overkill, but for camera gimbals, precision robotic joints, and anything involving coordinated multi-servo motion, it's the difference between a toy and a tool.

PWM as Part of a Larger Signal Chain

The micro servo rarely lives alone. In a typical small robot, a microcontroller generates PWM commands, possibly through a dedicated servo driver IC, while reading sensors over I2C or SPI. The PWM signal is one link in a chain that includes sensor sampling, command generation, trajectory interpolation, and sometimes closed-loop feedback from an external encoder.

Seeing PWM as a signal-processing stage rather than an isolated feature changes how you design the system. Command generation should account for the servo's response time. Trajectory interpolation should respect the PWM update rate. Sensor feedback should be filtered with a cutoff appropriate to the servo's dynamics. And the whole chain should be tested with instrumentation — a logic analyzer on the PWM line and a current probe on the power supply will reveal problems that no amount of code review will catch.

Practical Takeaways for Working with Micro Servos

A few habits separate smooth, reliable servo projects from jittery, buzzing ones. Use hardware timers for PWM generation whenever possible, and reserve software PWM for cases where timing jitter genuinely doesn't matter. Match your PWM resolution to the actuator rather than to your timer's maximum capability. Choose the update frequency empirically, starting from the datasheet and increasing cautiously. Filter command streams when quantization is visible in the motion. Characterize the dead band and hysteresis if repeatability matters. And always, always measure the actual signal on the wire — the pulse train your code intends and the pulse train your hardware emits are rarely identical.

The micro servo motor is a small, cheap, forgiving device, which is exactly why it's such a good teacher. It exposes PWM signal-processing concepts in a form you can see, hear, and feel. Get PWM right for a micro servo, and the same principles scale directly to larger motors, LED dimming, power converters, and audio class-D amplifiers. The math is the same; only the stakes change.