Here is a question: I have 2 different sets of pixel LEDs.

Archive FastLED Archive
1

Here is a question: I have 2 different sets of pixel LEDs. Both are using the WS2811 chips internally. The PTH type have the Red and Green reversed and the other set has the Red and Green as they should be. How would I use both together in the same strand? I have sorted the two types so I know which ones I have so I will put one set of the GRB type of say 15 and following that 15 of the RGB type for a total of 30 in the strip.

I create CRGB array of 30. Then in setup I did this:

FastLED.addLeds<NEOPIXEL, DATA_PIN, GRB>(strip, 0, 15);
FastLED.addLeds<NEOPIXEL, DATA_PIN>(strip, 15, 15);

When I try running anything like a solid color the first 15 blink.

for(i=0; i<NUM_LEDS; i++) {
strip[i] = CRGB:Red;
FastLED.show();
delay(50);
}

Am I going about this the right way or is there a better way to do it?

Thanks! :slight_smile:

2

I think you’re going to want them in separate strands, on separate pins. FastLED doesn’t really have a good way to “switching horses (or RGB orderings) mid-stream”.
On separate pins, life gets easier:

#define DATA_PIN_A 3
#define DATA_PIN_B 4

CRGB strip[30];

FastLED.addLeds<NEOPIXEL, DATA_PIN_A, GRB>(strip, 15);
FastLED.addLeds<NEOPIXEL, DATA_PIN_B, RGB>(strip+15, 15);

3

So - NEOPIXELs are, by default, GRB ordering (NEOPIXEL is just WS2812 w/GRB ordering - so first thing would be to change your setup lines to use WS2812 instead of NEOPIXEL.

The second is, you have both sets of leds on a single pin - and that’s what’s causing the flickering (if you write to ws2812’s too quickly the flicker).

What you need to do is put your leds with GRB ordering on 1 pin, and your leds with RGB ordering on another pin - then you can have something like:

setup() {
LEDS.addLeds<WS2812,DATA_PIN1,RGB>(strip,0,15);
LEDS.addLeds<WS2812,DATA_PIN2,GRB>(strip,15,15);
}

then the code will work as expected. There isn’t any support in the library (and because of how it is implemented, unlikely to ever be any) for changing RGB ordering mid-strip on a single controller.

4

Alternatively, you could join the strands, program them AS IF they were all GRB, but then just before you call FastLED.show(), swap the R and G values in the ‘strip’ array for the pixels that are different, e.g.

for( int i = 15; i < 30; i++) {
uint8_t temp = strip[i].red;
strip[i].red = strip[i].green;
strip[i].red = temp;
}
FastLED.show();

(And if you want, you can switch them back afterwards. Depends if your code expects the values in the strip array to persist between updates.)

I’ve often had to do this kind of software work-around for quirky hardware. Easier than soldering, sometimes… and sometimes soldering is easier.

5

DOH! Dan’s right - NEOPIXEL implies a certain ordering. Say WS2812B if you want to specify the ordering.

6

Ok. Using the NeoPixel library I did a similar thing (or rather I made a mod to the library that would allow me to store it based upon a pixel type). I am really impressed with this Library the more I get into it.

I do not know if there is any real need to do what I did in a practical sense other than I am experimenting. I can see that in an actual application you would actually use the same type through out the project.

So if I understand this correctly, each call to addLeds basically creates a new controller for which the serial data is sent. In my example I was basically invoking to signal controllers on after another on the same data line. So I created the blink by sending two streams of data over the same pin.

I think I got it! LOL

7

Correct on your understanding! And, in the interest of performance, the RGB ordering lookup is actually done in FastLED at compile time - saves at least a couple cycles per byte, sometimes more (especially on register constrained architectures like ARM).