NeoPixel now works with Arduino Uno but *not* Micro

[tlpada]

I have a 5-meter Adafruit NeoPixel Digital RGB LED Strip (ID: 1376)(30 LEDs/meter x 5 m = 150 LEDs) that has been working fine for months. Suddenly when testing out some matrix buttons the whole strip went dark and now only 1 LED lights up (see picture). I've tried several different programs via the arduino board running it (e.g. "strandtest", plus the custom program I was running when it blew), and the 1 working LED does seem to be lighting properly for each program. All 149 other LEDs on the strip are dark, however.

My power supply for the strip and board is an Adafruit 5V 10A switching power supply (ID: 658). Connected to the strip it tests at around 5.26v and 140 amps (with only the 1 LED lit up).

Could Adafruit please advise? If something shorted or burned out, would it be in the LED strip or in the power supply? The arduino board seems fine, loads code, responds to inputs, writes serial debug info out, and runs the 1 working LED apparently properly.

Thanks!

IMG_20210929_231537-c.jpg (986.56 KiB) Viewed 504 times

[dastels]

Possibly the second NeoPixel has "burned out" Are you using a capacitor as detailed in the first point at to mitigate https://learn.adafruit.com/adafruit-neo ... -practices?

If the second pixel is bad, connecting the data signal after it will let you use the rest of the pixels. If so, you could trim the first two from the strip and connect to the cut end. Alternatively you could connect the second pixles Dout to its Din, thus bypassing the bad pixel.

Dave

[tlpada]

Hi thank you for replying! Yes I am using 4700 uF capacitor inline also bought from Adafruit (ID: 1589), although it is a brand new one, a replacement of the same 4700 uF one I had before (is it possible a defective capacitor could 'blow out' something? if so would it risk blowing out more if I reconnect it?).

How do I physically connect the data signal to the third pixel to test if the second pixel being blown is the cause? Do I cut back the silicon/plastic skin, de-solder, I guess, the data wire, and then re-solder it to the copper DIN pad on the third pixel -- or can I just touch or tape it to it temporarily to test?

And/or do all three wires, data, power and ground, need to be connected to the third pixel, or just the data wire?

Thank you again.

Possibly the second NeoPixel has "burned out" Are you using a capacitor as detailed in the first point at to mitigate https://learn.adafruit.com/adafruit-neo ... -practices?

If the second pixel is bad, connecting the data signal after it will let you use the rest of the pixels. If so, you could trim the first two from the strip and connect to the cut end. Alternatively you could connect the second pixles Dout to its Din, thus bypassing the bad pixel.

Dave

[tlpada]

Something very strange is going on with my 5m Adafruit NeoPixel Digital RGB LED Strip (ID: 1376)(30 LEDs/meter x 5 m = 150 LEDs). The strip worked fine running code off an Arduino Micro and capacitor-protected 10A power supply, until an apparent 'blowout' caused all the LEDs except the first LED to go out suddenly.

In trying to bypass what appears to be the 'burned out' second, and third, LEDs by connecting the data wire to start on the fourth LED beyond it, I've found that:

• Using an Arduino Uno (newly), the strip works from the fourth pixel on to the end, running e.g. 'strandtest', just fine (and appears to confirm that the 2nd and 3rd LEDs are 'blown')
• Further and amazingly, the whole strip from the 4th pixel on runs *without* an external power supply, but rather just with the USB data/power leading from my laptop to the Uno board, and no other power source supplied.
• Previously, I drove the strip with a capacitor-protected Adafruit 5V 10A switching power supply (ID: 658), and the data signal coming from an Arduino Micro, which was also powered by the same capacitor-protected 10A power supply
• As part of troubleshooting, I also bought a new Adafruit Micro, to see if perhaps something had gone wrong with the Micro, that had caused the blowout
  Running the same circuit with the new Micro, however, behaves just as the 'old' Micro had, which after the blowout only lights up the 1st LED on the strip
  With the Micro, the 1st LED lights up and appears to run through correct color sequences, for itself, but the rest of the strip is dark (I confirmed there is +5v power to subsequent LEDs)
• Attaching the Uno to the 4th LED, in contrast, lights up the rest of the strip and appears to run through all the color sequences correctly

How is this possible, and how can I get the strip working with Micro again? (which is the preferred board and form factor size I wanted for this strip -- the Uno is too big).

Thanks,
TL

PS the original 'blowout' troubleshooting is captured in this topic/link: viewtopic.php?f=47&t=183716

[adafruit_support_carter]

Assuming there is no connection issue difference between the UNO and the Micro, it should work.

Post some photos of the Micro based setup showing how everything is connected.

[tlpada]

