Author Topic: RGB LED Driver Design  (Read 1295 times)

0 Members and 1 Guest are viewing this topic.

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
RGB LED Driver Design
« on: May 17, 2020, 03:20:02 am »
Hey all, over the last few months I've been working on an RGB LED light for scanning film with a DSLR. The basic idea is that I'm trying to mimic the approach used by high-end film scanners, which use red, green and blue light of specific wavelengths to measure the density of the individual film layers. The requirements for the light source are:

• Specific wavelengths of light, specifically 460nm blue and 660nm red which means I can't use combined RGB LED modules
• PWM dimming, because altering the driving current would change the emitted color wavelength
• 10-bit PWM, because I want fine adjustment of the colors relative to each other
• high frequency PWM to prevent flickering at high shutter speeds
• 24V input for ease of designing/source a power supply

I'm currently designing the board that will contain the driver circuits, and I had a few questions I'm hoping someone here can help me out with. I've chosen to drive my light with 3x TI TPS92515, which are designed for high frequency PWM via shunt-FET dimming. I've taken apart and analyzed several lights designed for photography and video, and they seem to all target 30khz as a PWM frequency, so I've decided to shoot for that frequency as well. It's well above the fastest shutter speed, and also above the frequencies that would emit an audible whine from the PWM circuitry.

I've chosen FDD6296 as my shunt FET (the LED current will be shunted through the FET during the "off" periods) because it features a combined on/off time that is less than the minimim pulse width for 10-bit, 30khz PWM.

The PWM signals will come from an ESP32 that will also function as the MCU for user interaction. I've chosen an ESP32 because I've read that I can use the WiFi and Bluetooth features without requring additional FCC certification as an intentional emitter, so if I decide to make a commercial product down the line I would only have to worry about the driver and PWM signals.

The LEDs I'm using will be from the Luxeon 2836 color line. I plan to run them at a maximum of 120mV, with 8 in series. The highest voltage LEDs have a voltage drop of ~3V, so they should draw near the target amperage at 24V. I will be running 3 parallel rows of each color, so each color will draw 360mA total. The overall power requirements for the light should be 1.08A at 24V = ~26W.

I'm particularly concerned about thermal issues on my driver board, so I've tried to give the components that will be subject to higher current some copper pour and thermal vias to dissipate heat. I've focussed on the inductors, shunt-FETs, driver chip and input filter circuitry.

I've based my board on a few reference designs that TI offers for this driver, though I've had to make modifications for the shunt-FET and to fit three drivers on the board. Some of the concerns I have with my design:

• VIN pin traces are on the thin side. On the reference board, there is a pour for the VIN area, but the actual connection to the VIN pin is still rather thin. As I understand it, the function of the VIN pin is to draw power for the chip and to feed the high side of a comparator that determine the output current. The datasheet notes:

"The device does not internally limit the maximum attainable average LED current. It does have a thermal limit based on the maximum junction temperature. The maximum junction temperature is a function of the system operating points (efficiency, ambient temperature, thermal management), component choices, and switching frequency."

So I'm not sure I actually need a thick trace to feed that pin.

• PWM traces are long. I was hoping to have all of my inputs on one side of the board, but my layout results in the PWM traves running the length of the board. I'm wondering if there's a reason to keep them short.

• My output voltage is equal to my input voltage in some cases. I'm trying to run the green LEDs at 120mA and 24V from a 24V power supply. I assume that I'll lose some voltage, and they'll actually end up running at a lower current/voltage. I'm not sure that's a problem, as long as the color wavelength doesn't shift too much.

• I'm using a single set of current comparison resistors (R5 & R6) for all three drivers. I figured I could get away with this since each color will be driven at the same current, but some of the drivers are further away from the resistors than others, and the datasheet does note that long traces can alter the resistance of the comparator circuit, and therefor the output current. I'm hoping the difference won't be significant.

• A friend of mine, who is fairly knowledgeable but not really an electrical engineer, suggested my entire approach was flawed and I should drive the LEDs with constant voltage instead of constant current since I'm using a power supply that already provides a regulated 24V. Every device I've analyzed has used a constant current driver, but I'm open to a constant voltage design since it would be significantly simpler.

I'd love to hear whatever feedback anyone might have regarding my design!

