RGB LED Driver Design, High Frequency/Resolution PWM - PCB Review

[amaschas]

Hey all, over the past few years I've been working on a design for an RGB LED driver board that can drive an array of RGB emitters. I've been asking design questions about this application for a few months now, and received some very helpful feedback. I'm several board revisions in, and I've reached the point where I think it would be helpful to open up my design to wider scrutiny to determine if the choices I have made are going to support my goals. The goals of this project were to build an LED panel that would accomplish the following:

1) Emit red, green and blue light at very specific wavelengths.
2) Cover an area of roughly 100mm x 100mm (the largest board you can make at JLCPCB without paying an extra fee, can illuminate a 120 negative).
3) Allow me to evenly mix the colors and create an even, bright field of light.
4) Control the brightness of the emitters with high precision (1024 bit PWM resolution).
5) Control the brightness of the emitters with high frequency PWM (>20khz) to avoid flicker and banding effects arising from camera shutters.

This board will be manufactured and 90% assembled by JLCPCB. After revision 3 I started getting lazy and having them solder everything SMD since it's so cheap.

The purpose of this light is pretty niche. I'm basically building a densitometry instrument for color negative film (hence the precise wavelengths of light). I basically want to use the light to sample the dye layers in the film at wavelengths defined by a standard known as status M, which was designed specifically for color negative film. The goal here is to re-create the functionality of professional film scanners with this custom light and a digital camera.

The trickiest part about this was finding an LED driving topology that could support the high PWM frequencies I wanted to achieve. After some research, I settled on an approach that TI had documented and labeled "shunt-FET LED dimming", in which the output of the LED power in a constant-current switching driver was shunted to ground through a mosfet during the PWM on period. TI helpfully provided a design for a high resolution, high PWM frequency RGBW light based on the LM3409: https://www.ti.com/tool/TIDA-01415, which I've used as a rough basis for my own design. I've changed the form factor of the board quite a bit, swapped in an ESP32 for the C2000 Piccolo Launchpad, killed the DAC and the DMX interface and added a set of rotary encoders to control the emitter colors as well as an i2c interface to support a OLED display.

I'm using a pretty standard 4-layer stackup for the board: signal - ground - power - signal. In my last few revisions I had full ground pours on both the top and bottom signal layer, but as a result of some feedback I received here and after further investigating the TI design, I decided to kill the full ground pours (except for the ground layer of course) and just add ground pour areas where necessary. I also realized that I had ended up badly splitting up my grounds on earlier designs, and adding discrete pours let me think more carefully about where my grounds where and how to keep them unbroken. I have noted that the TI design has a split ground on the ground layer, which from what I've read is possibly not the greatest idea? I'm curious about thought on this. It seems like the LED drivers have their own ground pour. I'm wondering if they do this because the presence of the DAC on the board introduces more stringent noise requirements?

I did borrow one particular approach from the TI design that I'm not quite sure about: the gaurd traces on the PWM lines. My sense is that these mostly function to ensure that no other signal traces can get close enough to the PWM lines to couple, but that they also potentially reduce the loop area? I know that return currents are going to travel under the signal trace, though the traces in question unavoidable cross some power planes, so maybe they will help in those cases? From what I've read this strategy meets with mixed success, but I'm curious to test it out here, particularly because I was forced to change planes with these PWM lines in order to route them. Most of the other signals on the boards are slow, so I'm not that worried about them. I've definitely encountered some EMI issues with these PWM lines, and while they are only 30khz signals, the rise and fall times on the pulses are in the single ns range to allow for 10-bit PWM resolution. I'm also thinking of introducing a minimum brightness limit so that I can still have the target resolution over most of the range, but slow down the pulse rise and fall times.

In past versions, I had built an array of individua color LEDS, but this introduced really difficult color mixing problems. As a result, I inquired with a chinese company that manufactuers custom LED emitters and they were able to provide me with a decent number of custom emitters for a reasonable price. I ended up paying ~$120 for 500 emitters shipped, and the color mixing of the output light is much improved. I am still encountering an odd vignetting effect, which I think is related to the brightness of the light, so I want to test out brighter emitters in the next version. The emitters themselves are essentially three rows of 8 LED emitters in parallel. In order to address the problems of driving LEDs in parallel, I've chosen to implement this board on an aluminum substrate, which will help to spread the heat and prevent the associated over-current problems.

