Go Down

Topic: Random noise in 8x8 LED Matrix with TLC5940 Mux? (Read 7385 times) previous topic - next topic

itoa

Hello,

I recently acquired an oscilloscope as I've been having some odd issues with multiplexing simple one color LED matrices with the TLC5940 Mux library. Standard setup using 1-of8 decoder into 8 p-channel FETs for each row, and then having each column tied to output pins 1->8 on the TLC5940. (And yes, the TLC5940 is decoupled.)

In the following image, the yellow channel is one of the p-channel FETs, and the blue channel is that FET's corresponding decoder output pin. The yellow channel is positioned at 0V and the blue channel is placed at -5V.



I cannot come up with a reason as to why the random noise is occurring all of the sudden - I've ruled out crosstalk as it's happening on every FET. I imagine that this issue is what is causing ghosting/flickering around my patterns that I am trying to draw to the matrix.

Thanks for any possible help!

Grumpy_Mike

Yes I have seen this sort of thing on my hexome project. It is instability caused by the inductance in the wires leading to the LEDs. I cured it by putting a very small capacitor on the LED to ground. I used 100pF.

dc42


I cannot come up with a reason as to why the random noise is occurring all of the sudden - I've ruled out crosstalk as it's happening on every FET. I imagine that this issue is what is causing ghosting/flickering around my patterns that I am trying to draw to the matrix.


What type of P-channel fet are you using, and how are you driving it from the Arduino?
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

itoa


Yes I have seen this sort of thing on my hexome project. It is instability caused by the inductance in the wires leading to the LEDs. I cured it by putting a very small capacitor on the LED to ground. I used 100pF.


Would that inductance cause the same noise on the decoder outputs (blue channel)? And since I have my LEDs row/column multiplexed, I assume that each capacitor would be placed between each row and ground, correct?


What type of P-channel fet are you using, and how are you driving it from the Arduino?


FQP27P06 - Datasheet here http://www.fairchildsemi.com/ds/FQ/FQP27P06.pdf

I am driving them from the Arduino in the same way that the Matrix example for the Tlc5940Mux library is driving them (following code is not exact but very close to what I have):

Code: [Select]

#define  NUM_TLCS  1
#define  NUM_ROWS  8
#include "Tlc5940Mux.h"

volatile uint8_t isShifting;
uint8_t shiftRow;

ISR(TIMER1_OVF_vect)
{
  if (!isShifting) {
    disable_XLAT_pulses();
    isShifting = 1;
    sei();
    TlcMux_shiftRow(shiftRow);
    PORTC = shiftRow++;
    if (shiftRow == NUM_ROWS) {
      shiftRow = 0;
    }
    enable_XLAT_pulses();
    isShifting = 0;
  }
}

void setup()
{
  DDRC |= _BV(PC0) | _BV(PC1) | _BV(PC2);
  TlcMux_init();
}

int[][8] board =
{
{ 4095, 0, 0, 0, 0, 0, 0, 0 },
{ 0, 4095, 0, 0, 0, 0, 0, 0 },
{ 0, 0, 4095, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 4095, 0, 0, 0, 0 },
{ 0, 0, 0, 4095, 4095, 0, 0, 0 },
{ 0, 0, 4095, 0, 0, 4095, 0, 0 },
{ 0, 4095, 0, 0, 0, 0, 4095, 0 },
{ 4095, 0, 0, 0, 0, 0, 0, 4095 },
};

void loop()
{
  TlcMux_clear();
  for (uint8_t col = 0; col < 8; col++) {
    for (uint8_t row = 0; row < NUM_ROWS; row++) {
      TlcMux_set(row, col, board[col][row]);
    }
  }
  delay(2000);
}

Grumpy_Mike

Quote
And since I have my LEDs row/column multiplexed, I assume that each capacitor would be placed between each row and ground, correct?

No, I placed them from the cathode of the LED to ground.
It is not noise by the way but spurious oscillations. You might look to your layout or put better decoupling on the chips. You don't say what you used but a smaller ceramic capacitor might be in order here. I would try a 22nF surface mount capacitor.

I say this because your problem seems to be bigger than the one I saw, see these two photos.


dc42

#5
Oct 04, 2011, 03:25 pm Last Edit: Oct 04, 2011, 03:30 pm by dc42 Reason: 1

I am driving them from the Arduino in the same way that the Matrix example for the Tlc5940Mux library is driving them (following code is not exact but very close to what I have):


What I actually meant was, how do you have them connected to the Arduino? If you have the gate terminal connected to the Arduino pin through a series resistor, what is the value of the resistor?

