LED flashing parameters to best let a human count flashes?

Question

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?

Answer 1

The Department of Defense Design Criteria Standard - Human Engineering (MIL-STD 1472) Section 5.2.1.1.4.1 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 5.2.1.5.5 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.

Answer 2

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.

Answer 3

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

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.