LED on when shouldn't be

[Nogtail]

I have an LED matrix where columns are driven by a shift register and a ULN2003A, and rows are driven from a UDN2580A connected directly to a microcontroller.



I drive it by shifting data into the shift register, then enabling the row the data needs to be displayed on. If I shift data too far (out of the shift register) the row should be blank (row and column should never be on at the same time), but the first LED in the row (first to receive data from shift register) glows very slightly. It does not glow if there are any other enabled LEDs on the row, or if I don't shift any new data (but keep cycling the rows).

The matrix is refreshed at around 150Hz running on 12V.

The effect is similar to what I would expect to happen if there was a decent capacitance on the rows, so when the row is pulsed it stores a charge on the row, then when data is shifted it can leave through the column when it is briefly enabled due to the shifted bit passing through. This would also explain why it is not visible when there is another LED enabled on the row (the charge would drain away through the other LED) and if I don't shift new data there is no way for the charge to leave the row through an LED, but I doubt the slight capacitance of the PCB trace, wires, pins etc. would be anywhere near enough to visibly light an LED.

Would the capacitance of PCB traces (about 0.5mm wide, 20cm long, no ground plane) be able to light an LED? What is more likely going on here?

[Zero999]

Please post a more complete schematic, showing the power rails for the MCU and the UDN2580A.

The UDN2580A is designed to switch negative voltages. It starts to turn on when the input falls below its supply voltage by about 1V. As you appear to have it configured, it will always be on, as the MCU's power supply voltage is always lower than the 12V powering the UDN2580A.

I don't think the UDN2580 is suitable for your application.

What you need is the UDN2981 but it's obsolete, although you may still be able to buy it.

Fortunately there are some alternatives, which are compatible:

MIC2981
http://ww1.microchip.com/downloads/en/DeviceDoc/mic2981.pdf

TD62783
http://acg.media.mit.edu/people/simong/hotpants/tech/media/TD62783AF.pdf

TBD62783A
https://toshiba.semicon-storage.com/info/docget.jsp?did=30523

M54563P
https://www.mitsubishielectric-mesh.com/products/pdf/m54563p_e.pdf

[capt bullshot]

Your observation is most likely caused by the storage / turn off time of the transistors. Bipolar transistors take a short amount of time to turn off after the base current is removed. Depending on the actual type of transistor, this ranges from nanoseconds to microseconds. When switching the rows / shifting new data: first turn off the row, wait a short amount of time, then start shifting new data and then turn on next row.

[james_s]

I observed something similar when I did a multiplexed 7 segment display on something I designed. I had to do as mentioned above and turn the display off, then change to the next digit, then turn it on for a time, then off, wash, rinse, repeat.

[Nogtail]

Please post a more complete schematic, showing the power rails for the MCU and the UDN2580A.

The UDN2580A is designed to switch negative voltages. It starts to turn on when the input falls below its supply voltage by about 1V. As you appear to have it configured, it will always be on, as the MCU's power supply voltage is always lower than the 12V powering the UDN2580A.

I don't think the UDN2580 is suitable for your application.

What you need is the UDN2981 but it's obsolete, although you may still be able to buy it.

Fortunately there are some alternatives, which are compatible:

MIC2981
http://ww1.microchip.com/downloads/en/DeviceDoc/mic2981.pdf

TD62783
http://acg.media.mit.edu/people/simong/hotpants/tech/media/TD62783AF.pdf

TBD62783A
https://toshiba.semicon-storage.com/info/docget.jsp?did=30523

M54563P
https://www.mitsubishielectric-mesh.com/products/pdf/m54563p_e.pdf

Sorry, I should have mentioned, this is not my design, just something I am trying to get working so I don't actually have a full schematic. I am shifting the levels from the microcontroller with a ULN2003A that I forgot to put in the image, sorry. Thanks for the part recommendations though, they will be useful for something else I am doing.

Your observation is most likely caused by the storage / turn off time of the transistors. Bipolar transistors take a short amount of time to turn off after the base current is removed. Depending on the actual type of transistor, this ranges from nanoseconds to microseconds. When switching the rows / shifting new data: first turn off the row, wait a short amount of time, then start shifting new data and then turn on next row.

