"Phantom Lights" in LED Matrix

[cabyambo]

Hello All,
I've made an LED Matrix following the schematic below, and I'm trying to have it display a checkerboard pattern using the following code.

const int rClock = 2; //chip pin 7
const int rData = 0; //chip pin 5
const int cData = 4; //chip pin 3
const int latch = 1; //chip pin 6 
const int cClock = 3; //chip pin 2

byte shape[] = {B01010101, B10101010, B01010101, B10101010, B01010101, B10101010, B01010101, B10101010}; 
byte rowActivator[] = {B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000};

void setup() {
  pinMode(rClock, OUTPUT);
  pinMode(rData, OUTPUT);
  pinMode(cData, OUTPUT);
  pinMode(latch, OUTPUT);
  pinMode(cClock, OUTPUT);
}

void loop() 
{
  for(int i=0; i<8; i++)
  {
    digitalWrite(latch, LOW);
    
    shiftOut(cData, cClock, LSBFIRST, shape[i]);
    shiftOut(rData, rClock, LSBFIRST, rowActivator[i]); 
    digitalWrite(latch, HIGH);
    delay(2);
  }
}

The problem is that while the lights that are supposed to be on are bright, all the other lights that shouldn't be on have a faint glow. Any suggestions or ways to help would be very appreciated!

[PaulRB]

If you set the pattern to all zeroes, all leds blank/off, do you still get the faint glow?

This will tell us if the problem is "ghosting" (from one row to the next) or "leaking" (transistors not shutting off completely). What part number are Q1-7?

[cabyambo]

If I set the registers completely to zero there is no glow. And the transistors are 400v 0.5A SOT23F-3 P/N: zxtn08400bffta

[PaulRB]

cabyambo:
If I set the registers completely to zero...

That's not what I meant. If you just set both registers to zero, the multiplexing/row scanning won't work.

set all 8x8 bits of the pattern to zero but leave the row "Activator" data as shown in your sketch above, so that the scanning works as before.

Set the pattern so that just one led is on, somewhere near the middle. Does one other led glow faintly?

[cabyambo]

Sorry for the misunderstanding! I just made the pattern all zeros but kept scanning the rows and the matrix has no glow at all.

[PaulRB]

Ok, sounds like ghosting then. Try my single led suggestion to confirm.

I'm a little surprised you are getting any noticeable ghosting, given that both 595's share the same latch signal. That means that both registers should output their updated pin states at almost exactly the same instant.

You are using surface mount transistors. Does this mean you have constructed a pcb already? You didn't prototype the circuit on breadboard?

What I want to suggest is using the Output Enable pins of one or both 595's to attempt to avoid the ghosting. But you would need another output pin on the tiny85 and they are currently all in use. To free up one of its pins, you could daisy chain the two shift registers. I wonder why you did not do that in the first place?

[cabyambo]

I do already have a PCB made unfortunately, but during the prototyping stage this problem didn't arise. And how exactly would I use the output enable pin to fix this problem? As to not daisy chianing I'm just unsure of how to set up the arrays and code for that scenario but I will definitely learn!

[PaulRB]

I just thought of another possible cause.

Let's assume the forward voltages of the LEDs are 1.8V and the voltage drop of the transistors is 0.7V. Your schematic shows batteries but does not show the voltage. If it was 5V, the 110R series resistors would need to drop 5-1.8-0.7=2.5V. the current would be about 22mA per 595 output. If even only 4 outputs are high, you would already be exceeding the maximum 70mA current for the 595. Could that be making it misbehave?

[cabyambo]

On paper the LED's would definitely exceed the current sourcing abilities of the shift registers, but for some reason in every prototype I've done and every tutorial I've seen, the 74hc595's perform without fault. So I just went for it lol.

I'VE FOUND A SOLUTION!
I was browsing other threads of people with similar problems and saw someone suggest clearing the data in the "row" register, which worked flawlessly for me. Below is the simple revised code.

const int rClock = 2; //chip pin 7
const int rData = 0; //chip pin 5
const int cData = 4; //chip pin 3
const int latch = 1; //chip pin 6 
const int cClock = 3; //chip pin 2

//byte shape[] = {B00000000, B00000000, B00000000, B00000000, B00000000, B00000000, B00000000, B00000000}; 
byte shape[] = {B10101010, B01010101, B10101010, B01010101, B10101010, B01010101, B10101010, B01010101}; 
byte rowActivator[] = {B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000};

