Never underestimate the ability of makers in over thinking and over-engineering the simplest of problems and demonstrating human ingenuity. The RGB LED sign made by [Hans and team] over at the [Hackheim hackerspace] in Trondheim is a testament to this fact.
As you would expect, the WS2812 RGB LEDs illuminate the sign. In this particular construction, an individual strip is responsible for each character. Powered by an ESP32 running FreeRTOS, the sign communicates using MQTT and each letter gets a copy of the 6 x 20 framebuffer which represents the color pattern that is expected to be displayed. A task on the ESP32 calculates the color value to be displayed by each LED.
The real question is, how to calibrate the distributed strings of LEDs such that LEDs on adjacent letters of the sign display an extrapolated value? The answer is to use OpenCV to create a map of the LEDs from their two-dimensional layout to a lookup table. The Python script sends a command to illuminate a single LED and the captured image with OpenCV records the position of the signal. This is repeated for all LEDs to generate a map that is used in the ESP32 firmware. How cool is that?
And if you are wondering about the code, it is up on [Github], and we would love to see someone take this up a level. The calibration code, as well as the Remote Client and ESP32 codes, are all there for your hacking pleasure.
Its been a while since we have seen OpenCV in action like with the Motion Tracking Turret and Face Recognition. The possibilities seem endless.
I have same dizziness every Saturday morning
coder1 : someone is gonna have to sequence this effect.
everyone sighs
coder2 : let’s throw some AI at it
fun ensues
I read that as HACKFEM.
You know when you draw a sign and the first letters are real big and wide because you think you have plenty of space but then you get near the end and all of a sudden all the letters are real skinny and squished together?
Just last week I ripped out and replaced a ws2812 based timer display system with alternative “dumb” tech. The cause of the concern was failing ws2812 chips. Were they originals or counterfeit? No one knows, they came on a self adhesive strip. The total combined Led count was approximately 1400 Leds across 4 systems and around 8 failures occured within 1 year. The bad part is that a single failed Led results in mission critical failure as the entire system is rendered inoperable. The alternative technology does have a lot more PCB and driver electronics, but a failed Led will now only reduce visibility, while still performing the key system functionality.
Daisy chained technology makes life easier, until the failures start. And Daisy chained technology on premanufactured low cost self adhesive strips manufactured by a no name lowest cost manufacturer potentially using counterfeit parts with no way of verification is a path to future pain.
I believe variants exist that can compensate for that by having redundant data channels overlapping each led.
Though it’d still croak if two LED’s in a row kick the bucket.
It is the original WorldSemi factory that is making those “improved” chips. It is a weird situation.
THEY are making an improvement, because THEIR chips fail. Wouldn’t it be better to just build a better version that does not fail?
And the failure mode seems to be most often, as murray says: they don’t work themselves and no longer output the stream to the following leds. That too is odd: I would expect the power-electronics to fail first. Not the digital part.
The ability to skip a led is a workaround for the underlying problem. Something that reduces the impact of a real problem but doesn’t really solve it. Solving the real problem would mean that they analyse the failures in the field, find what goes wrong in the chips and then they solve that problem. I had a batch of atmel chips that were bad “straight from the factory”. Their standard procedure was to ask for the chips back and then send me new ones, to make sure they had the old ones to analyse. But it had been published that the problem I had was already known. So in the end I just got replacement chips from them.
When WorldSemi doesn’t know how to properly fix this problem of dying chips, either there is a very big variation of how they fail, or they simply forgot to try to solve it that way.
My theory is that lots of these WS2812 leds are on strips. Long power supply lines when e.g. you put the power supply on one end of a 5m chip, the last ones will have a 4+ m strip as a power supply line. Voltage drop across the line, voltage spikes caused by a sudden: “all leds off” and maybe dynamic effects by the PWM cycles getting into lockstep across a bunch of chips…. That’s what I expect kills these chips. A 5V zener on the supply line every 10 chips or so should do the trick.
I suspect part of the problem is the CMOS comms over such a large distance. My replacement uses only BJTs on the output stages. With the CMOS WS2812 signals there is almost no headroom for spikes or static. My BJT output on the other hand uses cheapish bd680 transistors 100V 4A rated max. each driving 12V segments at 400mA. Personally I don’t let unprotected CMOS signals leave the PCB.
I cannot speak about the ws2812’s… but the WS2811 (the comm/PWM chip) used with 3 external RGB LEDs have been working without failure for about 4 years now… 24/7 outdoor operation (+35C to -40C). I believe the WS2811 is the same chip inside the WS2812 and so perhaps it is a heat dissipation issue given that the WS2812 has an integrated RGB LED?
I wouldn’t be surprised if the heat from the LED dies at full power are killing the “control chip”