Hi folks . I have setup fastled with ws2801 led strip.

Hi folks .
I have setup fastled with ws2801 led strip. Which works http://great.in the first place my TV setup had 64 leds without the buttom part covered.
For those led strip I had to change RGB code to RBG to show correct colours.

now the thing is I brought another set of 32 leds which I used for the button part of the screen. Just to find out this set doesn’t use the same RBG profile like my first set. Which doesn’t look good as you could imagen. Button part shows green as blue. Blue as green and so forth.
is there a way to fix this?
Or is there a way to tell arduino that leds 1-64 uses RBG and 64 to 92 uses RGB.

Thanks in advance

Should work :slight_smile:

Thanks Lukawski , i will give it a try :smiley:
looks prommising reading the title

wel i couldn’t figure this one out myself… Can anyone help me with the code?

my setup is following:

64 led strip covering the Left - TOP - Right- and side of the screen.
Connected to the arduino pins on GND - 13 and 11

to cover the buttom part of the screen i have the same looking ws2801 led strip. but this one uses RGB instead of the RBG color profile.

i connectet the new led strip on the ending part of the WS2801 by soldering the 4 points.

does this mean i have to desolder the new ws2801 thats meant to cover buttom part of my screen and have GND - 5V - CK - SPI connected to new pins on arduino?
or can i leave those connected to my WS2801 RBG profile which are covering LEFT TOP AND RIGHT side of screen?

the code i use in arduino are as follow:

// Slightly modified Adalight protocol implementation that uses FastLED
// library (http://fastled.io) for driving WS2811/WS2812 led stripe
// Was tested only with Prismatik software from Lightpack project (version 5.9.1, 5.9.6 and 5.11.1 so far - 5.11.1 has some issues on startup in windows so I’m not using it)

#include “FastLED.h”

#define NUM_LEDS 92 // Max LED count
#define LED_PIN 11 // arduino output pin - probably not required for WS2801
#define GROUND_PIN 10 // probably not required for WS2801
#define BRIGHTNESS 128 // maximum brightness
#define SPEED 115200 // virtual serial port speed, must be the same in boblight_config

CRGB leds[NUM_LEDS];
uint8_t * ledsRaw = (uint8_t *)leds;

// A ‘magic word’ (along with LED count & checksum) precedes each block
// of LED data; this assists the microcontroller in syncing up with the
// host-side software and properly issuing the latch (host I/O is
// likely buffered, making usleep() unreliable for latch). You may see
// an initial glitchy frame or two until the two come into alignment.
// The magic word can be whatever sequence you like, but each character
// should be unique, and frequent pixel values like 0 and 255 are
// avoided – fewer false positives. The host software will need to
// generate a compatible header: immediately following the magic word
// are three bytes: a 16-bit count of the number of LEDs (high byte
// first) followed by a simple checksum value (high byte XOR low byte
// XOR 0x55). LED data follows, 3 bytes per LED, in order R, G, B,
// where 0 = off and 255 = max brightness.

static const uint8_t magic[] = {‘A’, ‘d’, ‘a’};
#define MAGICSIZE sizeof(magic)
#define HEADERSIZE (MAGICSIZE + 3)

#define MODE_HEADER 0
#define MODE_DATA 2

// If no serial data is received for a while, the LEDs are shut off
// automatically. This avoids the annoying “stuck pixel” look when
// quitting LED display programs on the host computer.
static const unsigned long serialTimeout = 150000; // 150 seconds

