The Role of PWM in Signal Modulation: Applications and Techniques

If you’ve ever watched a tiny robotic arm twitch to life, a camera gimbal smoothly pan across a room, or a 3D printer’s extruder glide to a precise coordinate, you’ve witnessed the quiet magic of PWM. Pulse Width Modulation is the unsung hero of countless embedded systems, but nowhere is its role more visceral, more tangible, than in the humble micro servo motor. These little brass-geared workhorses—the SG90, the MG90S, the TowerPro clones—are essentially PWM interpreters. They take a square wave, decode its duty cycle, and convert it into angular position with a precision that can make a robot finger feel almost organic.

In this deep dive, we’re going to strip PWM down to its bare bones, then rebuild it around the micro servo motor. We’ll explore the physics, the protocol, the tuning techniques, and the common pitfalls—all through the lens of that 9-gram marvel that sits in every hobbyist’s drawer.

The Core Concept: Duty Cycle Is the Language, Not Frequency

Let’s get the most common misconception out of the way first. When we talk about PWM for servo control, we are not talking about frequency modulation. The frequency of a servo PWM signal is almost always fixed at 50 Hz (a period of 20 ms). What changes is the duty cycle—the percentage of time the signal is HIGH versus LOW.

But here’s the twist: a micro servo motor doesn’t care about the percentage. It cares about the absolute pulse width in microseconds. That’s a critical distinction.

• 1 ms pulse → typically 0° (full counterclockwise)
• 1.5 ms pulse → typically 90° (center)
• 2 ms pulse → typically 180° (full clockwise)

Now, if you’re running a 50 Hz signal, a 1 ms pulse has a duty cycle of 5% (1 ms / 20 ms). But if you accidentally set your PWM frequency to 100 Hz (10 ms period), a 1 ms pulse becomes a 10% duty cycle—yet the servo still moves to 0°. Why? Because the servo’s internal circuitry is looking at the width of the HIGH pulse, not the ratio. This is the single most important technical nuance for anyone working with micro servos.

Why 50 Hz? The Analog Roots of the Micro Servo

The 50 Hz standard isn’t arbitrary. It dates back to the 1960s and the original radio control (RC) hobby servos, which used analog comparators and a simple monostable multivibrator. The reference pulse was generated by a potentiometer wiper on the output shaft. When the input pulse width matched the internal reference pulse, the error was zero, and the motor stopped. The 20 ms period was chosen because it gave the control loop enough time to sample, compare, and correct without causing jitter or overheating the tiny DC motor inside.

Modern micro servos like the SG90 still use this exact architecture. They contain a small control IC (often a dedicated servo driver or a generic 555 timer variant), a feedback potentiometer, and a 3-pole pager motor. The PWM input is just a trigger. The servo does the rest.

The Micro Servo’s PWM Sweet Spot: Dead Band and Neutral Zone

Here’s where technique comes in. A raw PWM signal with a 1.5 ms pulse will, in theory, center the servo at 90°. But in practice, the SG90 has a dead band—a range of pulse widths around 1.5 ms where the motor simply doesn’t respond. For most cheap micro servos, that dead band is roughly ±5 µs to ±10 µs. So a 1.49 ms pulse and a 1.51 ms pulse might both result in the same physical position.

Why does this matter? Because if you’re building a closed-loop position controller (e.g., a pan-tilt camera stabilizer), you need to know that tiny PWM changes below the dead band are wasted energy. Your control algorithm will fight itself, causing humming and overheating. The technique is to add a dithering step: when the error is within the dead band, stop updating the PWM entirely. Let the servo rest.

The 500 µs to 2500 µs Extended Range: A Dangerous Trick

Most micro servos are spec’d for 1 ms to 2 ms. But many hobbyists have discovered that you can push the pulse width to 0.5 ms and 2.5 ms, unlocking a wider angular range (sometimes up to 210°). This is called extended travel or overdrive.

The technique is tempting, but it’s a double-edged sword. The internal potentiometer in an SG90 is mechanically limited. If you command a pulse width that drives the output arm past the pot’s physical stop, the motor will stall, draw excessive current (potentially 1A+), and burn out the driver transistor or strip the nylon gears. If you must use extended range, do it in software with a soft limit—clamp your PWM values to, say, 0.6 ms and 2.4 ms, and never allow a rapid step change from one extreme to the other. Ramping (incrementally changing the pulse width by 1 µs every 10 ms) is another essential technique to avoid mechanical shock.

Generating High-Precision PWM for Micro Servos: Three Distinct Techniques

Now let’s get practical. How do you actually generate that 50 Hz, 1–2 ms pulse? The answer depends on your platform, but the techniques fall into three camps.

1. Hardware PWM Peripherals (The Right Way)

