What will happen if I drive LEDs in parallel from a TLC5947?

The TLC5947 is a constant current driver. I'm just wondering, if I decided to run two LEDs in parallel, and I tell it to output 20mA, I assume it would divide that 20mA between the LEDs... But assuming the voltage drop of the two LEDs isn't identical, what would happen? Would one LED be dimmer than the other as I suspect, with the other drawing a larger share of the current?

And come to think of it... If I were to try to measure the voltage drop across the LEDs, what would I read, with the anodes and cathodes connected like that? Would it be the average of the two voltage drops? Or the smaller of the two?

scswift:
Would one LED be dimmer than the other as I suspect, with the other drawing a larger share of the current?

Yes.

scswift:
And come to think of it... If I were to try to measure the voltage drop across the LEDs, what would I read, with the anodes and cathodes connected like that? Would it be the average of the two voltage drops? Or the smaller of the two?

The voltage drop across both LEDs will be the same, only the amps will be different.

If you measured the voltage accross two LEDs in parallel, your meter probes would be connected to the same points, so one voltage.

You are right that the LED with the lowest forward voltage (Vf) would take the most current, and be brighter.

You could use resistors in series with each LED, of a lower value than if you were not using a constant current driver, but not having resistors is one of the advantages of that type of driver....

If the two LEDs are exactly the same type, then you may find that they share the current quite well. I once took apart a toy light sabre, and it had 16 green LEDs connected in parallel, with no resistors to balance the current. Amazingly, the brightness was fairly uniform across all the LEDs.

dc42:
If the two LEDs are exactly the same type, then you may find that they share the current quite well. I once took apart a toy light sabre, and it had 16 green LEDs connected in parallel, with no resistors to balance the current. Amazingly, the brightness was fairly uniform across all the LEDs.

They might have been sorted/binned at the factory.

I'm sure I've seen LED datasheets that mention you can order them in matched batches.

Given that these LEDs are super bright and 50% current looks like 75% brightness, I'm not too worried if there are small differences in the brightness. In this instance it doesn't matter if they're super uniform.

You are or should be worried if one LED is taking more current than it is rated for. Without a seprate resistor for each LED, worst case, one LED takes twice the design current.

These LEDs are attached to a constant current driver. So there's no worries about that happening.

scswift:
These LEDs are attached to a constant current driver. So there's no worries about that happening.

He's got you there, Mike...

If you are using the TLC5947 to drive a lot of LEDs, then you need to take the power dissipation of the chip into account. For each channel, it is the voltage at the output pin (which is the supply voltage less the LED forward voltage) times the output current. Then multiply by the number of channels you are using.

You may find that you need to reduce the voltage at the output pin to keep the power dissipation within limits. One way of doing this is to use series resistors - which gives you the opportunity to use the same series resistors for balancing the current between the LEDs.

I did take the power dissipation into account. I have used an appropriate resistor on the Iref pin to limit the chips to 20mA per channel, which I calculated to be below what they could handle with all outputs on. I also followed TI's recommendations closely for the thermal vias. They only get slightly warm and I have been testing them for the last two months and have never had any of them go into thermal shutdown.

I used these chips and set them up this way so that the boards would be idiot proof. They're designed for people who don't know anything about electronics to play with, so I wanted them to be able to just plug in any old LED and have it just work. I also did not want them to have to solder resistors onto the LEDs. (Nor did I want to have to do that myself when assembing kits.)

Btw, if you're interested in the project I'm using these chips in, you can check that out here:
http://arduino.cc/forum/index.php/topic,139819.0.html

There are a couple minor issues with the LED modules I designed. I should have put a 10K resistor on them to pull down the enable pin so they don't flash when you apply power. And there is some kind of reflection issue in the data lines when I have more than six modules in series, where the LEDs on the last few modules will be messed up. It isn't a serious problem since six modules is a whole lot of LEDs, but I'd like to fix that eventually. I assume I need to put some resistors or caps on the data lines to solve that issue, though I haven't really had time to research possible solutions.

fungus:

scswift:
These LEDs are attached to a constant current driver. So there's no worries about that happening.

He's got you there, Mike...

Well only because he is running the LEDs at less than half the rated current so there is little point in having two anyway. The fact remains putting two LEDs in parallel is just plane stupid design.

And there is some kind of reflection issue in the data lines when I have more than six modules in series, where the LEDs on the last few modules will be messed up.

Yes signal integrity problems are common with this chip as people tend to think you can string them together without considering the signals. You might be lucky but just R & Cs do not normally fix things. You need proper layout and proper buffering to the signal lines.

Grumpy_Mike:
Well only because he is running the LEDs at less than half the rated current so there is little point in having two anyway. The fact remains putting two LEDs in parallel is just plane stupid design.

Spoken like a true engineer. :slight_smile:

It may not be efficient to put two LEDs in parallel attached to a constant current source only capable of sourcing 20mA, but the consideration here is for aesthetics, not efficiency.

And there is some kind of reflection issue in the data lines when I have more than six modules in series, where the LEDs on the last few modules will be messed up.

Yes signal integrity problems are common with this chip as people tend to think you can string them together without considering the signals. You might be lucky but just R & Cs do not normally fix things. You need proper layout and proper buffering to the signal lines.[/quote]

