Editing Big LED Screen

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
{{LED}}
+
= The Big LED Screen =
 
 
{{headerbox}}'''The Big LED Screen''' is Noisebridge's first piece of LED art, a big LED screen salvaged and made to work running Conway's Game of Life since [[83c]].
 
{{boxend}}
 
 
 
The sign in its original form when we found it and had to figure out how to reverse engineer it.
 
 
 
[[File:Nbbigledsignhackonme.jpg|800px]]
 
  
 
=== Overview ===
 
=== Overview ===
Line 19: Line 12:
 
* The 386 connects via ISA to a "buffer board" which looks to be a memory buffer and power conditioner.
 
* The 386 connects via ISA to a "buffer board" which looks to be a memory buffer and power conditioner.
 
* The "buffer board" has most traces terminating to a socket with a missing chip, so we don't know what happened here.
 
* The "buffer board" has most traces terminating to a socket with a missing chip, so we don't know what happened here.
 
** ''I have a somewhat different version.  The missing chip I think you are referring to is a floppy drive controller.  In my version the floppy drive is connected to the LED driver board there on the top left connector which then feeds through and shares the same ISA connector.  -dpg  (sorry if this was an inappropriate way to add a comment.)''
 
 
   
 
   
 
==== Buffer board ====
 
==== Buffer board ====
Line 31: Line 22:
  
 
==== Daughterboards ====
 
==== Daughterboards ====
 
