Difference between revisions of "LED window display"

From Baltimore Node Wiki
Jump to navigationJump to search
Line 1: Line 1:
 
Collecting notes for the LED window display.
 
Collecting notes for the LED window display.
  
Anyone have ideas for a better project name???
 
  
 +
== System Architecture ==
 +
The full breakdown of the architecture works as follows:
 +
 +
(outside internet?)  --> Client programs --> Server --> Arduino --> GE color effect lights
 +
 +
== GE Color effect lights ==
 +
 +
These are individually addressable lights made by GE.  Robert Sun Quattlebaum figured out their data protocol.  You can find out more here.
 +
 +
http://www.deepdarc.com/2010/11/27/hacking-christmas-lights/
 +
 +
Each light is driven by about 5V. Each light consumes XXX amps displaying the color white at full brightness. 
 +
 +
In short, one data pin can drive up to 63 lights.  The data protocol allows for dimming and brightening all the lights, as well as 12 bit color.  Each frame takes 790 us to send, and there is a manditory 30 us quiet time between frames.
 +
 +
The maximum number of lights per string and the maximum FPS is given by the equation:
 +
 +
LPS * 0.820 * FPS = 1000
 +
 +
So if you want 30 FPS, you can have up to 40 lights per string.  If you have 32 lights per string, you can have 38 FPS.  If you instead have 24 lights per string, you can have 50 FPS.
 +
 +
Sherwin's display has 23 or 24 lights per strand using 4 arduinos, with 12 strands per arduino.  The display across the top of the display has 16 strands coming off of one arduino, each with 32 lights. 
 +
 +
We've bought a power supply for Sherwin's lights.
 +
 +
=== TODO ===
 +
* Kevin, can you document how much power it takes to drive the lights?
 +
* For our lights
 +
** We need to buy a power supply for our top display.
 +
** We need to wire everything up.
 +
** We need to decide on and complete the physical construction of our lights.
 +
* For Sherwin's lights
 +
** We need to connect up Sherwin's lights to the supply we purchased.
 +
 +
== Arduino ==
 +
 +
For the arduino side of the code, we are using code from the QC Co-Lab's Lightwall Project.  You can find their write up of their code here:
 +
 +
https://www.qccolab.com/LightWall
 +
 +
We've modified their code pretty heavily-- they disabled the serial port in their implementation.  We also enabled the ability to write to 16 strands from one arduino at a time. 
 +
 +
https://github.com/rblake/BmoreNodeSign
 +
 +
The time values used in the code were determined by hooking up the code to an oscilliscope and measuring how fast it took to adjust the wires. 
 +
 +
For Sherwin's display, we are going to use the same 16 strand version of the code.  It's possible we could save some time by removing 4 bits from the data stream, but the timings for the arduino are fairly tight and I'm not sure it would be able to unpack the data quickly enough.
 +
 +
=== TODO ===
 +
* The 8 string version of the code actually should have it's timings double checked with an oscilliscope.  We adjusted the timings with 8 strands, not 16. 
 +
* For the version of the code that writes 16 strands at once, a single frame takes 6144 bits to send.  FPS is related to bit rate by
 +
 +
FPS * 6144 = bps
 +
 +
This is a problem, as the maximum supported bit rate of the arduino is 115200.  This means we're limited to 18 FPS.  There are pages on how to increase this bitrate (USB supports 1.5 Mbps), but some of them require changing the timing of the arduino.  We can't do this without also changing the timing results that create the 10 us delays. 
  
== System Architecture ==
 
[[File:Display arch.png]]
 
  
== nCode ==
+
== Server ==
This is intended to be a common format that is read by the computer connected to the LED driver. The syntax is based on JSON. The pixels in the frames represent Red, Green, Blue, and Alpha values. It is assumed that 0,0 is in the upper left corner of the display.
 
  
 +
The server is a python twisted program that listens to an internet port and recieves 24 bit color frames on that port.  It also does the bit transposition and color reduction needed to quickly display the 12bit color frames colors on the arduino. 
  
    {
+
The code can be found here
        width: 3,
 
        height: 3,
 
        loop: true,
 
        framerate: 10,
 
        meta: {
 
            title: "",
 
            creator: "",
 
            description: ""
 
        },
 
        frames: [
 
            [
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255]
 
            ],
 
            [
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255]
 
            ],
 
            [
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255],
 
                [255,255,255,255], [255,255,255,255], [255,255,255,255]
 
            ]
 
        ]
 
    }
 
  
==Things to display==
+
https://github.com/rblake/BmoreNodeSign
four pixel font: https://lh6.googleusercontent.com/_iSF92uXnHLo/TWvGiduVcVI/AAAAAAAAFZk/VTqfa3jm8RU/s800/node%20window%20font.PNG
 
  
==Hardware==
+
The code is made up of
 +
