PDA

View Full Version : RGB Christmas Lights



JEC
- 28th December 2005, 03:40
Hi All,

I thought some of you might be interested in the Christmas lights I designed for the front balcony this year.

I fabricated 32 'pixels,' each containing superflux RGB LEDs. The pixels are driven by a DMX-512 signal, which is commonly used in theatres and concert halls to control lighing equipment. It's basically a differential RS-485 protocol which runs at 250 KBaud.

In this particular application, the source of the DMX signal is a video clip which runs at 30 frames per second. I hacked together some software bits which extract color data from an arbitrary video file and send it out the door as a DMX stream.

That's right - the lights can be driven by iTunes visuals! Some of the color fades and washes are majestic to behold. :)

It was a small batch / trial run sort of project, but I'm very pleased with the way everything turned out.

Photos, video clips, schematics and a fairly detailed write-up of the project are here:

www.response-box.com/lights/B1167474708/

And yes, it's somewhat over-engineered. But it works, and it only took about 30 minutes to write & test the PBP code for the pixels. Each processor contains an 'F628 running at 20 MHz.

Cheers,

John

DynamoBen
- 28th December 2005, 04:10
Cool idea, btw you can run more than 32 devices. Some of the newer RS-485 transceivers allow up to 128.

JEC
- 28th December 2005, 04:12
Excellent! Do you have a part number?

32 was partly because I didn't want to load the bus too much, partly because of cost for the entire rig and partly because I only have so much balcony... :)

DynamoBen
- 28th December 2005, 04:49
Off the top of my head the maxim MAX13442E, MAX13443E, MAX13444E should fit the bill.

BTW are you posting your PicBasic code on the website?

JEC
- 28th December 2005, 05:31
I really should post the code, but I'd like to tweak it a bit first.

Some thoughts -

My design as it stands is way, way too expensive. I used a crystal per chip because I knew the circuit was stable and would work without any optimization. I'd love to move to something based on a 12F529 or similar, using an internal oscillator.

I haven't tried it yet, but I suspect that even with some heavy assembly code, it would be a challenge to decode full-out DMX and run the PWM code at the same time.

One solution would be to have a crystal-driven PIC receive DMX, grab data starting at the appropriate start code, and re-transmit the required channels at a lower speed.

A string of 48 pixels spaced every 6" results in a string 25' long.

48 pixels x 3 colors/pixel x 8 bits/color x 30 updates/second equals 34,560 bits/second. Or 4.32 KB/s. Plus some start bits and stop bits.

And I suspect that a '529 could receive at 4800 reliably using the internal oscillator. Program the PIC to use Artistic License's BAM control scheme (google it) and the processor overhead drops tremendously. Maybe this could all fit on a 10F part...

I'm also not sure if it's feasable to run a single-ended serial signal 48 feet and maintain signal integrity with unshielded cable and 48 hi-z taps.

If it is, I could save even more money by eliminating the RS-485 receiver at each node.

Anyone done something similar?

The LEDs are still happiest at 70 mA, so direct drive is out.

Ideally, a pixel would contain a '529, 3 x drive transistors, a decoupling capacitor and current limiting resistors.

The current rig uses 18 gauge cable for power and ground and 1 pair+shield for the data connection.

If I could hit $2 or even $3 per pixel, I'd be deleriously happy.

Hmmmm...

Anyone interested in collaborating on a project for next year?

John

DynamoBen
- 28th December 2005, 06:16
How about CAN buss or Dallas one-wire to each of the nodes? You would then have 1 master that would convert DMX to CAN buss/one-wire.

JEC
- 28th December 2005, 16:54
Interesting - I'm only slightly familiar with CAN and the one-wire protocol.

I was thinking also of implementing a self-clocking protocol ala Manchester to handle the communication. Would be nice to run only 3 wires between each pixel.

Synchronous serial would also be fast, but it adds an additional wire...

DynamoBen
- 28th December 2005, 17:58
One-wire is super easy. You only really need messages sent when changes occur. The downfall is it is half-duplex. That being said you are basically running half-duplex now.

The reason I suggested CAN is because it is similar to RS-485 in that it uses two wires. You then have a full duplex network.
http://www.interfacebus.com/Design_Connector_CAN.html

BTW what type of container did you use for each node?

DynamoBen
- 31st December 2005, 17:53
Although these links are not exactly what you're trying to do they might provide some inspiration or additional ideas. Enjoy.

http://thediscobar.blogspot.com/

http://washufloor.blogspot.com/

JEC
- 2nd January 2006, 22:21
Groovy links! Thanks.

Steph 77
- 8th February 2006, 20:32
hello, your project is very interesting and I wanted to know it you could post your basic code same if it is not finished.


thank you


greeting

Steph

JEC
- 16th December 2008, 14:18
Hey Folks...

It's been a couple years. I've updated my lights with a new design and a much bigger quantity. Currently using ~ 663 channels of DMX to drive them.

Pictures here, video to be added when I get a decent camera.

http://response-box.com/rgb/

JEC

PS: Per post #5 above, I'm very, very close to being deliriously happy... :)

falingtrea
- 13th January 2009, 18:44
I don't know if this would help, but you might be able to use portA for a second LED. That way you could get 2 pixels with a minimum cost increase. Maybe use a piece of wire (or a bicycle spoke) to hold the LEDs away from the board so you get the spacing.