DIY LED Controler/Driver

[Sral]

There should be no need, you can drive the MOSFETs directly from the PCA9685 outputs. Anything more than about 10V is pointless, and, more importantly, 24V is above the maximum Vgs for the MOSFET (and pretty much any MOSFET)

So, just tie the ground from the PWM circuit and the PCA9685 and connect directly.

The pull-down to keep the channel off is fine.



This is fine to run on the perfboard. You can increase the current carrying capacity of a trace by laying solder on top of it for extra insurance.



Not needed. Paralleling devices can be done but unless done carefully one will take the bulk of the load anyway.

I may have missed this from an earlier post, is there anything controlling the current through each LED string?

Darnit, I completely forgot about that Limitation, thanks !

The Limitation of current is done by the Lamp itself. Normally you just connect the 24V power source and get 100%.

I’ll think about the optocoupling, my paranoia says to use them, especially since I have them lying around. Supplying them with less voltage shouldn’t be a big problem that a few resistors, zener diodes and/or a 5V regulator can’t solve.

Thanks a lot ! I’ll be trying to plan this out on a perfboard with extra solder, even though I have noticed that a propped PCB would both make the current requirement and space usage a lot easier … as @robsworld78 mentioned

 

[theatrus]

Darnit, I completely forgot about that Limitation, thanks !

The Limitation of current is done by the Lamp itself. Normally you just connect the 24V power source and get 100%.

I’ll think about the optocoupling, my paranoia says to use them, especially since I have them lying around. Supplying them with less voltage shouldn’t be a big problem that a few resistors, zener diodes and/or a 5V regulator can’t solve.

Thanks a lot ! I’ll be trying to plan this out on a perfboard with extra solder, even though I have noticed that a propped PCB would both make the current requirement and space usage a lot easier … as @robsworld78 mentioned

optocouplers totally can be used and aren’t a bad idea. As you said, just provide about a 10V supply to drive the gates of the FETs fully - current needs are very low.

 

[Sral]

optocouplers totally can be used and aren’t a bad idea. As you said, just provide about a 10V supply to drive the gates of the FETs fully - current needs are very low.

Well, the current needs of the gates are very low, but the optocouplers have a supply current of their own that surpasses this easily. Each of the 6 Gate drivers takes about 2.6 (typ) - 4.0 (max) mA between 10-15V. That equates to 15-25 mA total, which sounds like an ideal job for a zener diode ^^

I'm planing 4 parallel 2.2k resistors (1/2 W), 550 Ohm total that feed the gatedrivers and two series 5.2V Zener diodes. The gate drivers alone with the resistors drop my 24V to between 10.4 V and 12.9 volts, depending on performance, which get's clamped to the Zener voltage of around 10.4
Each resistor takes about 75 mW of his maximum of 500 mW
and each zener diode takes about 30-50 mW of the maximum 500 mW.
Should be well within limits:

I also thought about adding one or several bypass capacitors to the LED circuit, but those would probably experience a comparatively high constant current load at specific duty cycles, which might, if I'm unlucky, heat and blow up the capacitors. So I'll probably go with the Meanwell LPV-100-24 power supply's internal caps and cross my fingers.

I also read in the PCA9685's datasheet that you can program staggered timings for the channels to decrease load rippling. @Ranjib is that a thing in ReefPi, or can we make that a thing in a specialized driver version ?

 

[theatrus]

Well, the current needs of the gates are very low, but the optocouplers have a supply current of their own that surpasses this easily. Each of the 6 Gate drivers takes about 2.6 (typ) - 4.0 (max) mA between 10-15V. That equates to 15-25 mA total, which sounds like an ideal job for a zener diode ^^

Don't mix up the driving side with the receiving side. The driving side needs to run an LED in the package, but the other end likely has much lower current requirements. In either case, a Zener regulator would be just fine.

 

[Sral]

Don't mix up the driving side with the receiving side. The driving side needs to run an LED in the package, but the other end likely has much lower current requirements. In either case, a Zener regulator would be just fine.

Thanks for the reminder!
The datasheet does differentiate between input current (10-16 mA recommended, 30mA max) and VDD supply current (the mentioned 2.6 mA typical and 4.0 max) and even provides a plot of this current between 10-30V, which is way above the allowed voltage on the input side. So as long as I’m not terribly mistaken, that seems to be the driver side supply current.