* write_image.py  - does the bit transposition of a color frame.
 +
* lightDisplay.py - contains all the code for the server. 
 +
** LightWallServer - contains the twisted code for the server.  A server is made for each client that connects.
 +
** BaseSignDisplay - implements a mutex on the sign display shared by all the server processes
 +
** InMemorySignDisplay - implements a fake lightwall with pygame on your desktop so you can test out various displays without connecting them to the lights. 
 +
** SignDisplay - implements the code that does the actual writing to the serial port. 
  
Rainbowduino x 3
+
=== TODO ===
 +
* The code that writes to the serial port is prototyped but not working.  It needs to be tested.
 +
* The code to find all the arduinos attached needs to be written.
 +
* For Sherwin's lights we'll need a new Display that writes to 4 arduinos at once.  Mike and I have been debating if it's going to be a horrible chore to keep the arduinos syncronized.
 +
* We'll also need something to do a different bit transposition for Sherwin's lights.
 +
* For Sherwin's lights, we'll need to modify the arduino code to tell the server which arduino is which.
 +
* THERE IS NO ERROR CHECKING.  Someone should really fix this.
  
http://www.seeedstudio.com/depot/rainbowduino-led-driver-platform-atmega-328-p-371.html?cPath=163_169
+
== Clients ==
 +
The clients all connect to the server and take turns taking control of the display. I've implemented a trivia game, and will be implementing more clients in the server. I've also implemented an effects code and some code to render text in 8 bits.
  
Wire: about 110' per 16 x 4 section.
+
Routines that return deferred objects start with "d_". To implement a client process, you need to implement a routine with an @inlineCallback decorator, then yield all deferred objects you want to wait for. 
  
RGB LEDs (see below).
+
https://github.com/rblake/BmoreNodeSign
  
==Purchases==
+
* lightDisplay.py - Contains the code for the client. 
 +
** LightDisplayClient - Implements a twisted client for the display.
 +
* triviaGame.py - Code for my trivia game!  A work in progress.
  
http://cgi.ebay.com/100-pcs-5mm-RGB-LED-4000mcd-Common-Cathode-Free-R-/390294708451?pt=LH_DefaultDomain_0&hash=item5adf60a0e3#ht_1756wt_907 - 100 RGB LEDs.
+
=== TODO ===
 +
* I need to implement a routine that sends the current display to the client so I can do more effects.
 +
* I want to implement a font that isn't fixed width.  Dani and Rob are working on this.
 +
* Clients I'd like to implement:
 +
** Video games!  We have enough of a framework to do this!
 +
** A weather/temp/time client
 +
** riddles?
 +
** Something to read off of twitter?  Twisted has code to do the heavy lifting here.
 +
** Something to read off IRC?  Again, Twisted has code to do this.
 +
** The Rainbow code used in the old rainbowduinos could be ported to this framework.
 +
** Conway's game of life.
 +
** Code to draw animations.
 +
** Something to pipe "fortune" to the display.
 +
** Something to screen scrape wikipedia for historical facts that happened today.
 +
** Grab Node/LOF events from google or meetup, post them.
 +
** Tetris!
  
^^ these turned out to be wrong, since we needed common anode.
+
== Art ==
 +
We need art that we can display both on Sherwin's lights and our lights.
  
 +
Our lights will be 64x8 pixels.  Sherwin's display is 24x47 pixels.
  
Marty purchased 100 common anode ones so now we have those.
+
=== TODO ===
 +
* We need an /awesome/ node logo for both displays
 +
* We need awesome animations
 +
* I found a collection of 8 pixel fonts taken from old game boy games.  These need to be cleaned up so they can be used.

Revision as of 03:13, 20 August 2012

Collecting notes for the LED window display.


System Architecture

The full breakdown of the architecture works as follows:

(outside internet?) --> Client programs --> Server --> Arduino --> GE color effect lights

GE Color effect lights

These are individually addressable lights made by GE. Robert Sun Quattlebaum figured out their data protocol. You can find out more here.

http://www.deepdarc.com/2010/11/27/hacking-christmas-lights/

Each light is driven by about 5V. Each light consumes XXX amps displaying the color white at full brightness.

In short, one data pin can drive up to 63 lights. The data protocol allows for dimming and brightening all the lights, as well as 12 bit color. Each frame takes 790 us to send, and there is a manditory 30 us quiet time between frames.

The maximum number of lights per string and the maximum FPS is given by the equation:

LPS * 0.820 * FPS = 1000

So if you want 30 FPS, you can have up to 40 lights per string. If you have 32 lights per string, you can have 38 FPS. If you instead have 24 lights per string, you can have 50 FPS.

