Squeezing (seemingly) More Light From an LED




Introduction: Squeezing (seemingly) More Light From an LED

This project started as simple enough an idea, turned into a monster build over months and - yeah! - is finally finished. But that is a story for a blog (possibly to appear soon on www.hase.net/blog).

Here is Instructables, so let's see what I can pass on of the stuff I tried and learned here.

The basic idea behind the project is to make an LED appear brighter than it actually is.
Which saves power, and that is always a good idea in a camper.
It also saves heat generation (which is the same as "saving power, btw."), which is always a good idea when it comes to semiconductors such as Light Emitting Diodes.

From a pure Physics point of view, the idea is completely bonkers: conservation of energy dictates that the LED can emit only as much light as you pump electricity trough it - or less (the rest is converted to heat).

But appearances are not always about physical reality but about what biology (our, human biology) makes of it.

Long story short: the human eye is not a linear light energy -> brightness conversion sensor, so we can trick it into seeing more brightness than there is light for.

My buddy and me finished outfitting his camper with his new LED lighting just a few minutes ago, so I can not actually tell if the theory works.
Do your own experiments and please report back to me.

Step 1: All Theory Is Grey

And this stupid guy doesn't even pep it up with a nice picture.
Sorry, I have no picture handy to explain Persistence Of Vision.

The effect is well known and has a lot of uses.
To the human eye, motion pictures appear smooth at approx 25 Hz picture frequency. Doves would see a movie as a flickering sequence of still pictures, aka slide show. But what do they know (or care) about cinema anyway?

POV is one effect that comes to play in our little trick.

Another well known effect is the non-linear response of the eye to light hitting the retina.
The response is approximately logarithmic.

I think that might be the reason why all the figures in discussion of photometric units like candela use a logarithmic scale.

Basically: if we cut the power to an LED in half, the light will appear brighter than just "half the intensity". By how much? That is hard to say, there is no standard measurement for that.

If you compare the output of light sources, the unit is lumen; this value describes the amount of visible light coming from that source. Since the lumen is based on candela, it already has the spectral sensitivity of the eye factored in: an amount of (electromagnetic) energy in a 555nm/green wave will appear much brighter than the same amount in the form of a 780nm/red wave: the eye reacts differently to different wavelength.

Manufacturer of LEDs are using this to trick the eye: by excluding some frequencies and instead strengthening the emissions int he 555nm and its complement (customers want white light, not green), the efficiency (measured in lumen per watt) can be increased at the cost of the color rendering quality.
It all sounds very very complicated at first, but actually isn't that tricky.

But since the eye is so easily tricked, we have used that for a long time in technology (for example using only 4 inks in print and still getting lots of different color impressions).
And some of these tricks can interfere with each other, like "white" light that is not a continuum (meaning: all frequencies present) hitting a surface printed with an ink that is designed to reflect one wavelength in particular (like the "bright" colors of the HKS or Pantone scales): this looks great in sunlight (perfect continuum) and possibly shitty in the light of a super-efficient LED lamp.
Simple interference of eye-deceiving trickery.

My little trick here is based on the fact that a sequence of short, fast light pulses will be "seen" by the eye much brighter than it (by measurement in lumen) is.

Which basically boils down to PWM

Step 2: The Controller Circuit

Its actually very simple.

If you read my other instructable, the circuit may look familiar. Probably because it's identical.

The three pushbuttons are actually one rotary encoder; I was simply too lazy to create an encoder symbol for KiCAD at the time. I only drew the circuit to show you, I made the prototype just by seat of pants. (which is usually a bad idea and will bite you in the backside like it did me. Different story altogether).

The pushbutton in the encoder - sw3 in the schematic - turns the whole contraption on and after that serves as a pushbutton for the Arduino (model Nano V3 in this case, but any AVR Arduino would do).
The "switches" sw1 and sw2 are the A and B phases of the rotary encoder.

To read the encoder, I use the ClickEncoder library, not because I think it is the best implementation out there (and the number out there is approaching n-squared; n being the number you can actually overview).
But the lib works well in this single-encoder use case, provides acceleration (non-linear counting of pulses depending on rotational speed; much like mouse-pointer acceleration) and click, double-click and hold/release differentiation for the button.
All I needed.

The circuit has two outputs: the 12V controlled voltage to feed the LED driver board (not shown) and the open drain of the IRLZ44 Power MosFET.
The LED (also not shown; I was really lazy or sloppy when drawing that :-) is connected to the positive output of the driver board and to the open drain of the FET.

Caution: This circuit can only work with the el-cheapo non-isolated driver boards that have a common GND for input and output. All the boards I saw on eBay fulfill this criteria, since that is pretty much the cheapest way to implement a buck or boost converter.

Errata: the circuit show has the FET driven by pin D5, but I moved that to D9 later to get a 10bit-PWM.

A word on the MosFET: I like the IRLZ44, probably because I got a bunch of them quite cheap some time ago.
But the same circuit would work well with other FETs in its place.
Since we are driving the FET from a controller pin, it is essential to use a "logic level" FET: these will open quite a bit or even totally when driven with a 5V logic signal. Regular (non-logic-level) FETs will require gate voltages in the 10V-15V range to fully open; old workhorses like the BUZ10 will not even start to significantly conduct at 5Vgs.