That’s probably to supply and preload all the internal circuits, as the FOD3182 is much faster than a standard 817 optocoupler.

It also means that I’ll probably add a bit more resistance between the PCA9685 and the FOD3182 optocoupled gate driver (100 Ohm or so), as it would otherwise run each input with 23mA.

 

[Sral]

@Ranjib Okay I had a "go" at the driver code myself and of course, load staggering is not implemented. Yet.

Since I'm guessing that I'm the only one paranoid enough to request this feature: how easy would it be for me to reprogram the driver and exchange that locally in my ReefPi ? Do I need to compile the driver code, or even the whole of ReefPi, or can I simply exchange a local driver file ?

 

[theatrus]

@Ranjib Okay I had a "go" at the driver code myself and of course, load staggering is not implemented. Yet.

Since I'm guessing that I'm the only one paranoid enough to request this feature: how easy would it be for me to reprogram the driver and exchange that locally in my ReefPi ? Do I need to compile the driver code, or even the whole of ReefPi, or can I simply exchange a local driver file ?

You would just build reef-pi with the modified driver. Go modules have some gotchas to use local paths (need to modify go.mod in reef-pi).

Load staggering is a great idea

 

[Sral]

You would just build reef-pi with the modified driver. Go modules have some gotchas to use local paths (need to modify go.mod in reef-pi).

Load staggering is a great idea

@Ranjib Just thought about it and maybe the simplest way would be to modify the PCA9685 driver for everybody by including automatic load staggering. Not sure if that would hurt somebody. Only case I could imagine is when somebody uses the exact timing of several channels as a combined signal, but that sounds rather strange.

The Implementation I’m thinking about is to constantly offset the starting time of each channel by its ID/16*4095. That way for example, channel 9 would start half a period after channel 1.

In my case, since I want to stagger the 6 LED channels, I’d simply have to use the PCA9685 channels 1, 4, 7, 10, 13 and 16 as signals and have both a nice load staggering, as well as more PWM available for the least amount of settings needed.

 

[theatrus]

@Ranjib Just thought about it and maybe the simplest way would be to modify the PCA9685 driver for everybody by including automatic load staggering. Not sure if that would hurt somebody. Only case I could imagine is when somebody uses the exact timing of several channels as a combined signal, but that sounds rather strange.

The Implementation I’m thinking about is to constantly offset the starting time of each channel by its ID/16*4095. That way for example, channel 9 would start half a period after channel 1.

In my case, since I want to stagger the 6 LED channels, I’d simply have to use the PCA9685 channels 1, 4, 7, 10, 13 and 16 as signals and have both a nice load staggering, as well as more PWM available for the least amount of settings needed.

On my own LEDbrick drivers this is roughly what I did with the PCA9685 control. You can get all fancy to try to make some sort of average current figure, but its not really worth it. Most of the time staggering is useful for EMI purposes, which none of this will ever need to pass testing for, but its still nicer on the power supply.

As you said if someone needs the pulses synced it won't work, but for general lighting (and not some other purpose) there isn't any reason to need it.

 

[Ranjib]

@Ranjib Okay I had a "go" at the driver code myself and of course, load staggering is not implemented. Yet.

Since I'm guessing that I'm the only one paranoid enough to request this feature: how easy would it be for me to reprogram the driver and exchange that locally in my ReefPi ? Do I need to compile the driver code, or even the whole of ReefPi, or can I simply exchange a local driver file ?

yes.. you have to compile if you write it in go. how about a file driver?

 

[Sral]

yes.. you have to compile if you write it in go. how about a file driver?

I’m not quite sure what you mean with that, do you mean a single driver file that I can add to ReefPi or write the info into a file that an existing ReefPi driver can read/write/handle ?

 

[Sral]

yes.. you have to compile if you write it in go. how about a file driver?

Well, I would like to have as much as possible in ReefPi itself, so I can see and handle everything in the UI.

Since that would entail to write an SCD30 driver and additional light profiles in the future, I guess now is as good a time as any to start a development environment and have go at the ReefPi code itself ^^

 

[Ranjib]

Well, I would like to have as much as possible in ReefPi itself, so I can see and handle everything in the UI.

Since that would entail to write an SCD30 driver and additional light profiles in the future, I guess now is as good a time as any to start a development environment and have go at the ReefPi code itself ^^