Schematic for the board (please ignore the component values for now, they are placeholders): http://ur.sine.com/temp/driver/schematic.pdf

Schematic for the LED grid, for reference: http://ur.sine.com/temp/driver/led-grid-schematic.pdf

Top side of the board: http://ur.sine.com/temp/driver/board-top.pdf

Top side of the board with pours filled: http://ur.sine.com/temp/driver/board-top-filled.pdf

Bottom of the board: http://ur.sine.com/temp/driver/board-bottom.pdf

Bottom side of the board with pours filled: http://ur.sine.com/temp/driver/board-bottom-filled.pdf

All layers: http://ur.sine.com/temp/driver/board-all-layers.pdf

Reference designs: https://www.ti.com/lit/ug/slvuar5/slvuar5.pdf?&ts=1589589788530 and https://www.ti.com/lit/ug/tiducq5/tiducq5.pdf?&ts=1589589866368

For the curious, an article I wrote about DSLR scanning with tri-color compositing: https://medium.com/@alexi.maschas/color-negative-film-color-spaces-786e1d9903a4

A more technical article about densitometric scanning: http://mjbcolor.com/ScanningMetric.pdf
« Last Edit: May 17, 2020, 03:19:12 pm by amaschas »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: RGB LED Driver Design
« Reply #1 on: May 17, 2020, 04:32:30 am »
I've taken apart and analyzed several lights designed for photography and video, and they seem to all target 30khz as a PWM frequency, so I've decided to shoot for that frequency as well. It's well above the fastest shutter speed, and also above the frequencies that would emit an audible whine from the PWM circuitry.
Right. Anyway plan shutter speeds not exceeding "flash sync speed". For most SLR's it is around 1/200s, check specs of yours. Otherwise you are risking to get (colored) horizontal banding. Also it is good idea to unalign phases for channels, using center-aligned PWM mode of MCU timer. The rest of your post - TL;DR. Way too much of unessential reading

Quote
I'm open to a constant voltage design since it would be significantly simpler.
Never. Extremely bad idea in application where you need as good color control and repeatability as possible. Voltage control will give you different color output depending on LED temperature. Specs of different color LEDs differ, they drift differently. I don't get why you even mention voltage control when TPS92515 is proper constant current LED driver anyway.
« Last Edit: May 17, 2020, 04:44:33 am by ogden »
 

Offline I wanted a rude username

  • Frequent Contributor
  • **
  • Posts: 662
  • Country: au
  • ... but this username is also acceptable.
Re: RGB LED Driver Design
« Reply #2 on: May 17, 2020, 05:28:12 am »
More related to the photography side.

  • What does the research literature say about the ideal spectral bandwidth of the lights required for each colour channel? I suspect am fairly sure that if you use narrow-band, almost monochromatic LED light (particularly the blue), your scans will have unnatural colours. Your best bet may actually be high-CRI white LEDs and a calibrated colour wheel.
  • Have you considered using the DLSR in bulb (B) mode? Open the shutter fully, illuminate, close the shutter fully. That would seem to promise maximum quality without incurring a significant overall speed penalty ... taking into account loading/unloading time, the need for the transport to bring the film to a perfect stop before taking the series of three photos, etc.
« Last Edit: May 17, 2020, 05:30:18 am by I wanted a rude username »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: RGB LED Driver Design
« Reply #3 on: May 17, 2020, 09:27:29 am »
Your best bet may actually be high-CRI white LEDs and a calibrated colour wheel.
What you say sounds plausible, yet we shall not ignore what OP said:  hi-end film scanners uses RGB LEDs. Other way would be white high-CRI LEDs + some RGB combined to get option of color calibration.

Quote
Have you considered using the DLSR in bulb (B) mode? Open the shutter fully, illuminate, close the shutter fully. That would seem to promise maximum quality without incurring a significant overall speed penalty
No need. This is exactly what happens at "flash sync speeds" - shutter is fully open for said time.
 

Offline I wanted a rude username

  • Frequent Contributor
  • **
  • Posts: 662
  • Country: au
  • ... but this username is also acceptable.
Re: RGB LED Driver Design
« Reply #4 on: May 17, 2020, 10:59:19 am »
at "flash sync speeds" - shutter is fully open for said time.

