Restrictions on the use of smart LEDs WS2812, WS2801 and similar in modern projects of decorative lighting
For several years on the market of lighting, you can find such names as: "smart led strip", "smart led pixel" and the like. As a rule, a “smart pixel” is an assembly of a miniature 3-channel LED driver (with integrated current stabilizer, PWM modulator and shift register) connected to an RGB LED. Based on these pixels, many manufacturers produce "smart" flexible LED strips, LED "nails" and LED clusters. You can also find such chip models as WS2812, WS2813, with an integrated LED driver directly into the case of a 5050 RGB LED. Small dimensions, a large number of consecutively included pixels (more than 1000 pcs.), Simplicity of control over 1 (2) wire and relatively low solution cost - more than justify their use.
This is my first publication on Habré, in which I want to convey my experience of using and identify the shortcomings of such pixels. Over the past few years I have managed to work with the following LED drivers: LPD6803, WS2801, WS2811, WS2812 (B), TM1903, UCS1903, TM1804, TM1803, SM16716 and other less running. On the Internet, you can often come across such a term as “pixel addressable LED strip” - I completely disagree with this, and this is the first limitation .
Information in such tapes / pixels is loaded via a serial channel, namely via shift registers with 24-bit resolution (as a rule), i.e. 3 channels of 8 bits for RGB. Such addresses do not remember any LED pixels and work solely on a consistent basis. The absence of a control signal on the data line or synchronization (if any), serves as a command to convert the values in the registers into PWM signals for RGB LEDs. For this reason, if the information channel of one of the pixels fails, the subsequent pixels will no longer work correctly. Many inexperienced LED "advertisers" have stepped on this rake, applying such pixels to street screens.
')
The figure below shows broken stripes.
The second limitation is related to the temperature of use. In most cases, the pixels that are controlled only by one wire "DATA", for example, WS2812B - lower temperature use -25 degrees. In practice, often from -15 degrees. This is due to the lack of a good quartz signal regeneration unit inside the chip. Thus, at low temperatures, the pixel stops working correctly, there are “crickets”, etc. to the complete lack of pictures. Another thing - chips with synchronization: WS2801, LPD6803, for example. Here there is a good regeneration of signals by levels, in time - regeneration is not needed, since there is a synchronization line. The working temperature in this case is -40 degrees. But these chips cost twice as much.
The third limitation is the depth of color.
The figure below shows the screens assembled on WS2801 chips.
With the naked eye it is noticeable that the screen with the background is illuminated. The low levels of the “smart pixels” gradient (WS2812, WS2801, etc., almost all) are not able to reproduce in the way that modern screens do. This is due to the low bit depth of the generator integrated into the PWM chip (only 8 bits per channel) and, as a result, the absence of a full gamma correction. Simply put, the LED shines too brightly when you want quite a bit and nothing can be done about it.
A noticeable drawback, in any case for me, was the lack of good software for preparing and converting animation directly for outputting to the hardware. This was the fourth limitation .
At first, I used the LedEdit software.
"LedEdit" provides the ability to create and edit video animation, capture and then convert to hardware. But I can only use this software with their controllers. I also revealed the big drawbacks of LedEdit software in terms of video capture quality and stability of frame processing.
Since I was very interested in this topic and had quite good knowledge in the field of programming, including microcontrollers, I wrote my “grabber” video with subsequent conversion to “pixels”. I immediately put off the idea of combining the ability to create and convert animation in one program, since this is not a professional approach. The animation needs to be created and edited in specialized programs, for example, I chose FREE Jinx! Software.
At the output of the Jinx! Software, you can get an open binary * .out file representing the bit representation of the rectangular matrix data of pixels for each frame. Now it remains for the few: compare the rectangular matrix of data for each frame with the real location of the "smart pixel" on the pixel field and generate a hornbeam animation. This is how I came up with the FREE LS Terminal software.
Now “LS Terminal” software allows working with most video formats * .avi, * .flv and etc., use dozens of ports, process video capture for tens of thousands of “smart pixels” placed by the user. For video processing and visualization I used the OpenCV and OpenGL libraries. I upload data to smart pixels through a microcontroller that reads data from an SD card.
In general, I cited all the main drawbacks of the “smart pixels” and if we put them outside the brackets, then we can see tens of thousands of completed projects. Here are some of them made with my video grabber:
- for LED suits:
- small curved screen on WS2812:
- There are several thousand WS2801 smart pixels in this object:
This is my first publication on Habré, in which I want to convey my experience of using and identify the shortcomings of such pixels. Over the past few years I have managed to work with the following LED drivers: LPD6803, WS2801, WS2811, WS2812 (B), TM1903, UCS1903, TM1804, TM1803, SM16716 and other less running. On the Internet, you can often come across such a term as “pixel addressable LED strip” - I completely disagree with this, and this is the first limitation .
Information in such tapes / pixels is loaded via a serial channel, namely via shift registers with 24-bit resolution (as a rule), i.e. 3 channels of 8 bits for RGB. Such addresses do not remember any LED pixels and work solely on a consistent basis. The absence of a control signal on the data line or synchronization (if any), serves as a command to convert the values in the registers into PWM signals for RGB LEDs. For this reason, if the information channel of one of the pixels fails, the subsequent pixels will no longer work correctly. Many inexperienced LED "advertisers" have stepped on this rake, applying such pixels to street screens.
')
The figure below shows broken stripes.
The second limitation is related to the temperature of use. In most cases, the pixels that are controlled only by one wire "DATA", for example, WS2812B - lower temperature use -25 degrees. In practice, often from -15 degrees. This is due to the lack of a good quartz signal regeneration unit inside the chip. Thus, at low temperatures, the pixel stops working correctly, there are “crickets”, etc. to the complete lack of pictures. Another thing - chips with synchronization: WS2801, LPD6803, for example. Here there is a good regeneration of signals by levels, in time - regeneration is not needed, since there is a synchronization line. The working temperature in this case is -40 degrees. But these chips cost twice as much.
The third limitation is the depth of color.
The figure below shows the screens assembled on WS2801 chips.
With the naked eye it is noticeable that the screen with the background is illuminated. The low levels of the “smart pixels” gradient (WS2812, WS2801, etc., almost all) are not able to reproduce in the way that modern screens do. This is due to the low bit depth of the generator integrated into the PWM chip (only 8 bits per channel) and, as a result, the absence of a full gamma correction. Simply put, the LED shines too brightly when you want quite a bit and nothing can be done about it.
A noticeable drawback, in any case for me, was the lack of good software for preparing and converting animation directly for outputting to the hardware. This was the fourth limitation .
At first, I used the LedEdit software.
"LedEdit" provides the ability to create and edit video animation, capture and then convert to hardware. But I can only use this software with their controllers. I also revealed the big drawbacks of LedEdit software in terms of video capture quality and stability of frame processing.
Since I was very interested in this topic and had quite good knowledge in the field of programming, including microcontrollers, I wrote my “grabber” video with subsequent conversion to “pixels”. I immediately put off the idea of combining the ability to create and convert animation in one program, since this is not a professional approach. The animation needs to be created and edited in specialized programs, for example, I chose FREE Jinx! Software.
At the output of the Jinx! Software, you can get an open binary * .out file representing the bit representation of the rectangular matrix data of pixels for each frame. Now it remains for the few: compare the rectangular matrix of data for each frame with the real location of the "smart pixel" on the pixel field and generate a hornbeam animation. This is how I came up with the FREE LS Terminal software.
Now “LS Terminal” software allows working with most video formats * .avi, * .flv and etc., use dozens of ports, process video capture for tens of thousands of “smart pixels” placed by the user. For video processing and visualization I used the OpenCV and OpenGL libraries. I upload data to smart pixels through a microcontroller that reads data from an SD card.
In general, I cited all the main drawbacks of the “smart pixels” and if we put them outside the brackets, then we can see tens of thousands of completed projects. Here are some of them made with my video grabber:
- for LED suits:
- small curved screen on WS2812:
- There are several thousand WS2801 smart pixels in this object:
Source: https://habr.com/ru/post/305876/
All Articles