And a word on Power MosFETs in general and how to use them: not like this :-)

You should always limit the gate current (which actually I do: the AVR output is effectively current-limited...) and use a gate drive that ensures fast turn-on and fast cut-off.
The reason your want the transitions to be fast is this: each transition burns a certain amount of energy (that is: converts electricity to heat) inside the transistor. This amount is higher with longer transitions; so if your gate driver takes his sweet time to charge or discharge the gate, the heat buildup in the transistor will be high.

Since each transition burns this amount, the switching frequency becomes a multiplier: Losses will increase linear with the switching frequency (provided the gate drive stays the same).

In my experience, an AVR pin will drive an IRLZ44 gate just fine, if the AVRs power supply is above 4.8V (but below the chips maximum of 5.5V, of course).
And the transistor will not require a heat sink if switched at a few hundred Hz (as in typical lighting PWM applications). But be careful and use a heat sink if in doubt.

Step 3: Keeping Cool

Many fans of the incandescent bulbs who criticize the evil modern LEDs that do not provide the right kind of light, correctly point out the need for a heat sink.
A light bulb can easily handle temperatures that will burn you - that is the way they a built.
LEDs like to keep cool or rather, for you to keep them cool.

So, while the PowerFET might not require a heat sink, the Power LED definitely does.

When I cobble together quick-and-dirty LED lamps for the workshop/mancave, I simply screw the LED to an old CPU heatsink with heatpipes. Works fantastic, passive up to n Watts, with fan up to 3*n Watts, I'd say. But a lamp has to be quiet, so I usually use no fan.

For the camper, this was not an option: the car needs a high WAF (wife acceptance factor).

Also, space is limited somewhat.

The design I am showing here is not at all proven (!). Finished today it will have to prove itself in the upcoming holiday season.

But I expect no problems: a 4mm aluminum sheet, 42 by 42cm wide, is sunk into a ceiling panel as the main heat sink.
This is covered by 0.3mm brass to increase the WAF (and also because I like brass :-).

The LED is screwed to the aluminum after a thin layer of thermal grease had been applied.
If you do something like this, make sure to use very thin layers of thermal grease: it is only there to make sure, there is no air trapped between the heat sink and the semiconductor housing; its thermal conductivity is way lower than that of a direct metal-metal contact.
This is still true for the expensive thermal grease with silver powder in it.

I thought about adding thermal switches. I usually do in installations where traveling to the device is expensive (in terms of time or money) or where heat buildup would cause a risk of fire.
In this case, I skipped the bi-metal switches - because fixing stuff is almost as much fun as making it the first place, right?

The rest are details: because the CNC milling of the pocket in the wood of the ceiling plate didn't go as planned (frecking homebrew CNC mills! Unreliable, but fun to make), and because my buddy went a bit overboard when grinding the brass, we had to hide a couple of ugly marks behind a rather wide frame around the heatsink. (Did I mention this was kind of a monster build? It sure proves O'Tooles law: Murphy was an optimist).
Just do not tell my buddies wife, we'll try to pass this off an integral part of the artistic concept.

The LED is - not very well - hidden by an enclosure; the diffraction plate did not come out as well as expected (you can still see the LED under it), but it'll do for the vacation trip by bud is taking on.
The diffraction plate and the pieces for the spacer are acrylic sheet engraved and cut on the laser cutter; but they probably replaced when he gets back.

And once he gets back, we'll start the controlled experiments, measuring the effectiveness of the heat sink concept.
So before I make something similar for my car, I'll know if the aluminum is enough or a heat pipe is needed :-)

Enough of the show-and-tell part lets talk software.

Step 4: Software: Almost Trivial

The Sketch is pretty simple and straightforward.

We use the ClickEncoder library for the encoder (bummer) and the Timer1 library to get a 10bit PWM. Even with 1024 steps the lower settings seem pretty far apart, but that can not be helped. And it does not hurt overall function.

The compensation for the eyes sensitivity is simplified: instead of an exponential function I us a square function.
The increase in visual brightness from one encoder notch to the next does not appear strictly linear, but still the behavior is much better than a simple, linear dimmer: with a linear curve, brightness increases rather quickly at the lower settings and then apparently not at all for the last few notches.
Good enough for me.

The ClickEncoder provides us with an 8bit value, which we simply square (temp = dimmer * dimmer;) and then scale back to the 10bit limit (pwm10 = temp >> 4;). The arithmetic right shift is essentially a division by 16. With that scale, the dimmer operates quickly and still with good resolution.

Ignore the fiddling with the onboard LED on pin D13: I used that in debugging :-)

When the Arduino comes on, the PWM duty is set to a minimum value. This is part of the Zero Standby feature of the circuit: if the device draws power, there must be a visible indication. And the Power LED is very well visible.

