After deep-diving into intricacies of calculations related to the assumed age-related dimming of digit segments of a clock display, I realized I may have been pursuing the wrong culprit all along.
Like many of you, I have an inexpensive, no-name, large-digit LED clock in my office to keep reminding me of how fast time is passing and how much I still have left to do on any given day. I bought mine, with red LED digits about 2 inches (5 cm) high, about three years ago. When I first turned it on, I noticed that the all the segments of each of the four digits had the same intensity; I obviously could not determine if this was due to consistency at the LED production site or careful “binning” by the clock vendor.
Recently, I noticed that some of these segments were dimming unevenly (Figure 1). Oh, well, it’s been three years and a lot of hours, and LEDs do dim (age) over time: in this case it’s been 365 days/year × 24 hours/day × 3 years, or about 26,000 hours. I figured that’s a reasonable lifetime, usually defined as dimming to half brightness, which is what I estimated visually was the change in intensity (admittedly, very subjective).
Figure 1 A typical display with most segments on; note the dimmer appearance of some of the segments (of course, it is not possible to invoke the “1888” all-segment test pattern).
But then I thought about it some more (maybe I have too much time on my hands?) and realized that the 26,000-hour number was really an upper bound on operating time, and many of the segments would have been on for less than that.
So, how much less? I started with a basic look at the standard seven-segment digital display (Figure 2). Going through all possibilities of 0 through 9 displayed, it is obvious that the segment “on” time is a function of the digit being displayed.
Figure 2 These are the commonly used designations of “A” through “G” for the seven segments. (Image source: Jameco Electronics)
The next step would be to add it all up to see the usage duty cycle for a given segment over all digits. For example, by adding up the “on” designations (segment set to “1”) in the table (Figure 3), we see that segment "g" is on for seven of the digits 0 through 9 and off for three. That’s a 70% “on/off” ratio.
Figure 3 This logic truth table shows which segments must be turned on (set to 1) for each digit being displayed. (Image source: Jameco Electronics)
Well, that’s a start to the analysis. Then there’s the next twist: given that this is a clock, not all digits get equal use over the 12-hour readout cycle. The leftmost digit is either blank or shows a 1, the second-from-left shows 1 to 9, then 0, 1, 2 as the count goes from 1 through 12; the third-left digit only displays 0 through 5, and the right-most shows 0 through 9. But these digits are not displayed in equal weighting, of course, since this is clock-time display and not simple counting.
My next idea was to make some sort of spreadsheet to work all this out, and then determine what percent of the time that any given digit’s segment was active over a 12-hour period. Fortunately, my time-pressure reality returned, and I realized that I had other things to do, so I decided to stop the problem thought-cycle at this point. After all, one sign of having good judgement is knowing when to stop and move on, right?
Nonetheless, I think this would be a good problem for students to work out, either as a homework assignment or on a math quiz, while using any “tools” they wanted to try such as a spreadsheet. It works because they would have to think through the structure of the problem to be solved and the questions it raises before they do the spreadsheet setup. It’s a well-defined problem that can be clearly stated, with no hidden twists or “secret” knowledge required to understand it: “Over the course of a 12-hour cycle, what is the percentage of ‘on’ time for each segment of a seven-segment display of a digital clock?” Therefore, I am generously offering it to others who may be involved with students, with no royalties required.
Perhaps it’s a good thing I stopped when I did. I assumed the problem was LED aging. But I took a few more looks at the clock display and noticed that some of the LED segments were flickering slightly, and it seemed the flickering got worse as more segments were on (again, a somewhat subjective assessment, of course). Maybe the problem is not that the segments are aging unevenly as a function of their actual use after three years, but instead, the internal AC/DC power supply is aging. After all, it’s well-known that supply components such as capacitors have limited lives, and I am sure they don’t use long-life, high-reliability capacitors in a clock which retails for around $15.
It’s the old debugging story: often, the real source of the problem is not related to your first or obvious assumption and where that perhaps premature “jump to conclusion” takes you. In most cases, there is no substitute for keeping an open mind and asking yourself, “What else could it be?” when debugging or doing failure investigation.
Are there any examples that stand out in your mind where you assume the problem was due to one thing and avidly pursued that avenue, only to eventually come back to “square one” and look for other possible root causes? If you have done any debugging, I’ll bet there are!
Bill Schweber is an EE who has written three textbooks, hundreds of technical articles, opinion columns, and product features.