Hi @adafruit_support_carter, thank you for the reply. Here are photos of (1) the strip plugged in and wired how it was working for months before the LEDs 'blew out', (2) taking the same circuit but pulling the white data wire out of the strip's JST connector and touching it the fourth LED (touching to none of the DINs past the first LED do anything), and (3) the same #6 data Pin connected from an Uno, running the same code, instead.

The circuit looks somewhat complicated but you'll see it basically culminates in a 3-prong JST surface mount jack with red (+5v), black (GND), and white wire (DATA) coming from the JST jack on the board going into the strip's JST input. The white data cable basically comes from Pin 6, goes through that little resistor, where it connects to a long power-style connection down to where the jack is, where it connects back to the outgoing JST jack. In the second picture I simply take that white wire out and touch it to various DINS. The rest of the wires on the board are there simply for the 4-button control, which in my code is used to change the 'program.' But the code running here is just the factory Arduino "strandtest".

Note the first LED, which is lit, correctly goes through all the 'programs' in "strandtest," or any other code I test -- which appears to confirm the Micro is sending out the correct data (just like it always did).

The third picture is the same scheme on an Uno -- data coming out of Pin 6, with red power and black ground. When I connect Pin 6 with the white data wire to the strip's JST input, it mimics the Micro -- just the first LED lights up, but correctly goes through all the programs. When I touch the data wire to the fourth LED DIN, the rest of strip appears to work. Note the first LED is 'frozen' in its previous state, correctly, and that this appears to confirm that the 2nd and 3rd LEDs are 'burned out' -- which was the original problem with the Micro: that after working fine the whole strip suddenly went dark, except for the first LED.

white-data-cable-at-primary-input-IMG_20211011_232815-c.jpg (824.56 KiB) Viewed 438 times

trying-4th-LED-IMG_20211011_232957-c.jpg (820.03 KiB) Viewed 438 times

uno-IMG_20211011_234109-c.jpg (958.78 KiB) Viewed 438 times

Assuming there is no connection issue difference between the UNO and the Micro, it should work.

Post some photos of the Micro based setup showing how everything is connected.

[adafruit_support_carter]

Do you have a spare stand alone Micro? It could be something (unknown) related to the PCB build up with the current Micro arrangement. All of that should be ruled out. So if you have a spare Micro, or even just a third board, what happens if you do the same Uno test with that?

[tlpada]

Hi, yes, I can run the same test with a totally different, relatively new Micro board, running on a breadboard with no soldering and none of the extra wiring I had for the switches. Same result. The first picture is with the white data wire connected to the strip's JST input jack, along with power and ground. Once again, the first LED performs normally, running through the programs. The second photo is taking the white wire out and connecting it to downstream LEDs. The first LED remains frozen, correctly, in its prior state, and none of the downstream LEDs light up at all.

different-micro-board-data-main-IMG_20211012_125235.jpg (923.26 KiB) Viewed 429 times

different-micro-board-downstream-LEDs-IMG_20211012_161431-c.jpg (793.28 KiB) Viewed 429 times

Thanks,
TL

Do you have a spare stand alone Micro? It could be something (unknown) related to the PCB build up with the current Micro arrangement. All of that should be ruled out. So if you have a spare Micro, or even just a third board, what happens if you do the same Uno test with that?

[tlpada]

Hi, @adafruit_support_carter any update on this by any chance?

Many thanks

[oesterle]

Hi there!

Can you post your source code? (You can use the CODE button to format it.)

Cheers,

Eric

[tlpada]

Hi, thanks for the reply. The code is just "strandtest", from the 'Examples' that come with the factory Arduino IDE and Adafruit NeoPixel library. It's this:

Code: Select all

// A basic everyday NeoPixel strip test program.

// NEOPIXEL BEST PRACTICES for most reliable operation:
// - Add 1000 uF CAPACITOR between NeoPixel strip's + and - connections.
// - MINIMIZE WIRING LENGTH between microcontroller board and first pixel.
// - NeoPixel strip's DATA-IN should pass through a 300-500 OHM RESISTOR.
// - AVOID connecting NeoPixels on a LIVE CIRCUIT. If you must, ALWAYS
//   connect GROUND (-) first, then +, then data.
// - When using a 3.3V microcontroller with a 5V-powered NeoPixel strip,
//   a LOGIC-LEVEL CONVERTER on the data line is STRONGLY RECOMMENDED.
// (Skipping these may work OK on your workbench but can fail in the field)

#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
 #include <avr/power.h> // Required for 16 MHz Adafruit Trinket
#endif

// Which pin on the Arduino is connected to the NeoPixels?
// On a Trinket or Gemma we suggest changing this to 1:
#define LED_PIN    6

// How many NeoPixels are attached to the Arduino?
#define LED_COUNT 60

