Update on my color-changing LED projects

[jlforester]

I've been working on the color-changing LED landscape lighting recently, and it's nearing the point where it's ready to be installed.  I haven't written much here about it for a while, and I've had a couple of spinoff ideas from that project that I thought I'd post an update, complete with images.  So here goes:

One of the first things I realized right from the start was that I was going to need some sort of weatherproof method for connecting the lights to the power and data bus.  The power bus provides 14V and ground, and the data bus is RS485.  I decided on having small connection points spaced at intervals which would connect up to 4 lights.  The connection points would daisy-chain to each other as well.


This is the prototype conneciton point.

Inside the box is a small PCB which provides screw terminals for up to 4 lights (a 5th light can be connected to the OUT port if there is no need to daisy-chain any more connection points), and an RS485 repeater (I thought it would be nice to regenerate the data signal at each box).


Connection point open, revealing it's innards.


Connection point PCB

All of the lights have been constructed, and I have more boxes and cable glands on order to finish the rest of the connection points.

Spinoff Projects

During development of the landscape lights, some other applications of these lights came to mind, specifically for indoor lighting.  As a result, the LED driver and controllers evolved:


4 Generations of LED drivers, oldest to newest from left to right.

Major changes in each generation driver:

1st Generation to 2nd Generation

• Move power/data connection to center because the cable enters housing at center.
• Add pullup resistors for unused PIC pins.
• Remove jumper for termination (connection point will provide RS485 termination)

The second gen driver is the one being used in the landscape lights.

The third gen driver was the first for the spinoff projects.  The major change here was the shape of the board, addition of screw terminals for the power and data buses (in and out -- they daisy-chain to each other), and screw terminals for connecting the LEDs in whatever form they would take.

A major limitation of the 3rg gen driver is that power for ALL of the lighting fixtures comes from the power/data bus, and the LEDs are limited to 12V.  The 4th gen driver increases the flexibility of the system by adding a power connector and switching the data bus to using RJ45 style jacks.  Each lighting fixture could now have it's own power requirements based on the type and number of LEDs it will be driving.  Here are two samples:


4th Gen Driver with attached Luxeon Star LEDs


4th Gen Driver with attached strip of 5MM LEDs

The Luxeon strip is powered with a higher current power supply, and the 5MM LED strip is powered from a 500ma wall-wart

I also updated the LED controller to add a power jack and an RJ45 jack for the data bus:



General Info
LED Driver: PIC16F628, 10MHz
LED Controller:  PIC18F452, 20MHz
Data bus:  RS485, 62500bps, packet-based, addressable fixtures

I hope I didn't go overboard. 

[SteveyG]

Nice work!

Sounds similar to the project I'm currently working on. How are you driving your luxeons? Constant current? Or just like standard LEDs?


Any pictures of the system working?

[jlforester]

I'm driving the Luxeons like regular LEDs (hence the large resistors hanging off the driver in the picture).  They're part of the spinoff work I'm doing, so I don't have any video of them in action.  We're going to finish the basement and create a family room, and I hope to use the LED strips and Luxeons there.  My thing with the Luxeons right now is thermal management.  The aluminum tube they're mounted on gets very warm, but not too hot to touch or even hold.  Since I want to build them into enclosures, I'll probably have to do some sort of active cooling.  My main concern with active cooling was fan noise, but I found some 25mm fans that were rated at 18db.  The fans are just the right size to mount to the end of the aluminum tube and I hope it will draw enough air through the tube to keep it cooler.  I used Gorilla Glue to attach the fan to the tube.  No pics of it yet.

I have some videos of the landscape lights in my photo gallery at www.wvishome.com/jack/pg.  They're in the LED-based Color Changing Lighting album.  The videos on pages 4 & 5 show the first time I had all 25 lights connected up at once.  Not all of the lights in those videos are in their enclosures.  I didn't have all the enclosures until recently, but you can still get the effect.  I think I'm only about 2-3 weeks from installing the lights outside.  I'll do some more videos then.

[SteveyG]

Thanks for the link to your videos - they look really good!

Are the nodes dumb, or have you programmed them to have some intelligence whereby a single command will for example trigger flashing or fading modes?

Are they 1, 3, or 5W luxeons?

[jlforester]

The nodes are smart.  A fade to a new color can be done with a single command.  The fireflies effect is basically two commands:  SET_COLOR to set the color to white, and FADE_TO to fade back to the base color.  Here's a link to some more info:  http://www.wvishome.com/jack/index.php?option=com_content&task=view&id=18&Itemid=26  Since that was written, I did add a new mode where a single packet can contain color settings for multiple nodes.  I called it the bulk color setting mode.  The closest analogy would probably be DMX512 with the addition of an offset and count.  It can set the color of all of the nodes or a subset in a single packet.  Normally, a single data packet carries a single command.

The luxeons are the 3 watt flavor.

[SteveyG]

The instructions that you send to your nodes are similar to that of some 25cm³ RGB cubes I made a few years ago. The problem I faced with the single direction communications medium I used is that the controller had no idea when a node had completed fading from the start colour to the end colour which meant that I had to sit through the patterns as I designed them to make sure a fade didn't get interrupted half way through with the next fade.

The other option would be to buffer the data, but this leaves a problem such as that it might be on a really slow fade which has 1 minute to complete and then receives a 'turn off' command - the user would be puzzled as to why the lights aren't doing what they're supposed to, then suddenly a minute later they go mad after recieving 10 commands as the user bashes the control unit trying to get some response...

How do your units handle this?

I'm tempted to build my home lighting project DMX-512 style, so the lights just stay at the brightness they are assigned on the bus leaving all the hard work to the main controller, but I can see things getting pretty messy with perhaps 15 or more different fading routines going on at once.

[jlforester]

I had considered that there might be some instances where I needed to pay attention to fade speed when designing lighting effects, especially when effect speed is one of the user-modifiable parameters of the effect.  I hadn't come up with a real solution other than what you mentioned -- carefully designing the lighting effects so that I didn't trample on a fade with another command.

In the first major version of the LED driver code, when a node was fading, it would do nothing else.  Even if a new command for that node was sent, it would get ignored.  The change I incorporated was inspired by a lighting effect I saw on a cruise in 2005.  I made it so that a fade could be interruptable if the node received another command.  I liked the effect it gave the fireflies effect -- the lighting fixture could flash back to white even before it had finished fading from the previous time.  This may not be suitable in all cases, and I'm considering adding a command to set whether or not a fade is interruptable.

I don't actually use the fade all that often.  I have three effects that use it right now -- fireflies, rainbow fireflies, and random fade.  The random fade simply picks a random color and sets all the nodes to that color using a fade transition.  The user-modifiable parameters will be the delay between changes, and the speed of the transition.  I suppose the user could set the delay so that the next transition happens before the previous one completes, but in that case the interruptable fade is probably suitable.

There is one thing I have up my sleeve with the second generation of the controller -- bi-directional comm.  The nodes have had full control of the MAX485 since the very beginning, only the lighting controller didn't.  When I did the second gen controller, I added the ability for it to control the MAX485 and switch over to receiving.  I haven't had enough motivation to actually implement bi-directional comm yet.  The connection points on the landscape lights do not support bi-directional comm, however.  Only the 3rd and 4th gen LED drivers can easily handle it since they don't need the connection points.