Hey guys, I've been searching the posts but haven't found anything quite like my

Archive FastLED Archive
1

Hey guys, I’ve been searching the posts but haven’t found anything quite like my problem.

I am building a 533 led light suit for a friend. The costume has wings and glowy claws and the such. I decided to use the WS2812b PCB leds primarily, but for the wings and claws I used the APA106 (PL9823) 5mm bulb type leds. Turns out they are ‘RGB’ and everything else is ‘GRB’. I thought I’d be smart and simply have a function ‘CorrectColors();’ just before LEDs.show(); where it simply flips the leds[i].r to .g on the mapped areas.

It worked at first, but then I started getting weird behavior if I used nscale8 or other features of the FastLED library. I set my leds with CHSV, because that is way easier.

I’m using a Teensy 3.2 on a Octo2811 board.

If there is a way I can define specific leds to be a different color order in the setup stage, that’d be awesome! Any suggestions as to my problem would be greatly appreciated.

725a834a810b219f5d713d44e3d93d8e.jpeg
725a834a810b219f5d713d44e3d93d8e.jpeg5312×2988 842 KB

2

Unfortunately not while still using parallel output - the library’s assumption is that all leds for a given controller have the same rgb ordering

3

Welp… this is annoying, wish led protocols would have a standard! Maybe I can put in a attiny and have it do the color flip before it hits the leds.

4

So if you do
fill_solid(leds, NUM_LEDS, CRGB::Red)
and then print out the .r .g .b values for a pixel from each LED type the “red” channel values are 255 and the rest 0, correct?

And then if you did
for (int i = 0 ; i < NUM_LEDS ; i++) {
leds[i].nscale8(128);
}
and compare the “red” channels from each type again they don’t match?

Also, can you post the code for your CorrectColors(); function?

5

You have a CorrectColors() function so why not have a UncorrectColors() function which returns the values back after you do the FastLED.show()? That will allow you to retain all the same code for all and correct for the incorrect order.

6

@Justin_Eastman Awww, thats such a genious idea! I just called it again after the show() but nadda. It goes back to flipped colors. Gotta think this through again.

7

@marmil void CorrectColors() { // Because there are leds that use a different color order.
uint8_t color;
for(uint16_t i = 0; i < sizeof(Apa106LEDs)/2; i++) {
color = leds[Apa106LEDs[i]].r;
leds[Apa106LEDs[i]].r = leds[Apa106LEDs[i]].g;
leds[Apa106LEDs[i]].g = color;
}
}

8

@mBlade_Akita You created the UnCorrectColors() function that did the opposite of the CorrectColors() and it did not work?

9

it would go something like this:

show(){

CorrectColors(); // switch RGB >GRB
FastLED.show(); // show the lights
UnCorrectColors(); //switch GRB>RGB
}

10

@Justin_Eastman Yeah. I shouldn’t have to make a new function, just call it again and it’ll swap the ‘r’ for ‘g’ values again. See above the code for said function. Everything works fine until I use nscale8 it does weird things. Been playing with it for the last hour. It seems to swap the colors back for me… I think I literally figured it out as I’m typing this… What happening is i’m not actually telling the led to be a color anymore, so it gets swapped, but on the next loop, it doesn’t get assigned as ‘red’ anymore, so it does a flip flop behavior. Now how do I fix this. Hmmmmm.

11

@mBlade_Akita derr… yes now I guess that would be correct… sometimes the solution is much simpler than my brain thinks… I wonder what would happen if you do the CorrectColors() for before and after the nscale8? I think that might do it???
Basically have to get the leds in their true color state and then do the nscale. The other option that is clearly more work and what I usually due is use HSV and save the hue and brightness for each led… then just reset the brightness down 1. Results in the same things… Lastly as another option, could create a new function in the Fastled functions you intend to to take the RGB order as a parm and set the fields accordingly.

12

Ok, I have fixed the problem. (Who knows how many other issues I may have created. BUT this works… Here’s my changed function.

13

void ProcessColors() { // Because there are leds that use a different color order.
for (uint16_t i = 0;i < sizeof(WholeSuit)/2;i++) {
ledsout[WholeSuit[i]].r = leds[WholeSuit[i]].r;
ledsout[WholeSuit[i]].g = leds[WholeSuit[i]].g;
ledsout[WholeSuit[i]].b = leds[WholeSuit[i]].b;
}
// Change the Red and Green colors for the ‘special snowflake’ Apa106LEDs color order.
for(uint16_t i = 0; i < sizeof(Apa106LEDs)/2; i++) {
ledsout[Apa106LEDs[i]].r = leds[Apa106LEDs[i]].g;
ledsout[Apa106LEDs[i]].g = leds[Apa106LEDs[i]].r;
ledsout[Apa106LEDs[i]].b = leds[Apa106LEDs[i]].b;
}
}

14

So, I have created a whole new CRGB led array called ‘ledsout’ which is whats used in the setup. and now my old ‘leds’ array is a virtural one. Its a bit more processing. It added about 150 microseconds to the loop process. But it ‘works’.

15

@Justin_Eastman I see, I tried it, but not quite like that. Maybe I’ll give it a go before I settle for this virtural array idea.

16

@mBlade_Akita You could optimize a little more and do memcpy for the whole array. Then just change the R and G of the affected nodes. Or just memcpy the ones that dont change and then change the ones as you are . Either way should hopefully speed up things better than one by one.

17

@Justin_Eastman Hey cool, just looked it up and have implemented memcpy, saves me about 50-60 us in processing time. Thanks!

memcpy(&ledsout,&leds,sizeof(leds));

18

sorry i don’t know anything about your problem…(is it realy like this that google+ doesn’t have any private message mechanism?) but i have the same hardware setup (teensy+octo shield) and troubles getting it running with fastled. so my first question is are you using the arduino IDE for development?