I have added a 2ms delay before and after shifting the data, which hopefully is plenty for the transistors to turn off, but the LED glow is still visible (less bright, but I have halved the frequency due to the delay so that's understandable). I can't measure multiple channels at once so I have coupled the first and last row with a resistor and the shift register clock with a capacitor. All rows are on for the same period of time:

[Red Squirrel]

Shot in the dark, I'm a newb myself, but try putting pull down resistors on all the micro controller outputs.  1k should probably do.  Basically just a resistor that goes to ground so if the pin is floating it will drop any excess voltage that is making it register as on. Though I don't think this is normally needed on outputs... just on inputs.

Failing that, try the same, but at the outputs of the driver. 

If there is any transistors  involved a pull down at the base (or gate if it's a fet) is good to have too.

[Nogtail]

Shot in the dark, I'm a newb myself, but try putting pull down resistors on all the micro controller outputs.  1k should probably do.  Basically just a resistor that goes to ground so if the pin is floating it will drop any excess voltage that is making it register as on. Though I don't think this is normally needed on outputs... just on inputs.

Failing that, try the same, but at the outputs of the driver. 

If there is any transistors  involved a pull down at the base (or gate if it's a fet) is good to have too.

I have tried a large resistance (1 megohm) between a row and ground which stops the glow on that row:


This also seems to indicate capacitance on the rows, but it still seems unlikely that a PCB trace would have enough capacitance to even come close to lighting an LED.

[MK14]

A very quick look at the datasheet of the UDN2580A. Seems to show that the output leakage current can be as high as 50uA's (more, above room temperature), so I'm not surprised you need the pull down resistors.

[Nogtail]

A very quick look at the datasheet of the UDN2580A. Seems to show that the output leakage current can be as high as 50uA's (more, above room temperature), so I'm not surprised you need the pull down resistors.

Why would only the first LED on the row be on? Shouldn't a leakage current make all the LEDs glow fairly evenly?

[MK14]

A very quick look at the datasheet of the UDN2580A. Seems to show that the output leakage current can be as high as 50uA's (more, above room temperature), so I'm not surprised you need the pull down resistors.

Why would only the first LED on the row be on? Shouldn't a leakage current make all the LEDs glow fairly evenly?

Leakage currents vary widely, between devices/channels. Also it needs both the top side and bottom side, to be leaking enough to light LEDs.

On the other hand, the fact that it is just the first row, could also mean it is something else.

A 1 meg resistor, does not change things much, so I guess leakage current is a likely explanation. Because if there was really a significant problem/issue, the small currents a 1 meg resistor would allow, would probably not change things much.

tl;dr
If a datasheet says the maximum leakage current is say 100uAmps. That means that UPTO, a 100uAmps can flow, and be within the datasheet specification. But most devices (and channels) will be considerably less than that figure.

I.e. there may only be one or two significantly leaky channels.

There could also be contamination/dirt etc on the PCB, causing stray leakage currents.

[Nogtail]

A very quick look at the datasheet of the UDN2580A. Seems to show that the output leakage current can be as high as 50uA's (more, above room temperature), so I'm not surprised you need the pull down resistors.

Why would only the first LED on the row be on? Shouldn't a leakage current make all the LEDs glow fairly evenly?

Leakage currents vary widely, between devices/channels. Also it needs both the top side and bottom side, to be leaking enough to light LEDs.

On the other hand, the fact that it is just the first row, could also mean it is something else.

A 1 meg resistor, does not change things much, so I guess leakage current is a likely explanation. Because if there was really a significant problem/issue, the small currents a 1 meg resistor would allow, would probably not change things much.

tl;dr
If a datasheet says the maximum leakage current is say 100uAmps. That means that UPTO, a 100uAmps can flow, and be within the datasheet specification. But most devices (and channels) will be considerably less than that figure.

I.e. there may only be one or two significantly leaky channels.

There could also be contamination/dirt etc on the PCB, causing stray leakage currents.

I have several boards (designed to be chained together) and they all show the same problem on the first column (that shifted data reaches), so I doubt all of them have exactly the same leaky channels, and a leaky channel on the row driver should cause a whole row to light up.

[MK14]

I have several boards (designed to be chained together) and they all show the same problem on the first column (that shifted data reaches), so I doubt all of them have exactly the same leaky channels, and a leaky channel on the row driver should cause a whole row to light up.

I agree with you. I did not realize you had several boards, with the same problem.

Is the first channel special in any way ?

E.g. 74LS138 decoders used (mentioned elsewhere by you, apparently), or is this purely shift registers like you say ?
As it always has one output of the 1 of 8, "on", unless disabled.

Maybe others can help you better. I'm struggling, because of an apparent lack of information, on the exact details.
E.g. Real schematics, software listings etc.

[Nogtail]

I have several boards (designed to be chained together) and they all show the same problem on the first column (that shifted data reaches), so I doubt all of them have exactly the same leaky channels, and a leaky channel on the row driver should cause a whole row to light up.

I agree with you. I did not realize you had several boards, with the same problem.

Is the first channel special in any way ?

E.g. 74LS138 decoders used (mentioned elsewhere by you, apparently), or is this purely shift registers like you say ?
As it always has one output of the 1 of 8, "on", unless disabled.

Maybe others can help you better. I'm struggling, because of an apparent lack of information, on the exact details.
E.g. Real schematics, software listings etc.

I was originally using an ATtiny with a 74LS145to drive the rows, but switched to an Arduino in an effort to simplify everything as much as possible to find the problem, and am now powering it with 5 volts. The code I am using is here: https://gist.github.com/ElectronicsIdiot/3ef9cdecffb68426b64e3a87c9f0becc.

I don't have schematics or anything other than a rough idea of how things are connected.

The board:

The glowing LEDs are brighter towards the row that is pulsed first (bottom). If I reverse the row loop, the LEDs glow brighter at the top as the top row is now pulsed first:

The row that is pulsed first also seems to glow slightly, which I hadn't noticed before.

[BrianHG]

Sorry, I'm not an expert on you controller...

Q: Why aren't you clearing the columns off before changing the rows?  Using a 74LS138 can create random glitching during the transition.

In my design, I would:
{
Clear columns.  // make sure there is no initial pre-glow
   { //Refresh loop all rows and columns
   Clear rows.  // make sure the 74LS138 outputs all high without glitching.  This means not switching a single IO pin at a time driving the IC inputs.
   Shift columns.
   Set rows
   Pause
   }
Clear rows  // shutdown of display, make sure there is no afterglow
Clear columns
}

Have you a better multichannel scoping of the outputs at the first and second row?
Those pesky red led's will glow with the slightest pulse of current.

[Zero999]

What colour are the LEDs?

It doesn't take much current for modern efficient LEDs to glow dimly. Especially the blue, green and cool white colours, both because the eye is more sensitive to that end of the spectrum, at low light levels and the forward voltage is higher than the loner wavelength LEDs so you get more power for the same current.

Try putting a 10k to 1M resistor in parallel with the LEDs to reduce the voltage below the LEDs' turn on voltage.

[Nogtail]

Sorry, I'm not an expert on you controller...

Q: Why aren't you clearing the columns off before changing the rows?  Using a 74LS138 can create random glitching during the transition.

In my design, I would:
{
Clear columns.  // make sure there is no initial pre-glow
   { //Refresh loop all rows and columns
   Clear rows.  // make sure the 74LS138 outputs all high without glitching.  This means not switching a single IO pin at a time driving the IC inputs.
   Shift columns.
   Set rows
   Pause
   }
Clear rows  // shutdown of display, make sure there is no afterglow
Clear columns
}

Have you a better multichannel scoping of the outputs at the first and second row?
Those pesky red led's will glow with the slightest pulse of current.

The rows are currently connected via the UDN2580A to the Arduino, I'm not using any decoder at the moment. The program I have currently works like this:

loop forever {
  wait 1 ms
  shift data into columns
  wait 1ms
  loop rows {
    enable row
    // a delay of around 1ms would usually go here, but the glow is not as bright with a delay
    disable row
  }
}

This should give me a full column showing for every "1" bit I shift. The data I am shifting is "1" followed by 30 "0" (1000000000000000000000000000000) As the display is 30 LEDs wide the "1" should overflow and there should be nothing in the columns when the row is driven.

What colour are the LEDs?

It doesn't take much current for modern efficient LEDs to glow dimly. Especially the blue, green and cool white colours, both because the eye is more sensitive to that end of the spectrum, at low light levels and the forward voltage is higher than the loner wavelength LEDs so you get more power for the same current.

Try putting a 10k to 1M resistor in parallel with the LEDs to reduce the voltage below the LEDs' turn on voltage.

The LEDs are red, so complete other end of the spectrum, but as you say they glow at almost no current. I have tried a 1M resistor from the row (positive) to ground, and this fixes the problem but I'd still like to know why it's happening.

I have done some testing and the brightness I see is similar to the LED being powered by around 10ua continuously. The forward voltage is around 1.7 volts for this LED.

[BrianHG]

The rows are currently connected via the UDN2580A to the Arduino, I'm not using any decoder at the moment. The program I have currently works like this:

loop forever {

  wait 1 ms
  shift data into columns >>>inside here, at every bit & clock step>>>    disable all rows again and again.... <<<<<<<<<<<<<<
  wait 1ms
  loop rows {
    enable row
    // a delay of around 1ms would usually go here, but the glow is not as bright with a delay
    disable row
  }
}

This should give me a full column showing for every "1" bit I shift. The data I am shifting is "1" followed by 30 "0" (1000000000000000000000000000000) As the display is 30 LEDs wide the "1" should overflow and there should be nothing in the columns when the row is driven.

Try adding the command where I recommend just to see if anything changed...
Now, I know it shouldn't make a difference, but, something fishy is going on during your serial shift.  Is it possible during that time somehow a row pin is being triggered?
This is why when you add a delay in-between the enable row and disable row, the intensity of the glowing column dims since at this point the columns have guaranteed correct data & the time during the shift is a lower % of the time when the display is being erroneously turned on.

If this alters the brightness of the glow, then, you need to discover why one of your row pins is activating when clocking data out, otherwise you might have a short between that row 0 and you data or clock pin on the PCB itself.

[MK14]

I was originally using an ATtiny with a 74LS145to drive the rows, but switched to an Arduino in an effort to simplify everything as much as possible to find the problem, and am now powering it with 5 volts. The code I am using is here: https://gist.github.com/ElectronicsIdiot/3ef9cdecffb68426b64e3a87c9f0becc.

I don't have schematics or anything other than a rough idea of how things are connected.

The board:

The glowing LEDs are brighter towards the row that is pulsed first (bottom). If I reverse the row loop, the LEDs glow brighter at the top as the top row is now pulsed first:

The row that is pulsed first also seems to glow slightly, which I hadn't noticed before.

Thanks for all the extra information for everyone. I've looked through it and understand things better now. But can't put my finger on exactly what is wrong.

Ideally, if you have a decent Oscilloscope (I understand you don't have access to one, but are using some kind of utility program which does something like that), connect it up to an incorrectly glowing LED and see what it is being driven with. Then you can hopefully get clues as to what is going on. You could also look at the clocks and other things at the same time, to help diagnose what is wrong.

Another possible diagnostic experiment is to send all logic zeros (i.e. off) to all the rows, and all logic ones (i.e. on) to all columns, and check that all LEDs are off.

Similarly do the complete opposite, i.e. all rows on and all columns off, and again check that all the LEDs appear off.

N.B. I may have given you the wrong logic polarities. But I hope you can understand what I mean.

tl;dr
Turn on (active) all columns (but one at a time would probably do), but disable all rows.
Secondly, turn on (active) all rows (but one at a time would probably do), but disable all columns.

What is puzzling me
The LEDs would need two "faults" in order to glow when they are suppose to be off. I.e. both pins of the LED should NOT be seeing any connection to a voltage (current), so even if one side of the LED should be connected to a voltage, the other lead, should still be floating, so no current should flow and hence the LED should still NOT light up.