I don't understand. What do you mean by proper buffering and layout? TI's datasheets make no mention of any special layout other than keeping the capacitors near the pins, and properly heat sinking, nor do they mention any need for buffering.

Also, I'm not familiar with buffering, but if by that you mean put another chip on the line, that seems like it would be way too expensive, and I don't understand why it would be necessary. If the signal successfully reached one of the modules, and the LED driver picked it up, and passed it along to the next one, why would I need to worry about signal degradation? Shouldn't each chip emit a new clean signal?

Actually though, now that I think about it, while each chip does output data to the next, the clock signal used for that data isn't passed along in that manner. That's just on its own separate clock line. So maybe the data is reaching the end of my chain just fine, but the clock signal is no longer in sync with it, or reflected signals are messing it up?

Assuming adding buffering is too expensive, what would I do if I just wanted to try to reduce reflected signals in the clock line to try to extend its reach from 6 modules to 10?

It may not be efficient to put two LEDs in parallel attached to a constant current source only capable of sourcing 20mA, but the consideration here is for aesthetics, not efficiency.

The point is that by putting two LEDs in parallel you have no control over the current in either LED. Now you might be happy with having no control over what happens in your circuits, but it is not the way to design anything.

TI's datasheets make no mention of any special layout

Remember a chip's data sheet is designed for grown up engineers, not a kindergarten class. If a data sheet were to go into all the stupid things you should not do with it then it would be far too long.

Also, I'm not familiar with buffering, but if by that you mean put another chip on the line, that seems like it would be way too expensive,

Do you want it to work or not?
You need buffering on the signals that go to all the chips when the driver can not cope with that number of inputs. Normally I would recommend one buffer to drive 4 chips. The buffer's inputs can be common.
Layout should be tight and short to increase signal integrate and reduce pickup and radiation.

Assuming adding buffering is too expensive,

Buffers are one of the cheapest ICs you can get. You get 6 buffers in one package for less than $0.20.

Grumpy_Mike:

Also, I'm not familiar with buffering, but if by that you mean put another chip on the line, that seems like it would be way too expensive,

Do you want it to work or not?

Given a choice of being able to afford to have my PCBs manufactured and only being able to connect 6 LED modules, or making the PCBs so expensive to manufacture that I can't afford to manufacture them but allowing them to run 10 modules in theory, I'd chose "not".

I literally spent every last dime I had getting these boards made Grumpy. If I had had to spend another $500 on another chip, I would have had to have had fewer boards made, and I would not have had any spares to sell, and I would not be sitting here asking you how to improve the boards when I do a second run, because I wouldn't be able to afford to do a second run.

In fact, whether I will be able to do a second run is still up in the air. I have 35 kits I need to sell in less than a month to get there, and I only sold 6 this week.

You need buffering on the signals that go to all the chips when the driver can not cope with that number of inputs. Normally I would recommend one buffer to drive 4 chips. The buffer's inputs can be common.

Well the "driver" here is the Atmega1284P I have on my board. It drives 6 of those chips without a problem.

Layout should be tight and short to increase signal integrate and reduce pickup and radiation.

There's my boards. I made the LED driver boards as small as I could, and the traces as short as I could. Of course there is nothing I can do about the longish ribbon cables I need between the boards. The whole point is to be able to install them in various locations around a prop.

Buffers are one of the cheapest ICs you can get. You get 6 buffers in one package for less than $0.20.

Okay, well I had 440 of these LED driver boards made. So that's another $88 in parts, plus the additional assembly cost, plus the cost for any capacitors needed, plus the cost associated with having to make the PCBs larger and fitting fewer on each panel. Probably looking at around $100 more. Which may not seem like much, but I was treading on a razor's edge with my budget for this, since the project ran three months past when it was supposed to and I missed my prime sales season.

Also, I was kinda limited for space on the LED modules. They gotta fit in the props they'll be used in. Honestly, if the price I have to pay for not including he chip is only being able to run 6 modules at once, that's better than the alternative of not having the boards fit where they need to go.

But I'll definitely look into the buffers when I do redesign the modules. Needing more than 6 modules in a single prop however is extremely rare.

One of these buffers http://uk.farnell.com/texas-instruments/sn74lvc1g125dbvr/ic-buffer-gate-bus-smd-sot-23-5/dp/1470768 would take up very little space on your board.

dc42:
One of these buffers http://uk.farnell.com/texas-instruments/sn74lvc1g125dbvr/ic-buffer-gate-bus-smd-sot-23-5/dp/1470768 would take up very little space on your board.

Well I guess the question then is, is it just my clock line which needs buffering here? I would assume the led modules themselves are acting as buffers for the data line since it passes through them. Would that be correct?

I do also have lines for chip select and blank but I suspect those aren't as susceptible to whatever issue is plaguing the clock line.

It's almost certainly the clock line causing the problem. As you say, the LED driver chips themselves buffer the data. Ideally you would buffer CS and blank as well, however ringing or slow rise/fall times on those lines are unlikely to cause anything like the same scale of problems. If you did want to buffer those as well, you can get quad buffers such as http://uk.farnell.com/texas-instruments/sn74ahc126pw/logic-bus-buffer-tri-st-qd-14tssop/dp/1740922.