RGB Light Show (Wired/Wireless)

We were able to get our hands on a set of par-56 RGB led spots. We thought it would be fun to create a wireless controller for these. While experimenting, we soon found out that you may not want your stage lighting depend on the reliability of a cheap 433Mhz transmitter/receiver pair, so we soon added an option to send the command through a wire as well.

Each controller is based on an ATTiny 2313 and performs PWM control on 3 separate RGB spots (9 channels). Since the whole PWM is controlled through timer interrupts in software, 8 bits is the best resolution we could manage. This is pretty basic for an RGB spot, especially given that our perception of brightness is not linear to the relative pulse widths (or in other words: going from 1/256 to 2/256 pulse has a much bigger effect than moving from 200/256 to 201/256). Note that the schematics are for common-cathode leds, hence the P-channel mosfets.

The software implements 3 faders that control 3 channels each. Every fader uses Bresenham's line algorithm to smoothly change the 3 RGB values from some starting color to an end color, essentially creating a 4D line (R,G,B,time). Interrupt-driven pwm control makes sure that the RGB-values are translated into pulse widths.

top side of the print with 1x4 headers for the rgb-spots, a 2x3 programming header, a push button to program a device address and a 433Mhz receiver

Protocol

The protocol consists of three stacked protocol layers, from low to high

• RS-232, 1 start bit, 1 stop bit, 8 data bits. We expect ttl-level at the pins. In essence, the UART input pin of the AVR is connected directly to the data line of the 433 Mhz receiver.
• Our own packet protocol, with 8 bit addressing and CRC. See the table below.
• The spotlight command protocol.

packet protocol

packets look like this:

preamble (any sequence of zeros)

end-of-preamble (0x55)

address (1-255, 0 means broadcast)

size-of-data minus one (0-15), upper 4 bits unused

data bytes

2 byte CRC

The CRC is a 32 bit xmodem checksum. It covers only the data bytes. In hindsight, it should have covered the address and size byte as well and we may change the protocol some day to do just that

Command bytes

The commands for the spotlight controller are transported as sequences of data bytes inside the packets as described above. Each sequence consists of at least a command byte. Depending on the command, the command byte may be followed by parameters. In general, the most significant 4 bits of the command word describe the command (room for 16 commands), the lower 2 bits may contain a spot number, depending on the command. Arguments in <angle brackets> in the following table are encoded in the lower 2 bits of the command byte.

value	meaning	arguments	comments
0x90	wait_for_fader	<fader>	halts processing further commands until the given fader has finished
0xA0	fade	<spot> time red green blue	lets the spot fade from its current color to the given one
0xB0	set_initial	<spot> red green blue	sets the initial (switch-on) values for a spot
0xC0	hold	none	stops all faders
0xD0	resume	none	resumes all faders
0xE0	set	<spot> red green blue	sets the color for the given spot
0xF0	address	new addres	sets the device address of this controller, if the address button is pressend simultaneously

Commands are treated as a stream of bytes. That is, a command could be spread over multiple packets and a single packet could contain multiple commands. An example sequence would be:

   0xE1,0x0,0x0,0x0, 
   0xE0,0xFF,0x0,0xFF, 
   0xA1,0x32,xFF,0xFF,0xFF, 
   0x91, 
   0xA0,0x32,0x0,0x0,0x0

This sequence consists of 5 commands:

1. Switch off spot 1 (rgb: 0,0,0)
2. Set spot 0 to purple (rgb: 255, 0, 255)
3. Fade spot 1 in 50 ticks (1s) to white
4. Wait for spot 1 to finish fading
5. Fade spot 0 in 1s to black

Schematic & Board