Microcontrollers like the Arduino Uno (ATmega328P), ESP32, and STM32 have dedicated timer/counter peripherals that can output PWM without CPU intervention. For example, on an ATmega328P, Timer1 is a 16-bit timer that can be configured for phase-correct PWM on pins 9 and 10. You set the top value (ICR1) to 39999 for a 50 Hz signal with a 16 MHz clock and a prescaler of 8. Then, to get a 1.5 ms pulse, you set OCR1A to 3000 (since each tick is 0.5 µs, 3000 ticks = 1.5 ms).

The advantage is zero jitter. The hardware timer is crystal-accurate. The CPU is free to do other tasks. This is the gold standard for multi-servo robots where you’re driving 12 servos simultaneously and can’t afford timing drift.

2. Software Bit-Banging (The Hacky but Flexible Way)

If you’re out of hardware timers, you can manually toggle a GPIO pin using delayMicroseconds(). The classic Arduino Servo.h library actually uses a software interrupt (Timer1 on the Uno) that cycles through servos one at a time, holding each pulse width with busy-wait delays.

The problem is obvious: while you’re holding a 1.5 ms pulse, your main loop is frozen. If you have more than 4–5 servos, the total time spent in the interrupt handler grows, and you start missing other tasks. A better software technique is to use a state machine with a single hardware timer interrupt that fires every 20 ms. In the ISR, you set the pin HIGH, then you use a second timer (or a microsecond counter) to schedule the LOW transition. This way, the CPU is only tied up for a few microseconds per servo.

3. The DMA and PWM-DAC Hybrid (For Analog-Style Smoothness)

Here’s a more advanced technique used in high-end robotic hands. Instead of discrete pulses, you can use a PWM signal with a very high frequency (e.g., 20 kHz) and a low-pass filter (RC circuit) to create an analog voltage. Then you feed that voltage into the servo’s signal line. But wait—servos don’t accept analog voltage! They need digital edges.

However, you can trick a micro servo by using a PWM-DAC to generate a slowly varying pulse width. For example, you set your hardware PWM frequency to 50 Hz, but you update the compare register every 100 µs via DMA from a lookup table. The table contains a sine wave of pulse widths. The result is a servo that moves with silky, acceleration-controlled motion, free of the jerky steps you get from a simple write() call. This is a technique used in cinematography gimbals to avoid micro-jitter on the footage.

The Jitter Problem: Why Your Servo Twitches and How to Fix It

Every micro servo user has seen it: the servo holds position, but there’s a faint, high-frequency vibration. That’s jitter, and it’s almost always a PWM timing issue.

• Root cause 1: Interrupt interference. If you’re using software PWM, any interrupt (e.g., from a radio receiver or an encoder) can delay the GPIO toggle by a few microseconds. Solution: disable interrupts during the critical pulse generation, or move to hardware PWM.
• Root cause 2: Power supply ripple. When the servo motor starts, it can draw up to 500 mA. If your 5V rail is shared with the microcontroller, the voltage sag can cause the PWM output voltage to drop below the servo’s logic HIGH threshold (usually 2.5V). The servo sees a glitch and twitches. Technique: use a separate 5V supply for the servo, and tie the grounds together. Add a 100 µF electrolytic capacitor across the servo power pins.
• Root cause 3: Floating input. If your microcontroller boots up before the servo is ready, the servo’s input pin might float. Some servos interpret a floating pin as a 1.5 ms pulse; others as a full-speed command. Fix: add a 4.7 kΩ pull-down resistor on the signal line, and hold the pin LOW for at least 100 ms after power-up.

Advanced Modulation: Beyond Position—PWM for Speed and Torque Control

A micro servo is a position servo, but you can repurpose PWM to control its behavior indirectly. Here’s a trick: by rapidly toggling between two pulse widths (e.g., 1.3 ms and 1.7 ms) at a frequency higher than the servo’s mechanical bandwidth (say, 100 Hz), you can create an effective average position. But the servo’s internal PID loop will try to reach each target, causing a violent oscillation. Instead, use PWM on the servo’s power line (the red wire) to modulate the supply voltage. By chopping the 5V supply with a MOSFET at 20 kHz, you reduce the average voltage to the motor, which reduces its maximum torque and speed. This is a crude but effective way to implement a soft-start or to limit current draw on a battery-powered robot.

Another technique is pulse-width stretching for feedback. Some high-end micro servos (like the Hitec HS-5485HB) output a PWM signal on the signal wire that encodes the actual position (via a back-EMF sensor). You can measure the width of that feedback pulse with an input capture timer. This allows you to close the loop externally, compensating for gear backlash and load-induced position error. The technique is simple: configure your MCU’s input capture to measure the HIGH time of the servo’s feedback line, then compare it to your commanded pulse width. The difference is the error. Feed that error into a PI controller, and you get a stiffer, more accurate servo.

The Real-World Technique: Driving 12 Servos with One Timer

Let’s put it all together with a concrete scenario. You’re building a hexapod robot with 12 micro servos (two per leg). You’re on an ESP32, which has 16 independent hardware PWM channels. But here’s the catch: the ESP32’s LEDC peripheral has a limited resolution at low frequencies. At 50 Hz, you can get up to 16-bit resolution (0–65535), but the high-speed timer is shared.

