Series of 4xWS2812Bs connected but only first 4 in row react

Hi all,
I have a decorative setup behind a bar where three rows of 24 empty bottles are hanged on a wooden frame (total=72 bottles) and I want to attach ws2812bs at the bottom of each bottle. What I have come up with is cutting a LED strip in sections of 4 LEDS and attaching those 4xLED sections with approx. 10cm (3inch) wires (+,-,data). I could take two 5m LED strips, cut them in half and use 3 x 2.5 LED strips along the bottles’ bottoms but doing that I would have to cover all those LEDS that aren’t under a bottle using only those that are. Quite a waste of LEDS and wattage when I can just snip them at 4xLED intervals and join them with wire. Or so I thought. :frowning:

So, I have

  • a DCDuino Uno and using its data PIN 6
  • an old modified ATX power supply that provides up to 22A on the 5V rail (60mA x 288 LEDS = 17,2A so I’m safely within limits), tested its 5V out on my multimeter and it checks out ok. It doesn’t seem to have a minimum current load restriction circuit, it just switches on when told and stays on. :grinning:
  • 470Ω resistor on data wire
  • 1000μF 10V capacitor between the 5V +/- poles next to the first LED connection
  • switch on the 5V+ cable so this is switched on after the PSU is initially switched on and its initial voltage spike is avoided

All is soldered in place so I test the first row (96LEDS, 5,7A) to see how it works with the example sketch Fire2012 from FastLED. Initially it doesn’t blink or shift colors, I just get some random LEDS light up in random hues and brightnesses all along the length. Some are lit, most aren’t, not in groups of 4s or in any meaningful pattern, no blinking/flashing/fading, they just stay on at those random values. I check the direction arrows on all 4xLED sections and they are all pointing in the right direction. I measure the 5V end points and 5V is still reaching there with no disconnects.

I’m starting to think that for a 2.5m (8ft) setup I could also try connecting both the start and end positive and negative poles to the 5V rail so I can feed it from both ends.

No change. I now try some other examples from Neopixel library and all I’m now getting is the first set of 4xLEDs responds to what is expected while again a few of the rest down the line still randomly light up and stay unresponsive. I go back to the Fire2012 example and now only the first 4xLEDs section lights up, all the rest stay in the dark. I try fadeRGB, firstLight, strandtest examples and I only get the first 4xLEDs section responding, all the rest stay firmly in the dark (I once spotted a momentary blink of white on all other LEDs while using fadeRGB, so they are not dead… just asleep!). I’ve had it with this strip, so I move on to test the other two I made and I always get the same result: nothing happens after the first 4xLEDs section.

Any ideas?
Thanks and a happy new year to all.


So even the first group of 4 leds does not behave as expected?

Have you got all the necessary parameters set correctly in the sketch?

#define LED_PIN     6
#define CHIPSET     WS2812B
#define NUM_LEDS    4

I updated the schematic so the LED series look more like what I have.

actually only the first group of 4 LEDS behaves as expected on all tests I did. I just fired it up again now to take a photo (I didn’t connect its end to the 5V, only the beginning) and this time an additional group of LEDS lights up blue waaaaay down the line from the beginning of the series (see photo).

Could it be that all those wires in between somehow mess up the data signals?

Here is the code I run:

#include <FastLED.h>

#define LED_PIN     6
#define CHIPSET     WS2812
#define NUM_LEDS    96

#define BRIGHTNESS  150

bool gReverseDirection = false;