In an early version, I used the long-press of the pushbutton (actually: the "released" state from ClickEncoder, which is set after a long press) to shut down and double-click to set 100% PWM duty (maximum LED power).

It is not possible to use the long press itself: the Arduino would set the kill_pin just fine, but the pushbutton would immediately turn the device back on...
In the final version, we went for long-press => max. power and double-click to shutdown.

Please note that if you use Timer1, you must use pin D9 or D10 to drive the FET; only those are available to Timer1. The connection in the schematic still works, but with 8bit pwm (Arduino analogWrite) only.

Lets finish with a ProTip :-)

After I was done programming, I flipped the BOOTRST fuse in the AVR (all other fuses I kept as they were).
I used my AVRDragon, but you could do the same using another Arduino as SPI programmer (there is articles about this on the Big Evil Internet).

When BOOTRST is one way, program execution will begin at the bootloader after a reset.
This delays execution of the Arduino application by 2s, at least with the bootloader in my Nano.

When BOOTRST is the other way, program execution begins at the program itself - the bootloader is skipped, the delay eliminated.

(one way/the other way: I can never remember, whether "programmed" or "cleared" or "active" or whatever is what.
So I read the fuse settings from the working Arduino, feed the values to the hand fuse calculator, flip whatever is in BOOTRST to the other way and program those values back).

Of course, flipping BOOTRST disables the boot loader and locks out the Arduino IDE from reprogamming the device. But if I really need to change the software, I can simply flip BOOTRST back again using the same method I used the first place.

This is it for today, hope to have instirred a few ideas and

Happy Making!

Be the First to Share


    • Mason Jar Speed Challenge

      Mason Jar Speed Challenge
    • Bikes Challenge

      Bikes Challenge
    • Remix Contest

      Remix Contest

    3 Discussions


    4 years ago

    Hasenbaby, I bow to your superior knowledge of LED's, how they function, and how the human eye responds to light! (keep in mind, part of my final exam in high school, as a freshman in 1965, was to sketch a workable schematic of a 5-tube AM radio, with acceptable resistor values... LOL) I just started "playing" with 12V LED's in my personal 12V emergency light projects... Still trying to juggle Lumens vs Lux in my tired old brain while balancing "output" against dispersion and perceived brightness and 1/2-life of a charged battery and the adaptability of the aging human eyeball! I hope to understand at least the basics of your wonderful post in the near future. :-) One question- I believe your controller pulses "peak" light output, but at what freq? Prob. I missed something, I grow stupider by the day. I just remember that many people are subject to the catatonic effects of aging flourescent lights at 60 CPS. I mean, HZ! Thank you for your fascinating post!


    Reply 4 years ago

    pwm frequency?
    Actually: I have no idea :-)
    I simply use whatever the Timer1 library for Arduino creates. I think it is a few hundred Hertz.
    Definitely enough for me not to see any flickering, even at the lower intensities (the short pulses).

    So far I can tell tht running a 30W LED at 30% duty cycle (9W effective) looks brighter than a 10W LED at full power.
    My DSLR measures the 9W as lower - because that is the effect on the sensor.

    Next improvement to be done: implementing a higher PWM resolution. the 10bit (1024 steps nominal, 128 steps effective when using the value-squared scheme to approximate the eyes sensitivity curve) is a bit coarse. But still functional.

    The human eye can indeed be affected by 60Hz flicker (even more by the 50Hz flicker we have here in Europe).
    The reason is that the time-resolution is different for the different parts of the retina.
    The central area has better spatial resolution (more detail) and better color resolution.
    The peripheral vision has a much better time resolution, so it can actually see flickering when the central-area sensons do not. I nthe brain, this is merged into a non-flickering picture with annoying side-effect - causing headache and other symptomps in some inviduals. This specially affects older people, because their exes are under more stess anyway (loss of sensor cells, loss of near-sight focus, slower focusing etc.).

    With incandescent bulbs, the effect was small: the glowing wire would not cool down very much in 1/120th of a second, so it smoothed out the light output, resulting in no flickering.
    Fluroescent bulbs/tubes flicker more - especially if they use a more fluroescent than phosphorecent converter. The phosphorescent substances are less bright, so the manufacturers were usually market-pressed to use the type with the bad side-effects.

    But all that goes away completely at a few hundred Hertz: that is too fast even for the peripheral ganglions (iirc. the sensors are similar, its the ganglions that to the first stage of computing on the picture, and this is slower on the central part to achieve the higher resolution; gosh, biology class was over 30 years ago...).

    Long story short: at 120Hz or 150Hz to be on the safe side, there is no flicker and no adverse effects.
    Your typical LED driver (constant current source; usually using a switching regulator of boost or buck topology) will run at a few hundred kilohertz, definitely zero flicker there.

    The cheaper types can not be dimmed, and the types that have a dimmer function usually reduce the LED current.
    This gives smooth dimming action, zero flicker but does not use the POV-effect I am using here.
    So I use pulse modulation of the output of a (very cheap) boost converter.


    4 years ago

    I applaud you for the depth of this instructable but I have to question it's value outside of experimentation just based on the last paragraph of your intro.