Anybody used this LED strip?

I have it wired up as recommended with capacitor and 470ohm resistor:

I thought I had destroyed it, by briefly getting the power wires mixed up, because I couldn't get anything out of it from test programs in either Neopixel or FastLED.

But then this morning when I woke up it was doing a rather long sequence of things using the first 30 leds. Obviously capable of making light. I do not understand where that sequence came from. Is there demo code in the LED chips themselves? I've checked all my wiring, and nothing is flickering if I wiggle any of it.

So I uploaded the FastLED test code below, and it went to a single blue LED #0. Then I uploaded the Neopixel code below. Still one blue LED. It seems completely unresponsive now. But not completely dark like it was yesterday!

Here's the fastLED test code:

#include <FastLED.h>

#define NUM_LEDS  18
#define LED_PIN   6

CRGB leds[NUM_LEDS];

void setup() {

  FastLED.addLeds<WS2812B, LED_PIN, GRB>(leds, NUM_LEDS);
  FastLED.setBrightness(50);
}

void loop() {
  leds[0] = CRGB::Red;
  leds[1] = CRGB::Green;
  leds[2] = CRGB::Blue;
  FastLED.show();
}

after uploading (I'm not sure whether this code was already in the esp or not...) I got this trace:

09:16:24.178 -> EspIO: backend=UART0 (compile-time choice; #define FASTLED_ESP_FORCE_USB_SERIAL_JTAG to switch)
09:16:24.178 -> src/fl/channels/manager.cpp.hpp(38): ChannelManager: Initializing
09:16:24.178 -> src/fl/channels/manager.cpp.hpp(171): ChannelManager: Added driver 'RMT' (priority 2, caps: CLOCKLESS)
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt_memory_manager.cpp.hpp(49): RMT Memory (ESP32-S3): TX=192 words, RX=192 words (DEDICATED pools)
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(685): WARN: [RMT5_ENCODER] Timing config: resolution=40000000Hz, ns_per_tick=25
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(687): WARN: [RMT5_ENCODER] Bit0: high=10 ticks, low=40 ticks
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(688): WARN: [RMT5_ENCODER] Bit1: high=35 ticks, low=15 ticks
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(689): WARN: [RMT5_ENCODER] Reset: 11200 ticks
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(722): WARN: [RMT5_ENCODER] Encoder created successfully
09:16:24.275 -> E (5416) cache: esp_cache_msync(113): invalid addr or null pointer
09:16:24.275 -> src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(464): RMT5_PERIPH: Cache sync disabled due to ESP_ERR_INVALID_ARG. Memory barriers will ensure ordering. 

I searched on it, and it said it was not fatal, but I didn't do much more before trying the Neopixel code:

/*
 * This ESP32 code is created by esp32io.com
 *
 * This ESP32 code is released in the public domain
 *
 * For more detail (instruction and wiring diagram), visit https://esp32io.com/tutorials/esp32-ws2812b-led-strip
 */

#include <Adafruit_NeoPixel.h>

#define PIN_WS2812B 6  // The ESP32 pin GPIO16 connected to WS2812B
#define NUM_PIXELS 30   // The number of LEDs (pixels) on WS2812B LED strip

Adafruit_NeoPixel ws2812b(NUM_PIXELS, PIN_WS2812B, NEO_GRB + NEO_KHZ800);

void setup() {
    Serial.begin(115200);
  while (!Serial) {
    delay(100);
  }
  delay(5000);

  ws2812b.begin();  // initialize WS2812B strip object (REQUIRED)
}

void loop() {
  ws2812b.clear();  // set all pixel colors to 'off'. It only takes effect if pixels.show() is called

  // turn pixels to green one-by-one with delay between each pixel
  for (int pixel = 0; pixel < NUM_PIXELS; pixel++) {         // for each pixel
    ws2812b.setPixelColor(pixel, ws2812b.Color(0, 255, 0));  // it only takes effect if pixels.show() is called
    ws2812b.show();                                          // update to the WS2812B Led Strip

    delay(500);  // 500ms pause between each pixel
  }

  // turn off all pixels for two seconds
  ws2812b.clear();
  ws2812b.show();  // update to the WS2812B Led Strip
  delay(2000);     // 2 seconds off time

  // turn on all pixels to red at the same time for two seconds
  for (int pixel = 0; pixel < NUM_PIXELS; pixel++) {         // for each pixel
    ws2812b.setPixelColor(pixel, ws2812b.Color(255, 0, 0));  // it only takes effect if pixels.show() is called
  }
  ws2812b.show();  // update to the WS2812B Led Strip
  delay(1000);     // 1 second on time
  Serial.println("cycling");

  // turn off all pixels for one seconds
  ws2812b.clear();
  ws2812b.show();  // update to the WS2812B Led Strip
  delay(1000);     // 1 second off time
}

I tried cutting power for 30 seconds, still the same single blue LED. Cut power for half an hour, and now it's completely dark again. The neopixel routine is running....

I am very confused. Any troubleshooting tips welcomed.
Thanks!
-eric

For sure not.
Post a photo of your setup.

I have used many BTF-lighting, 5050, 5vdc, 6M/150pix with Adafruit and FastLED. The neopixels work out-of-box. Some users have said the neopixels fade over time, but I run mine at 50% brightness, have not faded, and are great for indoor decoration.

I get "randomness" when (1) I write out-of-bounds, (2) I put too many pixels at full-bright, (3) my solder joints are poor.

Your first sketch only shows three pixels in use. Your second code addresses 30. My guess is you loaded the second sketch. Did you see "cycling" on the Serial Monitor (second sketch)?

I used Wokwi.com on your second sketch, and it worked without error report.

You can "simulate" your issue (FastLED "ticks" and memory errors) in Wokwi.com

sketch.ino:

#include <FastLED.h>

#define NUM_LEDS  18
#define LED_PIN   6

CRGB leds[NUM_LEDS];

void setup() {
  FastLED.addLeds<WS2812B, LED_PIN, GRB>(leds, NUM_LEDS);
  FastLED.setBrightness(250);
}

void loop() {
  leds[0] = CRGB::Red;
  leds[1] = CRGB::Green;
  leds[2] = CRGB::Blue;
  FastLED.show();
}

diagram.json (using ESP-32 C3:

{
  "version": 1,
  "author": "xfpd",
  "editor": "wokwi",
  "parts": [
    { "type": "board-esp32-c3-devkitm-1", "id": "esp", "top": 0, "left": 0, "attrs": {} },
    {
      "type": "wokwi-led-matrix",
      "id": "matrix1",
      "top": -65.6,
      "left": 105.2,
      "attrs": { "rows": "6", "cols": "6", "pixelShape": "circle" }
    }
  ],
  "connections": [
    [ "esp:TX", "$serialMonitor:RX", "", [] ],
    [ "esp:RX", "$serialMonitor:TX", "", [] ],
    [ "esp:6", "matrix1:DIN", "green", [ "h0" ] ],
    [ "esp:5V.2", "matrix1:VDD", "red", [ "h0" ] ],
    [ "esp:GND.6", "matrix1:VSS", "black", [ "v-0.3", "h71.74" ] ]
  ],
  "dependencies": {}
}

Error report...

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0xc (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x420
load:0x403ce000,len:0x90c
load:0x403d0000,len:0x2370
entry 0x403ce000
E (EspIO: backend=UART0 (compile-time choice; #define FASTLED_ESP_FORCE_USB_SERIAL_JTAG to switch)
src/fl/channels/manager.cpp.hpp(38): ChannelManager: Initializing
src/fl/channels/manager.cpp.hpp(171): ChannelManager: Added driver 'RMT' (priority 2, caps: CLOCKLESS)
src/platforms/esp/32/drivers/rmt/rmt_5/rmt_memory_manager.cpp.hpp(56): RMT Memory (ESP32-C3/C6/H2): TX=96 words, RX=96 words (DEDICATED pools)
src/platforms/esp/32/drivers/rmt/rmt_5/rmt_memory_manager.cpp.hpp(305): calculateMemoryBlocks(networkActive=false): using 1 blocks (idle=2, network=3, max=2, allocated_tx_channels=0)
src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(685): WARN: [RMT5_ENCODER] Timing config: resolution=40000000Hz, ns_per_tick=25
src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(687): WARN: [RMT5_ENCODER] Bit0: high=10 ticks, low=40 ticks
src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(688): WARN: [RMT5_ENCODER] Bit1: high=35 ticks, low=15 ticks
src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(689): WARN: [RMT5_ENCODER] Reset: 11200 ticks
src/platforms/esp/32/drivers/rmt/rmt_5/rmt5_peripheral_esp.cpp.hpp(722): WARN: [RMT5_ENCODER] Encoder created successfully
src/platforms/esp/32/drivers/rmt/rmt_5/channel_driver_rmt.cpp.hpp(901): WARN: [RMT TX] Channel created on GPIO 6 (48 symbols, non-DMA)

You left it powered up overnight? Why.

Normally connecting the wires the wrong way round for a short time will destroy most electronic devices unless there is some circuit to mitigate this.

I find it hard to accept this version of events.

160 LEDs require a beefy 5volt supply.
And a level shifter when driven with 3V3 logic.
And a capacitor and a resistor at the start of the strip.
Did you, or did you just hope it would work without.

I am also quite surprised at times at what some chips actually survive. Accidental misconnection is not always fatal. Some Strips can use ws2811 chips without a 330R resistor between every cuttable place, and those break a lot easier.
Had some WS2815 LEDs just the other week and Data accidentally to GND or 12v appeared to be Ok. Reverse-power is usually a different matter though, but even then sometimes it's Ok.

I suspect that they innovate to make brighter strips and chips as well. When new stuff arrives it looks so much brighter than some old strip, but those old strips don't actually spend a lot of time being powered. It's all just testing you know.

The resistor in series is a termination resistor, to prevent reflections (false pulses) in longer data wires. It has little to do with the LED itself.

I didn't check which sketch, before loading one over it. I guess that was foolish, but I thought it was 'working' suddenly :\ Yes, I always see 'cycling' when I load that sketch, that part is working.

No, I power the esp down whenever I'm not working on it for any length of time. I did power it down last night. The lights all came on when I turned it on in the morning. Sorry about the inexact language.

I might have left it hooked up backwards on the PSU for 15-30 seconds. I don't remember exactly.

The very first line I wrote addresses this. Yes, I wired up the correct resistor and capacitor. Checked it against three different websites (one recommended a 330ohm resistor, otherwise they were the same) And yes, I ran a ground wire between the strip and the esp.

My PSU is 2 amps, 5 volts. I was hoping it would run 30 LEDs or so, but it's just for testing anyway. But I did not read anywhere about needing a level shifter to run from 3.3v. Is that for the logic? I'm not trying to POWER it from the ESP, if that's what you're suggesting!

I have not been able to post a photo on a reply from my phone, but I did rewire up everything to a fresh esp32, just in case some of the unrelated wiring (for servos and sensors) had some conflict on the original board (although I tried three different pins.) After that, I did get the single blue led again. And again nothing changed as I loaded one script and then the other.

Just now I powered it back up again, and got nothing lit up with either script. I guess I have to assume I've damaged the strip, or it was never working to begin with. I suppose it's the ICs that go, not the LEDs themselves.

Its behaviour this morning is still a puzzle. Maybe I dreamed it.

I'll order another one. Not the most expensive mistake I've made on this project ;)

Thanks all!
-e

That means the "30LED" sketch was loaded. The "3 led" sketch does not contain "cycling"

No. Do not.

It is possible you have fried only the first Neopixel, which now interrupts data.

First, verify your wiring is correct. Do you have data wired to DOUT? Do the (unpowered) power lines have continuity (without shorts)? Same with the ground lines.

If that is not the answer, try soldering a jumper from input data line to the second DIN copper pad. The power/ground should be good.

It also limits current, which can make a world of difference in case Dout is accidentally connected to GND or Vcc. In case of 12v strips it may even save Din to Vcc.

Whoo yeah, I can see I need to be really careful of my language here ;)

Yes I see 'cycling' in the script I put it in. The other script is not dynamic, so I didn't set up serial on it.

My initial wiring was super janky, and then in the process of re-doing it properly, I switched the power leads. So I probably never gave it a real chance....

Yes, I tested for + and - continuity up to the cable on the strip. Resistance of 470 ohms shows on the data line...

This strip is so tiny, I don't think I have a prayer of soldering to the second LED.... It will be far more than $13 worth of work. I have a tremor, so soldering is non-trivial for me. Basically nothing smaller than a 1/4" jack. I'll keep the old strip around, just in case that equation changes down the line. I hear there's a surgery you can get ;)

Thanks for the suggestions!!!!

I'll just mark this solved....

Are you certain this is a "5050" strip, and not a "2020" strip? The 5050 have large copper pads, bigger than a soldering iron tip... and big enough to use large scissors to "cut here" to make smaller strands.

Okay, I peeled back the backing....

I might be able to solder that.... much bigger than I expected for a 5mm wide strip.

I'll give it a shot.

No need to peel back the backing. The solder pads are on the front (yellow).

Why does this topic show "solved/solution?"

Have a look at the picture from the original post. There is a soft plastic cover on the top side. I would rather remove the backing than the plastic cover. But maybe that could come off too I don't know.... I'll try and upload a picture.

At any rate, I can just solder the control to the center pad of the second LED. And leave plus and minus as is?

The link shows a generic picture, but I understand the protective coating of IP30. I did not know the back had access to the solder pads.

I cut into the front side protection, peeled the protection away, soldered, then used clear silicone caulk to cover the bare area. A little messy the first try.

An addressable LED strip that is powered with 5volt expects 5volt logic.
It might or might not fully work with the 3V3 logic of an ESP.

If you start cutting, then consider the use af a sacrificial pixel as level translator.
See this page.

If it's 5mm strip, it will contain 2020 chips and one of the pads is on 1 side and the other 2 on the other.

Yep usually a gentle cross cut using a not to sharp cutter and then some peeling does the tricn

I use hot glue from a glue gun. Easier to remove and easier to work with.

This is one of the things we keep running into, is it the controller or is it the strip. If everybody would just start out with a 'known to be working' controller or at least a 5v MCU, that would make things easier to diagnose.

Well yes, but the Data Out from the first LED would need to be disconnected or it may interfere.

Inverted power may have killed the whole strip. I've done that a couple of times.