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

dhenry:
You do realize that that particular kit is not a constant current driver, right? However, if you add a small npn + a resistor to it, you can easily make it into a constant current drive.

Yes I realized that it was not a constant-current driver but had that available and thought of trying it with the benchtop power supply (ISO-TECH DC Power Supply IPS 3303S, http://radionics.rs-online.com/web/p/bench-power-supplies/6842998/). Do you think there is a more elegant way to switch the output from constant current supply such as those from benchtop lab power supply or from commercial LED drivers

[edit] The basic circuit that I know just sets up the current with the R3 resistor (http://www.instructables.com/id/Power-LED-s---simplest-light-with-constant-current/step2/Specs-Function/) but as I would already have the constant current source, I would like to tinker the circuit so that I could add the switching stage.

I am not sure what you are trying to do , but you could drive a simple constant current driver with the pwm to vary the brightness while limiting the max current to 20mA

Boffin1:
I am not sure what you are trying to do , but you could drive a simple constant current driver with the pwm to vary the brightness while limiting the max current to 20mA

Basically I just to want to increase the dynamic range of the light intensity. So if I would for example have a constant current supply (DC output) with 16-bit resolution, I could then the switch off then that output with 8/10-bit PWM of Arduino Uno or 16-bit PWM from Digilent Uno32 for example so I would in theory have 32-bit resolution for light intensity. So with that design idea I could replace independently the constant current and switching parts if better components become available. And my max current to be switched is at the moment 1 A.

So in other words the current sensing part of the constant current source would not probably in general like that the output current is switched ON and OFF and I was looking for ways to make the feedback loop to think that the current output from the constant current source is always the same even though the current passing through would not be the same, i.e. it would be determined by the PWM duty cycle outputted from Arduino. And when the PWM would be LOW the current would go through the PNP-transistor.

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?

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.!

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.