How to individually control about 100 LED's?

Thread Starter

markg85

Joined Sep 12, 2020
13
Hi,

I'm designing a downlight which is going to be rather extreme in terms of light features.
It will have:
  • ~30 warm white LED's with a 95+ CRI
  • ~30 daylight white LED's with a 95+ CRI
  • ~20 candle/amber light LED's (for the really warm light output)
  • ~20 RGB LED's (so 3-in-1 LED's thus in terms of actual "light points" this is 60)

That brings the total to 140 LED lights.
The combination of LED's might change but this is roughly the gist of it.

Thus far it's not a super complicated project.
It becomes slightly more complicated if i were to make all single color as "1 channel" dimmable. So effectively that would be just 6 different PWM levels to dim (1 for warm white, 1 for daylight white, 1 for amber, 1 for red, 1 for green and 1 for blue).

But i want to go a step further.
I want to individually control each and every single light point in this light.
Picture this light to be a circle. All the leds would be spaced around the edge.
If they are individually addressable then you could have actual animations happening there. So for instance a green dot circling around, but obviously much more then this would be possible.

Another thing that adds complexity is that i'm using LED's that don't exist with build in led driver (like the WS2813B).
Note that i must go this route because i want high quality white/warm white LED's (like this one). The White/warm white ones that you can buy with LED driver build in are of poor lighting quality. They are good for other purposes, not for a main lighting goal.

In the best case scenario i can use RGB leds with build in LED drivers to make them individually addressable, but i'm not counting on it.

So this brings me here as i'm not sure at all how to tackle this.
I do know of a few possible solutions but they all seem to have downsides as well.
But before i describe that further, please be aware of these PWM conditions.
I want the LED's to dim smoothly, also at the levels of - say - fading in from 0 to 10% brightness. When gamma correction is applied, a 10 bit PWM duty cycle is really not much, specifically in the low levels. With 10 bit you can actually see the individual brightness steps at the low levels. So, at the very least, the duty cycle must have a resolution of 12 bits. Preferably even 14 bits. The PWM frequency should also be "high enough" to consider it flicker free. Also at the low duty cycles.
Also look at this awesome video about LED frequencies.

I like to aim at having a 10Khz frequency with 12 bit duty cycle resolution as the lowest requirements.
More would be better but this seems to be good. It can be better but lets not start too difficult just yet for this project ;)

What are my options to get at these specs?
There are LED drivers out there that seem to be capable of this. For example just 3 of these might even work if i understand the specs correctly. The downside here would be a wire to each LED. Whereas a "data line" would be more appealing to me. On the other side, if there would be a data wire then i'd probably need to place a chip next to each led to translate that data for that LED to a PWM. Thus in effect having 120 PWM driver IC's, that's overkill i'd think.

So yeah, i'm really looking for the best way with the minimal IC's and wiring to get this working.
I'm assuming that if i wire each "led group" (so all warm whites in one matrix, all amber lights in another matrix, etc...) that i can use those matrix ways of controlling them individually too.
In that case, i'd have 6 matrix sets.

I'm looking forward to your replies :)

Cheers,
Mark
 

djsfantasi

Joined Apr 11, 2010
9,156
There’s a lot of control that you desire. IMHO, you’re going to need to create your own controller. How’s your programming skills?
 

Thread Starter

markg85

Joined Sep 12, 2020
13
There’s a lot of control that you desire. IMHO, you’re going to need to create your own controller. How’s your programming skills?
Well, i do C++ coding for a living so if it would be that, i think i'm fine :)
I've been playing with microcontrollers too, though only in the arduino world (and esp8266 but that's often the same libraries). So if it were to be in that world, i'm fine!

Anyhow, i think i can manage that part.
 

Sensacell

Joined Jun 19, 2012
3,432
This is not going to be easy or cheap.
You did not mention the power levels (LED currents) involved, or the wiring distances, all of which can influence the design choices.

If this is a one-off project, the most expedient way is to buy a bunch of cheap off-the-shelf DMX LED dimmers.
 

Thread Starter

markg85

Joined Sep 12, 2020
13
@upand_at_them and @DNA Robotics
Thank you for those suggestions!
However, no, i can't use them.
To quote myself from the first post:
Another thing that adds complexity is that i'm using LED's that don't exist with build in led driver (like the WS2813B).
Note that i must go this route because i want high quality white/warm white LED's (like this one).
So no, i can't go for those.
Unless you can point me to high quality LED's (that being high CRI index + high lumen/watt of at least 150). Then those options become feasible. As far as i'm aware, that doesn't exist.

