Why does my HAL eye LED flicker when the Pi boots up?

Nov 08, 2026 Last reply: 1 day ago 3 Replies

First reply

nic.eaton

That flicker at boot is mostly the GPIO pin doing its default thing, not your wiring. On the Pi, every GPIO pin starts up as an input in a floating state til your software sets it. During boot that can take several seconds, and the pin drifts around near the threshold, which is…

Read the full reply

So I've been slowly building a little HAL 9000 prop around a Pi Zero, and the red eye looks great when it's fully booted, but during startup it flickers like crazy. Sometimes it even dims down to almost nothing for a second, then snaps back bright. Is that just the Pi hogging power while it boots?



I'm running it off a wall adapter rated for plenty of amps, and the LED is wired through a GPIO pin with a resistor, nothing fancy. The camera module isn't hooked up yet, in case that matters. I measured the voltage at the LED while it was flickering and it does dip a bit, but I don't know what a normal dip would even look like.



Would a capacitor across the LED smooth it out, or is that papering over a wiring mistake? Also wondering if I should just move it to the 5V rail with a transistor instead of driving it straight from the pin. My electronics knowledge is basically 'it lit up, so we're good,' so any nudge in the right direction helps.


That flicker at boot is mostly the GPIO pin doing its default thing, not your wiring. On the Pi, every GPIO pin starts up as an input in a floating state til your software sets it. During boot that can take several seconds, and the pin drifts around near the threshold, which is exactly why the LED flickers, dims, and snaps back. I saw the same behavior on my own build before I moved the eye off the pin entirely. The dip you measured backs this up. If the LED is hanging off the pin, the voltage you're reading is whatever that floating pin happens to be doing, so there's no 'normal dip' to compare against. A capacitor across the LED would smooth out PWM flicker from your code, but it won't fix the boot dimming, because the real problem is the pin state, not noise. So yes, it would be papering over the actual issue.

Moving it to the 5V rail with a transistor is the right call, and it's the standard way to do this. You still use the GPIO pin, but only as the trigger for the transistor, and the LED draws its current from the rail instead. Two benefits: the rail is stable from power-on, and you can pick a resistor for a brighter eye than a GPIO pin can safely drive. Just remember the resistor for the LED goes on the 5V side now, so a diferent value than what you used before, and the transistor base gets its own small resistor from the pin.

One more thing worth checking while you're in there. If the whole 3.3V rail is sagging during boot, you'd see other symptoms too, like the camera or anything else on that rail acting up once you hook it up. But with just an LED on a pin, I'd bet on the floating pin over a power problem, especally since your wall adapter has headroom.

Worth adding that even after the transistor fix you can still get a brief flicker window, because those boot stages rewrite the pin configuration as the kernel and dt-blob get loaded, and some of those intermediate states aren't driven high. I noticed this on a status light I built, where the LED whould blink once or twice mid-boot even with the transistor in place. If that bugs you on a HAL prop, and honestly a momentary glitch before the eye settles kind of suits the aesthetic, you can leave the LED's transistor triggered low by default with a pull-down so it only lights when your script explicitly enables it.

So the little red eye is basicly flapping around becasue nothing is holding it steady until the software wakes up, got it. I did a similar thing with a status light on mine and gave up trying to make it behave during startup, I just let the code turn it on as its last step and accepted a dark eye for a few seconds. Kind of fits the HAL vibe anyway honestly. When I do the transistor swap, does the little leg of the transistor that hooks to the pin need to connect to the same pin I'm allready using, or can it be any pin since the software is what decides anyway?

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required