Of course, I immediately removed the original controller and installed a d1-mini in the same housing, installed wled, and then realized with disillusionment that it wasn’t working as planned. Only the first 20 LEDs light up.
After searching for quite a while, I finally came across this site.
Has there been any progress?
Has anyone tried to implement the protocol with the pauses, and is it even possible to do so with an ESP8266? I’ve already tried to find a test program.
I’ll connect my oscilloscope to the original controller in the next few days and see what’s going on. Hopefully I’ll be able to do it, I haven’t used it in a long time. But I think it will be the same as what has been found out so far.
I would be very happy if anyone had any information for me.
Have a wonderful day, evening, or night, everyone.
Currently in the process of finding out more about these curtains and it seems to be i am getting somewhere.
At first, i used Wled, but had no good results, so i switched to using a different controller, a commercial one, which can do WS2812S, but with a modified clockspeed of 600 kHz
Tomorrow i will try and see, if a firmware that has been created for testing with Wled, will give similar results.
If the results become usable, we might have some better support soon
(i am using the led curtain sold by Action in the Netherlands, which has an IC before every drop of the data. The IC seems to take off a part of the datastream, after ignoring the first 20 pieces of LED data, as that is for that specific drop.)
I will tell about the testing after the testing is done
But looking at the commercial available expensive controller being succesfull, i thing we have a big shot to getting this working
I’ve just gotten back to my WS2812B splitter project, which basically realizes a curtain (actually a ring of 24 segments radiating down the sides of a tree). The core is an MCU that counts bits directly and switches a network of external demuxes, and I’ve tested the logic on both NeoPixel and FastLED (the latter is way out of spec). I’ve since moved from atmega328 to somewhat faster MCUs (ch559 or ch32v003); the code is in tight assembler. It’s fast enough to switch the signal without delays, sacrifice pixels, regeneration or etc. Actually, it’s a little overkill as the state machine not only recognizes segments but also each pixel (for future projects requiring decoding).
I’m just about to test the 24-segment PCB. I didn’t make it for this Christmas
Do you have any ch32v003 code that might be viewable (github or such)?
I’ve got a bunch of those as well in both 8pin an 20pin versions.
I’d be interested in your approach to routing the bit streams based on timing/counting pixel data.
Those chips should be fast enough to spend at least a little time watching the edge changes.
I really like the fact they’ll run natively at 5V and even act as level shifters if required!
Let me take a look. I ported it but haven’t tested it yet, and am too busy to look at it for a month. But if I’ll check whether I have it up on GitHub and send you a link today of I do.