[http://www.flickr.com/photos/31848713@N00/3430719610/ Picture of a daughterboard]
 
  
 
The daughterboards each have qty 3 UCN5832A ([[Image:Ucn5832.pdf]]) 32-bit shift registers (for a total of 96 bits) which drive an array of 32 by 48 pixels (for a total of 1536).  The theory is the other end of the LEDs are connected to 16 different power sources, making all the LEDs addressable (96 * 16 = 1536).  (The shift register does a current sink)
 
The daughterboards each have qty 3 UCN5832A ([[Image:Ucn5832.pdf]]) 32-bit shift registers (for a total of 96 bits) which drive an array of 32 by 48 pixels (for a total of 1536).  The theory is the other end of the LEDs are connected to 16 different power sources, making all the LEDs addressable (96 * 16 = 1536).  (The shift register does a current sink)
Line 78: Line 67:
  
 
=== Overview ===
 
=== Overview ===
 
[http://www.flickr.com/photos/31848713@N00/3430728760/in/photostream/ Overview of the inside of the screen (picture)]
 
 
[http://www.flickr.com/photos/31848713@N00/3429916211/in/photostream/ Detail of our breadboard (picture)]
 
  
 
==== LED Hardware ====
 
==== LED Hardware ====
Line 99: Line 84:
 
The boarduinos have connections to the preexisting circuitry to tell which power source is in use at any time, and send the respective data to the shift registers for display.
 
The boarduinos have connections to the preexisting circuitry to tell which power source is in use at any time, and send the respective data to the shift registers for display.
  
We also have an xbee series 1 (802.15.4) wireless chip onboard so we don't have to open up the sign to talk to it.
+
We also have an xbee wireless chip onboard so we don't have to open up the sign to talk to it.
  
 
==== Software ====
 
==== Software ====
Line 112: Line 97:
  
 
=== Pin connections ===
 
=== Pin connections ===
 
[[Image:ledscreen-schematic.png|500px]]
 
  
 
Here are the pins that need to be connected other than power and ground:
 
Here are the pins that need to be connected other than power and ground:
Line 128: Line 111:
  
 
Unfortunately this has very little processor time to spare since it's spending all its time clocking out the serial data.  We're probably limited to very basic patterns on here.
 
Unfortunately this has very little processor time to spare since it's spending all its time clocking out the serial data.  We're probably limited to very basic patterns on here.
 
== Usage ==
 
 
=== Getting the source ===
 
The source is available on GitHub at the following location: https://github.com/miloh/bigledscreen/
 
A guide for using GitHub can be found here https://guides.github.com/activities/hello-world/
 
 
'''The following is historical'''
 
The source is in a mercurial repository on [[pony]].  Point your mercurial client at http://pony.local/d3/nils/bigledscreen to pull down a copy of it.
 
 
=== Programming the xbee ===
 
 
To control the sign wirelessly, you will want to program an xbee chip to interface with it.  I recommend the "xbee explorer" from sparkfun.  To program your new xbee, you will need to make sure your xbee has a recent enough firmware (10A5 is recommended).  Unfortunately firmware upgrade must be done using Digi/MaxStream's "X-CTU" application which runs under windows.  This can be performed with wine and linux.  See [http://paparazzi.enac.fr/wiki/XBee_configuration paparazzi's]xbee config page and [http://www.libelium.com/squidbee/upload/3/31/Data-sheet-max-stream.pdf digi's xbee AT command set] for information about using x-ctu or minicom with your xbee.
 
 
The Xbee on the computer side needs to have a small hardware modification to work: pins AD0 and AD1 need to be shorted, and pins AD2 and AD3 need to be shorted.  This is because the xbee connected to your computer toggles pins 0 and 2 to control the state of pins 1 and 3, and pins 1 and 3 are mirrored by the xbee connected to the sign.  If you use a stock xbee, you'll still be able to talk to the sign with it but you won't be able to flash new firmware.
 
 
Once you have your xbee connected to your computer, you can use xbee-pgm.pl to set it up to talk to the sign such as the following:
 
 
  ./xbee-pgm.pl /dev/cu.usbserial.A12345 program-computer-side
 
 
where /dev/cu.usbserial.A12345 is the serial port for your xbee.
 
 
If your xbee was configured to use the original 9600 baud rate, you will need to run this twice to actually write the new baud rate to flash.  Your xbee will now talk at 19200 baud, and is now configured to talk to the sign.
 
 
=== Uploading new sign code ===
 
 
To compile new sign code, simply "make" in the bigledscreen directory.  This will produce a "ledlife.hex" file that you can upload to the sign.  If you are unfamiliar with AVR programming and avrdude, you should go through one of the tutorials on the internet first.  This is not a good first project.
 
 
To upload new sign code, you must upload to each half of the sign separately.  First, activate the reset pins on both halves of the sign:
 
 
  ./xbee-pgm.pl /dev/cu.usbserial.A12345 all-high
 
 
Now, release the reset pin on half of the sign.  This allows the left half of the sign to boot up:
 
 
  ./xbee-pgm.pl /dev/cu.usbserial.A12345 3-high
 
 
The atmega168 will now start the Lady Ada's bootloader, which acts just like a stk500.
 
 
Immediately, start your "avrdude" to upload code.  If you do not do this fast enough, you will need to toggle the reset pin again.
 
 
  avrdude -F -b 19200 -c stk500v1 -p m168 -P /dev/cu.usbserial-A12345 -e -U flash:w:ledlife.hex
 
 
Sometimes this will fail.  If it fails repeatedly, reposition your xbee closer to the sign, or reorient it, and try again.
 
 
Once this half is done, you can upload the right half:
 
 
  ./xbee-pgm.pl /dev/cu.usbserial.A12345 1-high
 
  avrdude -F -b 19200 -c stk500v1 -p m168 -P /dev/cu.usbserial-A12345 -e -U flash:w:ledlife.hex
 
 
Then you can release the reset pin on the left half so it can boot up, and both halves can run:
 
 
  ./xbee-pgm.pl /dev/cu.usbserial.A12345 all-low
 
 
=== Controlling a running sign ===
 
 
You can use the "sendcmd.pl" script to send bytes to the sign.  The usage is similar to xbee-pgm.pl:
 
 
  ./sendcmd.pl <serial port> <byte code>
 
 
<byte code> is the decimal value of the byte to send.  You should not send bytes too fast, and sometimes bytes get missed.  Hopefully this will change in the future.
 
 
You can address one or both of the halves by sending one of the following values:
 
 
  0 - address left
 
  1 - address right
 
  2 - address both
 
 
If you want to send a data value from 0 to 3 (inclusive) and don't want to address a screen, you can first send a "3", which indicates that the next byte should be treated as a data byte instead of an address byte.
 
 
Immediately after you address a screen, you send a command:
 
 
  64 - Turn on life, and randomly occasionally reset
 
  65 - Turn on life without the periodic random reset
 
  66 - Run test pattern
 
  67 - Act as single-buffered framebuffer
 
  68 - Act as double-buffered framebuffer
 
 
 
  70 - clear framebuffer, home cursor
 
  71 - set x coordinate of cursor
 
  72 - set y coordinate of cursor
 
  73 - for double-buffered framebuffer, swap front and back buffers
 
  74 - for double-buffered framebuffer, do a single round of life and swap front and back buffers
 
 
When setting an x or y coordinate of the cursor, follow the command with the cursor position added to 128.  The cursor is 8 pixels wide horozontally and 1 pixel tall.  Valid values for setting the X cursor coordinate are 128 through 135.  Valid values for setting the Y cursor coordinate are 128 through 175.
 
 
After you have issued attention and a command, any further bytes you send will be placed on the screen at the cursor, and then the cursor will go to the next 8 pixels.  It scans in the standard left-to-right, top-to-bottom order.
 
 
An example script, "gliders.sh", will place a bunch of gliders on the display.  (You may need to change the "port" variable to match your local serial port).  Note that it has several times where it stops and asks you if everything is ok; use ctrl-c to abort if any bytes got missed in transit, and then start over.
 
 
For further information, UTSL.
 
 
[[Category:Pages with a Noisebridge Tiny URL]]
 

Please note that all contributions to Noisebridge are considered to be released under the Creative Commons Attribution-NonCommercial-ShareAlike (see Noisebridge:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel Editing help (opens in new window)