The design of the driver board looks a bit lopsided at this stage. The layout is constrained by the intended board size (I want the driver board to fit on top of the emitter board), and the position of the elements that need to interface with the case, like the rotary encoders and input jack. Not sure there's  much I can do about that.

At this stage I am mostly focussed on controlling some issues that I believe were caused by EMI in my previous revision. Specifically, the green and blue emitters (most noticeably the green) would start to visibly flicker at intermediate PWM duty cycles (40-65%), which didn't make a lot of sense. From what I could see on my oscilloscope, I think there was some sort of noise issue on the switching node. I had some bad ground loops, particularly on the driver power inputs, so I'm hoping that by eliminating those and improving the grounding situation generally I can solve the issue.

I'm hoping for some feedback on my design, though I'm happy to answer any questions about the application, and I hope that my process can hopefully serve as a resource for anyone going down the same path. At this stage I'm specifically concerned with EMI coming from the PWM lines, the switching node of the controller and the LED power lines, so any pointers for how I can improve my approach in these areas would be super helpful. Some things I'm thinking about:

Is it OK for the emitters to share a common ground?
Should the LED drivers have a split ground from the rest of the board?
Was removing the ground pours from the signal layers a good choice?

Here's the full layout of the driver board:

Here's the layout with the signal layer highlighted:

And with the power layer highlighted:

Here's the emitter schematics:

The emitter board layout:

And an image of the partially assembled project:

I've added the full board schematic as a PDF attachment.

[mariush]

I'm not gonna go in detail in the actual led drivers, just on a surface, brief look at the pictures.

Any particular reason why the ESP32 has to be in that corner so far away from the knobs, making you to have those traces travel across the whole pcb? 

I would move what seems to be the 3.3v regulator either towards the top near the rotary encoders or closer to the dc in jack and move the esp more towards the middle of the right side of the board. If that's a surface mounted electrolytic capacitor, change that, from experience they're not reliable, use either through hole or solid/polymer capacitors.

Your schematic has 0 ohm resistors for the status leds for the two voltage regulators you probably wanted that to disable or enable the status led , but it still needs some current limiting resistor or you'd damage that led.

The led drivers seem unnecessarily close together
If you move the DC in jack a bit to the right, you could have the on/off switch on the left side and the protection circuit right above the dc in jack, and have your power closer to the center of the board from where the three drivers could take the power .... and driver layout should be about the same for all three - and I'd even consider a layout that would allow covering the three ICs with a small heatsink through which air from the fan would blow and keep the drivers colder. most heat would go in the pcb but still.

no idea why you'd put the fan header in that corner ... it could just as easily be behind the rotary encoders, maybe in that corner near the right most encoder in the picture.

I'd work a bit on routing those two traces on the top right corner of the esp section so they don't need to use vias.

Speaking of rotary encoders, you could have simplified the design a bit by using resistor networks instead of 7 separate 10k resistors but resistor networks are more expensive and you have the space.

Would the light from the leds potentially reflect off the connector and bounce back causing issues?  Thinking maybe it would be worth using a much flatter connector and possibly use thinner wires (but maybe 2 for each r,g,b, and ground) for that reason.
Planning on having some filter / layers over the leds to make the light more uniform, so the brightness won't be less in the area between the leds?

[amaschas]

Any particular reason why the ESP32 has to be in that corner so far away from the knobs, making you to have those traces travel across the whole pcb?

Unfortunately yes. Espressif publishes guidelines for the placement of ESP32 modules on boards, and they basically that is the recommended spot for it. I believe it is intended to both maximize reception for the antenna and reduce any problems from emissions to a minimum.

I would move what seems to be the 3.3v regulator either towards the top near the rotary encoders or closer to the dc in jack and move the esp more towards the middle of the right side of the board. If that's a surface mounted electrolytic capacitor, change that, from experience they're not reliable, use either through hole or solid/polymer capacitors.

Yeah I kind of wondered about that. I pulled the design for those regulators from the TI webench app, and they were using electrolytic for pretty much any design I tried with that IC. In the case of the 3.3v regulator it's a pretty large amount of capacitance, so maybe it's a cost thing?

