Difference between revisions of "RGB Light Show (Wired/Wireless)"
From Just in Time
m |
|||
| Line 6: | Line 6: | ||
[[File:spot_controller_top.jpg|400px|thumb|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]] | [[File:spot_controller_top.jpg|400px|thumb|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]] | ||
| − | ==Command bytes== | + | |
| − | In general, the most significant 4 bits describe the command (room for 16 commands), the lower 2 bits may contain a spot number, depending on the command. Arguments in ''<angle brackets>'' are encoded in the lower 2 bits of the command byte. | + | ==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: | ||
| + | {| class="wikitable" border="1" | ||
| + | |- | ||
| + | | 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. | ||
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
| Line 29: | Line 51: | ||
| 0xF0 || address|| new addres|| sets the device address of this controller, if the address button is pressend simultaneously | | 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,0x | ||
| + | This sequence consists of 5 commands: | ||
| + | # Switch off spot 1 (rgb: 0,0,0) | ||
| + | # Set spot 0 to purple (rgb: 255, 0, 255) | ||
| + | # Fade spot 1 in 50 ticks (1s) to white | ||
| + | # Wait for spot 1 to finish fading | ||
| + | # Fade spot 0 in 1s to black | ||
| + | |||
==Schematic & Board== | ==Schematic & Board== | ||
[[File:ledspot_schematic.png|752px]][[File:ledspot_board.png|480px]] | [[File:ledspot_schematic.png|752px]][[File:ledspot_board.png|480px]] | ||
| + | [[Category:AVR]] | ||
Revision as of 18:46, 6 January 2013
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.
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,0x
This sequence consists of 5 commands:
- Switch off spot 1 (rgb: 0,0,0)
- Set spot 0 to purple (rgb: 255, 0, 255)
- Fade spot 1 in 50 ticks (1s) to white
- Wait for spot 1 to finish fading
- Fade spot 0 in 1s to black
Schematic & Board
