Lighting, the way

[RC Blogs]

Read in RC Blogs.

So much of this is just thinking ahead, trying to make sure it's not like being in the army ... hurry up, and wait ... hurry up, and wait ... ad nauseum.

The lighting set up is going to be DIY LEDs. This is for a couple of reasons:

• Cost is important - the less money I spend on lighting, the more I can spend on corals... oh, and the baby due in February [grin]
• Control is important too. The way I'm planning to ultimately set it up is a little more expressive than most. To start off with it'll be more basic, but I intend to enhance it over time

The plan is to use a whole bunch of 3W LEDs from CREE - the Bridgelux LEDs are cheaper, but they're not rated as having the higher current-load capacity as the CREE ones, so they're out. There's not sufficient price difference between CREE and any of the other major vendors to warrant me going with anyone other than the market leader, so the rest are out, too.

I'm not ready to spill the beans on the controller I'll be using just yet - keeping that one up my metaphorical sleeve, but the driver circuit is below:

The board is way larger than it could be, but that's because I'm using the copper on the board as a heatsink for the CAT4101 chips (the 7 large chips on the right-ish side). In my experiments, 1" of double-sided 1oz-copper is sufficient to keep the CAT4101's only warm to the touch. This board actually almost doubles that figure, so the CAT4101's ought to be ok. It's a bit more expensive to build the board in the first place, but that'll pay off with lower failure risk in the long run.

The left side are the outputs that drive the LEDs. There are 7 4101's, so there are 7 +/- connectors for the LEDs to be attached to. On the left are the inputs to the board. In this case I've incorporated a few debugging features (there is a 9-way serial port and several LEDs), as well as the ethernet and power connectors. Ethernet ? Yup, the board runs as a webserver, and the lights can be controlled interactively from there.

All very well, but what's it actually driving - well I've not built it yet, but here's a model of the lighting-pods I'll be making:

This is all T-slot Aluminium extrusion, so it's easy to bolt together and it's very strong. My thinking at the moment is to anodise the extrusion (either at home or get someone to do it) to a black colour, and to not run a canopy - the lights will be the only thing above the tank, which has a very neat black rim around it - it's almost like a rimless tank. There will be 4 of these pods over the 8' tank, with each pod being 23" wide. The extension at the rear of the module is to both attach to the automatic raise/lower mechanism, and as a support basis for the PSU and LED driver board.

You can see there are 7 rows of LEDs, each of which correspond to one driver circuit. That gives me a lot of lengthwise-along-the-tank control of the lighting intensity, since each driver circuit has PWM (pulse wave modulation) ability, and can therefore dim the LEDs along that row. The intention is to have a lengthwise sunrise/sunset ability, ramping the LEDs up or down in brightness to simulate the suns progress across the sky.

The resolution isn't quite as high as it looks because the LEDs are in groups of 6, but each group will be homogenous - so the pattern will look more like:

... where the darker blues are 'royal blue', the whites are neutral white or warm white, and the center row is an ordinary 'blue' LED. Thus, the resolution is effectively halved because the blues and whites combine to form the "colour temperature" of the tank, so will two-rows-at-a-time.

I'm going to be using the BJB LED connectors...

to attach the LEDs because it makes replacement easier in future, and LEDs are constantly getting better and better. If any of them fail, it also makes it easier to swap them out.

Speaking of LED failure, this setup (like most) wires a set of LEDs together in a circuit - in my case 6 LEDs are driven by a single driver. If a single LED fails in closed-circuit mode, ie: the path through the LED becomes very low resistance, all that really happens is that the CAT4101 has to sink a lot more power for that single 6-LED circuit, which it does by heating up. The large copper heatsinking area ought to help out here. The (still rare, but far more likely) failure is an open circuit failure, where the LED "blows" and there is no circuit path left. In this case, all 6 LEDs would normally shut down, and you have to (a) figure out which LED has blown, then (b) replace it before any of the LEDs in that circuit will operate again. This is usually a stressful experience...

Enter the PLED. These little devices are designed to act as a shunt if ever the LED fails. They are transparent to the circuit in normal use, but if the LED fails open-circuit, it provides a circuit path which allows the rest of the LEDs for that driver to continue to operate. This means only a single LED will go dark, and removes the "I must fix this now!" mentality - a single LED failing is neither here nor there. A whole strip failing has much more of an imperative psychological effect, and indeed (on larger strips-of-LEDs than mine) can even have a real negative effect on the lighting.

So, Every LED will get a little bypass circuit attached to it in the wiring harness. For the minimal extra cost, I think it's worth it. These weren't my idea, by the way, I got them from nuclearheli's build

So, that's the basic setup. It gives me quite a bit of flexibility, but it's not all the way there. Once I started thinking about the PLEDs and how they could be used, it seemed to me there was a lot of potential going to waste. Since a PLED can take over the duties of its associated LED, it effectively allows individual control of each LED. The idea is that once I have this protection per LED, I could also wire in a transistor along with it, and allow programmatic bypass of individual LEDs, with the PLED carrying the burden

At first, I was thinking that the 'on' LEDs would be limited to the same PWM level within the same string, but actually that's not the case. If the circuit is laid out as

• {A} master ATMega88 PWM controller for 7 strings, connected via I2C to
• {B} ATTiny per string, controlling the individual LEDs in that string, which
• can switch on or off a transistor that simulates an open circuit on individual LEDs

Where B has the PWM from A as an input, it can modulate the (known) PWM signal via the shunt and remove pulses in the stream. Each LED would actually be individually controllable - only by removing pulses, but that's not a problem because the PWM rate is also under control. Just set the PWM frequency to be that needed for the brightest LED on the string, and the rest are necessarily at most as bright, if they're darker remove some PWM pulses... Bob's your auntie's live-in-lover...

With this in place I was thinking I could do things like simulating storms / cloud-cover with the sun breaking through in places; I could do spot-lighting of the areas within the tank that I wanted (eg: the three islands); I could move that lighting around programmatically. If you wanted to be silly, you could set the lighting to music like people do their houses at halloween - fun for, oh at least 5 minutes... There's more possibilities, is what I'm saying, even if I don't really condone the 'halloween' effect...

So that's the long-term plan. I'll be wiring things up so that this can be done, but the first iteration of the driver won't actually provide for the fine control, I'm on a time-limit here (did I mention the baby in February ?) so getting things sorted out, up, and running is more important than getting everything perfect first time.

For now, I have to check over the circuit for the driver a few dozen more times, then send it off to be made (which takes a couple of weeks), so that when the next task (water in the tank) is complete, I'll have the ability to start the lighting straight away... Planning, planning, planning...