Tail of the 48 invisible pixels. New Copper Dipped Addressed Pixels it seems

[jamestutton]

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.

[Aircoookie]

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.

[jamestutton]

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

[jamestutton]

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.

[scruffynerf]

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!)

[scruffynerf]

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.

[scruffynerf]

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?)

[jamestutton]

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.

[scruffynerf]

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.

[nlflint]

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?

[scruffynerf]

@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.

[jamestutton]

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, notifications@github.com 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 .

[nlflint]

@jamestutton ah, well there you go.

[jamestutton]

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, notifications@github.com 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 .

[scruffynerf]

Yeah, these aren't ws2812s... Whatever is encased in epoxy is some new magic chip.

[nlflint]

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.

[jamestutton]

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, notifications@github.com 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 .

[nlflint]

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.

[simap]

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.

[THATDONFC]

So who's going to sacrifice one of their LED's and see what chip is inside?

[jamestutton]

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, notifications@github.com 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 .

[jamestutton]

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.

[simap]

@jamestutton, thanks for the photos! I was dying of curiosity! What did you end up using to get the goop off?

[jamestutton]

Hot air gun @200C seemed to make it brittle and then while it was warm was able to break it up a bit.

[simap]

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.

[scruffynerf]

@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?

[jamestutton]

To confi Large one is 5v+ middle is gnd then left is data

[simap]

Gotcha, updated comment for clarity for future readers.

[simap]

@scruffynerf These are the pads I'm talking about.

[scruffynerf]

@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?

[blardyblar]

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?

[cpldcpu]

@scruffynerf , @simap

Nice photos! This is one of the smallest RGB controllers I have seen. Have you tried measuring size by referencing to some known object?

I guess this is a fairly new design, that is probably rated for low current only. Maybe 5 mA? have you tried to measure?.

If you look at the two unpopulated die pads, you can see that one of them is smaller than the other. The smaller pads is possibly a test pad that can be used to program an address and/or test the die functionality.

The other remaining pad could be Dout, unused in that case? I don't think it is a fourth LED driver, since it is positioned at an angle.

[Corpsman09355]

I had just picked a string of these up in Oregon last night on nothing more then 'poor product description...that has to be individually addressable, I'll buy it and connect it to WLED, what could go wrong!" ;) I am more than a little tickled at the like minded approaches and a bit miffed at only finding this thread after my efforts petered out tonight that might have saved me racking out at 3am trying to figure out less than y'all have already. All I can say is thanks for the pointers towards ESPHome, and I've got a few epoxy chips missing from some sacrificial leds if anyone is short. Thanks for all your efforts, hopefully a spec sheet or manufacturer can be found. Something tells me support@vglightingplus.com isn't going to lead very far but I'll post if I hear something useful back.

[cpldcpu]

I looked into these LEDs and have been meaning to write up the details for a while. But alas, I don't think I'll get around to doing it, so just some quick notes here. I analysed transient changes of the supply current, which can give a lot of insight into what is happening in these devices.

These LEDs are actually quite interesting and are unlike any other I have looked into so far. It seems to be a design that is separate from WS2812 and clones that are on the market. This does not only refer to the unusual protocol, but also to other features.

• The LEDs do indeed have an address that is loaded from a one-time-programmable programmable memory after reset. One can see that there is a period of increased current consumption ("reload"), which most likely corresponds to biasing of the memory. (see first pic below. Note that a lower voltage corresponds to higher supply current.)
• The address determines how many packets of 24bit are skipped before accepting the data.
• Between 100µs - 150µs after power-on reset, there is a period when the device already accepts data, but the address has not been loaded. During this time, the address is fixed to "0". So the first data packet will be used to update the PWM.

A question that remains to be solved is when the address is actually programmed. This could happen at wafer level (using the small test pad close to the center of the die), before the die is assembled, or at device level. If it is done at device level, then there must be a way to activate the programming mode. For example by applying a voltage >VDD somewhere or entering a key code. However, it is possible that this programming mode is disabled after the device has been programmed once.

Other interesting features:

• I believe that one of the unpopulated pads is a data out pin. I can see current transients that correspond to this pad being driven. This means that the driver IC can also be used in a "classical" daisy chain configuration. (The address will still skip "n" data sets and not forward them, it appears).
• There is a standby mode that is activated a few 100µs after an RGB value of 0,0,0 was written to the PWM registers. Wakeup occurs when data is sent to the device and only takes around 1µs.

[stale[bot]]

Hey! This issue has been open for quite some time without any new comments now. It will be closed automatically in a week if no further activity occurs. Thank you for using WLED!

[marmilicious]

Has anyone run across any further information about this pixel or how it's addresses are set?

[birukun]

