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