@Sensacell
Ha, fair points :)
I'm aiming for a circular light with a diameter of 30 centimeter.
This is for now a one-off project indeed. To see if the pure technology requirements for this are feasible today.
So in that sense it's just a fun hobby project where i'm going for super quality in terms of light quality.
Thank you for your suggestion of those off-the-shelf dimmers, but i prefer to not go there. I certainly know that what i'm asking in terms of dimming capability is stretching (pun intended) the limits of PWM and current microcontrollers. But it should't be impossible.

The design i'm currently considering is going for level shifting. And as those are usually 8 or multiple of 8, i suppose i should have as many leds to make that sensible. So i'd need to go for an array of 9 level shifters that each have 16 outputs. In this setup the led's don't need to be in a matrix connection either as each led will get a wire from the level shifter.

Then for a little math (which i'm bad at so this is going to be fun).
If i want to maintain 10.000 hertz and 12 bit duty cycle resolution then i need the microcontroller (none picked yet) to be able to handle this. As far as i understand it i would want at every hertz the ability to accurately divide it into 4096 (12 bit). Or in other terms, i need a pwm resolution of: 10.000 * 4096 = 40.960.000. Or in more readable numbers, roughly 41MHz. This means that the loop to fill the data would need to write one bit every ~24 nanoseconds (according to this). Or to put it differently, i need to write as many bits as i just calculated the hertz (so 40.960.000 bits aka 40.960.000/8/1024 = 5 MiB per second).
Now here's the catch. What i just calculated is for one light point, not 144. If all 144 light points were to be connected to this then i would basically have 1 PWM channel with high resolution. This can still work as i only need one high resolution PWM and use the shift registers to get the individual value per pulse at either a 0 or 1. But that can only work if i can write 144 bits per ~24 nanoseconds. This would be with a SIPO level shifting setup of 9 level shifters of each 16 outputs, all the level shifters would be wired in series.

I have serious doubts if this is possible in the above thought up setup. As (if all the math is correct) that 5MiB/second was with 1 bit per ~24 nanoseconds. You can also interpret it as "5MiB per light point per second" Now that part needs to be 144 bits to control all leds. Thus the total throughput would become 5MiB * 144 = 720 MiB per second. Yup, not gonna work as-is.

Alternative approach #1
With all requirements staying the same, the data needs to be fed to the shift registers faster.
For this i think i could go for 2 layers of shift registers.
The first layer would be just 1 shift register but PIPO with 16 input pins and 16 output pins. There is a waste of pins here as i'd only be using 9 on either side. each output pin (of the 9) would be connected to 1 SIPO shift register. From there on it's the same setup as above. 9 shift registers which connect to the light points.
In terms of bandwidth this helps massively. As the MCU side now can write 9 pins in parallel. It still needs to write 144 bits per hertz only in 16 chunks. It would still need to do this within ~24 nanoseconds. Another advantage that can be used is actual parallel pin output writing. For example the STM32 does seem to have a CPU register to write to the whole port by which i assume that 1 instruction can be used to write to all output pins?.. (please correct me if i'm wrong).

Alternative approach #2
I'm a bit shocked by the bandwidth requirement (720 MiB/second) for the other requirements to work.
It only needs to be this high because at every ~24ns 144 bits need to be written. Sure, there might be optimizations possible of only writing changed data, but in terms of instructions that means comparing if it has changed and writing that bit if it has. In terms of memory this would be quite expensive too. As i suppose i don't just need 144 bits for that 1 resolution. I'd probably be much smarter to have "1 pwm pulse" in memory. So that means 144 * 4096 = ~74KB. That's nothing for desktop CPU's, but that's huge for MCU's...
So, isn't there a more efficient way of doing this? Somehow i keep thinking of a way to basically tell each LED "In X time go from point A to B in your gamma corrected curve. And you can tell a led that for just the duration of the animation. This changes the bandwidth equation to say a few bytes (the bytes needed to tell it what to do) times the number of light points but only once per animation timeframe. So say there is a 300ms animation and say the payload to tell a led what to do is 4 bytes (just guessing, take this for what it is). It would then need to send (4x144) = 576 bytes per animation for all light points in total! In fact, if a light goes on and it for instance fades in over 300ms then that 576 bytes is all that would need to be send till the light goes into another animation. Is there a way for this to work without the need to have 1 pwm per light point? I'd even assume that this approach would probably have one MCU per light point, that's not an option. That's too costly.

Any more alternative approaches that might make this possible?
 

Sensacell

Joined Jun 19, 2012
3,432
It's nuts to think of PWM at this speed to be anything other than a dedicated hardware engine- one that requires nothing from the CPU other than changing an input register now and then.

Each LED needs to run from it's own hardware channel, the idea of using some 16 channel LED signage drivers is reasonable, but they cannot drive power LED's directly.
You could interface them to some high-current transistors for example.
 

Thread Starter

markg85

Joined Sep 12, 2020
13
It's nuts to think of PWM at this speed to be anything other than a dedicated hardware engine- one that requires nothing from the CPU other than changing an input register now and then.

Each LED needs to run from it's own hardware channel, the idea of using some 16 channel LED signage drivers is reasonable, but they cannot drive power LED's directly.
You could interface them to some high-current transistors for example.
Sorry, i never wrote that down.
I fully expect there to be a mosfet between the end of the shift register and the LED. The output of the shift register would be tied to the gate of the mosfet.

Still, i'm very much open for alternative ideas :)
 

TechWise

Joined Aug 24, 2018
151
A few things spring to mind:
  1. As @Sensacell points out, it would be nuts to try and implement that number of PWMs in software, what you need is a hardware solution. This will already be present on most microcontrollers in the form of Timer peripherals and will provide 12-bit, 16-bit or even greater resolution. You would leave these peripherals to work away at their leisure and then just update the duty factor register using software. Problem - you're unlikely to get more than about 24 channels of PWM out of a microcontroller. That's based on an F28379D which is built from the ground up to do power electronics control using PWM so I doubt if you'll find much better, and at £20 a pop, you don't want to be using too many.
  2. For a great many simultaneous outputs, an FPGA springs to mind. You could potentially implement hundreds of PWM outputs but you'll need a pretty hefty FPGA which will not be cheap and programming it in HDL will be very different from the programming you're used to.
  3. You could go down a potentially complicated master-slave route where you perhaps have a master microcontroller sending out instructions to other microcontrollers or FPGAs each responsible for managing ~10 or so LEDs each. The slaves could potentially be much chaper microcontrollers. For example, an MSP430F6636 has multiple 16-bit PWM outputs and costs ~£5.
 

Thread Starter

markg85

Joined Sep 12, 2020
13
@TechWise Thank you very much for that reply!
This clarifies a lot for me!

Just for the FPGA. Yeah, let's not go that route :) I'm not feeling that adventurous.

Based on what you said, i'm now considering a setup of the following:
  • A master node that only tells other microcontrollers what to do with the LED's they manage. Each slave node probably manages 16 LED's.
    • Say there still are 144 led's. And say the lowest animation time is 10ms (ignore that it feels instant). This master node then needs to let the slave nodes know within that 10ms what needs to be done with the LED's. In terms of timings, it now "merely" needs to be able to send that (4 bytes * 144) within 10ms. Very much feasible i'd say. (important for the next step, the first byte contains the index of the LED)
  • Slave node receives the data and handles those where it has the indices.
    • Slave node consists of cheap MCU with at least a timer (or PWM) with enough resolution for 10.000KHz frequency and a 12 bit duty cycle times 16 to manage all 16 LED's. This "times 16" means it either has the resolution to be 16x as fast (as 10.000KHz * 4096) or have enough timers/pwm's to handle 16. The output will still be fed into a SIPO shift register with 16 outputs.
    • Eventually, the output connects to the gate of a mosfet to drive the LED.

Does that sound like a workable project?
 

Sensacell

Joined Jun 19, 2012
3,432
Here is a nice 16 channel signage driver- the TLC5940, I have used these to great success.
These have INTERNAL PWM engines X 16!

https://www.ti.com/lit/ds/symlink/tlc5940.pdf?ts=1600008994207&ref_url=https%3A%2F%2Fwww.ti.com%2Fpower-management%2Fled-drivers%2Fsignage-led-display-drivers%2Fproducts.html

To keep the wiring manageable, use a dirt-simple MCU to talk to the TLC5940, and a serial link to send out commands to all your boards, maybe RS-485.
Each board can have its own clock - so you don't need to move a 30 MHz signal around the place.

It's still a monster, but at least a sane one.
 

MisterBill2

Joined Jan 23, 2018
18,176
If the concept is really only 140 LEDs then another option is a matrix arrangement, possibly 10 x14, or 12x12, although 10 x14 can use more commonly available IC devices. Then you really only need one driver and one pulse width control at a time. There would be a bit more complexity at the LEDs end, but only a total of 24 drivers, although it could easily expand to 26, allowing 160 LEDs individually controlled. That is one approach, and while the code might be a bit tedoius, it should not be terribly hard. Possibly the low duty cycle might be a problem, worst case you could have ten sets of 14 each, expandable to 16 each.
 

Thread Starter

markg85

Joined Sep 12, 2020
13
Here is a nice 16 channel signage driver- the TLC5940, I have used these to great success.
These have INTERNAL PWM engines X 16!

https://www.ti.com/lit/ds/symlink/tlc5940.pdf?ts=1600008994207&ref_url=https%3A%2F%2Fwww.ti.com%2Fpower-management%2Fled-drivers%2Fsignage-led-display-drivers%2Fproducts.html

To keep the wiring manageable, use a dirt-simple MCU to talk to the TLC5940, and a serial link to send out commands to all your boards, maybe RS-485.
Each board can have its own clock - so you don't need to move a 30 MHz signal around the place.

It's still a monster, but at least a sane one.
I just looked at the TLC5940. At a first glance it looks awesome! :)
But.. not so much when digging deeper. It's only a pwm + dutycycle waveform. There is - and perhaps rightfully so - no direct way to animate using just that chip. That means i need a second chip with the same frequency to control that pwm chip. Sure, that's possible, but i don't see an advantage of that chip + mcu as opposed to shift register + mcu. Regardless, the mcu needs to do the bookkeeping of the animation.

If the concept is really only 140 LEDs then another option is a matrix arrangement, possibly 10 x14, or 12x12, although 10 x14 can use more commonly available IC devices. Then you really only need one driver and one pulse width control at a time. There would be a bit more complexity at the LEDs end, but only a total of 24 drivers, although it could easily expand to 26, allowing 160 LEDs individually controlled. That is one approach, and while the code might be a bit tedoius, it should not be terribly hard. Possibly the low duty cycle might be a problem, worst case you could have ten sets of 14 each, expandable to 16 each.
I don't think that's an option anymore. Unless you know of a way to fit the conditions of 10.000 hertz + 12 bit duty cycle per light point in the matrix idea. All the matrix solutions i've seen thus far have either a 8 or 10 bit duty cycle resolution and definitely a much lower frequency in the 500 - 1500 hertz area.

I'm trying to develop a light where you really don't see any flickering. Also not when looking at it through a camera. that 10.000 hertz puts it well outside the range of normal camera shutter speeds to catch flickering.
 

TechWise

Joined Aug 24, 2018
151
@TechWise Thank you very much for that reply!
This clarifies a lot for me!

Just for the FPGA. Yeah, let's not go that route :) I'm not feeling that adventurous.

Based on what you said, i'm now considering a setup of the following:
  • A master node that only tells other microcontrollers what to do with the LED's they manage. Each slave node probably manages 16 LED's.
    • Say there still are 144 led's. And say the lowest animation time is 10ms (ignore that it feels instant). This master node then needs to let the slave nodes know within that 10ms what needs to be done with the LED's. In terms of timings, it now "merely" needs to be able to send that (4 bytes * 144) within 10ms. Very much feasible i'd say. (important for the next step, the first byte contains the index of the LED)
  • Slave node receives the data and handles those where it has the indices.
    • Slave node consists of cheap MCU with at least a timer (or PWM) with enough resolution for 10.000KHz frequency and a 12 bit duty cycle times 16 to manage all 16 LED's. This "times 16" means it either has the resolution to be 16x as fast (as 10.000KHz * 4096) or have enough timers/pwm's to handle 16. The output will still be fed into a SIPO shift register with 16 outputs.
    • Eventually, the output connects to the gate of a mosfet to drive the LED.

Does that sound like a workable project?
You could have a master node which sends out instructions to the slaves over SPI. You can then have a chip select line going to each node to tell it when to listen. I see no need to use any sort of data packet or have any sort of acknowledgement so you can strip the messages down to the bare minimum. You need a 16-bit compare value to be sent to each slave and each slave controls 16 LEDs. You set the CS line to slave 1 high, then you output 16 16-bit values over SPI, then you set the CS line for slave 2 high and repeat. All the slaves need to do is listen up for 16 16-bit values coming in over SPI. In the interrupt handler for an SPI receive, you could just load the values into the Timer Compare register immediately, so the slaves can be very unintelligent indeed. In fact, the slaves could be so simple that you don't even use Timers for all of the PWMs so you could get away with a simpler and cheaper MCU and just do software PWM.
 

ElectricSpidey

Joined Dec 2, 2017
2,758
My Concept

A_100_LEDs.jpg

The PSOC:
Select the MUX addresses.
Set the analog voltage using internal counter & DAC.
Send digital pulse.

The Tiny:
Polls for digital pulse. (possible ISR)
Converts analog voltage to PWM.
Sends PWM to LED driver.
Waits for next pulse.

AMUX: Carries the analog signal.
DMUX & DMUXS Carries the Digital Pulse.
 

MisterBill2

Joined Jan 23, 2018
18,176
I was not really considering thos slow LED drivers, except as a drive source. I was really considering standard digital logic, although in the 5 volt power range. The LEDs themselves can work up to quite a few megahertz, The thinking was much higher brightness to make up for the lower duty cycle. Regular logic devices are more available than LED drivers, anyway. You would need several fast D/A converters to set up the supply voltage for each row as the other 9 were being addressed. so the code would need to be looking ahead as the array was being scanned. At least that is how I see it. one megahertz D/A converters and Ten megahertz column selection switches. So the flicker frequency would be one megahertz. a bit beyond most cameras.So the control processor would need to be fairly fast.
 

Sensacell

Joined Jun 19, 2012
3,432
I just looked at the TLC5940. At a first glance it looks awesome! :)
But.. not so much when digging deeper. It's only a pwm + dutycycle waveform. There is - and perhaps rightfully so - no direct way to animate using just that chip. That means i need a second chip with the same frequency to control that pwm chip. Sure, that's possible, but i don't see an advantage of that chip + mcu as opposed to shift register + mcu. Regardless, the mcu needs to do the bookkeeping of the animation.

