StrichLux
From Hackstrich
The StrichLux Modular Lighting Controller will control various kinds of lighting via various protocols/interfaces, or convert between two of the supported protocols/interfaces without directly controlling any devices.
Project Log
- 2012-05-27: Core board, PWR-DC5, and IO-ETH all sent off for PCB manufacturing.
- 2012-05-20: IO-DMX module is transmitting, core board is finished being designed/laid out and will go to manufacturing next week. PWR-DC5 Power Module is being designed and will go out for manufacturing at the same time as the core board.
- 2012-04: Status updates for individual I/O module are being tracked on each module's page.
- 2012-03-17: Completed BOM, schematic, and layout for DMX I/O module and I/O Breakout module. Both submitted to Laen for PCB manufacturing.
- 2012-03-13: Defined I/O Link connector pinout, started putting together BOM/schematic for DMX I/O module.
- 2012-03-12: Chose connectors, laid out basic core board interface components/defined sizes.
- 2012-03-06 - 2012-03-11: Defining specs, searching for appropriate parts.
Project Ideas
- Core Board, lets you plug in up to 4 input modules and 4 output modules plus an optional Power Module
- Each of the 4 would be up to one DMX universe worth of channels (512)
- SPI slave to each I/O module, 8 SPI slave transceivers total
- RS232 for troubleshooting and configuring the core board itself
- Local framebuffer memory
- Dual-port memory would be best so the output and input sections can both deal with it independently
- 8 bits per frame * 512 channels per universe * 4 universes = 16kbit (2kbyte) of framebuffer memory required
- Twice that for double-buffering would be awesome, so 32kbit/4kbyte of dual-port memory wanted
- Split into 4 channels, so each block would be 8kbit/1kbyte
- Reading/writing needs to happen in parallel for each block
- CPLD/FPGA seems a great fit for this
- Lattice LFXP2-5E-5TN144C or Xilinx XC3S50-4VQG100C both seem like good fits
- Since this will likely be the most powerful chip in the whole system, we could do transforms here to to take the load off the I/O modules
- HSV->RGB
- Input splitting (one input channel goes to two or more output channels)
- Input combining (two or more input channels get combined via some function and go to a single output channel)
- Scaling/offsetting (0-255 in = 32-64 out or such)
- Power Modules
- Stack underneath the Core Board, provide high-power busses for directly powering lighting from the system.
- Location makes sense because it doesn't block hot-swapping the I/O modules, but may be a thermal problem as it will get hot and heat up the Core Board
- Input-Only Modules
- Analog input channels (not 512 though, likely)
- Output-Only Modules
- LPD8806 LED strips
- Other LED strips
- Discrete power switches (relays/FETs/whatever)
- I/O Modules
- DMX
- Art-Net over Ethernet
- Art-Net over WiFi
- Dimensions
- Core board will be 3.95" x 6.25" (max limits of EAGLE Standard, purchased for this project)
- Modules will be 1.525" x 1.925" (2x4 layout on the board for input/output x 4 channels)
Protocol
- Modules are SPI masters, Core Board is SPI slave (x8)
- Simple read/write commands compatible with SPI SRAMs for easier testing/bring-up
- Commands
- 0000 0000 - NOOP - Do nothing
- 0000 0001 - Reserved - Write STATUS on SPI SRAMs
- 0000 0010 - WRITE - Write data to active "control" framebuffer
- Argument 0 - Starting address
- No return value
- Further clock cycles auto-increments the address pointer and continue shifting in new data
- 0000 0011 - READ - Read data from active "control" framebuffer starting at a set location
- Argument 0 - Starting address
- Further clock cycles auto-increments the address pointer and continue shifting out data
- 0000 0100 - READNEXT - Read data from active "control" framebuffer at the next pointer location
- No arguments
- 0000 0101 - Reserved - Read STATUS on SPI SRAMs
- 0000 0110 - GETLOC - Get data about the location of this module
- No arguments
- Return value: XXXX SSST
- T = Slot type (0=input, 1=output)
- S = Slot number
- X = Reserved (ignore)
- 0000 0111 - SETPTR - Set the address pointer used for READNEXT
- Argument 0 - Address to set pointer to
- No return value
- 0000 1000 - GETVER - Get CORE version information
- No arguments
- Return value 0: Protocol version (starts at 1, increments by 1 every significant change in protocol)
- Return value 1: Firmware version high-byte
- Return value 2: Firmware version low-byte (starts 1, increments by 1 every release
- Return value 3: Hardware revision (0 if unavailable)