I’m designing a circuit to switch a section of a 24 V CCT LED strip. I can’t add additional control lines, and the strip can’t be split at the dimmer, so I need an in-line circuit that can decode a command to toggle a switch. This board will sit between the two strip segments. The strip has a common 24 V rail, and each channel's ground is PWM’d by the main dimmer at 30 kHz. I have full control over the dimmer.

My initial idea is to use the PWM frequency itself as the control signal: if either CCT channel drops below ~20 kHz for let's say ~20 ms, the board should toggle the section. The detection should be OR’d across the two channels, so that either one triggering the command switches the full section. I’m also open to other approaches, but this method seems reasonable to me and should minimize visible flicker.

It could harvest power from the PWM'd grounds using schottky diodes, store charge in a capacitor and use two LDO's to generate 12V and 5V for the control logic.
The outputs will be driven by MOSFETs with the gates controlled by the detection and latching logic.

Does anyone have suggestions for reliable, duty cycle independent detection methods or ICs suitable for this application?

 

We have a FAIR desscription of what is wanted, but NO CIRCUIT AT ALL! Give us an actual circuit schematic and probably a solution can be suggested.

 

Word Salad.

Draw a block diagram of the idea.
Include part number or photos

 

To clarify, I was not presenting a finished schematic yet because I am specifically looking for guidance on an implementation. Does something like this help to convey my idea?

 

It's a start, but I still have no idea what the problem you want to solve is?

What is a "CCT LED" strip?

On your diagram, what is "CW" and "WW"?

 

A CCT LED strip is a tunable white LED strip with two independent LED channels. WW = warm white, CW = cold white. Both channels share a common +24V rail. Each channel has its own low side connection, which is PWM’d by the dimmer using open-drain outputs. Brightness and color temperature are controlled by varying the duty cycle between the WW and CW PWM signals.

The circuit I’m trying to design behaves like a small inline segment of LED strip. It has +24V, WW and CW connections on both sides. The left side connects to the first section of LED strip, the right side connects to the downstream LED strip section. The purpose of this circuit is to selectively enable or disable the downstream strip section without adding extra control wires and without splitting the strip at the dimmer. When enabled, the circuit should simply pass the PWM’d grounds through so the downstream strip behaves identically to the upstream one. When disabled, the circuit should disconnect the PWM'd grounds to turn off the downstream segment of strip. To do this, I was thinking of a circuit to decode a command embedded in the PWM itself, like detecting a change in PWM frequency.

The open question is how to reliably detect a command on this floating PWM signal and convert it into a latched enable/disable control for the downstream strip segment.

 

The PWM signal normally pulls the LED string cathodes to ground.
Just add a pullup resistor to 24V, it should give you a 24 volt square wave signal.
Or an optocoupler with a resistor...

It would be simpler to switch the high side 24 Volts, rather than trying to drive a low-side MOSFET at PWM frequencies.
IF (how?) you can generate PWM of different frequencies, a microcontroller capture-compare timer peripheral (or any hardware timer) could be used to discriminate the different frequencies.

Then you can use a PFET as a high-side switch to turn off the LEDs on the second strip.

 

I have full control over the dimmer firmware, so generating different PWM frequencies is not an issue. Switching the high side on the second strip seems like a good solution to avoid unnecessary referencing complexity on the gate drive circuit. Thanks!

My initial approach considered a small microcontroller (eg. ATtiny13A), but I’m currently leaning toward tone decoder ICs (LM567) or a purely analog / mixed signal solution to avoid firmware, startup edge cases, and clock tolerance issues.

The functional requirements are:

• A short, intentional frequency change (eg. <20kHz for ~20ms) constitutes a command. Normal operation uses a PWM frequency of ~30 kHz.
• The command must be detected on a wide range of duty cycles, let's say 10% to 90%, in order to reduce visual glitches during transmission.
• Detection should be OR’d across WW and CW so that either channel can issue the command.
• Each valid command toggles a latched state. The downstream strip section remains in its last state until another command is received.

 

I would shy away from the analog, discrete approach.
It's going to be 5X more complex, and a lot less repeatable/reliable.
If you have "full control" of the firmware, you must have some resources to write some simple code?

 

Going the ATtiny13A route, I've came up with this schematic. As you suggested the CW and WW PWM grounds pass straight through unchanged, exactly as they would on a normal strip. They are sensed with a HCPL-0630 optocoupler and read by the ATtiny. To disable the downstream strip section I'm switching its 24V rail with S80P06. How does it look?

 

