LEDs are perhaps the simplest bit of circuitry on any product - and yet they are usually the most fiercely debated part of any design. The issues appear to start right from the first concept stage of any new product, with questions such as: do we need LEDs? How many are really needed? Where should they be located? And by far the worst: what color should they be? In my previous life as an engineer working on my first design, I naively added a set of eight blue LEDs in a single row on the top of an XMC board to show port status and power.
I can hear the gasps of horror from you reading this. Thankfully, we do things quite differently.
Which dovetails conveniently into answering the first fundamental question for LEDs: why do we even need them? This is one that I believe can be answered quite simply in two points. First: for when all else fails, to help debug what’s happening on a board (e.g. presence of power, BIT failure, links up or data transmitting). Second: they are there to quickly and easily check key functionality without needing additional equipment such as a PC or multimeter.
I take these two points from a recent experience where my laptop wouldn’t start. What turned out to be an empty battery and failed update manifested as a completely unresponsive, hot slab of glass and metal. The sleek and minimal design is brilliant - until nothing happens when you attempt to hard restart or turn it on. A blank screen but flashing SSD activity and power LED would be all that’s needed to alleviate stress - yet not having either makes for a frustrating, and financially concerning, situation.
Now you know what you need. The next question is: how they should work, and what color will they be? An informal survey of the other product managers around me concluded that LED color was just ahead of FPGA size for decisions that ignite widespread debate. I won’t claim to hold the secret answer to what the “correct” color for a function should be; fortunately, I can say the general rule with Abaco networking products is: green is good, red is bad, and amber is usually something different than default is occurring.
The next thing to tackle is what should the LED do? There, I like to think back to the first thing my woodwork teacher told me at school: “in engineering, wherever you can - Keep It Stupidly Simple”. With that in mind, as a general rule of thumb, my view on how networking products should function is: off means the feature is off (BIT Failure LED off = no BIT failure); solid on is the feature being on; and flashing (or doing something) means the feature is doing something.
Sure, you can make it more complex by the inclusion of multicolour LEDs or complex flashing patterns, but in my experience (and that of many customers I have talked to) is the more time spent referring to the manual to work out what LEDs means results in less time to look at the actual problem. That’s why our latest network switch to start development lives up to these principle by only having a single LED per port: one for power, and one for BIT. Hopefully, that’s simple and quick to understand.
The final major consideration, once a design has progressed to layout of the PCB, is to decide upon where the LEDs should be. I will admit that when the first 3D print of the latest networking switch design was handed to me, the second thing I looked at (I had to check the right connectors were there) was where the LEDs were placed and how they fitted around the front panel ports.
The process for seeing what would work where and, more importantly, fit was a potential minefield of opinions, options and limitations. The sheer volume of different styles and types of LEDs available is quite staggering - from simple surface mount ones through to IP67-rated pushbuttons with integrated pulsing LEDs. You can be certain there is usually a solution somewhere on the market for even the most claustrophobic design.
Faced with the prospect of near infinite choice, the principle of using a simple solution was once again employed to pick a part that met the requirements of the right color and the right size to fit within the envelope. The benefit of going with a simple solution is that it often comes with the benefit of it being a more standard design provided by multiple manufacturers - which really helps if one goes obsolete. Then, all that needs doing is placing them far enough apart to be visible while also grouping them to be quick to look at.
It doesn’t always need to be about quantity either. With the RES3000 for instance, a single LED is all that is needed to confirm functionality - and by doing so, stops there being unnecessary illumination from the unit.
I hope you’ll excuse the pun, but: hopefully, that sheds some light on the process and theory put into every board to ensure it’s quick and easy to see what’s going on without needing to hook it up to a laptop. And: if we put that much thought into something that, on the surface, is relatively trivial – imagine how much thought we put into the design of the rest of the product.
The conversation about LEDs isn’t the most technical of conversations we have internally, that’s for sure. But then: you can have what you think is the best product in the world – but if it frustrates customers by being difficult to work with, it’s arguably not the best in the world. LEDs are a very small part of the design - but it’s one that contributes to making a network switch easier to use and quicker to develop with. I’ve never yet met a customer who would say “no” to that proposition.