What voltage level does the data line need to be? Can this be controlled with a Pi or should I use Arduino or Teensy, etc. Thanks

[jamestutton]

Hi experimentally they are 3.3V logic tolerant to a point. The issue you will have is voltage drop in the signal line and hence signal losses. Unlike the normal WS2812 etc there is no retransmission of the data signal. So the signal you put in to the first pixel needs to be read by the furthest pixel. So with a 3.3v line and the cable losses you can probably get away with 10-20pixels and signal still be readable. Anything over that your likely start getting weird behavior or no response.

What you can do as a trick is get the the single PCB mouted WS2812B search for "WS2812b White Mini board" and then use this as the first chip in the chain. These have seperate D-In and D-out so basically act as level shifter so that all the pixels downstream now have a 5V logic signal but you can drive the first pixel from 3.3V (Ideally near the board).

[prabbit237]

Some insights on these weird LEDs:

Don't worry about keeping track of which end is which. It actually doesn't matter and you can actually connect to EITHER end and the LED that was closest to the original controller (all the ones I've been seeing on Amazon come with their own controller) will be the lowest number and increment from there.

In fact, I suspect you could connect the ground, power and data anywhere in the strip and they'd work the same (I just haven't tried that experimentally yet.) So if you're concerned about issues with the cable losses, connect in the middle if possible (although I've currently got 30 of them connected at the high-numbered end and powered from the 5v pin on a Wemos D1 Mini and they're working like a charm.)

However.....no matter how you connect them, you still have the issue of them not starting with LED 0 (or 1, depending on how you look at it.) And I wanted to use some of these in some mood lamps that I'm making as gifts that I wanted to be somewhat idiot-proof and not having to worry about if someone resets it and then doesn't know what the starting number is. I want to be able to cut a section off the long string and then set it to start at 100 or 59 or 123, etc and have that survive a factory-reset. Took a while but I found the right spot in the code to set that.

In bus_manager.h, look for the line reading:

    _skip = bc.skipAmount;    //sacrificial pixels

Add the following defines and modify that one line:

#ifndef STARTING_OFFSET
#define STARTING_OFFSET 0
#endif
    _skip = bc.skipAmount + STARTING_OFFSET;    //sacrificial pixels

Then in platformio.ini, you can add something like -D STARTING_OFFSET=159 and it now skips to the right number. It'll survive a reboot and the autosave usermod works fine with it. The offset needs to be one less than the LED address of the lowest LED (i.e. it's zero-based.) So in this case, I'd cut off 40 LEDs at the end of the strip so was working with LEDs 161-200.

===edit===

====grrrrrr==== It's not surviving a reboot/power off and on like I thought it was. Will update this once I figure out the issue.

===edit 2===

Ok, this seems to work OK. The USERMOD auto_save wasn't storing the preset correctly. But the following seems to be working. Use the -D STARTING_OFFSET=(whatever) but instead of the above code change do the following change in bus_manager:

