Wrong but Right ?? - RGB colour order in sequencer vs controller

O

orchidman33

Full time elf
Joined
Jan 14, 2019
Messages
125
Here's one for the those that love to delve into lab/testing side of things.
This year I have changed the pixels in my Tree (20 strings of 100), gone from 3 wire WS2811 to GS2808, tying data 2 too ground.
All testing of the strings using xlights and FPP on a Pi test bench showed that the were connected BGR, I know. I set my tree in xlights as such. I checked that ALL strings showed the same colour when they were in place on Xlights, my show Pi running FPP and the F16V3. I also checked that the tree was set to the BRG on the F16, (all good).
Upon firing up and checking live sequences I was dismayed to see what was red is now blue ??😱😭. It did not matter wheather I ran the sequence from the Pi or Xlights.
In the end as a test (what did I have to lose) I reset the tree strings back to RGB colour order, :unsure: You can guess what the out come was xD . Once the squences were re-rendenered and uploaded to the show PI and the controler outputs reconfiguered. Yes you are correct - colours were showing correct again - RED was RED, GREEN was GREEN and BLUE was BLUE.

Can someone PLEASE explain how this has occured as I'm puzzled.
 
Double conversion. If it's set in two places - say the sequence data is sending BGR and then the controller is interpreting that as RGB and spitting out BGR, the red and blue get swapped twice, meaning it is then incorrect.
 
Skymaster said:
Double conversion. If it's set in two places - say the sequence data is sending BGR and then the controller is interpreting that as RGB and spitting out BGR, the red and blue get swapped twice, meaning it is then incorrect
Click to expand...

Both were set to BGR
 
orchidman33 said:
Here's one for the those that love to delve into lab/testing side of things.
This year I have changed the pixels in my Tree (20 strings of 100), gone from 3 wire WS2811 to GS2808, tying data 2 too ground.
All testing of the strings using xlights and FPP on a Pi test bench showed that the were connected BGR, I know. I set my tree in xlights as such. I checked that ALL strings showed the same colour when they were in place on Xlights, my show Pi running FPP and the F16V3. I also checked that the tree was set to the BRG on the F16, (all good).
Upon firing up and checking live sequences I was dismayed to see what was red is now blue ??😱😭. It did not matter wheather I ran the sequence from the Pi or Xlights.
In the end as a test (what did I have to lose) I reset the tree strings back to RGB colour order, :unsure: You can guess what the out come was xD . Once the squences were re-rendenered and uploaded to the show PI and the controler outputs reconfiguered. Yes you are correct - colours were showing correct again - RED was RED, GREEN was GREEN and BLUE was BLUE.

Can someone PLEASE explain how this has occured as I'm puzzled.
Click to expand...
I have to agree with you, something isn't right. You are not mad I had the same problem.
I think I have just figured about a mistake I made. I had the colour order set to BGR and the string type also set to BGR, but all the models I didn't have problem with had string type as RGB. I'll test it later and see if that fixes it and report back.Capture.PNG
 
Yeah you cant set the String type and the Colour order together.
Color Order is pushed to the controller - the controller always expects RGB data in its data stream, and fidgets with it to the WS2811 output.
String type is how xLights codes the channel order in the FSEQ, which then means it's no longer in RGB colour order.

So - having the Color Order set, and string type to RGB the process is
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • FSeq file sees 255/255/0
  • DDP/E1.31 Data sees 255/255/0
  • Controller takes assumes RGB and converts to BGR
  • WS2811 data to the string is 0/255/255
  • Pixels light up correctly.

If you set the String Type, and not the controller order (controller set to RGB)
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • Fseq file sees 0/255/255
  • DDP/E1.31 Data sees 0/255/255
  • Controller assumes this is RGB, and sends it as-is as it's set to RGB as well
  • WS2811 data to the string is 0/255/255
  • Pixels light up correctly.
If you set both the String Type, and the controller order to BGR
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • Fseq file sees 0/255/255
  • DDP/E1.31 Data sees 0/255/255
  • Controller takes assumes RGB and switches it round to BGR
  • WS2811 data to the string is 255/255/0
  • Pixels light up magenta instead of yellow due to the R/B swap
 
Skymaster said:
Yeah you cant set the String type and the Colour order together.
Color Order is pushed to the controller - the controller always expects RGB data in its data stream, and fidgets with it to the WS2811 output.
String type is how xLights codes the channel order in the FSEQ, which then means it's no longer in RGB colour order.

So - having the Color Order set, and string type to RGB the process is
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • FSeq file sees 255/255/0
  • DDP/E1.31 Data sees 255/255/0
  • Controller takes assumes RGB and converts to BGR
  • WS2811 data to the string is 0/255/255
  • Pixels light up correctly.

If you set the String Type, and not the controller order (controller set to RGB)
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • Fseq file sees 0/255/255
  • DDP/E1.31 Data sees 0/255/255
  • Controller assumes this is RGB, and sends it as-is as it's set to RGB as well
  • WS2811 data to the string is 0/255/255
  • Pixels light up correctly.
If you set both the String Type, and the controller order to BGR
  • Pixel set to Yellow (R = 255, G = 255, B = 0)
  • Fseq file sees 0/255/255
  • DDP/E1.31 Data sees 0/255/255
  • Controller takes assumes RGB and switches it round to BGR
  • WS2811 data to the string is 255/255/0
  • Pixels light up magenta instead of yellow due to the R/B swap
Click to expand...
Thanks, that makes a lot of sense now. I didn't realise I had changed the string, but lucky others were working and that's where I noticed it had been changed. Probably me and my old eyes. lol. Hope this helps the OP anyway.
 
I fought the same issue with some GRB pixels and then the penny dropped. Made it so much simpler just using the controller side to understand what was going on.
 
I use combination of strip and pixels, pixels are RGB, strip is *BRG. Everything in xlights is set to RGB and I set the strip colour order on the controller because it got all messed up in the past from xlights "uploading to controller" and having the sequences not playing correctly. FPP display testing worked ok, but not sequences because of the double colour shift as @Skymaster pointed out.
Frustrating AF at first until you understand what's going on
 
You must log in or register to reply here.
Back
Top