Sherwin's display has 23 or 24 lights per strand using 4 arduinos, with 12 strands per arduino. The display across the top of the display has 16 strands coming off of one arduino, each with 32 lights.

We've bought a power supply for Sherwin's lights.

TODO

  • Kevin, can you document how much power it takes to drive the lights?
  • For our lights
    • We need to buy a power supply for our top display.
    • We need to wire everything up.
    • We need to decide on and complete the physical construction of our lights.
  • For Sherwin's lights
    • We need to connect up Sherwin's lights to the supply we purchased.

Arduino

For the arduino side of the code, we are using code from the QC Co-Lab's Lightwall Project. You can find their write up of their code here:

https://www.qccolab.com/LightWall

We've modified their code pretty heavily-- they disabled the serial port in their implementation. We also enabled the ability to write to 16 strands from one arduino at a time.

https://github.com/rblake/BmoreNodeSign

The time values used in the code were determined by hooking up the code to an oscilliscope and measuring how fast it took to adjust the wires.

For Sherwin's display, we are going to use the same 16 strand version of the code. It's possible we could save some time by removing 4 bits from the data stream, but the timings for the arduino are fairly tight and I'm not sure it would be able to unpack the data quickly enough.

TODO

  • The 8 string version of the code actually should have it's timings double checked with an oscilliscope. We adjusted the timings with 8 strands, not 16.
  • For the version of the code that writes 16 strands at once, a single frame takes 6144 bits to send. FPS is related to bit rate by

FPS * 6144 = bps

This is a problem, as the maximum supported bit rate of the arduino is 115200. This means we're limited to 18 FPS. There are pages on how to increase this bitrate (USB supports 1.5 Mbps), but some of them require changing the timing of the arduino. We can't do this without also changing the timing results that create the 10 us delays.


Server

The server is a python twisted program that listens to an internet port and recieves 24 bit color frames on that port. It also does the bit transposition and color reduction needed to quickly display the 12bit color frames colors on the arduino.

The code can be found here

https://github.com/rblake/BmoreNodeSign

The code is made up of

  • write_image.py - does the bit transposition of a color frame.
  • lightDisplay.py - contains all the code for the server.
    • LightWallServer - contains the twisted code for the server. A server is made for each client that connects.
    • BaseSignDisplay - implements a mutex on the sign display shared by all the server processes
    • InMemorySignDisplay - implements a fake lightwall with pygame on your desktop so you can test out various displays without connecting them to the lights.
    • SignDisplay - implements the code that does the actual writing to the serial port.

TODO

  • The code that writes to the serial port is prototyped but not working. It needs to be tested.
  • The code to find all the arduinos attached needs to be written.
  • For Sherwin's lights we'll need a new Display that writes to 4 arduinos at once. Mike and I have been debating if it's going to be a horrible chore to keep the arduinos syncronized.
  • We'll also need something to do a different bit transposition for Sherwin's lights.
  • For Sherwin's lights, we'll need to modify the arduino code to tell the server which arduino is which.
  • THERE IS NO ERROR CHECKING. Someone should really fix this.

Clients

The clients all connect to the server and take turns taking control of the display. I've implemented a trivia game, and will be implementing more clients in the server. I've also implemented an effects code and some code to render text in 8 bits.

Routines that return deferred objects start with "d_". To implement a client process, you need to implement a routine with an @inlineCallback decorator, then yield all deferred objects you want to wait for.

https://github.com/rblake/BmoreNodeSign

  • lightDisplay.py - Contains the code for the client.
    • LightDisplayClient - Implements a twisted client for the display.
  • triviaGame.py - Code for my trivia game! A work in progress.

TODO

  • I need to implement a routine that sends the current display to the client so I can do more effects.
  • I want to implement a font that isn't fixed width. Dani and Rob are working on this.
  • Clients I'd like to implement:
    • Video games! We have enough of a framework to do this!
    • A weather/temp/time client
    • riddles?
    • Something to read off of twitter? Twisted has code to do the heavy lifting here.
    • Something to read off IRC? Again, Twisted has code to do this.
    • The Rainbow code used in the old rainbowduinos could be ported to this framework.
    • Conway's game of life.
    • Code to draw animations.
    • Something to pipe "fortune" to the display.
    • Something to screen scrape wikipedia for historical facts that happened today.
    • Grab Node/LOF events from google or meetup, post them.
    • Tetris!

Art

We need art that we can display both on Sherwin's lights and our lights.

Our lights will be 64x8 pixels. Sherwin's display is 24x47 pixels.

TODO

  • We need an /awesome/ node logo for both displays
  • We need awesome animations
  • I found a collection of 8 pixel fonts taken from old game boy games. These need to be cleaned up so they can be used.