void setup() {
  delay(3000); // sanity delay
  FastLED.addLeds<CHIPSET, LED_PIN, COLOR_ORDER>(leds, NUM_LEDS).setCorrection( TypicalLEDStrip );
  FastLED.setBrightness( BRIGHTNESS );

void loop()
  // Add entropy to random number generator; we use a lot of it.
  // random16_add_entropy( random());

  Fire2012(); // run simulation frame; // display this frame
  FastLED.delay(300 / FRAMES_PER_SECOND);

// Fire2012 by Mark Kriegsman, July 2012
// as part of "Five Elements" shown here:
// This basic one-dimensional 'fire' simulation works roughly as follows:
// There's a underlying array of 'heat' cells, that model the temperature
// at each point along the line.  Every cycle through the simulation,
// four steps are performed:
//  1) All cells cool down a little bit, losing heat to the air
//  2) The heat from each cell drifts 'up' and diffuses a little
//  3) Sometimes randomly new 'sparks' of heat are added at the bottom
//  4) The heat from each cell is rendered as a color into the leds array
//     The heat-to-color mapping uses a black-body radiation approximation.
// Temperature is in arbitrary units from 0 (cold black) to 255 (white hot).
// This simulation scales it self a bit depending on NUM_LEDS; it should look
// "OK" on anywhere from 20 to 100 LEDs without too much tweaking.
// I recommend running this simulation at anywhere from 30-100 frames per second,
// meaning an interframe delay of about 10-35 milliseconds.
// Looks best on a high-density LED setup (60+ pixels/meter).
// There are two main parameters you can play with to control the look and
// feel of your fire: COOLING (used in step 1 above), and SPARKING (used
// in step 3 above).
// COOLING: How much does the air cool as it rises?
// Less cooling = taller flames.  More cooling = shorter flames.
// Default 50, suggested range 20-100
#define COOLING  55

// SPARKING: What chance (out of 255) is there that a new spark will be lit?
// Higher chance = more roaring fire.  Lower chance = more flickery fire.
// Default 120, suggested range 50-200.
#define SPARKING 50

void Fire2012()
  // Array of temperature readings at each simulation cell
  static byte heat[NUM_LEDS];

  // Step 1.  Cool down every cell a little
  for ( int i = 0; i < NUM_LEDS; i++) {
    heat[i] = qsub8( heat[i],  random8(0, ((COOLING * 10) / NUM_LEDS) + 2));

  // Step 2.  Heat from each cell drifts 'up' and diffuses a little
  for ( int k = NUM_LEDS - 1; k >= 2; k--) {
    heat[k] = (heat[k - 1] + heat[k - 2] + heat[k - 2] ) / 3;

  // Step 3.  Randomly ignite new 'sparks' of heat near the bottom
  if ( random8() < SPARKING ) {
    int y = random8(7);
    heat[y] = qadd8( heat[y], random8(160, 255) );

  // Step 4.  Map from heat cells to LED colors
  for ( int j = 0; j < NUM_LEDS; j++) {
    CRGB color = HeatColor( heat[j]);
    int pixelnumber;
    if ( gReverseDirection ) {
      pixelnumber = (NUM_LEDS - 1) - j;
    } else {
      pixelnumber = j;
    leds[pixelnumber] = color;


Please learn to attach your photos to your post!

Try putting another 470R between the 1st & 2nd groups. I am wondering if the signal in those long-ish data cables between the groups is getting corrupted by reflections.

nope, no change, even separated those three cables so the data one wouldn't be sandwitched between 5V+ and ground >:(

Is it possible that the data wire connections are not meant to be done with stretches of wire and are introducing noise when run in length? If yes, wouldn't that start to manifest later on in the series of connections?

I updated the schematic so the LED series look more like what I have.

How accurately does that (LED_strip_bb.png) represent your present situation?
The wiring vs. the labels. What's with the switch and the power to both ends?

I changed the schematic again since I have now removed that 5V connection to the end of the series (and in reality the switch was connected to both +5V inputs before they hook on the ends of the LED series). The switch there is an extra precaution so any spikes from the PSU don’t reach the LEDs when it starts up. I first switch the PSU on and after a sec I hit that switch. Also, instead of four groups of 4xLED that are shown in the schematic, in reality I have 24 groups in a row.

(I’m trying to do that edit + paste URL thing for forum images but I’m restricted from editing posts too often in a row)

First thing i would do is check all the solder connection and make sure they are all solid. You should also verify you have the data flowing in the right direction o
n all sections.

Do you have any led strips not cut into sections left? Is there any change?

I’d also go back and try to simplify things. Start with one of the strand test examples or something like that. Once that’s working move on to this code.

You should also verify you have the data flowing in the right direction on all sections.

masbass has already checked that

I'd also go back and try to simplify things. Start with one of the strand test examples or something like that. Once that's working move on to this code.

masbass is using one of the fastLED example sketches, not his own code.

It seems it's a matter of connections not making contact. :cry: I took the first three sets apart and reconnected them and sure enough they now behave as expected. Those strips have very small contact points and even when I scratched some coating off to make more room for soldering they must not make adequate contact all over the series. I'll have to think of a workaround (or just use a long LED strip and mask the parts in between. Thanks all for your input.

First thing i would do is check all the solder connection and make sure they are all solid.

Ah, massbass had not checked that! Perhaps he will be so good as to give you your first karma point!

Glad to hear you got it figured out! Guess I missed where he said he had checked data flow.

Yeah, soldering on the wires is not the easiest, I just got done with some myself. What I found worked best for me, was to tin both the wire and the contact point on the strip first. Once I had everything tinned, I heated a wire back up until the solder was just at the melting point then, set the hot wire on the contact point of the LED strip and applied heat to the top of the wire. I found this help keep the LED strip cooler and keep the plastic of the strip from melting. I hope that makes sense..... Something to remember about soldering, once you think you have enough solder, you already have too much!