Why 2 cascaded regulators? There are tons of 5V regulators that can run from 24 V.
D7, D8 are not doing anything meaningful- a negative voltage spike here is not going to hurt anything. (and would be clamped by the LED's)
The drain of Q4 is flapping in the breeze- add a diode here to GND - clamping negative over voltages- ESD for example.

Otherwise looking reasonable.

 

The two cascaded regulators were a leftover from when I planned to use a 12V rail for MOSFET gate drive. I’ve replaced them with a single 78M05 and a series resistor to better spread the heat.
The SS14 diodes on CW and WW prevent the storage capacitors from discharging back into the LED strip when CW and WW are floating.
I've also added a pull-up on the ATtiny output as I want the downstream segment to default to on. But I'm not sure if there's enough power to keep it on even at very low duty cycles. The purpose of this board is to switch off the downstream segment only when instructed to do so. In every other scenario the segment should be left on.

Here's the updated schematic:

 

Swapped out the ATtiny13A for the more modern and powerful ATtiny402 and cleaned up the schematic. This is the updated version:

 

I really don't see how D1 and D2 do anything other than cost money and occupy board space?

Which "storage capacitors" discharge? via what path?

This board will always have power via 24 volts, R6 is only going to be relevant for the brief interval (20 mSec?) when the micro boots up- before it asserts the IO pin.
You can eliminate R6.

The fuse F1 is not needed, did you intend to fuse the 24V output? if so, it's in the wrong place.

Why make this any more complex than absolutely necessary?

 

If I remove D1/D2, won't C1/C2/C3 discharge through the led strip when CW/WW are floating and smooth the PWM?

Regarding R6: yes, the MCU will normally drive the pin shortly after power up, but I added it to guarantee a defined state during resets, brown-outs, programming, or any condition where the pin is floating. I thought leaving digital control signals floating was generally considered bad practice, the pull resistor avoids undefined behaviour at negligible cost and board space.

F1 was intended to protect the board itself, not the downstream segment.

 

If I remove D1/D2, won't C1/C2/C3 discharge through the led strip when CW/WW are floating and smooth the PWM?

No, the caps are between +24 and GND- oohhh wait! you are expecting this to work WITHOUT a system GND connection?
So then this whole thing drops out when the PWM duty goes to 0?
Ok, now I get what you are talking about, leave the diodes.

Regarding R6: yes, the MCU will normally drive the pin shortly after power up, but I added it to guarantee a defined state during resets, brown-outs, programming, or any condition where the pin is floating. I thought leaving digital control signals floating was generally considered bad practice, the pull resistor avoids undefined behaviour at negligible cost and board space.

F1 was intended to protect the board itself, not the downstream segment.
A fuse really is not going to protect anything on your board, fuses are slow, crude, and brutal devices that are really only good for preventing fires from glowing wires.
The high-side switch into a dead short on the output might glow some wires- put the fuse in that circuit. (I would not bother, it's more of a nuisance than "protection" )

 

Yes, sorry for not making that more explicit earlier. This inline board does not have access to the system ground. The only available references are 24V, CW, and WW. The diodes allow the reservoir capacitors to charge when CW or WW is actively pulled to ground by the dimmer, and to hold up the local supply when the PWM outputs are floating. Without the diodes, the storage capacitors would discharge back into the strip and smooth the PWM.

CW and WW are already fused at the dimmer, so any fault that shorts 24V to a PWM line would clear those fuses.

With those clarifications in mind, does the rest of the topology look reasonable to you?

 

Sure - time to breadboard it!

 

Sure - time to breadboard it!

I’ve done some testing on the power-harvesting and switching portions of the circuit. Overall it works at moderate and high PWM duty cycles, but it fails at very low duty.
At low duty, the harvested energy is insufficient to keep the storage capacitor charged. The VCC rail collapses to only a few volts, which causes the gate drive circuitry to collapse as well. As a result, the MOSFET no longer has sufficient Vgs to stay enhanced, and the downstream LED strip turns off unintentionally.

In other words, with the current approach the power conduction depends on having enough supply voltage to actively drive the MOSFET gate, which is not guaranteed at low PWM duty.

It seems the robust solution would be to pass power through passively by default, with no dependency on gate drive or logic power, and only actively disable the load when the MCU is alive and enough power is available. Conceptually this is similar to what a latching relay would provide, but implemented with semiconductors due to size constraints.

The key requirement is default conduction at all times, except when the MCU is alive and explicitly commands it to turn off.

Any further advice is appreciated. Thanks!

 

Why not use an actual latching relay?
The MCU can read it's state when it wakes up to determine what to do to match the incoming command.