The burned-out bulb mystery
Article By : Bill Schweber
Sometimes we have to just give up and walk away from diagnosing the actual source of a fault or failure, since the available data or number of units needed for observation and evaluation are insufficient.
The left-side brake bulb in my 2005 Honda Accord burned out a few days ago. No big deal: it fortunately takes only a few seconds to change it, unlike the headlight or some of the lights in today’s cars. Even so, what puzzled me is that the non-LED incandescent bulb at this same location burned out two years ago, and also did the same a few years before that, as well. (I know this because, as an engineer, I keep records of these things.) This “coincidence” has me greatly intrigued, especially as the complementary right-side bulb has never burned out.
On one hand, my debugging experience tells me that this could simply be a coincidence, similar to tossing a run of heads or tails. Still, that’s an easy way to dismiss the incidents, and perhaps too convenient and simplistic. So, I examined the socket, which looked clean (no rust or fritting), and all associated wires. Due to its age, this vehicle is not networked; all the wiring is basic, switched DC loops, which certainly does simplify the analysis and reduce the possible causes.
So, I started thinking about the possibilities. If the problem was with some weird overvoltage situation on the switched high-side line powering both lights, then the failures should occur on both sides. But given the low failure rate and mean time to failure (MTTF), maybe the other one would also fail soon; there’s just not enough data to go on. Perhaps there’s some ongoing microvibration the left side, which degrades the lifetime of the bulb, or possibilities I can’t envision.
My other idea was to look at it another way. Perhaps the first bulb burned out just “because,” but maybe the subsequent bulbs (both from the same two-bulb pack) were substandard (Figure 1), and the problem is not the car or its electrical system, but the replacement components themselves? This certainly wouldn’t be the first time, in the litany of troubleshooting, where the supposedly good replacement part really wasn’t.
Figure 1 Two bulbs from the same package failed, with one as the replacement for the other – could the problem be the bulbs rather than the car’s wiring, power, or other?
This is situation typifies what I called “the engineer’s dilemma.” Whether it is by our nature or by project imperative, engineers debug projects. Sometimes this debugging is easy; often, it is frustrating and riddled with false paths, conflicting evidence, unrelated coincidences, and false hopes. In my case, I don’t have access to the manufacturer’s database and the service-related specifics which might indicate that this problem is actually not uncommon for this make and model, based on numbers from tens of thousands of vehicles – the law of large numbers is powerful – while my experience is based on a sample size of one. Further, any larger conclusions I draw are inherently suspect because my individual case may not be representative but may only be a one-off quirk.
Debugging is one of those engineering skills that is part detailed knowledge, part experience, part mentoring, part hunch, part guesswork, and part magic, especially on the hardware side. If and when the subtle circuit problem is found, there may be an “aha” moment when it all became so obvious in retrospect; many times, though, the contrary is true, as there’s only a sigh of relief and that nagging worry in the back of your head: was the real source of the problem found, or just a coincidental discovery and the real problem will resurface later?
While there are many individual “case studies” and “war stories” about a specific debug problem and its resolution, there’s very little tutorial material about how to debug in general, for many reasons; as many of these general statements and guidelines often don’t apply. Nonetheless, there is one excellent book about it, “Debugging: The 9 Indispensable Rules For Finding Even the Most Elusive Software and Hardware Problems,” by David J. Agans (Figure 2). Don’t be concerned that it is published, somewhat incongruously, by the American Management Association; the book is not a high-level ivory-tower work, but a down-in-the-trenches guide.
Figure 2 This excellent book on debugging can help beginners as well as more-experienced hands-on engineers with that most challenging engineering skill. (Source: Amazon)
Meanwhile, I’m not going to worry about my bulb problem, since my “gut” tells me the chances of truly finding the source of this sort of problem are pretty slim. After all, it only occurs once every few years, and I have other things to do.
Have you ever had a debugging problem that really puzzled you, yet you were unable to solve due to lack of data, insufficient number of failed units, too-lengthy MTTF, or other real-world constraints?
Bill Schweber is an EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features.
Related articles:
- 11 steps to successful hardware troubleshooting
- Debugging hardware
- Incandescent lamps and service life
- LED lamp cycles on and off, why?
- Honey, I retrofitted the car’s interior lights with LEDs
- Can Incandescent Bulbs Make a Comeback?
- Use Lightbulbs as Current Limiters?
- Tales from the Cube: Engineers solving real-world problems