[EDIT: I've just re-read your original post, and I see that you are driving them from a decoder. Is that a 74HC138 or similar chip, and if you are using series gate resistors, what value are they?
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Grumpy_Mike

No need for a series resistor with a 74HC138.

itoa

#7
Oct 04, 2011, 03:54 pm Last Edit: Oct 04, 2011, 03:57 pm by itoa Reason: 1

No, I placed them from the cathode of the LED to ground.
It is not noise by the way but spurious oscillations. You might look to your layout or put better decoupling on the chips. You don't say what you used but a smaller ceramic capacitor might be in order here. I would try a 22nF surface mount capacitor.

I say this because your problem seems to be bigger than the one I saw, see these two photos.


I am using 0.1uF (100nF) capacitors to decouple the chips. I don't think I have any caps smaller than 0.1uF so I'll try throwing a couple in series when I get off of work and see if that makes any difference. Also, how can you tell that what is happening is "spurious oscillation"? I have no idea what this term means (just starting my third year in EE courses)


[EDIT: I've just re-read your original post, and I see that you are driving them from a decoder. Is that a 74HC138 or similar chip, and if you are using series gate resistors, what value are they?


Yes, I am driving them from a 74ls138 1-of-8 decoder. No, I am not using any series gate resistors. Could this cause an issue?

[EDIT: Read Mike's reply, I guess they aren't a necessity.]

As always, thank you both for the replies.


Grumpy_Mike

Quote
so I'll try throwing a couple in series when I get off of work and see if that makes any difference.

Don't bother it is not so much the value that is important but the low inductance of the smaller value chips. What is important is the lead length, that's why a surface mount part is best.

Quote
how can you tell that what is happening is "spurious oscillation"

Because that is what it is. Noise is generated from a totally different mechanism, depending on the type of noise. Also noise doesn't come in bursts where as oscillation does. As a colloquialism this is sometimes referred to as noise but it isn't really.

itoa


Don't bother it is not so much the value that is important but the low inductance of the smaller value chips. What is important is the lead length, that's why a surface mount part is best.


I'm prototyping this on a breadboard with the actual implementation on a perfboard... I'm not sure I'll be able to use surface mount caps on either of the two. Are there any alternatives?


Because that is what it is. Noise is generated from a totally different mechanism, depending on the type of noise. Also noise doesn't come in bursts where as oscillation does. As a colloquialism this is sometimes referred to as noise but it isn't really.


Do you have any good resources that I can learn more about this issue and why it occurs? I've tried googling "spurious oscillation" and the resulting pages seem to range from math to mechanics.

dc42


No need for a series resistor with a 74HC138.


Mike, would you care to explain your reasoning?

atmega328p: abs max rating 40mA per pin. You normally seem to recommend a 100 ohm resistor to limit the transient current to around this value while the gate capacitance is charging and discharging.

74HC138 and 74HCT138: abs max rating 25mA per pin. I would have thought that a similar conservative approach called for a series resistor of around 180 ohms?

@itoa, I'm not suggesting that the lack of a series resistor is causing the problem - I was more concerned that too high a series resistor would make it more likely.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

dc42


Yes, I am driving them from a 74ls138 1-of-8 decoder.


I think that may be part of the problem. TTL chips such as the 74LS series don't pull up very well (they're only guaranteed to pull up to 2.7v). So your mosfets are not being held off very effectively, which makes it easier for them to oscillate. This is clear from the blue trace in your original post. I suggest you replace it with a 74HC138 or 74HCT138. An alternative (not quite as effective) would be to add a 1k pullup resistor from each of the 8 outputs of the 74LS138 to +5v.

I would also check with the scope whether there is any noise on the +5v supply to the 74LS138, and add a decoupling cap between its Vcc and Gnd if there is or if you are in any doubt.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Grumpy_Mike

The 74LS series are rated for a short circuit current, which is what they see when charging a FET. The output configuration of a gate typically has push pull output with a 120R resistor between the top transistor and the supply. I would agree however that a pull up on the FET gate is essential, and I always include one when driving a p-channel FET.

The HC series are a little bit more sensitive but can also be shorted for short periods. No output voltage is guaranteed under these conditions but for small capacitance. 

dc42


The HC series are a little bit more sensitive but can also be shorted for short periods.


Likewise the atmega328p. I had a solder bridge on one of my stripboards, between a pin and ground AFAIR. I powered it up twice for around 10 secs each time before I worked out what was going on. The chip (including that pin) survived.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

itoa

I've tried adding pull-ups to each gate and trimming the leads of the de-coupling caps as short as possible; the issue still persists. I've noticed that the oscillation occurs on the led pins of the TLC (this would make sense), so it's hinting me toward a problem with the TLC Mux library.

The issues on my display (ghosting, flickering) are also described by this poster - http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286580054 - who also provides a resolution to the problem which I haven't tried implementing yet. I'm going to shift a couple wires in a minute when I get the chance and try implementing his fix and will return with results.

Go Up