LED Strip Diagnostics Tool is firmware for Cypress (Infineon) MCU devkit capable of analysing addressable LED strips. It measures power consumption of strip, iteratively send various commands to RGB LED strip and observes, if LED behaves adequately by observing power consumption changes. Can be used for identifying fault position on strip as well as for detecting partially faulty LEDs.
Features
- Work with Würth WL-ICLEDs:
- Also work with compatibles LEDs like WS2812
- Support both 24 GRB and 48-bit RRGGBB data formats
- Works with arbitrary long LED strip without need to recompile up to 4096 24-bit LEDs or 2048 48-bit LEDs (more detail about operation)
- Support featuring both 24 and 48-bit LEDs on single bus (more details about operation)
- Support for continuing detection over faulty LEDs when BI pin is used (more details about operation)
- Tests Red, Green, and Blue channels separately and can detect fault on both
- Tests PWM and Current limiting controllers separately and can detect fault on both
Story
I created this project as part of Light Up Your Life Design Challenge on element14 community. As part of this design challenge, I run several experiments and tests which become core part of this project. I documented them in dedicated forum posts. Here is list with links to all my forum pots which I wrote:
- Misaz’s WL-ICLED experiments: Introduction
- Misaz’s WL-ICLED experiments: It’s soldering time
- Misaz’s WL-ICLED experiments: Testing BI pin
- Misaz’s WL-ICLED experiments: Mysterious End Frame
- Misaz’s WL-ICLED experiments: Combining LEDs of multiple types
- Misaz’s WL-ICLED experiments: Counting LEDs on bus
Usage and showcase
When device is connected as shown below in electronics section and firmware is flashed to device, you just need to press single button to trigger strip analysis. Analysis protocol is print on serial console (on Window you can find COM port number in device manager and use PuTTY in serial mode with baud rate 115200 to access it). Firmware can be downloaded at the end of page and can be flashed via ModusToolbox Programmer, or directly from VS Code / Eclipse when building from sources (which are also available to download at the end of this post). Since it sends various test commands to every LED, it takes some time. About four second per 48-bit RRGGBB LED and about two second for 24-bit GRB LEDs. When analysis is ongoing, LEDs quickly flashes and frequently switches colours. Pay attention to this if you are epileptics. Device prints strip analysis report continuously as it goes. It looks as follows:
When testing is in progress it looks as follows:
As shown on screenshot above, device can detect fully or partially faulty LEDs. On strip tested above the two LEDs are actually missing, but because they are LEDs with BI pin, strip can continue operating even without them. I wrote more details about it in my forum post Misaz’s WL-ICLED experiments: Testing BI pin.
Since protocol for classis RGB LEDs like Würth 1315050930002 (which are itself compatible with WS2812) have same protocol and very similar timing shared with more advanced Würth LEDs 1312121320437, they can be used on single strip. I experimentally tested it as part of experiment and explained with more details in Misaz’s WL-ICLED experiments: Combining LEDs of multiple types. This tool utilizes my observations and can detect both types of LED on single strip.
The only remaining piece of information is how to programmatically and automatically detect what LEDs are where on strip without knowing format of LED strip in advance. Since it was not explained in any separate blog/forum post yet, I will briefly describe it here.
Distinguishing 24-bit and 48-bit LEDs
The idea which I used in this project is based on finding pattern which lights up one LED type but do not light up second LED type at all. There could be other approaches based on fact, that 48-bit LEDs have steps in brightness because they have two separately configurable drive modes: Current limiting and PWM. But I stick with simpler idea of single pattern which do not light up one LED type at all. Such pattern is 0xF00000000000 (note that it is correct that there is only one F). 48-bit LEDs identify it as setting current gain/limiting to value 15 (first F in pattern) which is maximum value, but at the same time setting PWM drive to 0 (which are 3 zeros following F). Because PWM drive is set to 0, LEDs do not emit any light.
When 24-bit LED receive this command (it actually receive only half of it: 0xF00000 because it process only 24-bit data instead of 48-bit), it interpret is as setting 0xF0 (240 in decimal) which is quite a high value (max value is 255), so LED will light at almost maximum brightness.
So, when this command is received by 48-bit LEDs they do not emit light and consume very little current. When the same command is received by 24-boit LED, it emits lot of red light and draw a decent pretty easily measurable current. Based on this analysis, my tool determines if analysed LED is 24-bit or 48-bit type. It is actually slightly more difficult because there may be faulty 48-bit or 24-bit LEDs, but my tool takes some of these faults into consideration and can detect various faults of both type of LEDs.
Electronics
For MCU board I selected PSoC 62S2 development kit because this MCU has pretty versatile clocking system. For measuring power consumption, I used MAX40080 Current Sense Amplifier Click Board. It is I2C Sensor with onboard shunt resistor with pretty good range and very low noise. Resolution defined by onboard shunt resistor is not very suitable for this application and allows only very limited characterization of LEDs, but it is good enough to identify if it works or is broken. On the other hand, it has good range, so it can work well even if very long strips with high quiescent current what LEDs draw even when do not emitting any light. It is the same CSA which I used in Experimenting with Current Sense Amplifier in 2022 and write long series of detailed blogs about it. At that time, I create pretty comprehensive library. I reused this library in this project. Here is schematics of device (Click image to zoom):
Firmware
Firmware of device is pretty simple. It is written in C. I made my own library for RGB LEDs. It is written using Modus Toolbox which is used for configuring most parts of system. Actually, configuration of DMAs and SPIs for driving LED signal is moved to related drivers, because I was modifying them frequently. Firmware itself is quite simple, main loop after some basic initializations wait in loop until button is pressed and then start analysis of strip. Some macros are there to define thresholds for checking how much power consumption need to change. You need to modify these if you want to use different CSA. Feel free to download firmware sources codes at the end of this article and modify it for your needs.
Design Challenge Conclusion
Since I joined this design challenge on my own expense and was not selected as sponsored challenge, I did not give it high priority. Especially, I had troubles with receiving PCBs needed for experimenting, so I was not sure If I even get them in time. I got them in time, but had to make it in hurry in about week. But at the end I am satisfied. I spend all my free time this week by playing with these LEDs (and writing blog and forum posts). I like tested Würth LEDs. I made the tool which I originally wanted to do. I tested all three interfaces of LEDs which Würth nowadays uses for controlling their WL-ICLEDs and tool described in this article actually support two of them. I experimented with fallback mechanism, played with multiple types of LEDs on some bus and then integrated experiences from such experiments to final product. I was super excited to play with third interface (two wire) as well. It has some nice properties, but there are some additional complexities which I did not expected. I expect propagation of signals between LEDs to work differently and did not realize some properties before. I will continue to understand how exactly they works after design challenge conclude.
At last, I would like to say thank you to all who read this article so far and even bigger thank you to all who read even my forum posts related to my experiments and tests. At last, I would like to thank element14 community and Würth Elektronik for organizing such interesting design challenge.