void setup()
{
// pinMode(GROUND_PIN, OUTPUT);
// digitalWrite(GROUND_PIN, LOW);
// FastLED.addLeds<WS2811, LED_PIN, BRG>(leds, NUM_LEDS);
FastLED.addLeds<WS2801, 11, 13, RBG>(leds, NUM_LEDS);

// Dirty trick: the circular buffer for serial data is 256 bytes,
// and the “in” and “out” indices are unsigned 8-bit types – this
// much simplifies the cases where in/out need to “wrap around” the
// beginning/end of the buffer. Otherwise there’d be a ton of bit-
// masking and/or conditional code every time one of these indices
// needs to change, slowing things down tremendously.
uint8_t
buffer[256],
indexIn = 0,
indexOut = 0,
mode = MODE_HEADER,
hi, lo, chk, i, spiFlag;
int16_t
bytesBuffered = 0,
hold = 0,
c;
int32_t
bytesRemaining;
unsigned long
startTime,
lastByteTime,
lastAckTime,
t;
int32_t outPos = 0;

Serial.begin(SPEED); // Teensy/32u4 disregards baud rate; is OK!

Serial.print(“Ada\n”); // Send ACK string to host

startTime = micros();
lastByteTime = lastAckTime = millis();

// loop() is avoided as even that small bit of function overhead
// has a measurable impact on this code’s overall throughput.

for (;:wink: {

// Implementation is a simple finite-state machine.
// Regardless of mode, check for serial input each time:
t = millis();
if ((bytesBuffered < 256) && ((c = Serial.read()) >= 0)) {
  buffer[indexIn++] = c;
  bytesBuffered++;
  lastByteTime = lastAckTime = t; // Reset timeout counters
} else {
  // No data received.  If this persists, send an ACK packet
  // to host once every second to alert it to our presence.
  if ((t - lastAckTime) > 1000) {
    Serial.print("Ada\n"); // Send ACK string to host
    lastAckTime = t; // Reset counter
  }
  // If no data received for an extended time, turn off all LEDs.
  if ((t - lastByteTime) > serialTimeout) {
    memset(leds, 0,  NUM_LEDS * sizeof(struct CRGB)); //filling Led array by zeroes
    FastLED.show();
    lastByteTime = t; // Reset counter
  }
}

switch (mode) {

  case MODE_HEADER:

    // In header-seeking mode.  Is there enough data to check?
    if (bytesBuffered >= HEADERSIZE) {
      // Indeed.  Check for a 'magic word' match.
      for (i = 0; (i < MAGICSIZE) && (buffer[indexOut++] == magic[i++]););
      if (i == MAGICSIZE) {
        // Magic word matches.  Now how about the checksum?
        hi  = buffer[indexOut++];
        lo  = buffer[indexOut++];
        chk = buffer[indexOut++];
        if (chk == (hi ^ lo ^ 0x55)) {
          // Checksum looks valid.  Get 16-bit LED count, add 1
          // (# LEDs is always > 0) and multiply by 3 for R,G,B.
          bytesRemaining = 3L * (256L * (long)hi + (long)lo + 1L);
          bytesBuffered -= 3;
          outPos = 0;
          memset(leds, 0,  NUM_LEDS * sizeof(struct CRGB));
          mode           = MODE_DATA; // Proceed to latch wait mode
        } else {
          // Checksum didn't match; search resumes after magic word.
          indexOut  -= 3; // Rewind
        }
      } // else no header match.  Resume at first mismatched byte.
      bytesBuffered -= i;
    }
    break;

  case MODE_DATA:

    if (bytesRemaining > 0) {
      if (bytesBuffered > 0) {
        if (outPos < sizeof(leds))
          ledsRaw[outPos++] = buffer[indexOut++];   // Issue next byte
        bytesBuffered--;
        bytesRemaining--;
      }
      // If serial buffer is threatening to underrun, start
      // introducing progressively longer pauses to allow more
      // data to arrive (up to a point).
    } else {
      // End of data -- issue latch:
      startTime  = micros();
      mode       = MODE_HEADER; // Begin next header search
      FastLED.show();
    }
} // end switch

} // end for(;:wink:
}

void loop()
{
// Not used. See note in setup() function.
}

“does this mean i have to desolder the new ws2801 thats meant to cover buttom part of my screen and have GND - 5V - CK - SPI connected to new pins on arduino?”

Yes - the RGB ordering is set for an entire_strip - not for a portion of a strip.

(Also - as mentioned in http://fastled.io/faq - please use http://pastebin.com or http://gist.github.com to post code - don’t post code in g+ comments - it’s a pain to read).

The other possibility would be to write your own code before the call to FastLED.show that swaps the B and G bytes in the leds that need it.

For example, something like:

My Apologies about the code paste, I will make sure to use the format in future.

About the de soldering part. Do you really think it’s necessary to desolder all 4 pins from the first strip?

I ask this because GND and 5v pin would still be connected to the same pin on arduino so I might as wel leave them on the first strip soldered ?

And about the clock pin I am not sure. Logical thinking makes me think the clock needs to be connected on same line as wel to make it work in sync so can leave this pin connected to the first led strip as wel?

and just desolder the data pin and use another wire to connect it to a free pin point on arduino? (Example: Pin 6 )

But ofcourse i am not a expert with arduino or fastled. This is my first project , am just thinking out loud. Hope you guys can enlighten me.

At the very least you need to do the clock and data pins and put them on two new pins on the Arduino. You can leave power and ground connected if you want.

(The code I suggested would also work - since you are overwriting the data every frame from the pc anyway)

that clears up some issues i was having when left CLK still attached to the main strip.

i am gonna try the code you provided before and after that i will desolder the 2 pins which are connected to CLK and DATA, place those in 2 free pins on arduino. and see how far i get :slight_smile: thanks for your time Garcia!

Garcia, i tryed your code on multiple location in the arduino FastLed code without any effect.

like you instructed i tryed placing yours code before FastLED.show on line 103. just under memset(leds, …

as i mentioned this didnt change anything, the buttom lights were stil showing blue as green and green as blue.

further, i tryed placing your code underneath void setup()
{
“here”

this didnt produce any change either.

i am sure i am doing something wrong here

Garcia i think i might have figured it out. this time i placed your code above FastLED.show on line 150. its showing diffirent colours now! amezing stuff. gonna work on this little bit more to see if i can get it all correct.
amezing that such little code can change so much

one little ISSIUE here.

while testing individual colours everthing is working perfect. green shows green , blue shows blue, red shows red

now i opened the following image(look at link bellow) it shows correct colours everywhere except the buttom part

any idea how this is possible?

Imgur

its fixed. the issiue was in Prismatik. it was mirroring the top side of screen to buttom leds.

thanks once more for your help !