LED controller

C

charleskerr

New elf
Joined
May 28, 2011
Messages
37
Last year we had some RBG balls in the mega tree, which we controlled with DC controllers. We noticed, that most DC controllers where overkill, they are designed to handle way more current then we needed (each ball was made of about 5 to 8 5050's. Each tree had 8 balls in it.


So, we thought we would make a small dc controller to handle a "trees" worth of RGB balls (a total of 24 channels). Thought we would share the schematic for any feedback or comments. The two 485 inputs are unique to our SSD protocol, so that may seem unusually for some.


NOTE: We have taken in the input from others and put the updated schematic on our site. We didn't want an incorrect schematic to stay up in case it causes confusion. Again, thanks for all the feedback.
 
Some quick observations:

FETs are backwards - source should go to 0V and drain should go to load.

No series resistors in FET gates

Power input capacitor missing

3.3V rail capacitor could be too large for regulator stability

3.3V regulator may overheat dropping 8.7V @ ?? mA
 
David_AVD,


Thanks for the feedback on our DC Controller. I must confess that I'm the guilty party regarding our schematic and I screwed up a number of items. You're right I did put the FETs in backwards. Again, thanks for the catch.


Second, when I transferred my sketch to the drawing I put the power input capacitor on the output and left off the output capacitor. Again, good catch.


However, I'm not sure that I have problems in the other area you mentioned. Consequently, I would like to explore those a bit more with you to see if my understanding is lacking.


Regarding your voltage regulator observation, the component that I called out is a high efficiency switching regulator. It's made by INNOLINE and they call it a DC/DC Converter. I selected this item specifically to address the thermal issues associated with dropping the 8.7V that you identified. I don't have any experience with this component but they claim the efficiency is so high that it does not require a heatsink. Any experience or comments on this component?


Regarding the series resistors in the FET gates, I have placed a 10K resistor between the Iref pin and ground on the TLC5947 chip. This resistor is sized to limit the current on each of the output pins of the TLC5947 to 5 ma or less. Given this, I was thinking that I would not need series resistors for the FET gates. Again, any thoughts?


Thanks again for your comments. You saved me from wasting a lot of time building up a prototype board with the FETs in backwards.
 
Robert Waller said:
Regarding your voltage regulator observation, the component that I called out is a high efficiency switching regulator.
Click to expand...

In that case, ignore the warning about the power dissipation. It would still be wise to check if there are min/max specs for the capacitance on the regulator input and output.

Robert Waller said:
Regarding the series resistors in the FET gates, I have placed a 10K resistor between the Iref pin and ground on the TLC5947 chip. This resistor is sized to limit the current on each of the output pins of the TLC5947 to 5 ma or less. Given this, I was thinking that I would not need series resistors for the FET gates. Again, any thoughts?
Click to expand...

The gate series resistors are there to reduce the ringing in the FETs due to the PWM on the gates. Typical values for something like this are in the 47R to 100R range. Too low and the ringing is not reduced. Too high and the FET switching is too slow causing heat rise.
 
I'd also tie the (unused) transmit pin of the 485 chips to either Vss or Vdd.

The 470R pull down resistors could also be higher in value (4K7 ?) without issue. That will reduce the current draw a little.
 
ChillOutDocDoc said:
David, I've read a lot about low frequency switching being able to get away without a gate resistor, thoughts on this?
Click to expand...

It all depends on the PWM rate. Best way to know is by checking (with an oscilloscope) the FET output when it's running. The ringing can also vary with load.
 
charleskerr said:
The two 485 inputs are unique to our SSD protocol, so that may seem unusually for some.
Click to expand...

Just curious, I know NOTHING about pics/firmware/protocols..etc, just wondering for my little brain, with your protocol why are two inputs required? are you sending twice the info as normal? I am amazed how clean and simple the board looks.
 
I got bitten badly on the backside by leaving out the gate resistor on a circuit. The circuit worked beautifully up until the load hit 20 amps and then weird stuff was happening. I was convinced it was the program as I'd had a number of issues and I was certain that it had to be the current sensing circuitry and the relevant bit of program. Several days of debugging later with an oscilloscope and going step by step in the program it ended up being the mosfet gate doing something strange. I could never electrically isolate the problem because as soon as my oscilloscope touched the pcb the problem would disappear. After chatting with David_AVD in chat i stuck in a gate resistor and the problem disappeared. Even though this mosfet was a logic level 1 I now make it practice to have 1 on each circuit. The cost and size of the resistors compared to my sanity and my remaining hair is incomparable.
I haven't looked at specs on that pic but does is have a nice stable internal oscillator?
You may want to think about a fuse on the pcb too as it can save you blowing tracks or a mosfet.
I have a personal preference of putting a 0.1u cap on every chip just to keep the supplies nice and stable. With lots of high frequency switching and the capacative loads of the mosfets this can be important.

Nice work by the way Charles. Look forward to seeing some pictures when it's up and running.
 
David_AVD,

Again, thanks for the feedback.

It would still be wise to check if there are min/max specs for the capacitance on the regulator input and output.
Click to expand...


The data sheet suggests using a 100 uf on the output to reduce ripple but there are no stated requirements. I will check things as we go.

The gate series resistors are there to reduce the ringing in the FETs due to the PWM on the gates. Typical values for something like this are in the 47R to 100R range. Too low and the ringing is not reduced. Too high and the FET switching is too slow causing heat rise.
Click to expand...


I'll put a scope on it and see what the ringing looks like. I did not know this would be an issue, so thanks again. I will definitely add gate resistors and check the results with the scope. Just about everything is surface mount and I'm using 0603 so I have plenty of room for these.

I'd also tie the (unused) transmit pin of the 485 chips to either Vss or Vdd.
Click to expand...


Will do.

The 470R pull down resistors could also be higher in value (4K7 ?) without issue. That will reduce the current draw a little.
Click to expand...


We're already down to 7 ma at those pins but < 1 ma won't hurt either so I'll make those changes as well.
 
It all depends on the PWM rate. Best way to know is by checking (with an oscilloscope) the FET output when it's running. The ringing can also vary with load.
Click to expand...


We will be using the TLC5947 in 12-bit mode and we will use the built in 4Mz clock so the PWM rate at the output pins / gate has to be less than 1KHz. This doesn't factor into the equation but we're also using logic level FETs that are only rated at 220 ma max. We only need about 80 - 100 ma to drive our RGB elements.
 
Just curious, I know NOTHING about pics/firmware/protocols..etc, just wondering for my little brain, with your protocol why are two inputs required? are you sending twice the info as normal?
Click to expand...


[font=tahoma, sans-serif]You got the answer. We are using two pair of twisted wire to pass the data to the controller. The first have of the channels is on the first pair and the second half is on the second pair. The firmware on the PIC reads data from both pair of wires and pulls the channels that it needs. We are currently running 3036 channels but we're looking to get to 4096 channels with the next PIC that has 16K of RAM. With our design the controller doesn't care which pair of wires it's channels are on since it reads them both. It doesn't know or care if the channels happen to be split across the two pairs of wires. We were trying to avoid the 512 channel boundaries at the controller with this protocol.[/font]

[font=tahoma, sans-serif]When the dongle and controller are jumpered to run DMX, we deliver two universes of data to the controller. [/font]
 
AAH,

[font=tahoma, sans-serif]You guys have convinced me. I will definitely put on the gate resistors. I just need to determine the correct value. Besides, they are about a penny each in the 0603 format.[/font]

I haven't looked at specs on that pic but does is have a nice stable internal oscillator?
Click to expand...


We have been getting very stable outputs but that's been using a logic analyzer and not a scope to view the data stream to the TLC chips. Since the TLC5947 has an internal oscillator and has a built in auto display repeat function, the stability of the pic oscillator is not as important as it is when you have to generator the GSCLK for the other TLC chips.

You may want to think about a fuse on the pcb too as it can save you blowing tracks or a mosfet.
Click to expand...


Another great catch. I have the fuse and pcb fuse holders in my parts list and forgot to put them on the schematic.

I have a personal preference of putting a 0.1u cap on every chip just to keep the supplies nice and stable. With lots of high frequency switching and the capacative loads of the mosfets this can be important.
Click to expand...


I don't fully understand this comment. Are you suggesting that we include .1 uf caps on all chips between Vcc and Gnd or are you suggesting they need to go on the pins? I think I already have all the required caps needed to support the PIC. Can you elaborate a bit more on this point?
 
As far as installing 0.1's I put them as close as possible to each chip so that track length, capacitance, inductance and resistance have a lesser effect on the supplies. I personally go through my pcbs and the last thing I do is fatten up the supply traces as much as possible and also put a via or 2 though between layers to reduce the length of traces.
It wasn't the pic-> tlc frequency stability that i was concerned about. It was the possibility of losing the dmx signal if there was too much drift.
 
You must log in or register to reply here.
Back
Top