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.

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