Got it. If the logic is somewhere, i’ll find some time to roll it up in reef-pi core. Don’t worry about it. It will take some time , but we‘ll get it done

 

[Sral]

Got it. If the logic is somewhere, i’ll find some time to roll it up in reef-pi core. Don’t worry about it. It will take some time , but we‘ll get it done

Thanks ! I'll see if I manage to be patient until then ^^

Should be fairly easy though. Current code in hal.go says:

return p.hwDriver.SetPwm(pin, 0, uint16(value*40.95))

Change that to something like:

return p.hwDriver.SetPwm(pin, pin*256, (pin*256+uint16(value*40.95)) % 4095)

depending on whether pin is zero based, otherwise you would of xourse have to use off = (pin-1)*256

I have checked the datasheet, you can define start time numbers that are higher than stop time numbers.

 

[Sral]

Next step: I have build the optocoupled driver board and measured the current draw of:
- two 5.2V Zener diodes in series by themselves
- the same with an additional 6 FOD3182 circuits

As soon as I go over 10.6V the current draw decreases quickly after an initial increase and settles on a lower level. I guess that's a side-effect of the Zener-diodes heating up. The two Zener diodes in series end up with about
onset voltage:10.57 V
(the knee in the green curve)
resistance: 7.7 Ohm
(the slope afterwards, e.g. about 0,23V per 30mA)

The orange curve has a lower slope because I measured after the Zener diodes were already warm/hot. The Zeners have a heat dissipation of about 150-300 K/W, so towards the end they should already warm up to about 20-30°C (about 36 to 54 °F) above ambient from about 160mW on each Zener diode.

If I want to drop my 24V to a working voltage of 10.2V to keep my Zeners nice and cool, I will get a current draw of about 17mA. To drop my 24V to these 10.2V I would therefore need a series resistance of ~812 Ohm ((24V - 10.2V)/17mA), which is about 4 parallel 3,25k resistors, luckily, that's exactly what I have lying around ^^

The resistors will in total dissipate about 235mW, so every individual resistor will get about 60mW, increasing their temperature by something like 6°C (or about 11°F).

 

[Sral]

Here is the final result. Not my prettiest job, but I hope it will do. I would recommend everybody that tried the same to go for a full PCB-design, it’s just a lot smaller and with less cables that way

Side view with the 24V power plug (yellow below the 8-cable light connector on the right) and the 2 shielded USB-A ports for the I2C network on the left:

 

[Sral]

Furnished a nice shielded USB-cable, this time I checked that I solder the correct cables to the right contacts by plugging both sides into identical USB breakout boards and checking continuity with my multimeter. That way the PCA 9685 lights up nicely:

and shows up under its correct address 0x40 (decimal 64 in Reef-PI):

Just FIY, 0x61 is my AirQuality chip (SCD30), 0x68 is the RealTimeClock (RTC) and 0x70 is the all channel call address for all PCA9685 chips in the network, if I'm not mistaken.

Next up I'll test if my PWM signals reaches my MOSFETs as planned.

 

[Sral]

I supplied the circuit with 24V, at first limited to 20mA, to limit risk to the circuit in case something goes wrong. It drew exactly the 17.07V that I measured before for the bare optocoupled circuit. Instead of the lamp I then connected a 3.25k resistor across V+ and the contact for the green light and increased the PWM for the green channel:

Aligns perfectly with the relative fraction of the current that should flow across a 3,25k resistor from 24V PWM ^^

I also connected the lamp and it works nicely for 5 out of 6 channels. One of them is partially active all the time though ... so I'll have to find out why that is.

Another thing I noticed: the lamp does visibly flicker a bit. Maybe I'll have to rip out the PCA9685 and use an ESP32 with its 5kHz, we'll see

 

[Sral]

Found the culprit, I believe. One of the jumper wires slipped from the header pin and therefore the MOSFET gate was floating.

 

[Sral]

Works beautifully:

When I use a diurnal profile the lamp starts up at about 0.03%, exactly where it should, since the PCA9685 can only go in steps of 1/4096~0.025%. Using the FOD3182 seems to work well in this regard. Although I believe that a PCA9685 feeding the MOSFET gates directly should manage the same.

No flickering visible. The only thing I noticed is that my 100W 24V power supply starts whining when I use too many channels at once, when they are around 50%. I think I will need to wait for @Ranjib or myself to implement load staggering or use the ESP32 with its higher frequency