StrichLux

From Hackstrich
Revision as of 15:07, 25 November 2012 by SarahEmm (talk | contribs) (Fixing category.)

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-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
  • 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)
Retrieved from "http://hackstrich.sen.cx/wiki/index.php?title=StrichLux&oldid=1623"