I need to indicate an error code with an LED. This is in case we have a really bad error in our embedded system where we can't reliably use higher-level GUIs to indicate a problem -- I have to fall back on flashing an LED.

What's surprising to me, is how slowly it seems I have to flash it, to count the number of flashes. I'm testing with 4 flashes (max error code not likely to exceed 5) and I'm finding that if the flash rate is more than about 3Hz, sometimes I count 3 flashes instead of 4.

Are there some rules of thumb for frequency and duty cycle for perception of LED flashes?

  • 3
    Hmm. Interestingly enough I found this W3C guideline not to exceed 3Hz for the seizure-trigger problem. w3.org/TR/WCAG20/#seizure
    – Jason S
    Apr 16 '12 at 22:04
  • Hardware usually uses Beeps or multiple Led's to indicate a 'code'. Counting repeated beeps is pretty easy.
    – Barfieldmv
    Apr 17 '12 at 8:49
  • Yeah, I'm getting the sense that counting sounds is much easier than counting flashes. But unfortunately I don't have a speaker of any kind, just an LED.
    – Jason S
    Apr 17 '12 at 13:32
  • 1
    I think counting flashes is very bad idea. Changing pattern* according to error code is better, but still, without training users are not able to recognize what went wrong. * by pattern I mean different changes in on/off durring specific period of time: [xxx.] [xx..] [x.x.] [x...] Apr 17 '12 at 15:55
  • This is not for random users; this is for engineer users on an in-house project, so whatever I do will have a secret decoder ring to determine what error message the code corresponds to.
    – Jason S
    Apr 17 '12 at 17:12

The Department of Defense Design Criteria Standard - Human Engineering (MIL-STD 1472) Section Warning Signals recommend a flash rate between 3 and 5 Hz for warnings, so 3 Hz is certainly acceptable. I’m guessing the 3-to-5 range isintended to optimize the light’s attention-getting ability, not count-ability. MIL-STD 1472 doesn’t discuss coding information in the number of blinks (neither do any of the other human factors standards I have).

Section Flash Coding suggests you can use a second flash rate to code information, with second rate being as low as 0.8 Hz, which tells me it’s acceptable to go that low if you have to. (I don’t think you want to use a second flash rate in your application since presumably users are unlikely to ever need to use this display. Unless the users have seen both flash rates before, how do they know the one they’re seeing is the slow or fast one? However, different patterns of flashes, like in Andre’s answer, may be worth exploring)

I think instantly perceiving more than three of anything gets difficult. The user has to mentally count the items. That implies your flash rate should be no faster than a person can comfortably count –about 2 Hz, I’d say, which fits nicely between 3 and 0.8 Hz.

This is not a display a user is going to able to read quickly no matter what you do. Even if users could count faster, they’ll probably have to look up the code to know what it means. If fast response is critical, then you’re going to have to redesign the hardware to include a better display.

MIL-STD 1472 recommends a 50% duty cycle.


Note, that this is not based on research at all:

It seems to me that counting the number of flashes is going to be difficult in any case. Would it possible to not just use a number of flashes, but distinct, repeating patterns instead? Something like (where a . represents a short flash and dash a longer burn, and the space time where the led is off):

...... vs - - - - - vs -.-.-.-

You could come up with more patterns that are easy to distinguish, I think. I guess it depends on how many different error states you need to communicate, because obviously the pattern can't be too complicated.

  • 4
    Oh go on -- spell out the problem with Morse code. You know you want to. :-) Apr 17 '12 at 15:31
  • 1
    @MonicaCellio: Well, I certainly would signal the most serious error with ...---... (repeatingly) :-)
    – André
    Apr 18 '12 at 12:27

This is a common pattern in HVAC equipment error codes. Here's a pretty representative case from a Carrier furnace manual:

enter image description here

This may look like an extreme case to you. There are 101 possible error states this system can represent! However, there are some key design patterns to glean.

  • The first patterns in the decision tree are the easiest to recognize. Is the LED on or off? If it's on, is it blinking rapidly without a pause? Or, is it blinking slowly with a combination of short and long flashes? These initial distinctions are easily perceived by homeowners, perhaps on the phone with a tech, and serve to handle the simplest of cases. After that, the system gets much complex and involves counting shorts and longs to create two-digit error codes.

  • Comparing pulse lengths is hard. Limit yourself to slow and long. Slow vs. long is much easier than comparing slow vs. medium vs. long, (or for that matter 4hz vs 3hz vs 2hz vs 1hz).

  • I can't find any docs about exactly how long the pulses last, but I've encountered one or two, and I would guess that the short is about .5 seconds and the long is 1.0 seconds. (If I'm far off on my guess, I would guess the actual is slower than that. It feels tedious to count error codes.)
  • Parsing anything complex out of a single LED is likely tedious as the "bandwidth" of accurately counting pulses is inherently s-l-o-w. (Naval signal lamps, another interesting point of reference, reach an impressive 14 words-per-minute with morse code, but that's with highly trained personnel sending and receiving and a recognized set of conventions to govern the interaction).

So, if you only need to represent one or two error states, and you wanted to follow the well-worn HVAC path, you could go with the first (easiest) set of logic gates from above, something like:

  1. Light on = power
  2. Light flashing rapidly, consistently = critical error
  3. Light flashing slowly, with a combination of shorter and longer flashes = secondary error

The more error states you need to represent, obviously, the more complex (and harder to parse) your patterns need to be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.