---  BusConfig(uint8_t busType, uint8_t* ppins, uint16_t pstart, uint16_t len = 1, uint8_t pcolorOrder = COL_ORDER_RGB, bool rev = false, uint8_t skip = 0) {

+++ #ifndef STARTING_OFFSET
+++ #define STARTING_OFFSET 0
+++ #endif
+++   BusConfig(uint8_t busType, uint8_t* ppins, uint16_t pstart, uint16_t len = 1, uint8_t pcolorOrder = COL_ORDER_RGB, bool rev = false, uint8_t skip = STARTING_OFFSET) {

Then add the following code to usermod.cpp in the userSetup() function:

void userSetup()
{
    for (uint8_t s = 0; s < WLED_MAX_BUSSES; s++)
    {
        // actual finalization is done in WLED::loop() (removing old busses and adding new)
        uint8_t type, reverse, colorOrder, skip, pins[5];
        uint16_t length, start;

        if (busConfigs[s] != nullptr)
        {
            // We don't want to change any values. We simply want to recreate the busses. 
            // The code in set.cpp pulls these values from the POST data so it but we can't do that here. 
            // So set.cpp simply looks for an existing busConfigs and deletes it but we save the data first.
            type = busConfigs[s]->type;
            for (uint8_t i = 0; i < 5; i++)
                pins[i] = busConfigs[s]->pins[i];
            start = busConfigs[s]->start;
            length = busConfigs[s]->count;
            colorOrder = busConfigs[s]->colorOrder;
            reverse = busConfigs[s]->reversed;
            skip = busConfigs[s]->skipAmount;
            // NOW we can delete it.
            delete busConfigs[s];
        }
        // And then re-add the buss. 
        busConfigs[s] = new BusConfig(type, pins, start, length, colorOrder, reverse, skip);
        doInitBusses = true;
    }
}

I had found that the original change worked OK when first setup but then on reboot it didn't load the AUTO_SAVE preset properly. In playing around in the CONFIG section of the GUI, I went into LED PREFERENCES and clicked on SAVE without changing anything and it started changing the LEDs again as it should have. So the code for userSetup() does the same thing as the SAVE in terns of setting up the bus(es) again.

[thoj]

Has anyone got the 20m version to run without flickering on low brightness? I have tried most things. But I seem to get some flickering on the first 20-30 leds on some runs when the brightness is set at below 50-60%

I have tried series resistor (this just seems to make the problem worse?)

Level shifter. Makes the whole run flicker wildly.

Ceramic cap on data line (some success, seems to flicker less.

My oscilloscope shows really bad noise on the data line.

Yellow is data line with 3.3nf cap. Turquoise is without anything. Just directly form the esp32 to the data line on the fairy lights. Please note that the second peak goes much higher on low brightness/load. Guess it's ringing and reflections? I have yet to try a small cap + and series resistor.

Any other suggestions? Also I really want to know why this pretty much just affects the first leds. Pretty counter intuitive in my head.

[todbot]

Any other suggestions? Also I really want to know why this pretty much just affects the first leds. Pretty counter intuitive in my head.

You need a level shifter on your data line to bring it to 5V. And you're powering the strip at 5V too, yes?

[thoj]

A 5v level shifter makes the whole string fliker wildly. As I said in the first post. The same level shifter circuit work great for ws2812b but not for this type of chip. If the signal level was the problem the flickering would occur more on the last leds not the first(?) as this chip uses a continuous bus.

Yes the power is at 5v.

[todbot]

Weird. I've been driving a full strand of these with a 5V Arduino Pro Micro with no problem. What is your 5V power supply? Perhaps it's spitting out noisy 5V.

[thoj]

Its a pretty good supply and I put a 1000uF cap right before the leds too. Do you use a series resistor on the data output? I might have to try with a diffent level shifter that can supply more current 😓

[todbot]

Level shifters do not supply current. They just convert a data line from 3.3V to 5V. It would be useful to see a wiring diagram of how you have things hooked up.

[blazoncek]

Level shifter (fast enough) should solve the issues regarding the noise at 3.3V. What kind were you using? Some LEDs may be more susceptible to noise (input voltage level on 1st LED) than others.

[blardyblar]

have you tried a resistor in series with the data line at the beginning, and another (matching) resistor at the end of the string on the data line as a terminator? Regular pixels don't need a terminator at the end, as each pixel regenerates the data out signal, but here where it's actually a long bus, both ends should be terminated.

Not sure about these pixels, but for regular pixels, the consensus seems to be 33 ohms in series with the data line provides the best matching / least ringing.

I'd get a couple decade resistor boxes, put one in series at the beginning, and one to ground at the end, and play with different values while watching the scope to reduce the ringing

On Thu, Dec 16, 2021 at 9:36 PM Blaž Kristan @.***> wrote:

Level shifter (fast enough) should solve the issues regarding the noise at 3.3V. What kind were you using? Some LEDs may be more susceptible to noise (input voltage level on 1st LED) than others.

— Reply to this email directly, view it on GitHub https://github.com/Aircoookie/WLED/issues/1312#issuecomment-996451535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADVNDP3QPGKGPB5PPGVLXE3URLD5NANCNFSM4TJGYLYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[ChayD]

Apropos of these devices, I thought I'd mention that I've recently run across some even more intriguing tiny two wire addressable RGB LEDs (as in ground, and multiplexed power and data). My dad brought a string of them in a "rope light" format, which piqued my interest. As I didn't want to destroy my Dad's lights, I've ordered a set (still en-route from China). From what I can see, based on the pre-programmed patterns they display, they operate in groups of eight repeated along the chain, and appear to be pre-programmed with (I guess), a three bit address with the data and ground lines being common across all devices on the line. Once I receive them, I'll scope the data lines and post some images.

[cpldcpu]

I've recently run across some even more intriguing tiny two wire addressable RGB LEDs (as in ground, and multiplexed power and data).

Sounds interesting. Do you have a link?

[ChayD]

I've recently run across some even more intriguing tiny two wire addressable RGB LEDs (as in ground, and multiplexed power and data).

Sounds interesting. Do you have a link?

Sure, here you go: https://www.wish.com/product/5f8d550f2ab2f78f0d06414b?share=web

[cpldcpu]

Thanks! I found this on Aliexpress: https://www.aliexpress.com/item/1005003070133485.html

Same remote control. And it came with a high resolution photo.

Edit: I ordered one set, looks intriguing to hack into it :)