My theory is that the chip in the hook at the top of each strand works similar to to how each pixel in a WS281x works. It strips off a certain number of bits and sends them down the strand and then sends the rest of the data down to the next hook. I also figure you must be able to configure how many bits it sends down the strand vs passes along to next hook.
I was talking to a Chinese manufacturer who said he’d sell me just the hooks. But the the image he sent was mostly in Chinese. It does look like each hook is numbered. So I may not be correct in how they work. I’d like to make custom sized curtains. If anyone knows of any documentation or reverse engineering in English I’d appreciate it.
How did you go with this? I’m trying to get an LED curtain going that looks like this, and would be interested in the protocol details for the hooks, otherwise I’m going to have to crack open the logic analyser and start reverse engineering it.
Here’s what I’ve discovered so far:
Setting the strip as WS2812 only writes to the first string, regardless of the length
Setting the strip as APA106, and setting a very long length (>575 pixels) seems to overflow the chips in the tees, and causes a cascading wave of replicated data down the curtain, eventually causing the whole curtain to mirror the first segment. This can be confirmed by creating a 20 pixel segment, and another segment for the rest. Run an effect on the first segment, and turn the second segment off, and each column mirrors the first.
The SOT23-5 chip on the right appears to be one of these, or similar:
The chip on the left has had it’s markings blasted off, but is probably a microcontroller.
The VCC line of the buffer is connected to a uC pin, the input is connected to DI, and the output is connected to the downstream DO. This allows the uC to regenerate the signal and pass it down the line, after blanking however much it wants to keep.
For the LED strip connection, DO is connected directly to DI.
I’m not sure why they have the buffer there, I would have though the uC’s GPIO would be sufficient to regenerate the signal.
The chip on left could be a Padauk PMC150:
The VCC (2) and Ground (5) pins align with the datasheet.
I hooked up a logic analyser to the original controller, and every 20 leds, I can clearly see a logic high pulse that is ~5uS long. This is out of spec for the LEDs, so they ignore it, but it’s pretty likely that this is the signal to tell the chips in the hook to direct the next data stream down to the next hook.
BLE is named ELK-LAMPL with last bits of MAC (i assume)
BLE Thingy cracked open.
It is 20 pixels by column. 20 columns in total. 400 leds / pixels. At each Y split connection from the master row to the column, there’s a chip which seems to take the first 20 adresses and output the rest to the next column.
Dividers. This is the last so nothing is hooked to DO
I dug up a 8266 with Wled 15, plug that shit up to D4 annnnnnddd… Only the first row is ligthing.
Hook back up the BLE thingy, fire it up, works again in full.
What i tried so far :
400 ohm Resistor inline on D4
Level shifter 3-5v
So i broke out the cheap USB osc. i got years ago and hook it up to each of them.
Hooked up to the Data line at the output of the BLE
Hooked up to the ESP8266 with WLED. Config : WS281x 400 leds
So clearly this is not looking to be the same communicaiton protocol. I tested it up with 2 different ESP8266.
So i’m at a loss here. Any other pointers i should check ?
So this sounds like you need to either (1) recreate the protocol on the controller, with a 5uS pulse every 20 leds, or (2) create a switch that copies Di to an output while counting 24*20 pulses and then switches the output from the string to the Do. I’m trying to do something like (2) and am having problems getting stable results probably because my chosen MCU (an ATtiny202) struggles to keep up, but I’m still working on it. Approach (1) seems easier to try and give up if it doesn’t work.
Saying an I2c Levelshifter is equivalent to a 74AHCT125 version is Wrong.
Promoting this stuff in YouTube and elsewhere just continues to cause people issues.
This guy has done this in multiple videos, and promotes less than useful practices in his builds.
DON’T USE I2C shifters with addressable LEDS.
It’s not worth the headaches.
I snipped the 3 wires from the inbuilt controller (USB stick) and tested the voltage… Copper coloured wire is +5V, middle is data, other is 0V.
I then powered this through my WLED controller, I initially set up as a 20 x 20 (400 LED, which it is) matrix but found only half of the lights illuminated, this was all of Y (e.g. all lights on a dangle string… lets call it a column), but only half of X (half of the strings… lets call them rows). After a bit of messing around and some random guessing I tried changing to 800 LED setup, with 40 x 20 LEDs… now this worked in illuminating everything.
However… every other row is missing. what I mean is, to illuminate the first 3 strings I need to set my Y to columns 1, 3, and 5… what this means is overall the effects don’t really work.
