3
\$\begingroup\$

Application:
6 LED strips: each strip has LEDs connected in series
Driver is TPS92691 (CC LED driver)
The source is a battery

The LED strips will be flashed in a carefully controlled cycle, starting at 7Hz and gradually ramping up to 10Hz. While we anticipate a slight delay in the lighting of the 6th and 1st LED strips as the frequency increases, this is a minor detail that won't affect the overall operation.

enter image description here

Problem:
Unsure how to approach switching multiple loads with one driver, it's simple to visualize, but harder to implement - figuring out how the control signals are to be mapped.

See below the LED driver (boost) example from the datasheet:
enter image description here As you can see DDRV (the gate driver) is driving a low-side N channel FET (SIS176LDN-T1-GE3)

Two ways I was able to come up with approaching this problem:

  1. Use the controller's PWM input and split the DDRV output to each strip based on the processor's input. I'm unsure how to go about that.
  2. Tie the Controller's PWM input to VCC to make it a constant output and control each NFET with a separate PWM channel on the MCU—this seems like the easiest solution. However, this approach, with its constant output, seems to generate more heat in Q1.

(For the above two, I'm going with all of the strips having the same sense resistor)

enter image description here

What is the best way to approach this problem (least heat dissipation, less complexity), or can you elucidate how to approach my two proposed approaches more clearly?

PS: Please don't suggest using separate LED controllers for each strip; that is by far the easiest solution, but I am stuck with one LED controller and want to figure out a solution for such a scenario.

EDIT:

Based on the answer, this is how I've routed it. However, due to the TPS92691's dropout operation concerns, I've applied a similar concept to MAX25611B.

Key elements:

  • N channel FET attached to each channel
  • Input to the gate is from a level-shifted GPIO pin using 74HCT.
  • High-side current sensing and high-side switching, are there any potential concerns going for a high-side switching instead of a low-side?

enter image description here

EDIT 2:

Low-side seems to be the way to go, as high side gate switching with pmos would require additional circuitry and high side gate for nmos would require a gate driver. A low side nmos is simple and convenient.

Below is the final edit; the controller would be switching 2A across 6 led strips based on MCU input. enter image description here

\$\endgroup\$
1
  • 1
    \$\begingroup\$ The stuff following "EDIT" appears to be an answer, rather than part of your question. I recommend you create an Answer, and move that section there. \$\endgroup\$ May 21 at 8:38

2 Answers 2

10
\$\begingroup\$

Your boost LED driver circuit has high side current sensing, its output is ground referenced, so you can switch your LEDs with low side MOSFETs, which is convenient.

All you have to do is duplicate Q2 MOSFET (one per LED strip) and drive these FETs with your MCU.

However there are a few gotchas: the an output capacitor (Cout) is charged to the output voltage. When switching from red to green LEDs, the latter have higher Vf so there will be a small delay while Cout charges to the higher Vf. In the other direction, green to red, Cout is charged to the higher Vf when the MOSFET turns on, so it will dump its charge into the LEDs, causing a current spike.

Thus Cout should not be a large electrolytic cap, instead it should be a low value ceramic cap, just enough to clean up the output but not more.

The chip's datasheet mentions that, when the PWM input goes low, it turns off Q2 and the chip also stops switching. If you duplicate Q2 you can no longer use the chip's DDRV output to control Q2, using the MCU instead. This means if you turn off all the LEDs without setting the PWM input low, then the chip will still try to pump current into the output and charge the output cap until it hits the OVP threshold. This will cause a larger current spike when you turn the LEDs back on.

A simple solution is to set the OVP threshold to a reasonable value (a bit higher than your LED Vf but not way higher) and also use a MCU output to set PWM low when you turn off the LEDs. This replicates what the chip would normally do to its DDRV output, in this case DDRV doesn't need to drive the MOSFETs so it can be left unused.

In fact, you could do it like this:

  • PWM=0
  • Wait a couple tens of µs so Cout discharges
  • Turn off MOSFET for current LED and turn on MOSFET for next LED
  • PWM=1

You don't need to switch the MOSFETs quickly, so driving them from MCU GPIO is fine. If you have a 3V3 MCU and 5V FETs you can use any 74HCT logic gate as a cheap 3V3 to 5V level translator, for example 74HCT245 provides 8 channels.

If you want to use DDRV output for PWM dimming, then you can also route it through a 1-8 demultiplexer so it drives the FET corresponding to the LEDs that should be active. But DDRV is not 5V logic level, so this requires a bit of adaptation.

\$\endgroup\$
22
  • \$\begingroup\$ Detailed answer! " This means if you turn off all the LEDs without setting the PWM input low, then the chip will still try to pump current into the output and charge the output cap until it hits the OVP threshold." - What situation is this talking about? Is it the duration between the 6th and 1st LED - in that case, the PWM input to the controller and PWM input from the MCU to the discrete Q2s will be low, right? Also will 2 timers be required in this case? \$\endgroup\$
    – roaibrain
    May 12 at 15:47
  • 1
    \$\begingroup\$ At 7-10Hz you don't need PWM. Just set a timer to raise an interrupt every time you want to switch to a different LED and flip the GPIOs... then you can do anything you want. \$\endgroup\$
    – bobflux
    May 12 at 17:58
  • 1
    \$\begingroup\$ It just means you need a separate GPIO to control the chip's PWM input, besides the other GPIOs to control the MOSFETs switching each LED strip. Note the idle current of this chip is quite high (2mA) so if you don't have a physical on/off switch it would be a good idea to cut VIN with a PMOS so it doesn't drain the battery when not using the device... \$\endgroup\$
    – bobflux
    May 12 at 19:59
  • 1
    \$\begingroup\$ That would also work, the chip is similar... There's LT3796 which is the 1 channel version too. If you set PWM to 0 they will stop switching like the TPS92691 to avoid overcharging the output cap, so it's pretty much the same... \$\endgroup\$
    – bobflux
    May 13 at 6:16
  • 1
    \$\begingroup\$ I'd just put footprints for several caps like the 4 you had originally and experiment with various values until desired results are achieved. It shouldn't take long. \$\endgroup\$
    – bobflux
    May 18 at 6:13
2
\$\begingroup\$

Definitely possible to do with a switching regulator, but not trivial. I would consider a linear current regulator if the current will permit it. They make multichannel linear regulators that are digitally controllable specifically for this sort of application. These can actually be quite efficient if you can match the LED and supply voltages.

Edit: From the comments, the target current is 1 A per channel, so linear is not a good choice.

\$\endgroup\$
3
  • \$\begingroup\$ That's a good suggestion, but as you can see in my question, there's a boost controller. The LED strips have a higher voltage than the battery—do you have any alternative suggestions to make it work with a switching regulator? \$\endgroup\$
    – roaibrain
    May 12 at 16:47
  • \$\begingroup\$ You can use the boost converter to step up the voltage and then a multichannel linear current regulator to control the current into each individual channel. \$\endgroup\$ May 12 at 17:17
  • \$\begingroup\$ Ah, that's true; that seems to be the approach many power management systems use, which is interesting. At an output current ~1A. It seems unlikely to find a multichannel linear current regulator that fits in. \$\endgroup\$
    – roaibrain
    May 12 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.