StrichLux

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-07-07: Full system is working end-to-end in one-channel mode. Next up is implementing multi-channel fanout mode.
• 2012-07-04: Read/write on CORE now works, IO-ETH successfully takes Art-Net packets and writes to the framebuffer, and it can be read back via SPI. IO-SPI not successfully reading yet, still working on it.
• 2012-07-02: Integration testing started, IO-ETH initializes properly and negotiates with CORE. Read/write still not working, more troubleshooting tomorrow.
• 2012-07-02: Firmware mostly functional, integration testing starts today on Core board, IO-ETH, and IO-SPI .
• 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)
  • 0000 1001 - TAKEOVER - Take over another channel's framebuffer
    • Argument 0: Channel number to take over
    • Return value 0: Result (0 = success, nonzero = failed to take over)