Stopping The Signal Is Not Switching It Off

Mostafa Dhouib·10 min read

Stopping The Signal Is Not Switching It Off

The short answer. A servo is not a motor, it is a motor with a closed-loop controller inside it, and the control signal you send is a setpoint rather than an enable. Stop sending that signal, or detach the pin in software, and the internal controller carries on running off the supply rail. If there is any mechanical load on the output, the loop keeps fighting it, so the part keeps drawing current and often hums audibly while doing it. The only way to get real silence and real zero is to cut the supply rail with a transistor under firmware control. In a battery wearable, the average current is dominated by what remains powered between events, which is why duty-cycled power gating buys hours and choosing a lower-current part does not.

The device actuated for a short burst and then was supposed to be quiet. It was not quiet. It sat there with a faint buzz, and the battery drained far faster than the arithmetic said it should.

The firmware had stopped commanding the actuator. That turned out to be a different thing from switching it off.

Stopping control and removing power are different operations

Inside a standard servo there is a motor, a gear train, a position sensor on the output, and a small controller that compares the commanded position against the measured position and drives the motor to close the gap. All of that is powered from the supply rail, not from the signal line.

The signal line carries a setpoint. It tells the controller where to go. It does not tell the controller whether to exist.

So consider what happens when firmware "turns the actuator off" the usual way, by stopping the timer that generates the control waveform and releasing the pin. The rail is untouched. The internal controller is still powered and still running its loop. What it does next depends on the part. Some hold the last commanded position. Some go limp and stop driving. Some interpret the absence of a valid signal as a fault and behave in a third way entirely. None of them stop consuming power, because nothing told them to.

Then add mechanical load, which in a wearable is always present, because the actuator is pressed against a body by a strap. If the servo is holding position, the load produces a position error. A position error produces drive current. The loop never settles, because the load keeps pushing and the controller keeps correcting, so you get a continuous small drive current and the characteristic hum of a control loop hunting around its setpoint. The device sounds alive while the firmware believes it is idle.

This is the same family of error as a sensor that stays awake after you cut its rail, but the mechanism is the opposite way round. There the rail went away and the part stayed powered through another path. Here the rail was never removed at all, and only the instruction was withdrawn.

Where the current actually goes in a battery wearable

It is worth separating the contributions, because the intuition about which one dominates is usually wrong.

Actuation bursts. The highest current the device ever draws, and the one everyone budgets for. It is also the smallest contributor to the average in most designs, because it lasts for a short fraction of the duty cycle.

Holding torque against load. Much lower than a burst, but potentially continuous. Continuous beats peak in any integral, and this is the term that was quietly ruining the battery life above.

The actuator's own standby electronics. The internal controller, its reference, its sensor excitation. Small, continuous, and present whenever the rail is up regardless of what the signal line is doing.

Regulator quiescent current. The supply itself consumes something to stay regulated. Present whenever it is enabled.

Processor sleep current and the radio. Both well understood and both usually already optimised, because they are the ones the datasheet makes easy to find.

The pattern is that the terms that dominate the average are the ones that are always on, not the ones that are large. A power budget built by adding up peak currents and multiplying by a guessed duty cycle will consistently be optimistic, because it accounts carefully for the loud contributions and omits the quiet continuous ones.

Duty-cycled power gating is what buys hours

The average current over a cycle is the sum, over each state the device occupies, of the current in that state multiplied by the fraction of time spent in it. That is the whole model, and reading it tells you where the leverage is.

If the device spends the overwhelming majority of its time between events, then the average is set almost entirely by the between-events state. Reducing the active current by a modest factor barely moves the total. Reducing the between-events current by a large factor moves it almost one for one.

This is why part selection disappoints. Swapping an actuator for one with a lower stall current improves a term that is already a small part of the integral. Swapping a regulator for one with lower quiescent current helps a term that is continuous, which is better, but it is bounded by how small that term already is. Neither does what cutting the rail does, which is to remove whole terms from the sum for the majority of the cycle.

The reason this gets missed is that the two actions look similar in a datasheet comparison and are completely different in the integral. One changes a coefficient. The other changes a duration, and durations are where the orders of magnitude live.

What cutting the rail actually takes

A gate is not free, and the implementation details are where this goes wrong.

A high-side switch, not a low-side one. The actuator shares a ground with everything else, including the signal reference. Interrupting the ground leg leaves the part's ground floating relative to the controller driving its signal line, which creates a path through the signal pin. Switch the positive rail with a P-channel device or an integrated load switch.

