"Fooling" constant-current control loops in LED driving?

dhenry:

with 16-bit resolution, ...
have 32-bit resolution for light intensity.

A couple of questions:

  1. What kind of eyes do you have that require that kind of resolution?
  2. What kind of computing power is required for that kind of resolution?
  1. 32-bit resolution would give me 4.29 x 10^9 levels, thus around 9.6 log levels of light intensity which would be little less than normal ambient light levels experienced by humans [1]. So when designing a visual stimulator like that one for example in optimal case you would like to have the whole ambient light level intensity under electronic control and not having to play with neutral density filters for example. For example, using the same system when the subject is light-adapted and after full dark adaptation when retinal sensitivity is significantly increased [2].

[edit] So if you would only want a normal operating range of 256 intensity levels (8-bit) your retinal sensitivity would have increased around 4 log units during full dark adaptation (~45 minutes in full darkness, Light and Dark Adaptation by Michael Kalloniatis and Charles Luu – Webvision) then it would not be possible at all to have the same operating range of 256 intensity levels in this new condition without using attenuating filters such as normal neutral density (ND) filters. That is why the high dynamic range was desired initially.

So the work by Demontis et al. [3] for example gave ~4.5 log units of resolution which is kinda nice for most of the applications, but if you would start modulating the output with a sinusoidal or other waveform envelope [e.g. 4], a little leeway could be nice.

[1] Fain, G L, H R Matthews, M C Cornwall, and Y Koutalos. “Adaptation in Vertebrate Photoreceptors.” Physiological Reviews 81, no. 1 (January 2001): 117–151. Adaptation in vertebrate photoreceptors - PubMed
[2] Lamb, T. D., and E. N. Pugh. “Dark Adaptation and the Retinoid Cycle of Vision.” Progress in Retinal and Eye Research 23, no. 3 (May 2004): 307–380. http://dx.doi.org/10.1016/j.preteyeres.2004.03.001.
[3] Demontis, Gian Carlo, Andrea Sbrana, Claudia Gargini, and Luigi Cervetto. “A Simple and Inexpensive Light Source for Research in Visual Neuroscience.” Journal of Neuroscience Methods 146, no. 1 (July 15, 2005): 13–21. http://dx.doi.org/10.1016/j.jneumeth.2005.01.007.
[4] Gooley, Joshua J., Ivan Ho Mien, Melissa A. St Hilaire, Sing-Chen Yeo, Eric Chern-Pin Chua, Eliza van Reen, Catherine J. Hanley, Joseph T. Hull, Charles A. Czeisler, and Steven W. Lockley. “Melanopsin and Rod–Cone Photoreceptors Play Different Roles in Mediating Pupillary Light Responses During Exposure to Continuous Light in Humans.” The Journal of Neuroscience 32, no. 41 (October 10, 2012): 14242–14253. http://dx.doi.org/10.1523/JNEUROSCI.1321-12.2012.

  1. Computing power meaning what exactly in this context? I could control a LED driver with DMX input and DC output with 16-bit resolution using a DMX shield and then switch that with a Uno32's 16-bit PWM for example so not very special hardware would be required

