Difference between revisions of "LED window display"
Line 57: | Line 57: | ||
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. | 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. | ||
+ | |||
+ | Delays in the code have been set using an oscilliscope on an duemilanova atmega328 | ||
=== TODO === | === TODO === | ||
− | |||
* The code we're using now disables all interrupts while it's writing to the lights because it wants to get the timing absolutely correct. This means that it can't recieve any serial data. We've fixed this by having the arduino write an "OK" back to the server, and make the server pause until it recieves this go-ahead. If this creates too much slowdown though, we need to tmplement the writing of the lights as an interrupt routine, which would require a bunch of work. Doing things the interrupt way would shave off 12.28ms from the render time. | * The code we're using now disables all interrupts while it's writing to the lights because it wants to get the timing absolutely correct. This means that it can't recieve any serial data. We've fixed this by having the arduino write an "OK" back to the server, and make the server pause until it recieves this go-ahead. If this creates too much slowdown though, we need to tmplement the writing of the lights as an interrupt routine, which would require a bunch of work. Doing things the interrupt way would shave off 12.28ms from the render time. |
Revision as of 02:24, 28 August 2012
Collecting notes for the LED window display.
Contents
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. This involves cutting the lights, soldering lights together, cutting holes in boards to hold the lights.
- For Sherwin's lights
- Some of the strands on Sherwin's display are buggy and need to be replaced.
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.
We've set the bps to 500000 as per the forum post below: http://arduino.cc/forum/index.php/topic,98364.0.html 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
With 500000 bps, each frame will take 12.288ms to send. Each light frame takes .82ms*num_lights to display (sherwin => 19.68ms, ours => 26.24ms). This means each frame takes 31.968 ms to send, max, which is about 30 FPS.
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.
Delays in the code have been set using an oscilliscope on an duemilanova atmega328
TODO
- The code we're using now disables all interrupts while it's writing to the lights because it wants to get the timing absolutely correct. This means that it can't recieve any serial data. We've fixed this by having the arduino write an "OK" back to the server, and make the server pause until it recieves this go-ahead. If this creates too much slowdown though, we need to tmplement the writing of the lights as an interrupt routine, which would require a bunch of work. Doing things the interrupt way would shave off 12.28ms from the render time.
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 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.
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.
- rainbow.py - Implements a rainbow animation on the lights, based off of Rainbow Plasma
- triviaGame.py - Code for my trivia game! A work in progress.
- singleFrame.py - Shows a single frame on the screen and exits.
- loopFrames.py - Loops static images over all the frames
TODO
- I need to implement a routine that sends the current display to the client so I can do more effects.
- THERE IS NO ERROR CHECKING! Someone should fix 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.
- 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. I'll write up more on this soon-- Dani and I have come up with a font system.