The technique to avoid cross-channel jitter is to use the same timer base for all 12 channels. In the ESP32 Arduino core, you call ledcSetup(channel, 50, 16) for each channel, but you use the same timer (e.g., timer 0) for all of them. The hardware automatically interleaves the channels. However, the ESP32’s PWM output is edge-aligned, not center-aligned. For servos, this doesn’t matter, but if you’re doing precision multi-servo synchronization (e.g., a robotic hand that needs all fingers to start moving at the exact same instant), you might see a skew of up to 20 µs between channels. The fix is to use the MCPWM peripheral instead, which allows synchronous updates via a shadow register. You write all 12 compare values, then trigger a global update latch. This is the technique used in professional animatronics.

The 50 Hz Myth: When Higher Frequencies Actually Help

We said 50 Hz is standard, but there’s a growing trend of running micro servos at 100 Hz or even 200 Hz. Why? Because the servo’s internal control loop samples the input pulse once per period. At 50 Hz, the loop updates every 20 ms. If you command a new position, the servo won’t even see it until the next rising edge. That’s up to 20 ms of latency. At 100 Hz, latency drops to 10 ms.

But here’s the catch: most analog micro servos have a fixed internal timing reference. If you feed them a 100 Hz signal, they still think the period is 20 ms. They will measure the pulse width correctly, but the internal error amplifier might not reset properly, leading to a slow oscillation or a hunting behavior. The technique is to test your specific servo. The SG90 actually works fine at 100 Hz because its internal one-shot retriggers on every rising edge. The MG996R, however, will overheat. The golden rule: if your servo runs warm at 50 Hz, don’t double the frequency.

The “Digital Servo” Exception

Digital micro servos (like the DS3218) have a microcontroller inside that samples the PWM at a much higher rate (e.g., 300 Hz) and drives the motor with a 24 kHz PWM. For these, you should use a higher input frequency (100–200 Hz) to match their internal update rate. A 50 Hz signal will make them feel sluggish. The technique here is to read the datasheet and set your PWM frequency to the servo’s refresh rate, not the classic 50 Hz.

Calibration and Linearization: The Final Technique

No two micro servos are identical. The 1.5 ms center pulse might actually be 1.48 ms on one SG90 and 1.52 ms on another. Worse, the relationship between pulse width and angle is not perfectly linear—it’s a curve caused by the potentiometer’s taper and the gear train’s eccentricity.

The technique to fix this is per-servo calibration. Here’s a step-by-step procedure:

1. Mount a laser pointer or a long needle on the servo horn.
2. Command a 1 ms pulse. Measure the actual angle with a protractor.
3. Command a 2 ms pulse. Measure again.
4. Compute the slope (degrees per µs) and the offset.
5. In your code, apply the inverse mapping: pulse_width = (target_angle - offset) / slope.

But wait—this only corrects the endpoints. The middle might still be off by 2°. To fix that, you need a piecewise linear interpolation table. Store 5–10 calibration points in EEPROM. During operation, look up the two nearest points and interpolate. This is exactly what high-end robot servo drivers (like the Dynamixel series) do internally, but you can do it for $2 servos with a few lines of code.

One more trick: thermal drift. As the servo heats up, the internal potentiometer’s resistance changes, shifting the zero point. If you’re running a continuous rotation servo (like the FS90R) for a robot wheel, this drift is catastrophic. The technique is to periodically re-center the servo by commanding a 1.5 ms pulse and measuring the actual motor speed (via an encoder or a hall sensor). Then adjust the pulse width offset in real time.

The Future: PWM vs. Serial Bus Servos

We can’t talk about PWM techniques without acknowledging the elephant in the room. Serial bus servos (TTL UART, RS485, or CAN) are eating the micro servo market. They offer daisy-chaining, feedback, and PID tuning—all without PWM. But they cost 5x more and require a different control architecture.

Why does PWM still matter? Because it’s universal. Every microcontroller has a timer. You can drive a PWM servo with a 555 timer, a Raspberry Pi PIO, or even an FPGA. The protocol is dead simple. And for high-frequency applications (like a quadcopter’s gimbal), the latency of a 50 Hz PWM signal is actually lower than a 115200 baud UART packet (which takes ~87 µs just to transmit one byte, plus protocol overhead). A PWM pulse is just one edge—the servo sees it in 1 µs.

So the role of PWM in signal modulation isn’t dying; it’s evolving. We’re seeing hybrid techniques: using PWM to trigger a local servo controller that then uses internal PID. And in the micro servo world, the classic 1–2 ms pulse remains the lingua franca. Master it, and you can control anything from a $2 SG90 to a $200 industrial actuator.

Now go grab a servo, a scope, and a timer. Measure your actual pulse widths. Add a pull-down resistor. And never, ever trust the datasheet’s 1.5 ms center—measure it yourself. That’s the real technique.