WLED
WLED copied to clipboard
Aircoookie
Tail of the 48 invisible pixels. New Copper Dipped Addressed Pixels it seems
A very odd issue.
Have some of the "ws2812b" dipped copper wire style LEDs. They have been cut off a larger strip off 100. In total there are 40 pixels on the strip. Original set was 100 LEDs.
Was having issues getting them working with both wled and esphome untill I set the pixel count to a a number greater than there length. Then realised the odd issue. The first pixel appears to be the 49th pixel. Ie the first 48 addresses do nothing.
Even hooked them up to a larger strip of normal 12mm ws2812b 1-150 normal ws2812s. Pixels 150-190 should be these. But no. Have to set the chain as 238. LEDs 1-150 light normally 151-198 don't exist so nothing happens 199 onwards light this strip first led onwards
So 48 addresses get skipped then these LEDs start again from 199 onwards.
Hopefully this is clear and someone seen this before and has a clue?
Currently these LEDs terminate on last led of the strip so not able to see what happens of add more to end of the chain. But may cut last one off just to see.
That is indeed strange and I haven't heard of it before... Did you try connecting the input of these directly to the ESP? That would help to see if the problem is with the output of the first 150 LEDs or with the input of these 40.
So Plot thinkens. Split the 40 LEDs into 2 chains of 20 as have a theory that the LEDs actually have a hardcoded or at least static addresses. And then put them in a Y config.
Which technically should with my understanding of normal WS2812s cause them to mirror in they were doing normal shifting of data. And Low and behold on direct conection with ESP one chain responds to Addresses 48-67 the other branch 68-87.
So it seems that the LEDs are physically/logically addressed as 48-87. And I expect they actually pass every packet vs shifting the stream so if I connect normal WS2812s down stream of these ! can get individual leds to light twise with one command. A scan for example goes down first fork then falls off end and lights first led of the second fork
ebay link to the item : https://www.ebay.co.uk/itm/10M-WS2812B-sk6812-RGBW-Fairy-String-Light-Copper-Wire-5V-USB-Pixel-timer-remote/324288164000?hash=item4b8114b0a0:g:l1gAAOSw-mNfbGXT
So yes they seem to be a new sort of "addressed" pixel in some way. They respond to the normal WS2812B commands but are transmitting the entire data stream and know which packet is for them!!!
So New Test Setup Will Refer to new leds as "Copper Dipped Pixels==CDP"
ESP -> JUNCTION -> (A) 20 CDP (Addr48-67) -> (C) 50x 12mm WS2812B -> (D) 50x 12mm WS2812B ->END
^^^ -> (B) 20 CDP (Addr68-87) ->END
So borrowing a bit of code from ESPHOME same effect with WLED as well
Data Sent
it.all() = ESPColor(0, 0, 0);
it[48] = ESPColor(255, 0, 0);
it[50] = ESPColor(0, 255, 0);
it[67] = ESPColor(0, 0, 255);
it[69] = ESPColor(255, 255, 0);
it[71] = ESPColor(0, 255, 255);
it[87] = ESPColor(255, 0, 255);
So with the above 6 commands. A total of 12 LEDS are lite at physical postions
A)
1 = it[48] = ESPColor(255, 0, 0);
3 = it[50] = ESPColor(0, 255, 0);
20 = it[67] = ESPColor(0, 0, 255);
B)
2 = it[69] = ESPColor(255, 255, 0);
4 = it[71] = ESPColor(0, 255, 255);
20 = it[87] = ESPColor(255, 0, 255);
C)
48 = it[48] = ESPColor(255, 0, 0);
D)
1 = it[50] = ESPColor(0, 255, 0);
18 = it[67] = ESPColor(0, 0, 255);
20 = it[69] = ESPColor(255, 255, 0);
22 = it[71] = ESPColor(0, 255, 255);
38 = it[87] = ESPColor(255, 0, 255);
Love to know what these are. Only other thing i can tell you all is the pinout is VCC / GND / DATA. So a little different from the normal. Have to believe the addresseses are software programable in some way but are obviously stored in some way so maybe a programming mode of some sort.
Will keep posting any further findings here.
Interested in this... Bought a bunch of these strings, and using a Pixelblaze on them, noticed that they like 300ns timing, yet depending on pattern, I have 1-2 pixels (usually #2+3 or #4 alone) at the start that "flicker wildly" with lots of data, while the others all work correctly, in a string of 200. Same model/type, same V,G,D layout. These are a weird beast, and I look forward to more people experimenting and reporting back.
If you are correct that forking the data line doesn't created a mirror, these will be a nifty new way to control LEDs, allowing a forked data line to simplify wiring. (Imagine an infinity polyhedra [cube/whatever] where the data line can just split into multiple paths as needed to easily fill all vertexes, but all pixels remain individually addressable!)
I can now confirm these do seem to have a "location memory". Cut 10 off the end of a strand of 200, cleaned the wires (flame off the lacquer and sandpaper), wired to a connector and hooked up to my PB, and they insist (and work normally) on being pixels 191-200, despite being the only pixels in the circuit. More testing coming soon.
https://youtu.be/ge8Swdd9Srw Seeing is believing. 4 individual strands all with a common data line (so data line splits into 4, but all LEDs remain individually addressable!! Not the usual WS2812, eh?)
Glad I'm not going mad. Tried reaching out to some of sellers and even the ws2812 manufacturers. To see if anyone has a data sheet or any info but so far no luck. I had only brought the sets of 100 so it good to know they must have at least 200 programmable addresses. Wondered if the 200 was 2*100 so repeated. As that's the other thing you can do. Join 2 sets of 100 and they will repeat.
Good to know, Ben of Pixelblaze wondered about that aspect... So two strings in serial will repeat?
This really is a mystery. Thank you for posting, as I'm sure I'd have been discovering this and totally confused why it wasn't working normally. Your post here put me on track to confirm and see the value of this.
Interesting. The 2811/2812/2812b "protocol" doesn't send an ID in the data, so what the heck? A theory: each chip is sending the full data set of color bits on to the next chip, and only takes its color from the nth color data from the full set. That would be different from 2811/12/12b, in that, they only send bits that overflow to the next chip.
A way to test: Set the LED count to 1. Hook up a scope or logic analyzer to the data line between the last 2 LEDs in strip. What is being sent? 24bits, or nothing?
@nlflint Given that the single forked data line is transmitting to all 4 strings, I think it's sending all of the data. I can test this (not today), by doing a fork on both ends:
Controller /\ S1 S2 /\ S3 S4
If that works as expected, they have to be passing the entire dataset.
Don't have the scope but sure it full data set as can put normal ws2812s downstream of last pixel and they behave as behave as full data stream is received. Ie can send 100 packets and light 100 of these and the 100 ws2812s downstream so pixel 101 and 1 are both pixel 1 in transactional sense
On Wed, 18 Nov 2020, 22:30 Nathan Flint, [email protected] wrote:
Interesting. The 2811/2812/2812b "protocol" doesn't send an ID in the data, so what the heck? A theory: each chip is sending the full data set of color bits on to the next chip, and only takes its color from the nth color data from the full set.
A way to test: Set the LED count so only lights to the last LED on a given string. Hook up a scope or logic analyzer to the data line between the last 2 LEDs in strip. What is being sent? Full dataset, or data for 1 pixel?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1312#issuecomment-729998204, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRMJZIEVIT6C3H2VXXVALSQRDIDANCNFSM4TJGYLYQ .
It also full dataset as you can put them out of order. So can wire them as 30-39,20-29,1-9,10-19 if you want
On Wed, 18 Nov 2020, 22:36 scruffynerf, [email protected] wrote:
@nlflint https://github.com/nlflint Given that the single forked data line is transmitting to all 4 strings, I think it's sending all of the data. I can test this (not today), by doing a fork on both ends:
Controller / S1 S2 / S3 S4
If that works as expected, they have to be passing the entire dataset.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1312#issuecomment-730000829, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRMJ3JOPZ47XWDNAUTVN3SQRD57ANCNFSM4TJGYLYQ .
Yeah, these aren't ws2812s... Whatever is encased in epoxy is some new magic chip.
There gotta be a way to easily reprogram them. In the factory, they wouldn't do it individually before assembling the strip. There's no way you could keep track of the order. They have to do it after the strip is assembled. Need that datasheet, it probably explains the protocol for reprogramming.
My guess is programming mode is like standard ws2812 protocol so they cascade to learn there string position.
Then normal usage they just pass along the full data stream and then listen for there own packet number. Must be some sort of limit to how many you can have as it storing it's ID in some sort of solid state mem.
Also worth mentioning they really good for power usage. 100 light bright on a USB power bank with little to no dimming in my tests so far.
On Wed, 18 Nov 2020, 22:42 Nathan Flint, [email protected] wrote:
There gotta be a way to easily reprogram them. In the factory, they wouldn't do it individually before assembling the strip. There's no way you could keep track of the order. They have to do it after the strip is assembled. Need that datasheet, it probably explains the protocol for reprogramming.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1312#issuecomment-730003542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRMJYBNYA6OFOXACHEUUTSQREUZANCNFSM4TJGYLYQ .
yeah, that's gotta be how it works. It could also be a one-time programming, once it's done, it's final. If they could be reprogrammed, then once you cut them up, and hook them up in a spiderweb-like configuration, each LED could no longer infer its position. There would be ambiguity until they were put back in a straight line.
Based on what @scruffynerf was demoing, I think they have a permanent (or semi-permanent) address code burned in to them.
I'm guessing the data line is not regenerated, but connected through as one long bussed data line. That would save manufacturing cost, allowing them to have 3 solid uncut wires bonded to the LED modules, compared to the usual WS2812 which will not work if your data line shorts DIN and DOUT, forcing either non-contiguous wires to be assembled or these cut 4-wire hacks you see in other WS2812-compatible fairy wire:
Notice that it looks like that was made with 4 contiguous wires, then every-other middle wire is cut. The red/green color is probably so they don't mix them up during manufacturing, and I bet each color swaps DIN/DOUT order.
Compared to that, these 3-wire bussed-addressable LEDs would be easier to assemble, even with the extra step of programming their addresses somehow after the string was soldered.
So who's going to sacrifice one of their LED's and see what chip is inside?
Willing to try any tips for removing the resin coating as it very hard.
Have dropped one in ISO and another in asotone see if either of those effects it. Had a quick test with side cutters but it so small and hard they just slide or chop straight through the lot.
On Thu, 19 Nov 2020, 03:52 THATDONFC, [email protected] wrote:
So who's going to sacrifice one of their LED's and see what chip is inside?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1312#issuecomment-730111925, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRMJZMRGCOBHWUO3QK7VLSQSI57ANCNFSM4TJGYLYQ .
So first attempt at tearing one down.
So for ref Golden Wire is 5V then GND and Data.
Seems the Data line is indeed continuous so no seperate Din/Dout.
Continutiy check also confirms this. All 3 leads are ~8Ohms for ~10cm section with LED in middle.
As such it seems they must be one time programmed at the factory some how.
@jamestutton, thanks for the photos! I was dying of curiosity! What did you end up using to get the goop off?
Hot air gun @200C seemed to make it brittle and then while it was warm was able to break it up a bit.
I got some, was able to crack the goop after a few tries w/ heat (thanks for the tip!). There's some distortion or residue on the LED package epoxy that made clearer photos challenging. Was mainly trying to find out the method of programming, nothing obvious. Would probably need proper de-cap and a microscope. I do see some pads on the IC that look like they could be unused bond wire spots, opposite the data input bond.
I'm totally speculating here, but it makes me wonder if this IC is floating around in other WS2812 clones on the market that haven't had an address burned in.
@simap to clarify, the middle wire is ground, which is the V+ and data sides? Is the bigger side the V+? (Looking at the original photos, looks like it) Which would make the single wire running to the IC on the left of your photos, the data line connection. Which pads are you discussing, the two near the ground wire?
@scruffynerf These are the pads I'm talking about.
I wonder if one is a potential White, as in RGBW.
But honestly these have to be some new chip, cause it's got just 3 pads, not 4... and I'm really curious what is it. That's not DIN, its just D, cause there is no Dout.
Compare this to ws2812 (really this is likely a SK6812)
Notice the 4 pads because V, G, DI, DO
Or even a apa102 (again this is likely the improved clone):
2 more pads, adding CI, CO
So what is this? Why isn't anyone listing it accurately?
I got some of these "addressable ws2812" LEDs from the thread mentioning them on Reddit. I got the 20M set, and the LEDs on the second half are definitely individually addressable from the first half, but I haven't had a look at the datastream yet. One of the patterns in the included controller turns on (or changes colors) of the LEDs successively, or kind of randomly, and it definitely does the first half of the strip first, then the second half.
Is there a repository of RGB(W) LED controller die photos anywhere? I also took some die photos of WS2815s I got last year (which I suspect are real WS2815s), vs "WS2815"s I got this year with entirely different die in them (I suspect they are GS8208). I would like to either contribute my die photos, or compare to the existing ones to see what I really have
WS2815 from last year - probably real ws2815 with a ceramic cap mounted next to the die
"WS2815" from this year - maybe a GS8208?