That should be fine as long as the brightness is sufficient. I thought you were referring to modern high-speed modes in which the flash pulses while a partially open shutter moves over the plane of the sensor. Now I see you were warning about exactly what I was concerned about.

Still not convinced you can perfectly separate out each of the film's layers without matching the wavelengths to the dye sets. And you can't even shoot calibration negatives because most films are no longer produced ...
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: RGB LED Driver Design
« Reply #5 on: May 17, 2020, 03:24:01 pm »
Quote
Never. Extremely bad idea in application where you need as good color control and repeatability as possible. Voltage control will give you different color output depending on LED temperature. Specs of different color LEDs differ, they drift differently. I don't get why you even mention voltage control when TPS92515 is proper constant current LED driver anyway.

OK, that's pretty much what I thought. Thanks for confirming!

I didn't realize I'd prompt so much speculation about the scanning technique. For those that are interested: there are actually a few people working on this in a few DSLR scanning groups, and I as well as others have tested it and confirmed it works. I've added links to the OP to article I wrote about why I think it works, as well as a more technical article about densitometric scanning.
« Last Edit: May 17, 2020, 04:10:43 pm by amaschas »
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: RGB LED Driver Design
« Reply #6 on: May 17, 2020, 08:50:15 pm »
I didn't realize I'd prompt so much speculation about the scanning technique.
Geez, cool down. One accassional and already dried out challenge of your idea does not count as "so much speculations".
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: RGB LED Driver Design
« Reply #7 on: May 17, 2020, 09:02:56 pm »
Geez, cool down. One accassional and already dried out challenge of your idea does not count as "so much speculations".

I was just referring to the fact that most of the discussion in this thread was about the scanning technique or other aspects of the photographic approach, rather than the technical questions I had about my board. As you noted, that's probably my fault for including all of that information. I figured providing as much context as possible would be useful, but it seems like the opposite happened.

Anyway, thank you for answering my question about driving at constant voltage.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: RGB LED Driver Design
« Reply #8 on: May 17, 2020, 09:08:23 pm »
Just post again. Ask *few* most important questions without being too verbal

I was just referring to the fact that most of the discussion in this thread was about the scanning technique or other aspects of the photographic approach, rather than the technical questions
Please do not confuse technical support page with public forum. Here people talk about stuff *they* are interested in.

[edit] When I said about flash sync speed - it was not speculation. I was sharing my tested & proven knowledge.
« Last Edit: May 17, 2020, 09:18:10 pm by ogden »
 

Offline amaschasTopic starter

  • Regular Contributor
  • *
  • Posts: 125
  • Country: us
  • checking for causal domain sheer
Re: RGB LED Driver Design
« Reply #9 on: May 17, 2020, 10:59:27 pm »
Just post again. Ask *few* most important questions without being too verbal

...
Please do not confuse technical support page with public forum. Here people talk about stuff *they* are interested in.

[edit] When I said about flash sync speed - it was not speculation. I was sharing my tested & proven knowledge.

Thanks, I'll give that a try!

I think I have stayed below my camera's flash sync speed for most of my test with early versions of the light, though that's mostly because it's not bright enough to shoot at faster speeds. I thought that the issue with flash sync was that above a certain speed the period of time the flash is on would not align with the period of time that the entire shutter is open. I didn't realize it was an issue with a light that's constantly on for the entire exposure.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: RGB LED Driver Design
« Reply #10 on: May 18, 2020, 06:15:45 pm »
I think I have stayed below my camera's flash sync speed for most of my test with early versions of the light, though that's mostly because it's not bright enough to shoot at faster speeds. I thought that the issue with flash sync was that above a certain speed the period of time the flash is on would not align with the period of time that the entire shutter is open. I didn't realize it was an issue with a light that's constantly on for the entire exposure.
Good idea to stay well below flash sync max speed because DSLR shutter physics is not that straightforward. It does not open in an instant. Shutted of 5D Mark II at 1/200 sec is wide open for much less that 1/200 sec time. YT video here. I did not care to investigate but it seems like it is < 1/400 sec or so. The rest of the time one of the courtains is moving over sensor, thus creating "banding" if your light source flickers. This is why I would try to make variable current control so LEDs do not flicker.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf