0

TLC5947 - Need advice to identify problem
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

TLC5947 - Need advice to identify problem

by maurobarreca on Mon Aug 07, 2017 12:31 am

Hi. I've built an RGB LED matrix of 45 RGB LEDs (135 individual LEDs). I used 6 chained TLC5947 breakout boards and I'm having some issues. Didn't have time to do all the tests, but I'm near a deadline and need to speed up the testing processes, so I'll describe the project and the problem to see if someone finds the solution obvious, and could tell me which tests to do first.

The project:

I have a 45 RGB LED matrix (they're high power LEDs, so each one have an individual driver connected to the TLC outputs, more on this later). The matrix is controlled via Processing through an Arduino UNO R3. A 5x9 pixel image is generated once per frame and the 12bit color information is sent in a string to the Arduino via serial. This is the string structure (supposing that all the pixels are white):

Code: Select all | TOGGLE FULL SIZE
<4095 4095 4095 ... 4095 4095 4095>


The string has a length of 674 characters and is sent (and received) at 250000 baud. They're always 674 characters, when the numbers are lower than 1000, 0's are added to reach 4 characters (for example: 0023, 0002, 0134, etc.). I think there's no problem on the Processing side, I think the main problem is on the Arduino code. The Arduino receives the string and assign each value to one LED (using setPWM() ). This is the Arduino code:

Code: Select all | TOGGLE FULL SIZE
#include "Adafruit_TLC5947.h"

#define NUM_TLC5974 6

#define data   4
#define clock   5
#define latch   6
#define oe  -1  // set to -1 to not use the enable pin (its optional)

Adafruit_TLC5947 tlc = Adafruit_TLC5947(NUM_TLC5974, clock, data, latch);

char val; // Data received from the serial port
char receivedChars[674];
char arrayOfNums[135];
boolean started = false;
boolean ended = false;
int serialIn = 0;

void setup()
{

  Serial.begin(250000);
 
  tlc.begin();
  if (oe >= 0) {
    pinMode(oe, OUTPUT);
    digitalWrite(oe, LOW);
  }
}

void loop(){

  while(Serial.available() > 0) {
    int incomingByte = Serial.read();
    if(incomingByte == '<'){
      started = true;
      ended = false;
    } else if (incomingByte == '>') {
      ended = true;
      break;
    } else {
      receivedChars[serialIn] = incomingByte;
      serialIn++;
    }
  }

 
  if (started && ended) {
    int arrIndex = 0;   

    char * token = strtok(receivedChars," ");
    while (token != NULL){
      int aNum = atoi(token);
      if(arrIndex <= 134){
        //arrayOfNums[arrIndex] = aNum;
        tlc.setPWM(arrIndex, aNum);
        arrIndex++;
      }
      token = strtok (NULL, " ");
    }
    tlc.write();

    serialIn = 0;
    receivedChars[serialIn] = '\0';
   
    started = false;
    ended = false;
  }
 
}


The problem I have is that the matrix seems to work well until the second LED of the 4th TLC board. At the LED 26 through 40 the LEDs don't update and stay white. The final 5 LEDs (6th TLC board) seem to receive data, but they display it with a lot of "noise" (not flicker).

This is a video showing the problem (in this example I was sending blinking green data): https://youtu.be/Y3cabM3mLAo (the static non-white colors are failing LEDs, don't pay attention to them).

NOTE: because of the circuit design and build status, the current circuit sends inverted signals to the LEDs, so instead of a black flicker you'll se a short white pulse. I don't know if the solid white LEDs are display color info sent from the Arduino or a static 0 value sent from the TLCs. Later I'll add a signal inverter at the input of each LED.

My guesses are:

- The communication from Processing to the Arduino is long and fast, and the Arduino can't keep up with it, so it looses some data at the second half of the string.
- The communication from the Arduino to the TLC boards is failing, maybe some synchronization problem.

What do you think the problem is?

I was thinking of maybe dividing the chain of TLCs in two groups of 3, but I prefer to resolve this just via software.

When I run on the Arduino the Adafruit's test for the TLC the matrix works perfectly, so I guess the problem is my code. I need fast communication, I want to keep the refresh rate at 25fps at least, but with the current setup 25fps show some noisy results (the "noise" increases as the chain advances). To make it work like in the video I had to slow Processing down to 10fps.

maurobarreca
 
Posts: 16
Joined: Sun Jun 25, 2017 9:53 pm

Re: TLC5947 - Need advice to identify problem

by maurobarreca on Tue Aug 08, 2017 2:44 pm

It seems to be an Arduino problem. I tried sending only one value from Processing and mirroring that value to all the LEDs and the problem persists. Does someone knows why? It should be pretty straightforward. The only LED that works flawlessly is the first one. The tlc5947test sketch written by Adafruit works really well.

maurobarreca
 
Posts: 16
Joined: Sun Jun 25, 2017 9:53 pm

Re: TLC5947 - Need advice to identify problem

by adafruit_support_bill on Tue Aug 08, 2017 3:02 pm

My guess would be a buffer overrun. That is a pretty fast baud rate. The Arduino has a relatively small receive buffer (64 bytes if I recall correctly) and no handshaking.

You might try breaking up the transmission and adding a 1-byte 'ACK' per row from the Arduino.

adafruit_support_bill
 
Posts: 61001
Joined: Sat Feb 07, 2009 10:11 am

Re: TLC5947 - Need advice to identify problem

by maurobarreca on Wed Aug 09, 2017 1:25 am

Hi, thank you for your response.

I was doing some testing today and found out some new things:

    The problem starts always at LED number 25 (73 if you count the RGB independently), that's the first LED of the 4th TLC board. This happens independently of the baud rate, the Processing framerate or the size of the transmission. So I now know that the problem is not transmission related.
    The LEDs that stayed white on the first video I linked in reality receive the data sent from the Arduino. I know this because when doing some tests today I found out that some colours, basically the ones that are made by lighting two of the R-G-B LEDs (mainly magenta, yellow and cyan), display correctly. My theory is that the white is data that should not be visible (remember that I'm using inverted signals for now) and is covering out every less luminous colour. I think this is a little weird, but I also think that this finding is key to know what's going on.
    Doing some research if found this post where the user mpinner talks about using a signal buffer every three TLCs, and I'm having problems at the 4th! Could his problem be related to mine? I think not, my tests with with the Adafruit TLC test shows no problem at the 4th TLC. The real question is: why this happens with my code and not with the Adafruit's one? Could it be related to the high TLC refresh rate (forced to 20fps by the Processing code)?

Tomorrow I'll hook up some signal inverter circuits and check if the problem persists.

I recorded this video today, here you can see that the problem disappears when displaying two LED colors (magenta and cyan in this case): https://youtu.be/vznK_YJ88fo

maurobarreca
 
Posts: 16
Joined: Sun Jun 25, 2017 9:53 pm

Re: TLC5947 - Need advice to identify problem

by adafruit_support_bill on Wed Aug 09, 2017 8:13 am

The 'while' loop for receiving input exits when no characters are available - but does not reset any state variables if it does not receive a complete buffer with both < and >. Looks like it could easily get out of sync. Not sure why different colors would affect anything if all of your input is padded out to 4 digits,

adafruit_support_bill
 
Posts: 61001
Joined: Sat Feb 07, 2009 10:11 am

Re: TLC5947 - Need advice to identify problem

by maurobarreca on Thu Aug 10, 2017 1:36 am

OK, I'll try some new things with the code (big delays between tlc.write's, sending shorter packages from Processing -maybe using bytes instead of a string-, handshakes, etc.)

adafruit_support_bill wrote:Not sure why different colors would affect anything if all of your input is padded out to 4 digits.


Yes, that's really weird. My theory is that because of an undefined reason sometimes the TLCs set their outputs to 0 and, being common cathode LEDs, those 0's are perceived as white. Less frequently the right data reaches those TLCs and they set their output correctly, but the white 0's wash out those colours, with exception of the colours that emit more light by using 2 LEDs (magenta, cyan and yellow). Tomorrow I'll check with some common anode LEDs if the reds, greens and blues are also received (if my theory is right the common anode LEDs shouldn't turn white).

maurobarreca
 
Posts: 16
Joined: Sun Jun 25, 2017 9:53 pm

Re: TLC5947 - Need advice to identify problem

by maurobarreca on Thu Aug 10, 2017 1:58 pm

OK, doing some tests I found out that the problem seems to be the power source. I was using a 5v 3A source for the Arduino and the 6 TLCs. I thought it should be enough, but it seems not. I'm feeding the TLCs using the Vin and GND pins on the Arduino, I'll try feeding directly from the power source (I don't know if feeding through the Arduino limits the current draw or not) or switching it for a 10A one.

maurobarreca
 
Posts: 16
Joined: Sun Jun 25, 2017 9:53 pm

Re: TLC5947 - Need advice to identify problem

by adafruit_support_bill on Thu Aug 10, 2017 2:27 pm

Most Arduinos have a 500mA slow response polyfuse. But if you are feeding via the VIN pin, you are probably bypassing that.

However, the combine contact resistance and wiring resistance may be enough to cause a voltage drop in the units further away from the power source. You might even consider feeding power to multiple points in your chain.

That may also explain why colors made a difference. With more channels active, you would have higher current draw and a proportionally higher voltage drop due to resistance. (And possibly also some voltage sag if the power supply was at its limit).

adafruit_support_bill
 
Posts: 61001
Joined: Sat Feb 07, 2009 10:11 am

Please be positive and constructive with your questions and comments.