// Declare our NeoPixel strip object:
Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);
// Argument 1 = Number of pixels in NeoPixel strip
// Argument 2 = Arduino pin number (most are valid)
// Argument 3 = Pixel type flags, add together as needed:
//   NEO_KHZ800  800 KHz bitstream (most NeoPixel products w/WS2812 LEDs)
//   NEO_KHZ400  400 KHz (classic 'v1' (not v2) FLORA pixels, WS2811 drivers)
//   NEO_GRB     Pixels are wired for GRB bitstream (most NeoPixel products)
//   NEO_RGB     Pixels are wired for RGB bitstream (v1 FLORA pixels, not v2)
//   NEO_RGBW    Pixels are wired for RGBW bitstream (NeoPixel RGBW products)


// setup() function -- runs once at startup --------------------------------

void setup() {
  // These lines are specifically to support the Adafruit Trinket 5V 16 MHz.
  // Any other board, you can remove this part (but no harm leaving it):
#if defined(__AVR_ATtiny85__) && (F_CPU == 16000000)
  clock_prescale_set(clock_div_1);
#endif
  // END of Trinket-specific code.

  strip.begin();           // INITIALIZE NeoPixel strip object (REQUIRED)
  strip.show();            // Turn OFF all pixels ASAP
  strip.setBrightness(50); // Set BRIGHTNESS to about 1/5 (max = 255)
}


// loop() function -- runs repeatedly as long as board is on ---------------

void loop() {
  // Fill along the length of the strip in various colors...
  colorWipe(strip.Color(255,   0,   0), 50); // Red
  colorWipe(strip.Color(  0, 255,   0), 50); // Green
  colorWipe(strip.Color(  0,   0, 255), 50); // Blue

  // Do a theater marquee effect in various colors...
  theaterChase(strip.Color(127, 127, 127), 50); // White, half brightness
  theaterChase(strip.Color(127,   0,   0), 50); // Red, half brightness
  theaterChase(strip.Color(  0,   0, 127), 50); // Blue, half brightness

  rainbow(10);             // Flowing rainbow cycle along the whole strip
  theaterChaseRainbow(50); // Rainbow-enhanced theaterChase variant
}


// Some functions of our own for creating animated effects -----------------

// Fill strip pixels one after another with a color. Strip is NOT cleared
// first; anything there will be covered pixel by pixel. Pass in color
// (as a single 'packed' 32-bit value, which you can get by calling
// strip.Color(red, green, blue) as shown in the loop() function above),
// and a delay time (in milliseconds) between pixels.
void colorWipe(uint32_t color, int wait) {
  for(int i=0; i<strip.numPixels(); i++) { // For each pixel in strip...
    strip.setPixelColor(i, color);         //  Set pixel's color (in RAM)
    strip.show();                          //  Update strip to match
    delay(wait);                           //  Pause for a moment
  }
}

// Theater-marquee-style chasing lights. Pass in a color (32-bit value,
// a la strip.Color(r,g,b) as mentioned above), and a delay time (in ms)
// between frames.
void theaterChase(uint32_t color, int wait) {
  for(int a=0; a<10; a++) {  // Repeat 10 times...
    for(int b=0; b<3; b++) { //  'b' counts from 0 to 2...
      strip.clear();         //   Set all pixels in RAM to 0 (off)
      // 'c' counts up from 'b' to end of strip in steps of 3...
      for(int c=b; c<strip.numPixels(); c += 3) {
        strip.setPixelColor(c, color); // Set pixel 'c' to value 'color'
      }
      strip.show(); // Update strip with new contents
      delay(wait);  // Pause for a moment
    }
  }
}

// Rainbow cycle along whole strip. Pass delay time (in ms) between frames.
void rainbow(int wait) {
  // Hue of first pixel runs 5 complete loops through the color wheel.
  // Color wheel has a range of 65536 but it's OK if we roll over, so
  // just count from 0 to 5*65536. Adding 256 to firstPixelHue each time
  // means we'll make 5*65536/256 = 1280 passes through this outer loop:
  for(long firstPixelHue = 0; firstPixelHue < 5*65536; firstPixelHue += 256) {
    for(int i=0; i<strip.numPixels(); i++) { // For each pixel in strip...
      // Offset pixel hue by an amount to make one full revolution of the
      // color wheel (range of 65536) along the length of the strip
      // (strip.numPixels() steps):
      int pixelHue = firstPixelHue + (i * 65536L / strip.numPixels());
      // strip.ColorHSV() can take 1 or 3 arguments: a hue (0 to 65535) or
      // optionally add saturation and value (brightness) (each 0 to 255).
      // Here we're using just the single-argument hue variant. The result
      // is passed through strip.gamma32() to provide 'truer' colors
      // before assigning to each pixel:
      strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
    }
    strip.show(); // Update strip with new contents
    delay(wait);  // Pause for a moment
  }
}

