Go Down

Topic: What will happen if I drive LEDs in parallel from a TLC5947? (Read 6361 times)previous topic - next topic

scswift

http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=tlc5947&fileType=pdf

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?

fungus

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

Yes.

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.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

John_Smith

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....
45 years of editing projects with a knife and soldering iron, then I found Arduino !

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.
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.

fungus

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.

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

scswift

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.

Grumpy_Mike

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.

scswift

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

fungus

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

He's got you there, Mike...

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

dc42

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.
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.

scswift

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.)

scswift

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.

Grumpy_Mike

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.

Quote
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.

scswift

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.

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.

Quote
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?

Grumpy_Mike

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Go Up