When I started building an IoT smart parking system on an ESP32,
I expected the hardest part to be the software — MQTT messaging,
the real-time dashboard, the sensor logic. I did not expect my
biggest engineering problem to be electricity itself.
The Symptom
My setup had a 7-sensor infrared array feeding into the ESP32,
which controlled multiple servo motors to open and close parking
gates. The moment I wired the servos directly to the same power
rail as the ESP32, things got weird:
- The display would randomly turn off
- The servos themselves wouldn't move reliably
- Programming the open/close angle logic became a nightmare — behavior that should have been simple felt inconsistent and unpredictable
At first, I assumed it was a code problem. It wasn't.
Isolating the Problem
Instead of guessing, I disconnected the servo motors from the
circuit first — and the ESP32 and display immediately behaved
normally again. That confirmed the servos were the source of the
issue, not my code.
I brought the problem to a teammate and did some research to
understand the why, not just patch the symptom.
The Actual Cause: Inrush Current
Servo motors, especially under load, draw a large spike of current
the moment they activate — far more than their steady-state
operating current. This is called inrush current.
When multiple servos pulled that current spike from the same power
rail as the ESP32, it caused a voltage drop (brownout) on the
line. The ESP32 is sensitive to voltage stability — even a brief
dip is enough to reset it or disrupt connected peripherals like
the display. That's exactly why the screen kept turning off: it
wasn't a display bug, it was a power problem wearing a display bug's
disguise.
The Fix: Power Domain Separation
The fix wasn't a smarter piece of code — it was an isolated servo
shield to physically separate the servo power domain from the
ESP32's logic power domain. The servos now draw their current spikes
from their own supply, instead of dragging down the rail the ESP32
depends on.
Once that separation was in place:
- The brownout resets disappeared completely
- The display stopped randomly turning off
- The servo angle control — which had felt buggy and inconsistent before — suddenly worked exactly as programmed, because the logic was never actually broken. It was just running on unstable power.
The Lesson
The most valuable part of this bug wasn't the fix itself — it was
realizing the bug wasn't in my code at all. When symptoms show up
in seemingly unrelated places (a display glitching, motor logic
acting "buggy"), it's worth stepping back and asking whether the
real problem is one layer lower than where the symptoms appear.
In embedded systems, software and hardware failures can look
identical from the outside. Isolating variables — literally
disconnecting components one at a time — is still the fastest way
to tell them apart.
Top comments (0)