StrichLux

The StrichLux Modular Lighting Controller controls various kinds of lighting via various protocols/interfaces and/or converts between two of the supported protocols/interfaces without directly controlling any devices.

Components

• Core Board - StrichLux/CORE (fully working except dynamic configuration)
• Ethernet I/O Module - StrichLux/IO-ETH (fully working except dynamic configuration)
• DMX I/O Module - StrichLux/IO-DMX (in development, basic functionality working)
• SPI I/O Module - StrichLux/IO-SPI (fully working as an output module)
• 12V input 5V output 40A Power Module - StrichLux/PWR-DC5 (in development, basic functionality working)

Project Log

• 2014-10: Got 2 of the 3 StrichLux boxes up and running driving LED strips on the ceiling of HackLab.TO's new space. The third box is still down due to PHY soldering issues, really need to redesign StrichLux/IO-ETH to use a non-QFN PHY before we can get that one back up.
• 2013-09: Got existing StrichLux boxes from Beacon4 up and running again for Mini Maker Faire Toronto 2013, fixed a number of IO-ETH firmware bugs while rolling this out.
• 2013-05: On hold for how due to too many other paying/deadlined projects. Will resume when working on invisibleMaze.
• 2012-08: Completed testing, now works with all 4 output channels. Used at BRC2012 for Beacon4 with only user-error issues (same MAC address programmed onto each IO-ETH) and software issues (LightJams was outputting significantly reduced refresh rates on each higher channel number for each box). Next step is to make configuration more dynamic, add serial/USB configuration support.
• 2012-07-14: Connectorized the rest of the channels, tests successful on one channel at a time. Still only have one IO-SPI module built, so can't test more than one channel at once yet.
• 2012-07-13: Regression testing at the lab was successful, but only have channel 1 connectors mounted, so couldn't test more channels. Will test today, hopefully.
• 2012-07-12: Completed the 4x4 crossbar that should allow multi-channel fanout mode via TAKEOVER command. Will test next time I'm at the lab.
• 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
  • WS2801 LED strips (as of 2012-11)
  • 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 (1-4 currently)
      • 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 (0 = back to native channel)
    • Return value 0: Result (0 = success, nonzero = failed to take over)
  • 0000 1011 - POWERCTL - Turn on/off the high-power busses
    • Argument 0: Power control byte: XXXX XXSB
      • B = Bus (0 = A, 1 = B)
      • S = State (0 = Off, 1 = On)