// Rainbow-enhanced theater marquee. Pass delay time (in ms) between frames.
void theaterChaseRainbow(int wait) {
  int firstPixelHue = 0;     // First pixel starts at red (hue 0)
  for(int a=0; a<30; a++) {  // Repeat 30 times...
    for(int b=0; b<3; b++) { //  'b' counts from 0 to 2...
      strip.clear();         //   Set all pixels in RAM to 0 (off)
      // 'c' counts up from 'b' to end of strip in increments of 3...
      for(int c=b; c<strip.numPixels(); c += 3) {
        // hue of pixel 'c' is offset by an amount to make one full
        // revolution of the color wheel (range 65536) along the length
        // of the strip (strip.numPixels() steps):
        int      hue   = firstPixelHue + c * 65536L / strip.numPixels();
        uint32_t color = strip.gamma32(strip.ColorHSV(hue)); // hue -> RGB
        strip.setPixelColor(c, color); // Set pixel 'c' to value 'color'
      }
      strip.show();                // Update strip with new contents
      delay(wait);                 // Pause for a moment
      firstPixelHue += 65536 / 90; // One cycle of color wheel over 90 frames
    }
  }
}

Many thanks,
TL

Hi there!

Can you post your source code? (You can use the CODE button to format it.)

Cheers,

Eric

[adafruit_support_carter]

Sorry. Weird issue and I'm not sure what could be causing it. It was working and then not working, so can only assume the issue is related to whatever the "blowout" event was. Why different boards are showing different behavior is a mystery.

[oesterle]

Hi again!

Thanks for the sharp photos of your build!

Looking over the wiring, I see that you are powering the Arduino Micro and your NeoPixel strip with the 5 VDC power adapter.

The Arduino Micro's Vin pin you're powering wants 7-9 VDC, according to the official Arduino Micro docs. This is because some overhead is typically required by an onboard power regulator to generate 5 VDC.

I'd try moving the positive lead from your 5 VDC power supply to the Arduino Micro's +5V pin directly. (When bypassing the onboard regulator, I'd be sure to use a high-quality, well-regulated 5V power supply.)

Cheers,

Eric

[tlpada]

Interesting idea and great catch Eric thanks!

Only thing, though, wouldn't putting a +5 volt supply on the +5V output Micro pin... like... blow it up or something? The Micro pinout shows it with a faint grey arrow pointing outbound, confirming I assume that its expected current flows opposite the direction of the VIN pin, where the arrow points in. There's also the mystery of how this ran at all, then, for months, if there was insufficient voltage on the VIN pin, but I guess we'll ponder that later if this works.

And if it doesn't blow up the Micro, how is it that the Micro would get power at all, to run the code? (sorry if I'm not grasping something obvious)

My power supply btw is Adafruit's 5V 10A switching power supply (ID: 658) so hopefully that's quality enough.

Please lmk, thanks!

All best
TL

Hi again!

Thanks for the sharp photos of your build!

Looking over the wiring, I see that you are powering the Arduino Micro and your NeoPixel strip with the 5 VDC power adapter.

The Arduino Micro's Vin pin you're powering wants 7-9 VDC, according to the official Arduino Micro docs. This is because some overhead is typically required by an onboard power regulator to generate 5 VDC.

I'd try moving the positive lead from your 5 VDC power supply to the Arduino Micro's +5V pin directly. (When bypassing the onboard regulator, I'd be sure to use a high-quality, well-regulated 5V power supply.)

Cheers,

Eric

[oesterle]

Hi again!

You asked:

Only thing, though, wouldn't putting a +5 volt supply on the +5V output Micro pin... like... blow it up or something? The Micro pinout shows it with a faint grey arrow pointing outbound, confirming I assume that its expected current flows opposite the direction of the VIN pin, where the arrow points in.

I like your caution. Here's what I've found:

The Micro's 5V pin is being used by many as an input with a regulated 5V power supply. Arduino's official description (see the Documentation section in Arduino Micro) implies this; although I wish they were a bit clearer:

5V. The regulated power supply used to power the microcontroller and other components on the board. This can come either from VIN via an on-board regulator, or be supplied by USB or another regulated 5V supply.

Over at the Arduino forum, in a discussion of a somewhat similar Arduino Micro and LED strip project, MorganS writes:

Yes, regulated 5V can be provided to the 5V pin. You obviously need to be a bit more careful with your wiring as you don't want a loose wire accidentally touching your unprotected 5V input.

I've also read, but can't put my finger on it, that the Micro includes a diode between VUSB and the 5V pin, which should protect a connected computer's USB from being back-powered. Here's the Micro's official schematic.


Cheers,

Eric