LEDs on Boards - Pros and Cons?

Question

OK - I tend to design high value low volume boards so my view of this is biased. I like to sprinkle a lot of LEDs around my boards. One (red) LED for every power voltage on the board. Multiple s/w driven LEDs that show different execution paths in action. LEDs on communications ports, CAN, USART, USB etc so I can see when they are active.

Pros

• I can see whether a board is operating approximately OK at a glance.
• Ditto with service engineers in the field.

Cons

• They cost money in high volume manufacturing.
• They take up board space.
• There may also be power constraints.

What other considerations exist?

Answer 1

Cons

• LEDs can be distracting or outright annoying, especially if used with too high a brightness (modern I_f=20 mA LEDs when actually driven with that current, especially when blue, are blindingly bright wenn one looks too closely at them)
• Information overload: if there's too many LEDs, how can you see, without searching the silkscreen or a manual, which means what. Where's the benefit of having an easy to read LED if you don't know which LED to read?
  • I'd go with something like: as soon as you have more LEDs than you can mentally connect to their meaning after a week of not working on the board, more LEDs have diminishing returns – if you need to consult your design documentation to know which LED means what, a simple test point + multimeter might not be much worse
  • If the state of your board is complex (i.e. there's many bits – LED on/off – of status), and might be relevant during operation, not just during prototype testing, maybe a board management IC would be wise, i.e. a microcontroller with ADC channels, GPIOs (not only to sense, but also to do things like resetting stuff, or controlling fans, beepers), and a serial port. Maybe even with an OLED display or something. Often, these same microcontrollers fulfill the role of power sequencer, temperature monitor and watchdog.
    Sounds like more development work to me, but then again, you sound like you're doing more than one board per year, so maybe putting together a simple firmware once that does what you need is wise, and then throwing the same microcontroller on every board, no matter how simple (personal advise: go for a microcontroller that has USB; your laptop-wielding field engineer (so: most likely you) will like that).
    Options range from a few lines of C for your own minimal firmware to using the Embedded Controller Firmware for Chromebooks. I'd not cheap out on the microcontroller too much and avoid going for the 8 bitters – a cheap STM32 ARM would do, for example, and really has the nicer development workflow if you're nowhere near caring for latency in the sub-microseconds.
• aside from power constraints e.g. of driving digital logic, overall power usage
• potentially: assume you have some reference voltage rail, or other low-current supply rail (say, a low-speed opamp driving a weak load at < 0.1 mA average). You might need to redesign your supply to suit the much higher LED load, or add complex (and thus, new source of failure) means of buffering (e.g. NPNs, digital gates) to drive the LED.

Pros

• Looks: A board that has 50 green LEDs turn on, partially sequentially, after powerup is bound to impress your customer
• Human Observability: Of course, even if it's confusingly many, having an LED is still worst case as good as having none.
• Machine Observability: another LED, simply taped to the LED of interest, on a constant current source, makes an excellent oscilloscope / ADC input
• More Observability: OpenCV is relatively easy. Add a QR code to two or three corners of your board, scan for that in a camera picture, use the result to unskew the image, and then use a fixed mask to lazily monitor a board in a lab, while working from home.

Answer 2

In addition to what's already been said:

Pros:

• Relatively cheap and easy to implement compared to displays, serial debug interfaces etc. You don't need any deeper software or electronics knowledge to design in a LED, just a bit of Ohm's law.

• High availability and lots of 2nd source on the market. If your favourite LED company can't deliver in time, it is very easy to find an alternative.

Cons:

• Roughly 8% of all men and 0.5% of all women are "color blind", which most commonly manifests itself as problems distinguishing between red and green. Which also happens to be the two most common LED colors.

  This can be especially problematic if you use different colors on the same spot (RGB etc) to indicate different product status. If you ask a customer over phone what color they see, there's a pretty big chance that you get an incorrect answer, particularly so if the products are designed for a traditionally male dominated industry (such as electronics).

• Light pollution. In products with IR sensors, photocouplers etc, LED light might cause "optical noise".

• Polarity problems during assembly. As a rule of thumb, components with polarity will eventually get mounted backwards during assembly. Someone loads the pick & place wrong or misunderstands the component placement drawings etc. This is a rather common quality problem in my experience, particularly when it comes to LEDs and tantalum caps. Ultimately this is a production quality issue, but a designer who has the option not to pick components with polarity reduces the number of things that can go wrong.

• Sensitive components. LEDs are among the most sensitive parts during SMD assembly, and may not survive an oven several times during assembly. Particularly so if you picked some cheap brand.

• MCU source/sink current budget. It is most often preferable to drive LEDs directly from MCU pins, since it saves you from external circuits and complexity. Most designs hopefully take the source/sink ability of the individual pins in account, but it is common to forget the total source/sink capacity of the chip as whole.

  Imagine that you have a lot of different LEDs that indicate various states in your product, then suddenly during some conditions you experience an unexplained MCU latch-up or reset. The first thing you'll suspect is an application problem in "state x", because the error only occurs when the LEDs for that state are lit. That sends you trouble-shooting in the completely wrong direction, since the actual problem isn't your application logic but the LEDs themselves.

Pro + Con:

• PWM characteristics. If you hook a LED to a PWM, a serial bus or similar, the human eye is too slow to catch flickering - the LED may appear as constantly lit. This enables various tricks with power saving, multiplexing & color mixing between different LEDs.

  But it also makes it hard to distinguish between for example idle high and operational modes of a serial bus. At best you end up with "how bright does it shine" which is very subjective and not something you want to ask your customer over phone during trouble-shooting. "Umm... it shines quite a bit!"

Answer 3

Too many indicators can lead to confusion from the user side :

Image link

The indicators you have on your board seem to be very numerous and are useful only for a maintenance engineer. I don't know what is the architecture of your boards but probably it is better to use software checks or hardware test loop for the maintenance in case of issues :

Image link

Answer 4

Just some 'personal brainstorming':

Cons

• Longer design time: although mostly fairly easy to add a LED, it cost time.
• Reduced power: you already mentioned it, but probably you mean the (micro)Amperes the LED itself is using is deducted from the total. However, also by using a LED, the current is reduced from the original path (unless e.g. a transistor is used), so it affects the current also of the area 'around' the LED.
• Added/changed GND return paths: as each LED has a return path, could affect e.g. analog (parts of) PCB boards.
• CPU pin usage: when using a software controlled LED, it cost a pin, or a multiplexer output.
• Board space: already mentioned by you, however also take the description text next to each LED into account.

Answer 5

I have built boards run by PIC MPUs and added just a few LEDs to indicate power and MPU status, and a "heart-beat" LED to show that software was not hung up. Add another LED to show links to another board were good.

Still this is judicious use of LEDs. The last thing I wanted was a board to show the chief engineer that looked like a Christmas tree. Instead there was just a row of 8 tiny SMD LEDs, red and green, running at 2 mA so they had a soft glow, not bright like spot-lights.

In my mind there are no cons for judicious use of LEDs as crucial condition indicators. One look at a Ethernet hub and solid or blinking LEDs for power and data shows that in small numbers they are very useful.

Answer 6

LEDs are useful for basic diagnostics such as checking power is on and all rails have come up, or for indicating certain activity such as communication or connection status.

However for more detailed diagnostics there are better options. If you have a microcontroller you can add a UART interface. No harm in having debug messages on your production boards most of the time. JTAG is another good option.

For low volume stuff you could also add a small display. Miniature OLED displays are cheap and easy to interface with, and can display a lot more information in a more readable format.