Gate drive referenced properly. A high-side switch needs its gate driven relative to the source, which means either an integrated load switch with a logic-level enable, or a small level-shifting arrangement. A microcontroller pin driven directly at a P-channel gate on a higher rail does not fully turn it off.

Inrush when the rail comes up. The decoupling capacitance on the actuator's rail charges from zero every time you enable it, and the servo's own startup draws a transient on top of that. On a coin cell or a small lithium cell, that transient can sag the supply enough to reset the processor. Controlled turn-on, or a soft-start feature in the load switch, is part of the design and not an optional refinement.

Sequencing on the way back up. This is the one that bites. Re-apply the rail to a servo whose signal line is in an undefined state and it may slam to a default position the instant it is powered. In a device strapped to a person that is both startling and a mechanical stress. The firmware has to establish a valid setpoint before or at the moment the rail becomes live, which means the signal generator starts first and the gate opens second, with the pin held in a defined state in between rather than floating.

Losing position knowledge. A gated servo does not remember anything. Whatever positional state your firmware was tracking is now an assumption. Either the profile has to begin from a known mechanical reference every time, or the design has to tolerate starting from wherever the output happens to be resting.

The test that settles it

The claim "the actuator is off" is a measurement, not a configuration. Put an instrument on the actuator's own rail, not on the battery, and look at the current in the supposedly idle state. Then do it twice: once with the output unloaded, and once with the strap at a realistic tension, because the loaded case is the one that reveals a control loop still working.

And listen. The hum is free diagnostic information, and it is the fastest indication that a loop is running when you believed nothing was.

There is no model anywhere in this. It is a rail, a transistor, an integral and a measurement.

The honest limit

Gating costs something real. It adds a part, a control line, a small voltage drop across the switch, and a new failure mode, because a switch stuck off looks exactly like a dead actuator and a switch stuck on returns you to the original problem silently.

Not every part tolerates being hard-cycled frequently. Some devices have startup sequences, calibration on power-up, or a settling time that makes rapid gating either slow or unreliable, and in those cases the correct answer may be a genuine low-power mode in the part rather than removing its rail. Where such a mode exists and is honest about its current, use it, because it avoids all of the sequencing and inrush work above.

The deeper limit is measurement. Everything in this piece is an argument about an integral across states that differ by large factors, and a bench multimeter cannot resolve that. If you gate the rail and the meter reads zero while the battery still disagrees with your budget, the meter is the thing that is wrong. Believing the instrument over the battery is how a quiet continuous term survives a whole development cycle.

FAQ

Does stopping the control signal turn a servo off? No. The control signal is a setpoint, not an enable. The servo's internal closed-loop controller runs off the supply rail, so stopping the signal or releasing the pin leaves the part powered and running. Under mechanical load it can keep drawing drive current and humming audibly while the firmware believes the actuator is idle.

Why does an idle servo hum? Because the loop is still closed and the load is still pushing. A strap pressing the output against a body creates a standing position error, the controller drives the motor to correct it, the load pushes back, and the loop hunts around the setpoint. The hum is the audible signature of a control loop that is still working, which also means current is still flowing.

What is the correct way to silence an actuator in firmware? Cut its supply rail with a transistor under firmware control, using a high-side switch on the positive rail rather than interrupting the ground. Then sequence the return carefully: establish a valid setpoint on the signal line before the rail goes live, so the part does not jump to a default position the moment it is powered.

Why does power gating save more battery than choosing a lower-power part? Because average current is the sum of each state's current multiplied by the fraction of time spent in it. A better part reduces a coefficient. Gating removes whole terms for the majority of the cycle, which changes a duration. In a device that actuates briefly and idles the rest of the time, the durations carry the large factors.

What goes wrong when you re-apply power to a gated servo? Two things. Inrush, because the decoupling capacitance charges from zero and the servo's own startup transient lands on top of it, which can sag a small cell enough to reset the processor. And an uncommanded jump, because a servo powered with no valid setpoint may drive straight to a default position.

Should I use the actuator's low-power mode instead of gating the rail? If it has a genuine one with a stated current, yes, because it avoids the extra switch, the sequencing and the inrush design. The caveat is to verify the figure on the actuator's own rail rather than trusting the datasheet, since a mode that leaves the internal controller powered is not the same as a rail at zero.