Most "my code is broken" evenings are actually power problems.
The symptoms are convincing: LEDs flicker, colours come out wrong, the board resets halfway through a loop, a sensor returns nonsense. All of that looks like a software bug. None of it is. It's a supply that can't deliver the current the circuit is asking for.
This is worth learning properly and early, because it's the one class of fault that makes you distrust code that was correct all along.
Voltage, current, and which one bites you
Two numbers describe any supply.
Voltage is what the supply offers. A USB port offers 5 volts whether you draw a milliamp or an amp. You choose this deliberately and you rarely get it wrong — you either wired 5 V to a 5 V pin or you didn't.
Current is what your circuit takes. You don't set it; the circuit decides. An LED at full brightness draws what it draws. A motor starting up pulls several times what it pulls once spinning. A radio transmitting draws far more than one sitting idle.
Every supply has a limit on current it can deliver. Exceed it and the voltage sags — and that is where the trouble starts, because digital chips have a minimum voltage below which they simply stop behaving.
The shorthand: voltage is what you provide, current is what your circuit demands. Choosing a supply means adding up the demand and finding a source that comfortably exceeds it.
What a brownout actually looks like
When the supply can't keep up, voltage drops. A microcontroller running at 3.3 V has a floor — somewhere below about 3 V it stops being reliable — and what happens near that floor is worse than a clean shutdown.
Above the floor, everything works. Right at it, you get:
- The board resets, sometimes in a loop, often mid-task
- LEDs show colours you never asked for, or flicker on a pattern that should be steady
- Sensor readings drift or return garbage
- Serial output turns to nonsense characters
- The board works fine when idle and fails only under load
That last one is the real trap. You add the code that lights all the LEDs, it misbehaves, and the obvious conclusion is that the new code is wrong. The new code was fine — it was the first thing that drew serious current.
There's a second failure mode worth knowing: voltage sag corrupts data signals too. A data line whose logic levels are referenced to a sagging supply can be misread. So a power problem can present as a communication problem, which sends you debugging the wrong subsystem entirely.
If a circuit behaves differently when it's doing more work, suspect power before you suspect logic. Intermittent faults that scale with activity are almost never code.
Knowing what your USB port can give you
"USB" isn't one thing. The ports on one laptop can differ from each other.
| Source | Typical limit | Realistic use |
|---|---|---|
| USB 2.0 port | 500 mA | A microcontroller and a few sensors. Tight for anything with LEDs at brightness |
| USB 3.x port | 900 mA | Comfortable for a microcontroller plus a modest LED load |
| USB-C (standard) | 1.5 A | Plenty for most single-board projects |
| USB-C (high power) | 3.0 A | Multiple boards, or LEDs at full brightness |
| USB Power Delivery | up to 5 A | Effectively not your limiting factor |
| Unpowered USB hub | shared, often 500 mA total | Avoid for anything that draws real current |
That last row catches people. A hub splits one port's budget across everything plugged into it, so a project that ran fine directly can fail through a hub — with no code change to blame.
Adding up what you need
The method is unglamorous and works: list every component, find its worst-case draw, add them up, then add margin.
Worst case matters more than typical. A design sized for average draw fails at the exact moment everything happens at once — which, in a program with a loop, is a certainty rather than bad luck.
A worked example, using an addressable LED board as the load. Each RGB LED draws roughly 7 mA at full white. A board with 96 of them:
96 LEDs × 7 mA = 672 mA at full white, full brightness
plus the idle draw of the driver ICs
96 × 0.35 mA = 34 mA
plus the microcontroller ~ 50 mA (more with Wi-Fi active)
-------
~756 mA
So about 0.76 A worst case. That's fine on a 1.5 A USB-C port, marginal on a 900 mA USB 3 port, and beyond a 500 mA USB 2 port.
Two things fall out of that arithmetic immediately.
Brightness is a power setting. Halving brightness roughly halves LED current. Most addressable-LED libraries have a global brightness cap, and setting it to about 60% of maximum is the single most effective thing you can do to make a project run reliably on modest power. It also looks better in a room — full brightness is usually blinding at close range.
Full white is the worst case. White means all three colour channels at once, so it draws roughly three times a single-colour effect. A project that only ever shows blue has far more headroom than the arithmetic above suggests.
Size for the worst case your code can actually produce. If your program never displays white, don't budget for white — but do check that no error state, startup flash, or test routine turns everything on at once.
Wi-Fi changes the numbers
A microcontroller with Wi-Fi draws modestly while idle and then spikes hard — often several hundred milliamps — for the milliseconds it's transmitting.
This produces one of the most confusing failure patterns in hobby electronics: a project that runs perfectly for minutes, then resets the moment it connects to the network. Average draw is comfortable; the transmit spike isn't. If your supply can't absorb that peak, the board browns out and reboots, which is why "it crashes when it connects to Wi-Fi" is so often a power fault rather than a networking one.
The fix is usually not a bigger supply. It's a capacitor.
Capacitors: local reserves for sudden demand
A capacitor near your board acts as a small local reservoir. When demand spikes faster than the supply and its wiring can respond, the capacitor covers the gap.
This is why a 470 µF to 1000 µF electrolytic capacitor across 5 V and ground, physically near the load, is standard practice on LED projects. When many LEDs switch on in the same instant, the current step is close to instantaneous; the capacitor supplies that step locally instead of letting the voltage dip while the supply catches up.
Two practical points. Electrolytic capacitors are polarised — they have a marked negative leg and fitting one backwards can make it fail, sometimes loudly. And placement matters: a capacitor is only useful near the thing that spikes, because the wiring between them has resistance and inductance of its own.
Wire is not free
Wire has resistance. Push enough current through enough length of thin wire and a measurable fraction of your voltage is lost getting there.
This is why a long chain of LED boards often looks bright at the near end and dim and colour-shifted at the far end. Nothing is broken; the far end is running on less voltage than the near end.
The fix is power injection: run supply wires to the far end of the chain as well as the near end, so current doesn't have to travel the whole length through the board-to-board connections. Data still flows along the chain; power arrives at several points.
Keep power wires short and reasonably thick. For runs carrying an amp or more, thin jumper wire is a genuine limitation rather than a detail.
Batteries behave differently from USB
A USB port is a stiff supply: 5 V until you exceed its limit. A battery is not.
A single-cell lithium battery runs from about 4.2 V fully charged down to roughly 3.0 V empty, drifting the whole way. Everything downstream has to work across that range, which is why boards designed for LiPo power include a regulator.
Two consequences worth planning for:
Brownouts arrive with age. A project that runs happily on a fresh battery may reset as the battery nears empty — the supply that coped at 4.0 V can't at 3.2 V. Same code, same circuit, different day.
A battery's internal resistance rises as it depletes, so its ability to deliver current spikes gets worse exactly as its voltage gets lower. A near-empty battery and a Wi-Fi transmission is a common combination behind "it randomly reboots after a few hours."
Never connect a raw battery terminal to a microcontroller pin. A full LiPo sits at 4.2 V, well above the 3.3 V most pins tolerate. Boards that expose a battery pin expose it for powering motors and servos — reading battery level is done through a voltage divider, which is why those pins typically report half the battery voltage.
Habits that prevent most of this
- Start at low brightness and turn it up. Costs nothing, eliminates the most common failure before it happens.
- Use a dedicated supply once you pass one board. A 5 V 3 A adapter is inexpensive and removes USB limits from the equation entirely.
- Fit a capacitor near the load on anything with LEDs or a radio.
- Inject power at both ends of a long chain rather than assuming wire is ideal.
- Don't power up at full brightness. Inrush current when everything initialises at once can exceed steady-state draw. Start dark, then ramp.
- Suspect power first when a fault scales with activity. It will save you hours you'd otherwise spend rereading correct code.
The short version
Voltage is what you supply; current is what your circuit demands. Add up the worst case, choose a source with margin, keep a capacitor near anything that spikes, and remember that wire and batteries both sag under load.
Get that right and a whole category of maddening, intermittent, code-looking bugs simply never appears.