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':

Pros (see comment DarrenW):

• The time saved by a technician or other design engineers by not having to hook up JTAG or poke around with a scope probe (because of the LEDs) adds up.

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

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.

Answer 6

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. Bi-color and RGB LEDs can present a GO/NO-GO/BUSY status in 1 small LED. LED flashing vs. LED solid color can also imply a higher status level.

Answer 7

Cons: few more things to consider

1- total raise in temperature, LEDs dissipates high amount of heat compared to other devices. This could affect some sensitive devices specially when the board has to be isolated from surroundings, like boards in ROVs or so.

2- more current means more trace width, larger power supply, higher rated components, much bigger board size thus more overall cost.

3- one more important thing to consider, the expected operating time to devices operated by battery will significantly drop down. Some applications requires devices with long battery operating time. Hot kiln alignment as an example which is the major I'm specialized in requires devices that can operate for long periods of time, 3 hours for example and yes 3 hours is too much long enough because temperature in shells in such cases rises to some how near 350 °C. That means you have to depend on devices that can withstand these temperatures and withstand the circumstances until your job has been done.

Pros:

1- Nicely looking boards.

2- Attracts attention.

3- Ease of monitoring and troubleshooting.

Conclusion Avoid placing LEDs on boards that are not mandatory. If it has no use then its not worth having to be placed.

Answer 8

If you want to keep the pros and avoid most of the cons, ditch the LEDs and route the signals driving them to a debug connector somewhere. Design a small debug breakout board that can attach to this connector. Put all the LEDs on the breakout board. That way, you only pay for one set of LEDs per technician instead of one per board. You still have the debug option, but you don't have to pay for the extra hardware unless you're actually going to use it. Power the LEDs from the debug board to avoid changing the device's power profile when it's plugged in. You also avoid confusing the end-user since they can no longer see those debug signals that are only meaningful to your technicians.

A breakout board for debugging has other useful advantages, like allowing you to label and organize the LEDs in a more user-friendly layout, and enabling you to add (for instance) a small microcontroller to monitor LED states and report status to a connected PC over USB.

The con here is that routing all those debug signals might be tricky, depending on your current board density.