Thank you @cpixip.
In this case I am controlling white LEDs only, but as you point out it seems that the color balance changes with current.
1 Like
That is interesting! So your test shows to me that the whitebalance of a white light LED changes noticibly with different driving currents. Something to expect, but I have never checked it. This will make it difficult to use an illumination system based only on white light LEDs at variable light intensities.
1 Like
After additional thinking, I think what we are seeing is a combination of black clipping and white clipping, in addition to a gain difference between the colors. In the following test, using the same current steps as before, I decreased the amount of light using the lens aperture. What -I believe- can be seen now is that there is a difference in colors, which is proportional to current (basically the gain of green, red, and blue is slightly different) and it shows that it was probably the knee and clipping of the camera that was compressing the previous test. Also, we are measuring the result of the entire system led source-current control-camera, and the camera sensor plays a role too. So one would have to be mindful of the non-linearities of the camera and the particulars of the sensor when using a light that is off-balance. But, with the additional test, I am wouldn’t conclude that it would be difficult to use White LEDs only when using current control, the same behavior would happen if using color LEDs that are not perfectly balanced. So my initial conclusion is slightly different, color balancing of light can decrease (or avoid) issues of camera non-linear compensation systems (knee/clipping).
1 Like
A couple of additional information points.
- The video is captured using an HDMI to USB device. OBS provides some settings for a proc-amp on it, so there may be some differences between the live camera output (captured by the device) and a camera recording/capture. I did a white-balance on the light, and still see a bit of off-green.
- The test below was done after doing the camera white balance on the light source, and while the colors remain slightly apart, the variation at different current levels are quite small… it is consistently off through the current range.
1 Like
That could very well be the case! And: good if the whitebalance does not shift too much (as your later tests indicate) when changing the current.
Indeed. You already pointed out the knee and shoulder deviation one would have to expect. Actually, one can circumvent this issue in two ways. One is to use the raw image data coming from the camera, if available. This is what I am using occationally, but it is rather inconvient for various reasons. What I am usually doing is working in the center of the camera’s curve (around values of 128 for 8bit-channel data, for example). I adjust the whitebalance for every one of the five exposure steps I am working with; the corresponding current values are simply stored in an array (see the example given above).
Here’s a log-plot of those currents, showing the deviations between the driving currents:
The efficiency of the green LED is noticibly reduced at larger currents compared to the red and blue one (the later need less driving current than the green one).
As I am using separate red, green and blue LEDs, I have to make that whitebalance adjustment for every exposure value I am using. Your results seem to indicate (at least for the white light LEDs you are using), that in this case, a single whitebalance will be sufficient - great!
Thank you @cpixip.
The workflow that I presently use for capturing uses RAW. Described in this post.
Back to the driver, the good news is that the design performs well, and by its modular nature, if one wishes to do white only or RGB or RGBW is just a matter of building more of these and setting the resistor for the operating current of the particular LED. Thanks again to the exchange of information at this forum, and the insightful discussions, suggestions and feedback.
We are not seeing ripple in the output current of the femtobuck, when the femtobuck’s dimming is controlled with an analog voltage (vs direct PWM). Can you elaborate?
Well, let’s see. The Femtobuck driver uses a AL8805 which, according to the data sheet, “is a step-down DC/DC converter designed to drive LEDs with a constant current”.
Now, the AL8805 is a switching regulator, basically connecting the power rail to an inductor for a short period of time until the requested current level is reached. After that, the switch is opened, but the inductor keeps supplying a somewhat decaying current to the LED. After a short while, the decaying current is sensed by the chip, and the power rail is again switched on. This switch-on-and-off cycle continues at a fast rate to provide an approximately constant current to the LED - albeit with a small ripple, simply because of the principle of operation.
Note that this has nothing to do with the way the input of the IC is driven (be it analog input or PWM), but with the basic principle of operation of this chip.
The ripple inherent in the operating principle will certainly not matter if this IC is used for home illumination purposes, as our human eyes will have difficulties to resolve any frequencies higher than, say, 100 Hz and the on-off cycle of the IC is much much faster than this. But I am not so sure if we are talking about cameras operating in the msec and faster regime.
With this small cutout from the AL8805 datasheet:
Let me also cite directly from the datasheet:
Reducing Output Ripple
Peak to peak ripple current in the LED(s) can be reduced, if required, by shunting a capacitor C2 across the LED(s) as shown already in the circuit schematic.A value of 1μF will reduce the supply ripple current by a factor three (approx.). Proportionally lower ripple can be achieved with higher capacitor values. Note that the capacitor will not affect operating frequency or efficiency, but it will increase start-up delay, by reducing the rate of rise of LED voltage. By adding this capacitor the current waveform through the LED(s) changes from a triangular ramp to a more sinusoidal version without altering the mean current value.
So, even the datasheet is talking about output ripple, and ways to reduce it. And the last sentence indicates that it will never really go away (just be “more sinusoidal”).
This is in contrast to the LED driver described in this thread (or the driver I designed and described elsewhere in this forum) - here, the current supplied to the LEDs is indeed constant over time, without any intrinsic output ripple.
1 Like
We have not yet found a downside to using the femtobuck in terms of image quality, but that may be in part due to the way our scanner works. There are quite a few built-in delays which would hide things like the time it takes to ramp up power. For example, the sequence to snap an image, issued entirely from the control software, is:
- Tell the controller to turn on the color channel at the specified brightness
- Wait for the controller to tell you it’s done
- Capture the frame
- Tell the controller to turn off the channel you’re using
- Wait for the controller to respond
…repeat
We’re communicating via TCP, which has been incredibly robust, but there is a tiny bit of lag. Doesn’t matter too much in terms of overall speed, and our exposure times are likely to be around 20ms/image. So my bet is that any ramping up is happening while we’re waiting for the controller to tell us the lights are one, and ripple is getting averaged out over the exposure time. I’ve done quite a bit of testing on the images we have captured and don’t see anything that could be attributed to that. Of course, in a system that’s pulsing the light from a camera trigger and working at much faster speeds, there’s no time to wait for power to ramp up, and exposure times are so short there may not be enough to cover the ripple.
@PM490 - I might be interested in trying out a version of this sometime soon. We need it to be 36V @ 330mA (max current). Each string of LEDs is a bit different in terms of the forward voltage requirements, but they almost all have the same current requirements. What would need to change in your design to accommodate these requirements?
@friolator when operating in similar power range, it would be changing the values of R1 -changes the operating voltage of the LM317, and the current at the mirror is set by the four parallel resistors at the Emitter of Q3.
36V and 330mA per string (4 strings in the circuit) would not allow the use of the on-board regulator, no big deal if the power supply is clean.
This may require an update on Q4 and good heatsinking. Since this is linear power, what doesn’t come out as light comes out as heat. So it is good to have a sense of the number of LEDs and the forward voltage to verify that the transistor handling the string is adequate. Let me know and I’ll draft some numbers.
Sure:
Red1: 12x 1.99Vf, 350mA
Red2: 12x 2.05Vf, 350mA
Green: 6x 3.3Vf, 350mA
Blue: 10x 3.3Vf, 350mA
IR: 12x 1.4Vf, 20mA
The IR channel is a special case, and we haven’t started testing with this yet as it’s a low priority. The plan is to knock the current down with an inline resistor, which is why we have a current-set jumper block built into the design. But we didn’t hardwire the resistor onto the board at this time, because it will require some experimentation to determine the right amount of IR light to create a dust map.
Thank you @friolator.
For colors other than Ir, the power on the power in the current setting resistors would be between 1.5W and 3W each (multiply times 4), that is a lot of heat. The mirror would also require higher power transistors.
For Infrared, the design would work well, understanding is only one string. I am a bit short of time until next week, but if you are interested in trying it I can give you the specific values for Ir then.
Let me know if you wish to do about the higher power strings, it may not be a good fit for a single string, but if you like to try it let me know… and give me some time to look up some higher power transistors.
Thanks. Heat would be my concern as well. The current setup runs quite cool and is in a box on a DIN rail with several other things, so we’d want to avoid things getting too hot. Though we could put it on an aluminum PCB, and heatsink it, but we’d want to move it out of the box with the other stuff, if it generates too much heat. We’re in no rush. It’s something I’d try out at some point, but the system we have now works fine for us.
If you have a lower-voltage higher-current power supply the numbers would work better. The led strings (as in the schematic) can be adjusted for the desired number of LEDs, and a bit less heat would go into the sensing current resistor.
For reference the schematic configuration is close to 8W of light on 100mA LEDs, a bit more than the total green light (7W) from the numbers on the LEDs you shared.
Having more LEDs provides the ability to split into different sources on the sphere, and/or to physically distribute the LEDs for source pattern or heat management.
From the narrative on the scanning sequence, it sounds you will manage the light heat by only turning on for exposure… if should work. Let me know if you need any additional information.
thanks. Heat on the LEDs hasn’t been much of an issue for us. In part I think that’s because we’re only turning them on momentarily as you say. but also, the LED board is mounted directly to a 1/2" thick slab of aluminum, which is how it’s attached to the chassis. That alone will wick away a ton of heat. And we have mount points in that block for a fan, should we need it, but so far we haven’t.
I’m focused on other stuff now that we have the LED stuff mostly nailed down to our satisfaction, but may come back to this. Really curious to see how it performs relative to what we’re doing now.
Thanks!
1 Like
Afterthought question regarding the quantity of LED chosen.
Context: I was looking at optimizing power to use medium size transistors in a higher current design, and was looking at the quantities of LEDs for each color and the voltage gap (calling the gap Vsupply - (Vf * Qty LEDs). In a linear circuit, that which does not become light would become heat.
The optimal design would set the quantity of LEDs be as many as one can fit budgeting for the transistor Collector-Emmiter operation. In looking at the quantities above, 10x3.3Vf for Blue would make 33V = 3V gap. 12x2Vf for Reds (rounding) make 24V = 12V gap. And 6x3.3Vf for Green make 19.8V = 16.2V gap.
With the femtobuck (switching regulator), that should be no issue.
With the current mirror however, holding the driver transistor with a larger gap (Vce) will require a larger power transistor. Instead, one can manage the gap by increasing the number of LEDs and keeping the Vce to the operating minimum.
Is there a reason to limit the quantity of green LEDs to 6, or red to 10?
A gap of 16V @ 350mA would require that transistor to dissipate 5.6W. If instead of 6 one uses 10 green LEDs the gap would be reduced to 3V @ 350mA = 1W.
The current mirror may not be a good fit for a large voltage power supply, unless precise control of a very large quantity of LEDs is required.
Nevertheless I was looking at how to adjust the design for the larger LED current (350mA) and thought I would run the question on the specific quantities of LEDs.
Thanks.
2 Likes
Yes - light output. The green LEDs are about twice as bright as the reds, and the blues are also very bright. So the goal was to try to get an even amount of light from each channel, thus the uneven quantities of each LED on the board. We specced them all at 350mA because that’s close to the output of the femtobuck (330mA), so we’d be running them a little under full power, hopefully extending their lifespan).
Great!. If that is the reason, then there would not be a problem -other than the cost and the space in the board- using 10 green LEDs running at a lesser current, which would achieve the same light output of 6 green LEDs running at maximum current.
As I said earlier, this design may not be the best fit for that level of power, but is an interesting challenge to contemplate.
That’s good to know.
Space is a bit of a concern as well, but squeezing in a few more LEDs would probably be possible with a few modifications to the board. We’re trying to keep them close together because the entry port of our integrating sphere isn’t especially wide and we can’t really make it any bigger.
I’m not convinced we need as many IR LEDs as we have (but we won’t know until we test that, at some point), so potentially the space we use for those could be occupied by other colors.
1 Like
and it’s possible we may end up needing to use your design after all, since the DACs we’re using aren’t available again until February, and we’re down to our last three. I’ve had two that were bad, out of the box, which seems unusual. Can’t find a supplier anywhere. If these last three I have now don’t work, we may be redesigning in a hurry!