It Works Until the Motor Starts

I came across a question on Reddit that made me smile.

Not because someone had done something spectacularly wrong. Quite the opposite.

They were building an Arduino project with a gas sensor, a buzzer, a servo that opens a window, a pump, a relay and some other bits and pieces. It all worked, until something started moving.

The poster said the current drawn by those components made the Arduino “go banana.” They’d also tried a 7805 regulator to power the servo, fed from three lithium-ion cells, and measured only 4.3 V at its output.

There’s quite a lot to like about this question. Something works in one condition and not another. The person has noticed when the behaviour changes, made a measurement, and asked why.

We don’t know who they are, what they’ve studied or how long they’ve been doing electronics. We don’t need to.

Now, I can almost hear the familiar advice.

Get rid of the 7805. Use a buck converter.

Maybe that will ultimately be a sensible change. A linear regulator dropping 12 V to 5 V can dissipate an awful lot of heat.

But a 1 A buck converter asked to supply more than it can deliver may behave every bit as badly as a 1 A linear regulator. And changing regulators won’t necessarily fix a poor ground return, a bad connection or a motor disturbing the supply somewhere else.

Replacing a component is an experiment. It isn’t a diagnosis.

So imagine we’re sitting at a table with this project between us. Where do we begin?

I’d reach for a piece of paper.

Seriously. A napkin will do.

Draw the battery. Draw the regulator. Draw the Arduino, servo, pump, relay and sensors. Connect them as they’re actually wired, including the ground returns. Mark which devices use the battery directly and which share a regulated rail. If something’s connected through a breadboard strip, include that too.

Staring at a nest of wires tells you what the project looks like. A drawing shows you where current has to travel.

We don’t have the poster’s drawing, so we can’t tell whether the pump shares the 7805, merely shares the battery, or shares a return path with the Arduino. That’s the first uncertainty to resolve—not something to guess away.

Now I’d take the meter they already appear to have and begin building a measured power budget.

Start with the system doing as little as possible. What voltage is at the battery? What voltage is on each supply rail? How much current is the Arduino and its sensors taking? The servo, while commanded idle? The pump, when switched off?

Take the current measurements one load or branch at a time, under known conditions, and write them beside the drawing. A DMM connected correctly in series with a load can do an excellent job of steady-state current measurements, often well down into the microamp range where appropriate. Just respect its current range and fuse: an ammeter isn’t something you put straight across a battery, and inserting it can itself introduce a voltage drop.

Some idle readings may be tiny. Some may be surprising. That’s fine. We’re observing the hardware rather than borrowing numbers from a catalogue.

Then reconnect the loads and measure the current drawn by the whole rail.

Do the numbers make sense together?

If two loads on the same 5 V rail take, say, 80 mA and 120 mA separately in their idle states, we’d expect something around 200 mA when they’re connected together in those same states. If the combined rail instead draws 450 mA, don’t immediately blame the regulator. Ask what changed. Is the servo now holding a different position? Is something cycling? Has the supply voltage shifted? Did our measurement alter the circuit?

That discrepancy is useful. It points us toward the next experiment.

And pay attention to the words same rail. You can’t just add currents taken at 12 V to currents taken at 5 V and call the result a regulator load. Keep separate budgets for separate rails. If you need to compare what a source must provide, account for voltage and conversion losses.

Now repeat the exercise with the pump running. Then with the servo moving. Then under the combinations of loads the product is genuinely expected to encounter.

For each condition, record what the individual loads demand and what the shared rail actually supplies. If the sums stop agreeing, investigate why before proceeding.

That is a power budget grounded in observation: not a list of component ratings, but a description of this circuit’s behaviour under defined conditions.

And it’s quite different from reading an Absolute Maximum Ratings table. Those ratings generally identify limits not to exceed, not typical operating current or evidence of what this particular pump or servo draws. Datasheets can guide what to expect, but they don’t replace the measurement.

There’s a catch worth knowing, though. A DMM may tell us the current while a motor is running steadily without catching the brief surge when it starts. Likewise, an ordinary reading won’t necessarily capture a servo’s rapidly changing demand. Those events may need a suitably rated current-sensing arrangement and an oscilloscope. We shouldn’t deliberately stall an unknown motor or exceed a meter’s current range just to get another number.

Now let’s do the arithmetic that makes the 7805 interesting.

For a linear regulator, a useful first estimate is:

Heat dissipated ≈ (input voltage − output voltage) × output current.

If its input really is 12 V and it’s regulating at 5 V while supplying 500 mA, that’s (12 − 5) × 0.5 = 3.5 W of heat. At 1 A it’s 7 W.

That’s a lot to ask of a small, unheatsinked package, depending on its thermal conditions. A regulator’s headline current rating isn’t a guarantee it can sustain that current at every input voltage and ambient temperature. The manufacturer’s data, such as the TI LM340/LM7805 family documentation, makes clear that adequate heatsinking matters.

But see what changed? We can now take a measured load current and ask a specific thermal question. Before measuring it, our 3.5 W and 7 W examples were only possibilities.

And if the regulator is already down at 4.3 V, we must use its actual input, output and current to estimate dissipation under that condition. We don’t get to quietly assume it’s still delivering 5 V.

Suppose we’ve built the budget and something still goes wrong when the motor starts. Next, follow the path we drew.

Measure the battery at its terminals under the troublesome condition. Then the voltage directly at the regulator’s input and ground pins. Then its output and ground pins. Then the voltage across the Arduino’s actual supply and ground pins.

Don’t mix measurements from different operating conditions and expect them to explain one event. Make the load state repeatable.

If the battery holds its voltage while the regulator input falls, we’ve learned something about the path between them. A collapsing battery is a less convincing explanation. If the regulator input holds but its output falls, attention moves to that regulator, its loading and its surrounding circuit. If the regulator’s output holds while the Arduino supply falls, our drawing should tell us which wiring and returns to investigate.

That’s how hypotheses begin to fall away.

If all the DC readings look fine, we haven’t proved the power is fine. We may simply be measuring too slowly.

The poster’s 4.3 V is a good example. Is the rail really sitting at 4.3 V, or is a meter displaying a value influenced by brief dips, cycling or oscillation? The display doesn’t tell us. An oscilloscope, used with an appropriate and safe probing setup, can reveal whether the voltage collapses briefly, repeatedly cycles or slowly changes as the regulator warms up.

Those different waveforms suggest different next experiments. The temperature of the device, its input voltage, the load current and the time at which the fault appears can help us distinguish overheating from current limiting, supply sag or instability.

And sometimes the measurements clear the power system sufficiently that we ought to stop blaming it and move on to reset signals, interference or firmware.

That leaves us with something better than a replacement-part suggestion: actionable evidence.

We don’t know why the 7805 shows 4.3 V and the Arduino goes bananas. But we now have the equipped knowledge to test where and when it occurs, and from that understand why.

Anything less is unproven hypothesis and suppositions.