I fried the first led of my (one and only) 16x16 serpentine matrix.

I fried the first led of my (one and only) 16x16 serpentine matrix. I’ve no idea why that happened, but it did. Unfortunately I have no spare WS2812B arround. So I soldered the datawire to the 2nd led (which was a nightmare on these thin flexible plasic “pcb”). Anyway, now the controller speaks again to the rest of the leds.

Problem: When calling FastLED.show I need to manage to start writing led data beginning at the 2nd led. Sounds easy, just move the content of the framebuffer by 1 led. But if I touch the leds CRGB inbetween all my effects don’t work properly anymore.
So I really need to output the framebuffer as it is - just skipping led nr. 1 and beginning with led nr. 2.

It might sound stupid, but I have no idea how to do that…
Any thoughts about a solution or a clever work arround?

CRGB leds[NUM_LEDS];

void setup() { LEDS.addLeds(leds+1, NUM_LEDS - 1);}

It will now silently skip over the first led.

(where NUM_LEDS is the pre-burned out count of lsds)

(why no, I have_never_ had to do this before, why do you ask?)

Super, that does the trick! Thanx @Daniel_Garcia !

I do something slightly different, for a slightly different case: each column of the matrix on my jacket is a different height, to allow for head and arm holes. For the pixels that aren’t there, I return a dummy pixel:

https://bitbucket.org/ratkins/technocolourdreamcoat2014/src/c7a8b9100e30e697cc92a8559051ee135559d9eb/Effect.cpp

class Effect {

protected:

CRGB deadPixel;

int columnHeights[WIDTH] = {
    20, 20, 20, 20, 18, 18, 18, 14, 12, 
    12, 14, 20, 20, 20, 20, 18, 18, 18, 
    18, 18, 18, 20, 20, 20, 20, 14, 12, 
    12, 14, 18, 18, 18, 20, 20, 20, 20
};

public:
Effect(CRGB *leds) : leds(leds), deadPixel(CRGB::Black) {}

bool visible(int16_t x, int16_t y) {
  return x >= 0 && y >= 0 && x < WIDTH && y < columnHeights[x];
}

// […]
struct CRGB& pixel(int16_t x, int16_t y) {

    if (visible(x, y)) {
        uint16_t sum = 0;
        for (int i = 0; i < x; i++) {
          sum += columnHeights[i];
        }

        if (x & 0x01) {
            return leds[sum + columnHeights[x] - y - 1];
        } else {
            return leds[sum + y];
        }
    } else {
        return deadPixel;
    } 
}

// […]

(Note that I’m also returning a reference from my pixel() method, so I can say things like “pixel(x, y) = CRGB:Orange” from the calling code. Works well.)

define the whole array and an additional pointer just point the pointer for the FASTLED constructor to the the addtional pointer?

CRGB LEDS[100];
CRGB * LEDPTR = &LEDS[1];

FASTLED<WS2812,LEDPTR>;

Just a guess here…

I have burned the first WS2812b in a strip before, that was before I knew about the 300-500 ohm resistor on the data line before the LEDs.

I have solderd a 220 ohm resistor in the dataline to each from my projects. After i burned 2 Leds… Safety first :wink: In case i have a other 220 ohm resistor in line the serial value are less than the alowed 500 ohms.

There was a 220 ohm resistor before the first led. And I did nothing different than the 1000 times before: switching on the led power supply first, switching on Arduino second. I have no clue, what caused the problem.

@Stefan_Petrick How about a capacitor across the power supply to block voltage spike at startup?

I use an old AT computer supply and the capacitor(s) look ok. (Although Daniel recommended not to do so.) The current while switching on and off looks still ok on an (old analog…) oscilloscope, too.
If a dirty voltage would cause the problem, I see a very little chance that it would only affect one and then only the first led… Or am I thinking too simple here?

The WS2811/2’s regenerate the signal from chip to chip, which means there’s no direct connection between the data line coming into the chip and the data line coming out of the chip. So, if you have a voltage spike over the data line fry one of your WS2812’s, it’s not going to continue down the line taking them all out :slight_smile:

Would a 5v zener diode on the data line help with this?

that’s beyond my electronics knowledge to know. I still shout “YOLO!” as I connect the data pin on my MCU directly to DIN on my leds :slight_smile:

2 ideas I have what might caused the dead WS2812: A) The room is full of all kind of electric gadgets radiating electromagnetic emissions: wifi, bluetooth, cell phone, tube amplifiers, … My 2m data line was not shielded. Maybe it catched enough voltage “from the air” to damage the chip. Hard to believe. B) I used an old 30 kW buzzsaw (a nice toy!) connected to the same electric house connection - possibly that caused by induction massive voltage spikes. But then I would expect more then one dead led. And no other electronic showed any symptoms.

I dont think a zener diode help in this case. The problem is a to high current from the data line to the strip when the ground is connected and the +5v not. In this case all leds try to get the power over the data in from the first led and destroy something inside. The resistor limit only the current. But Stefan Petrick had this… i had no idea… maybe you can check your resistor. Coils can have the same form and same color marks like resistors but complete different electrical values (coil with 220mH )

@Michael_Albert Is there a good way to ensure that the LEDs never get power before Data? Like a mosfet or something?

I think you mean data before power :slight_smile:

@Daniel_Garcia It’s one of those days