The difference between managing 40 MHz PWM signals and the frame update rate (say 30 frames-per-second) is huge in terms of bandwidth.
Bandwidth costs - you really want all the PWM and current control to happen locally, and in hardware, using only the necessary bandwidth to send out the "animation"
A shift register solution requires massive overhead from the MCU, it would be really difficult to create 16 X PWM in that manner- forget 40 Mhz.

Don't do analog multiplexing! This idea invites all manner of nasty problems, especially if you are looking for brightness ratios of 4096 : 1 (12 bit).
Just trying to move those analog signals around without introducing noise is a monster headache by itself.

Look to the signage industry - they need to solve this problem every day.
 

MisterBill2

Joined Jan 23, 2018
18,176
The difference between managing 40 MHz PWM signals and the frame update rate (say 30 frames-per-second) is huge in terms of bandwidth.
Bandwidth costs - you really want all the PWM and current control to happen locally, and in hardware, using only the necessary bandwidth to send out the "animation"
A shift register solution requires massive overhead from the MCU, it would be really difficult to create 16 X PWM in that manner- forget 40 Mhz.

Don't do analog multiplexing! This idea invites all manner of nasty problems, especially if you are looking for brightness ratios of 4096 : 1 (12 bit).
Just trying to move those analog signals around without introducing noise is a monster headache by itself.

Look to the signage industry - they need to solve this problem every day.
I was not considering using PWM signaling, but rather having the D/A converters setting up the drive voltage feeding the multiplexers. Yes, this is a strange concept, but so is the application rather unusual.
 

Thread Starter

markg85

Joined Sep 12, 2020
13
I was not considering using PWM signaling, but rather having the D/A converters setting up the drive voltage feeding the multiplexers. Yes, this is a strange concept, but so is the application rather unusual.
It's not, conceptually, that unusual. Individual addressable RGB lights are half the story already. Controllable white + warm white (individually that is) is common too. I merely want to:
1. Have a much higher "refresh" rate
2. Have a still smooth animation (say dimming) at that refresh rate
3. Have all individually controllable to allow for super fancy effects

Each point on their own exists today already.
Just the whole picture doesn't. Yet :)
 
Top