DVDdoug:
Uh... Yeah.... Dynamic range is the difference between full-bright and fully-dark. You can't get any more dark than "off", so you can only go brighter ... and you can't (or shouldn't) go over the device's maximum current rating on the bright-end.

16-bits (converted to decimal) gives you a range from 0 to 65,535. I'm sure you can't tell the brightness-difference difference between 0 and 1, between 65,534 and 65,535, or between 30,000 and 30,001, etc.!

So maybe I was not specific-enough about the application so it would be for a generic-purpose visual stimulator to be used in vision research. So I agree that in general the difference that you mentioned would not be of a huge aesthetic difference but especially if you start using the system with other species than humans, the same logic might not apply anymore.

so not very special hardware would be required

You probably want your pwm sessions to end fairly quickly. Say 50hz, or 20ms.

Each tick of a 32-bit pwm train would be then 20ms / 2^32 = 5e-6 us. or about 200Ghz.

Good luck with that.

dhenry:

so not very special hardware would be required

You probably want your pwm sessions to end fairly quickly. Say 50hz, or 20ms.

Each tick of a 32-bit pwm train would be then 20ms / 2^32 = 5e-6 us. or about 200Ghz.

Good luck with that.

I think the 80 MHz clock signal provided by the 32-bit timers of Uno32 (chipKIT32/chipKIT-core · Discussions · GitHub) should be enough for my purposes at this point. So the duty cycle resolution does not have to be necessarily 32-bit and I can compromise duty cycle resolution for temporal resolution and vice versa.

So I was thinking of combining 16 bit for constant current control and then another 8-16 bits for PWM duty cycle resolution to increase the already 16-bit resolution of the DC (unswitched current). So I did not really get the requirement for a 200 GHz frequency?

[edit] So if I did not quite misunderstood the PIC32 tutorial there: PIC32MX: PWM Motor Control - Northwestern Mechatronics Wiki with 80 MHz you can have a PWM frequency of 20 kHz with 4000 duty cycle steps?

// init Timer2 mode and period (PR2) (frequency of 1 / 20 kHz = (3999 + 1) / 80MHz * 1
OpenTimer2( T2_ON | T2_PS_1_1 | T2_SOURCE_INT, MAX_DUTY);

4000 duty cycle steps

That's about 12 bits, on a 80Mhz mcu.

From there, it goes up exponentially.

If I were you, I would try to understand what you are trying to do, and what can be done realistically and decide where to compromise.

I got lost with the numbers, but what about having one pwm output from the arduino, switching a MOSFET as a normal switch mode with inductor and filter to feed to the LEDs a variable DC, and then another pwm pin to the drivers for the normal duty cycle brightness?

Should give you 255 x 255 levels of brightness ( OK perhaps not 255 as you would have to play with the variable DC not going below the min V of the LEDs, and that side wouldn't be linear brightness wise)

dhenry:

4000 duty cycle steps

That's about 12 bits, on a 80Mhz mcu.

From there, it goes up exponentially.

If I were you, I would try to understand what you are trying to do, and what can be done realistically and decide where to compromise.

I get the impression that I was not very clear what I wanted to do, so maybe a simple scheme would illustrate the idea a bit better.

So I already have a LED driver that I can control with DMX512/RDM signal at a theoretical 16-bit resolution and when measuring the light output with a power meter, some bits are lost but the resolution is still quite good in practice. And that driver can combine to 8-bit DMX signals as HI and LO bytes (or coarse and fine) so that part is already under control with the digital output pin of Arduino and a DMX shield (Arduino Playground - DMXShield)

So now my problem is that I cannot really switch the output current from that LED driver with a single transistor as the control algorithm of the LED driver would like to keep the output current constant. So I thought of adding the PNP transistor to the scheme so that it would conduct when the PWM signal from Arduino is LO (basically short circuit) to "fool" (thus the title) the LED driver to sense non-changing current even though I would be changing the current going through the LED.

I could then independently set the DC current from LED driver with DMX at 16-bit resolution and add to that the switching stage with 8-16 bit resolution of duty cycle which would be totally satisfactory for me and I would not need to go to the 200 GHz clock frequency ever.

In other words

ResolutionSUM = DMX(8 bit + 8 bit) + PWM(8-16 bit) = 16 + (8 to 16 bits) = 24 to 32 bits

DVDdoug:
16-bits (converted to decimal) gives you a range from 0 to 65,535. I'm sure you can't tell the brightness-difference difference between 0 and 1

Using PWM? You probably can...the difference between 0 and 1 is very hard to eliminate.

DVDdoug:
, between 65,534 and 65,535, or between 30,000 and 30,001, etc.!

Brightnesses in that range are a bit more difficult.

fungus:

DVDdoug:
, between 65,534 and 65,535, or between 30,000 and 30,001, etc.!

Brightnesses in that range are a bit more difficult.

And as my main interest for such a system is scientific, so if the power meter detects a difference between 30,000 and 30,001 or more importantly between 40 and 41 then it is a useful property for me. And then you could for example use the setup for a psychophysical experiment to actually measure which step differences are actually perceived :stuck_out_tongue:

petteri_t:

  1. 32-bit resolution would give me 4.29 x 10^9 levels, thus around 9.6 log levels of light intensity which would be little less than normal ambient light levels experienced by humans [1]. So when designing a visual stimulator like that one for example in optimal case you would like to have the whole ambient light level intensity under electronic control and not having to play with neutral density filters for example. For example, using the same system when the subject is light-adapted and after full dark adaptation when retinal sensitivity is significantly increased [2].

You should have started by stating what it is you're trying to do. It always saves a lot of time. (All posters take note!)

For a first attempt I'd use a TLC5940. That gives 12 bit PWM values (0 to 4095) plus a separate six-bit 'power' setting for each LED.

For steps smaller then 4096 you can multiplex the PWM values.

eg. To get a brightness value of 1/32768 you can sent the following PWM sequence: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ...

(ie. one PWM cycle of 1/4096 followed by eight PWM cycles of 0/4096).

Eight steps of mutiplexing gives you an extra three bits, that's 15-bit precision. Combined with the power setting it might be enough. To get better results with cheap hardware could be difficult.

fungus:
You should have started by stating what it is you're trying to do. It always saves a lot of time. (All posters take note!)

For a first attempt I'd use a TLC5940. That gives 12 bit PWM values (0 to 4095) plus a separate six-bit 'power' setting for each LED.

I am sorry about the initial confusion. I was not aware that the need for dynamic range would attract more interest than the actual electronics problem that I was trying to solve.

I did not quite understand the benefit of the TLC5940 chip to my project?

The maximum current (1000 mA in my case, whereas the maximum current of TLC5940 seems to be 120 mA?) is already set by the ISTL Quattro CC LED driver (http://www.istl.com/quattrocc.php) that I use to drive my power LEDs so I would want to switch that current with the proposed transistor scheme. And I already have the Digilent Uno32 which provides 5 PWM outputs which is sufficient for my use so there is no need to multiplex and get more PWM outputs.

petteri_t:
The maximum current (1000 mA in my case, whereas the maximum current of TLC5940 seems to be 120 mA?) is already set by the ISTL Quattro CC LED driver (http://www.istl.com/quattrocc.php) that I use to drive my power LEDs so I would want to switch that current with the proposed transistor scheme. And I already have the Digilent Uno32 which provides 5 PWM outputs which is sufficient for my use so there is no need to multiplex and get more PWM outputs.

Before we go on: Is there anything else you forgot to mention...?

fungus:

petteri_t:
The maximum current (1000 mA in my case, whereas the maximum current of TLC5940 seems to be 120 mA?) is already set by the ISTL Quattro CC LED driver (http://www.istl.com/quattrocc.php) that I use to drive my power LEDs so I would want to switch that current with the proposed transistor scheme. And I already have the Digilent Uno32 which provides 5 PWM outputs which is sufficient for my use so there is no need to multiplex and get more PWM outputs.

Before we go on: Is there anything else you forgot to mention...?

I think the specs were given before, but basically in summary. I have:

  • ISTL Quattro CC LED Driver -> 1000 mA DC out, DMX Control
  • Both Digilent Uno32 and Arduino UNO to generate the PWM
  • Power LEDs, maximum forward current 1000 mA

So what I lack is somekind of transistor circuit to ensure that the control algorithm of the Quattro CC LED Driver provides constantly 1000 mA and does not try to correct the switching artifacts if I just had on NPN transistor.

And I tested the thing with a lab power supply so it provides also constant current and could be used instead of the ISTL Quattro CC for testing, or for final implementation.

[edit] Sorry if this forum category deals with multiplexing LEDs rather than driving LEDs without multiplexing but thought of this the most fitting part of this question but maybe I was mistaken?

So what I lack is somekind of transistor circuit to ensure that the control algorithm of the Quattro CC LED Driver provides constantly 1000 mA and does not try to correct the switching artifacts if I just had on NPN transistor.

I have no idea what "switching artifacts" you are talking about but if I understand the module correctly, it sets the duty cycle for each channel on command.

So all you need to do is to low it with the desired intensity and it will do that by itself.

What else are you trying to do?

dhenry:

So what I lack is somekind of transistor circuit to ensure that the control algorithm of the Quattro CC LED Driver provides constantly 1000 mA and does not try to correct the switching artifacts if I just had on NPN transistor.

I have no idea what "switching artifacts" you are talking about but if I understand the module correctly, it sets the duty cycle for each channel on command.

So all you need to do is to low it with the desired intensity and it will do that by itself.

What else are you trying to do?

Switching artifacts meaning in this case the time that the LED is not on.

So if I have a duty cycle of 50% with the LED current being 1000 mA, then the time average of that is 500 mA, but the ISTL Quattro CC wants to output 1000 mA all the time so it won't like that half of the time there is no path for the current.

So the idea of putting a PNP transistor there to provide path for the current when the LED is turned off by the PWM would in theory "fool" the ISTL Quattro (or any other constant current source) to think that the current is truly constant. I guess if I had access to the derivative part of PID-algorithm of the LED driver I could tune it so that it would not react to such switching but that doesn't seem to be the case

but the ISTL Quattro CC wants to output 1000 mA all the time so it won't like that half of the time there is no path for the current.

Are you sure about that? If that's the case, how does the controller dim anything?

Essentially, you are saying that the controller is not capable of doing what it claims to do.

dhenry:

but the ISTL Quattro CC wants to output 1000 mA all the time so it won't like that half of the time there is no path for the current.

Are you sure about that? If that's the case, how does the controller dim anything?

Essentially, you are saying that the controller is not capable of doing what it claims to do.

According to the manufacturer and initial testing it is the case, and I don't really understand how would that be in conflict with the dimming capability?

Because you feed the driver DMX (DALI or PWM also possible) and then it outputs the current according to that. And then I would like to add my own circuit to that output and dim the output even more with the PWM from Arduino

They didn't provide a schematic for the controller. But if you look at the picture, you will see four inductors and 8 caps. This thing is a switching mode power supply (boost / buck I think, given the voltages). That means that it has a current sampling resistor in serial with the leds. The dimming controls the controler's duty cycle so that the output voltage across the leds produces the desired current (voltage drop) on the led string.

How the controller behaves with a dynamically changing low is really unknown, and unknowable until you put something to it. From my experience, I would say that something like that shouldn't be attempted.

dhenry:
How the controller behaves with a dynamically changing low is really unknown, and unknowable until you put something to it. From my experience, I would say that something like that shouldn't be attempted.

Well now we finally get into to my question after all these messages. So this is exactly what I was trying to accomplish, and the manufacturer itself said that the controller would not like the switching of the current output, but the dual NPN-PNP-transistor pair could work.

And I now soldered a simple transistor pair (NPN and PNP bipolar transistors) to be tested with my benchtop voltage supply and now on its display the current stays constant which was not case with the inital attempt with only one transistor. So basically combined the NPN and PNP of those together and matched the resistor values for my hFE of around 30:
SECARS Homepage - SECARS (Figure 1 and Figure 2)

Now I can control the LED intensity with the Arduino but now the light intensity is slowly declining/fluctuating (-2% of the initial value more or less) with the given duty cycle when left untouched so there is some problem that I don't understand at the point.

What you need is a shunt, electronically controlled load in parallel with the led string. The load will divert current away from the leds but without reducing the current going through the sampling resistor.

As the load is referenced to the leds' cathode, building it is no small matter.

dhenry:
What you need is a shunt, electronically controlled load in parallel with the led string. The load will divert current away from the leds but without reducing the current going through the sampling resistor.

As the load is referenced to the leds' cathode, building it is no small matter.

You happen to have any insights what to look for when trying to find similar example circuits / projects?