void setup() {
  pinMode(rClock, OUTPUT);
  pinMode(rData, OUTPUT);
  pinMode(cData, OUTPUT);
  pinMode(latch, OUTPUT);
  pinMode(cClock, OUTPUT);
}

void loop()
{
  for(int i=0; i<8; i++)
  {
    clrData();
    digitalWrite(latch, LOW);
    shiftOut(cData, cClock, LSBFIRST, shape[i]);
    shiftOut(rData, rClock, LSBFIRST, rowActivator[i]); 
    digitalWrite(latch, HIGH);
    delay(2);
  }
}

void clrData () 
{
  digitalWrite(latch, LOW);
  shiftOut(rData, rClock, LSBFIRST, B00000000);
  digitalWrite(latch, HIGH); 
}

Thanks so much for all your help! I hope this can help someone else in the future.

[PaulRB]

The ghosting may be caused by a slight timing difference between when the two shift registers output their new data. For example if the row data changed slightly before the column data, then for a very short time, a current would flow to the wrong LEDs. This should only be nanoseconds, so I would not expect the LEDs would glow visibly.

By using the Output Enable pin, perhaps you could prevent the ghosting by blanking the outputs of one of the registers, until both registers' outputs had updated. It might not help, but would be worth trying.

[PaulRB]

Well done. The solution you found proves that the problem was ghosting. My output enable suggestion would have had the same effect, but of course would have needed an extra output pin, which you don't have.

[Wawa]

A TPIC6B595 could replace the 74HC595 and all the transistors/resistors.
Leo..

[PaulRB]

Not all the resistors, Leo...

[Wawa]

PaulRB:
Not all the resistors, Leo...

Yes, ofcourse only the base resistors.

Better to use PNP transistors with resistors (or small p-channel fets without resistors) on the other (U2) shift register. And a TPIC6B595 (or other family member) to switch to ground.
Leo..

[eric8he]

cabyambo:

void loop()

{
 for(int i=0; i<8; i++)
 {
   clrData();
   digitalWrite(latch, LOW);
   shiftOut(cData, cClock, LSBFIRST, shape[i]);
   shiftOut(rData, rClock, LSBFIRST, rowActivator[i]);
   digitalWrite(latch, HIGH);
   delay(2);
 }
}

void clrData ()
{
 digitalWrite(latch, LOW);
 shiftOut(rData, rClock, LSBFIRST, B00000000);
 digitalWrite(latch, HIGH);
}

Noting the new code, does the latch pin need to be low when we're writing to the shift registers? Absolutely not. Just toggle the latch pin low and high after you shift out the data, and you can omit clearing the scanning register, which opens up more processing time.

[Wawa]

Never build a LED matrix, but couldn't you use SPI.transfer to speed things up?
Leo..

[PaulRB]

eric8he:
Noting the new code, does the latch pin need to be low when we're writing to the shift registers? Absolutely not. Just toggle the latch pin low and high after you shift out the data, and you can omit clearing the scanning register, which opens up more processing time.

If I remember correctly, it does not matter whether the code sets the latch pin low before or after writing to the shift register. The data is output on the rising edge of the latch signal. The falling edge is ignored.

As for omitting clearing the register, that was added by the OP to correct the ghosting which was the reason for starting this thread.

[PaulRB]

Wawa:
Never build a LED matrix, but couldn't you use SPI.transfer to speed things up?

The circuit is driven by an ATtiny85, so I don't know if the SPI library would work. The tiny does have a USI (universal serial interface) which should be able to simulate SPI. But if that can be used, how would speeding the sketch up help? The OP had not reported that speed is a problem.

[Wawa]

PaulRB:
The circuit is driven by an ATtiny85...

Ahh, missed that.
Leo..

[daba]

You can also get "ghosting" in multiplexed LEDs if one of them passes current when it is reverse-biased.

I have seen this often in RGB common-anode LEDs.

It is worthwhile taking the time to test every single LED, before assembly, after lead-forming, and after soldering, as these can make an LED go "bad". Discard any that show any reverse-biased current.

Sometimes an LED can just go "bad" on it's own, then it has to be replaced. This isn't so bad on a 2D matrix, but I had one go on my 8 x 8 x 8 RGB LED Cube. Thankfully is was an "edge" one, so replacement wasn't too tricky, but if it had been in the middle on the cube, it would have been time to go out and buy some extra-extra long pliers or tweezers. The cube designer says it's possible to replace LEDs in the middle of the cube, but it's a real PITA !