Your schematic has 0 ohm resistors for the status leds for the two voltage regulators you probably wanted that to disable or enable the status led , but it still needs some current limiting resistor or you'd damage that led.

Those are just placeholders for now. I'm making some choices the emitter I want to use there, and I may just pull them off the board entirely, but the proper resistor will be in place when the board is manufactured.

The led drivers seem unnecessarily close together
If you move the DC in jack a bit to the right, you could have the on/off switch on the left side and the protection circuit right above the dc in jack, and have your power closer to the center of the board from where the three drivers could take the power .... and driver layout should be about the same for all three - and I'd even consider a layout that would allow covering the three ICs with a small heatsink through which air from the fan would blow and keep the drivers colder. most heat would go in the pcb but still.

Yeah, I could spread the out a bit, you're probably right about that. The driver ICs don't actually get that hot with the loads I'm using, so I'm not super worried about cooling them, (they max out at ~35C). The fan is there more to help cool the emitter board.

no idea why you'd put the fan header in that corner ... it could just as easily be behind the rotary encoders, maybe in that corner near the right most encoder in the picture.

Basically I wanted to avoid splitting my power planes with the 12v trace. I couldn't find another place to put it which didn't involve running a 12v trace through the 30v power plane in a way that would avoid having a trace between the 30V source and one of the ICs that need it. If I made a list of devices ranked by criticality of power delivery on the board, I think I'd put the fan dead last, so I figured it could hang out in the corner. Is there a technical reason it shouldn't go there? I was a little worried about hanging it off the end of the trace that delivered 12v to the red LED shunt-FET driver.

I'd work a bit on routing those two traces on the top right corner of the esp section so they don't need to use vias.

Do you mean the two rotary encoder lines that run along the right side of the board? I was trying to avoid splitting the ground pour for the ESP32. Couldn't really find a way to route those without doing that. I generally figured that I didn't have to worry about the signals for the rotary encoders, since the rise and fall times were on the order of 0.5-1ms and there's not much they can interfere with where they're placed. Do you think those vias will cause problems?

Speaking of rotary encoders, you could have simplified the design a bit by using resistor networks instead of 7 separate 10k resistors but resistor networks are more expensive and you have the space.

I actually had a resistor network in there originally, but as you guessed I pulled it to cut down on the cost. The way JLCPCB prices 10k resistors I can literally cover the surface of the board with them for less than a dollar.

Would the light from the leds potentially reflect off the connector and bounce back causing issues?  Thinking maybe it would be worth using a much flatter connector and possibly use thinner wires (but maybe 2 for each r,g,b, and ground) for that reason.
Planning on having some filter / layers over the leds to make the light more uniform, so the brightness won't be less in the area between the leds?

You can't see the top part of the case from the photo I uploaded, but here's an image to give you an idea:

When the case is pressed tight together (which it isn't in that photo because I'm in the midst of testing some stuff), there is only a tiny sliver of space between the reflector portion of the case and the emitter board. In my testing so far, I've been able to get a really even field of light with only a simple piece of semi-opaque white plastic. I have some LED backlight material I recycled out of some old tablets for comparison, and there's no observable difference. You definitely can't see the individual emitters in photos of the device, though there is a strange vignette effect (the light appears darker around the edges), which isn't actually caused by the emitters, but appears to be an optical effect that I don't quite understand. I have a feeling it might have more to do with the lens I'm using than the device, since my testing indicates that the strength of the vignette varies with the brightness of the light output. Regardless, further testing is required.

I think in the final version I'll definitely use a thinner connector, potential a ribbon cable. I'm just using JST-XH connectors everywhere because I have a bunch of them.

Thanks for taking a look at the design, appreciate the feedback!

[amaschas]

Gave some thought to mariush's comments and decided to incorporate some of their suggested changes. The driver board layouts have been updated. Still couldn't really figure out a great place to stick the fan connector. I gave some thought to the tradeoff of avoiding vias for some of the rotary encoder lines vs. splitting ground pours and decided to stick with the vias. My sense is that rotary encoders aren't a particularly fast signal even in the intervals when they are sending pulses, so I'm not too worried about where those traces end up.

I also looked into why the webench designs for the TPS5430 were all using electrolytic caps, and it turns out that the datasheet indicates that there is a _minimum_ ESR for output capacitors which would rule out ceramic caps, and pretty much requires the use of electrolytics.