I came across something really strange today.
I ordered these fairy icicle lights off Amazon to use with my WLED/xlights display and I figured they would be just like the low density curtain matrix and the waterfall tree by the same company. Aka fixed address.
Well to my surprise they seem to be addressable. But I am not sure how.
They have a main 3 wire lead that runs horizontal across the top along with an additional 2 wire power injection tied from the lead end to the far end. Then they have repeating segmented drops of 6-4-3 for the icicles. The icicle drops are 3 wire and do not have any wires coming back out of the bottom ends of the icicles to run data back up to the next drop, but somehow they are addressable??
How I know this: I took a cheap string of uncoated BTF fairy lights and hooked them to the Esp, from the end of that string I connected the icicles and set the length to 51 LEDs and all 50 of the BTF string lit along with 1 LED on the icicles. Set to 60… All 50 BTF light and 10 icicles…
Remove the BTF string and connect just the icicles and Bam! 60 LEDs on the icicles light.
I wonder how in the world they are setting the addresses w/out data running from the end of each drop to the beginning of the next drop?
P.S. Just to make sure I was not crazy I did the above tests 2x to be sure I was not crazy.
What happens with Sweep or Sinelon effects, can you actually address a single LED by itself in the "drop string:?
It’s possible the drop LEDs are hard coded addresses, in which case if you swap the first and last drop string, you should see your effects go out of wack. If you do some presets lighting only LED 1-3 and 57-59 (for eg.) you should be able to prove/disprove this theory.
Hmm not 100% sure I understand your idea. Here is what I have tried though.
I connected the string to the gpio and lit 1: first pixel lights
Switched on 10: first 10 pixels light (drops are 6,4,3 so first 2 drops lit)
Connected a 50 ct string of lights in front of the icicles to see if the icicles would light with the same 1-50 addresses as that string and they didn’t. : only the 50ct string lit.
Switched on 51: first string and first pixel of icicles lights.
Switched on 60: first string of 50 light + first 2 drops of icicles (10 pixels) lit
I would think that if they were fixed address the first 50 icicles would have lit along with the 50 pixels in the addressable string that I put in front of the icicles?
I can’t move the far end to the beginning as it’s one string of 260 and I’m not going to cut them apart.
I did just set a segment that corresponded to the first 10 icicles and turned it on and also reversed it. the first 10 came on and when reversed it moved to the last 10.
“I figured they would be just like the low density [curtain matrix and the waterfall tree by the same company. Aka fixed address. Well to my surprise they seem to be addressable. But I am not sure how.”
Let me understand your usage. By “addressable” do you mean “addressable serially” via daisy chaining like the WS2811 etc? And by “fixed address” do you mean addressable in parallel (feeding the same data to all pixels, and each pixel chooses the pre-programmed bytes) like some fairy lights do?
If so, you cannot determine that by inserting serially addressable pixels between them and the controller. A string of 50 serially addressable pixels will “eat” the first 50 outputs (150 bytes of RGB) before it sends the 51st to the following icicles. The 51st RGB sequence will appear to the icicles exactly as if it were the first, whether it’s going to serial or parallel addressable pixels.
The only way to tell is (1) to cut up the icicles (which you don’t want to do, understandably), or (2) to add more pixels after the end of the icicles. The icicles probably do not have an output connector, tho, right?
The way the parallel addressable (fixed-address) pixels work is that each pixel “counts” how many RGB packets to ignore after a reset timeout, before taking the next RGB packet. The first one skips 0 packets, the second skips one packet, etc. But if they are placed after a serial addressable string, the icicle pixels don’t see the first 50 packets at all, and are not counting them. So they will naturally start at the address after the last in the previous serial string.
My guess is that the icicles are indeed parallel addressable (fixed-address), so that they don’t need to bother with a forth wire in each drop to bring back the data out of the last pixel in the drop.
If I’m not understanding your question, feel free to clarify.
I actually have some info on this. I am a member of several xLights FB groups and I came across a post in there where the person took these apart and as it turns out there is a microchip at the top of each drop that tells each drop what pixel data to receive and sends the rest of the data down the line to the next section and so on… The post I am currently able to find talks about the matrix style ones, but same thing… There are also some that have fixed address LEDs. I think mine must have the chips because I remember sticking them after another string of pixels and they worked… The weird thing is I don’t remember seeing any chips on mine. I dunno… Here is a pic from the guy that took them apart:
So, mine doesn’t have a chip at the top of the strand (that would make more sense).
It’s just as per your drawing. Effectively a bus of +v data and ground and each drop is soldered directly. A blob of hot glue to hold it all together.
I suppose it’s possible that the first LED in the chain is “special”, if that’s the case, if I extend a chain (tap off the data line with a sharp pin) and send data for more LEDs, the extension should light if it’s not “special”.
If it is a special LED type, I would very much like to know what they are.
More likely they’re hard-coded addresses.
If you cut the whole thing in half and hook the 2nd half in front of the first, you’ll probably see the new 2nd half light up before the new 1st half.
But wouldn’t putting a string of other fairy lights in front of that whole icicle string cause that first string and the first same # of LEDs in the icicles to both light?
Like a string of 50 in front lit. If the icicles were hard coded wouldn’t the first 50 of them light matching the front string? Cause they don’t
The way hard coded addresses work for addressable LEDs: a particular pixel will have an internal number and it will only respond to that number, none of the others.
What we think of as the normal data “daisy chain” is done differently, the data wire is connected continuously to all pixels just like the power lines. Every pixel watches the entire data stream and waits till it’s numbered info shows up to determine its colour. Nothing is “passed on to the next guy” as in a normal setup so it doesn’t matter where the pixel is physically placed on the string. The LED numbered 37 will always take the 37th piece of colour data in the stream.
Right. So if there were a string of 10 regular pixels before a hard coded string and I lit 1 pixel (so address 0). That means that the first pixel in the normal addressable string would light and the hard coded string connected after that addressable string of 10 would light it’s first pixel as well (assuming that first pixel was the one hard coded to address 0). Right? Or am I not understanding this lol.
Sorry, when I said “split your string” I meant split the supposedly hard coded string to test if its actually hard coded or not. I wasn’t suggesting you mix it with a known “regular addressable” string.
Mixing regular with hard coded is possible, but less useful than you might think.
One issue is that the hard code string doesn’t regenerate the data stream as the data bus is common to all devices, not daisy-chained.
Haha. I was not planning on running addressable lights before it. It would be just as a test to see if the icicles are fixed address or not.
I would assume if they were fixed that the first led in the icicles along with the first LED in the addressable string would turn on if I lit 1 LED in WLED with the addressable string in front of the (possibly fixed address) icicles.
As an example: I have a 100% known string of fixed address fairy lights. Confirmed because I cut the last one off and that cut off led would not light till I told WLED I had enough LEDS to include that ones address. Like if it were a string of 10 and I cut the 10th one off and connected just that one it would not light till I told WLED there were 10 LEDs (even though in reality only 1 was connected) Thus providing solid proof the cot off LEDs address was fixed.
Test 2: Connect a string of 15 ‘addressable’ LEDs and then that single LED after them… That one LED would light up when I told WLED I had 10 LEDs connected.
1-10 addressable LEDs would light
The last 5 addressable would not light
The following single fixed address LED would light (because I hit it’s fixed address of “10”.
I hope you are following this lol…
So as a test for that whole string of icicle lights:
I would think that sticking a string of we will say 10 addressable LEDs in front of it, that if I told WLED that there were 10 LEDs that I would then have the string of 10 addressable LEDs lit ‘as well as’ the 10 LEDs in the icicle string lit that had those same 10 fixed addresses.
If the icicles did not light I would then assume they are not fixed address as if they were addressable none of them should light till I told WLED that I had at least 11 LEDs. At which time the first LED in the icicles would light.
Or am I crazy?
I would think that ‘Test 2’ above would hold true for the icicles as it did for the fixed address fairy lights from the test if the icicles were also fixed address.
Basically testing for fixed address w/out chopping up the icicles. If that test worked for a reg fairy string why would it not work the same for the icicles?
I’ve lying a little about the “serial number” in the hard coded LEDs
There isn’t anyway to “embed” an address number in the LED data stream.
It’s just a series of 8 bit RGB triplet sets that give the brightness for each of 3 LED elements in a pixel.
“Normal” pixels grab the 1st triplet they see at DIn and wait. If they get a “disp” timing sequence, they display the last number they saw. If instead they get another valid triplet, they take what they had and dump it out to the next LED vi DOut and grab the current DIn triplet. Thus the daisy chain carries on for as many LEDs as you tell WLED to display.
Hard coded LED’s don’t pass anything on, they just count how many triplets go by and load up the one set they’re programmed to grab ignoring everything else until they see a “disp” code.
If you have a hard code set attached to the last Dout of a sequence set, the hard code won’t actually see anything until 1+ the number of LEDs in the sequence set, then they’ll start counting.
So if your seq. set is 15 LEDs and you attach hard code 10,11,12 after it, the hard code won’t start to light until 15+10=25 triplets are sent.
Remember, a typical hard code setup has a common data bus not a daisy chain like we’re used to.
Ok. I just did some testing and again @divsys Thanks for the knowledge.
Reference:
Argb = Addressable
Frgb = Fixed/hard coded
Test 1:
50ct BTF addressable fairy string
1 fixed address fairy light (address 63)
Connected 50ct Argb string and connected Frgb pixel after Argb string.
Just as you described, the Frgb pixel would not light with the Argb string in front of it till I got to it’s fixed address + the length of the addressable string. 50 Argb + Frgb’s fixed address of 63. WLED Length 113
Test 2:
Connect Avatar Controls icicle lights
Set WLED Length to 50
50 pixels lit
Test 3:
50ct BTF addressable fairy string
Avatar Controls icicle lights
Connected 50ct Argb string and connected icicles after Argb string
Set WLED Length to 51 and I had all 50 Argb string lit + 1 pixel on icicle string.
Set WLED Length to 57 and I had 50ct Argb string lit + 7 icicle pixels lit.
So that seems like they are truly addressable, but how in the world can they work w/out a 4th wire to return the signal to the top of each drop?
They got some sort of voodoo in those pixels or something.
When looking close I also do not see any chips connected to the wire. Pix attached.
I’m just guessing now, but what if the used Argb for the horizontal part of the strip and Frgb for the vertical “icicles”? Or what if the drop is just a parallel duplicate of the horizontal string after the drop?
One way to check without cutting things is to use a pin or sharp probe to measure the data line resistance at the top of the vertical and at the bottom. If you have Argb, it will be some high value or infinite. For Frgb you should measure 0 (or very low).
Yea they are very strange. They light in the actual order you would expect them to light and everything. There are actually no LEDs on the horizontal line. It is just a power/data bus. The pixels are all on the spliced drops and the first pixel of each drop is I think 3-4in below the horizontal bus (best seen at pixel 7 in the pic).
They worked fine last Christmas w/xLights too. (youtube blocking Christmas video here is New Years) - YouTube
If I get a chance tomorrow I’ll check the resistance of the data line. Might not get to it till next week as I am going out of town Friday.
Not a big deal. They work as intended. I just wonder how… If they weren’t $50+ a string I would be more inclined to cut them for a true test.
On the flip side of things I can 100% tell you that these ones in the tree config from Avatar are all just parallel as each drop lights exactly the same at the same time. Light 2 LEDs and the first 2 of each drop light. Light 3 and first 3 of each drop light and so on…
I went ahead and cut the last pixel off of the first drop. Drop was 6 pixels long so now it’s 5.
Test 1: Connected the 6th cut off pixel to controller and told WLED there was 1 pixel. It lit.
Test 2: Connected icicle string to controller and set WLED to 5. First drop lit. Set it to 6 first drop (remember there are only 5 pixels there now) still lit. Set to 7, first drop lit and first pixel of second drop lit.
Test 3: connected icicles and connected Argb fairy string to where I cut the pixel off. Set WLED to 6, First drop and 1 pixel on fairy string light. Set to 7 and first drop, 2 pixels on fairy string light AND first pixel on second drop light. Set it to 8, First drop and 3 pixels on fairy string light AND first 2 on second drop light.
Mystery solved!
It looks like the first pixel of each drop is a fixed/hard coded one and the ones below it are regular addressable pixels. Test 1; supports this.
The interesting thing here is that the hard coded pixel must still be passing on the data to the addressable pixels below it and also letting them know to take the address after it’s hard coded one.
So as long as the first pixel of every drop is good you can replace any of the other pixels if they fail, with an addressable one.
Cause they don’t 
glad that’s over lol.