Noisebridge - User contributions [en]

Big LED Screen

2025-03-08T23:43:46Z

Shkoo: Fix picture to depict proper screen

{{LED}}

{{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:Big LED screen.jpg|800x800px]]

=== Overview ===

* Dimensions (in pixels) are 128 by 48
* The buffer board stores data into a couple memory chips, which are then accessible to the daughterboards which drive the actual LEDs.
* There are four daughterboards, in two chains of length two. Each of these daughterboards is connected to a single "section" of LEDs (ie: there are four big "sections" of LEDs). Each daughterboard runs a section of 32 by 48 pixels.

=== History ===

* Originally controlled by a 386; mobo is shot.
* 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.

** ''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 ====

Tonight (2008-12-30) Josh worked from the backend up a bit, but eventually gave up. He then moved to the ISA frontside and worked down, which was far more productive.

The device appears to sit at ISA IO ports 0x180 through 0x183. The addresses are decoded by U51 (74688 comparator), which then hits the OE2 on U52-19 (74541 driver iirc). This is then used to feed U53 and U54 (both 74574 D-flip-flops). These appear to be there to combat fan-out. He's not entirely certain where these go, but it seemed like they were going into the RAMs.

The low bits of the ISA address selection sit on the rightmost two pins on the top row of the header, SA1 and SA0, in that order (Just hook the connector up and use the multimeter if that's nonsensical). I haven't traced them through yet; I was in the middle of it when my time ran out. They look to run over to the empty chip socket on the right side of the board. Most traces tend to terminate at this chip socket, so most likely we won't be able to use the display logic on the buffer board.

==== 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 receive serial based on the following:

* The long 10-pin pigtails are as follows:
1 - UCN-40 CLK (serial clock)
2 - GND
3 - UCN-4 STROBE (latch driver)
4 - GND
5 - UCN-2 SIN (serial in)
6 - GND
7 - UCN-3 GND
8 - GND
9 - GND

Pin 1 is marked red. When looking into the end of the connector, when the red-marked wire is on the left, odd pins are on top. The keyed edge of the connector is also on top. The top left pin is pin 1.

Per Josh, the grounds do not need to be connected for now.

The serial is daisy chained together. There are two sets of two daughterboards (four daughterboards total) with 3 shift registers on each daughterboard. So, each chain of shift registers includes 6 shift registers for a total of 192 bits per chain.

* The 10-pin ports between the daughterboards (J3 and J2) are wired differently. J3 is:
1 -
2 -
3 -
4 -
5 - ground
6 -
7 - clock
8 -
9 - serial out (j2) / serial in (j3)
10 -

(The existing logic shifts out 200 bits instead of 192; we don't know why).

Looking at the sign doing STROBE: sequences 130us apart, within each sequence, 5 peaks @+5V, 4us each high, otherwise the signal is low.

Looking at CLK: We do a bunch of lcokign, the strobe, etc. 8 CLKs in 5us, entire process takes 125us, appx 200CLKs. This gives an input rate of 1.6MHz(!)

The shift register is rated for 3.3Mhz, so we could conceivably drive it faster than the 1.5Mhz that it's currently running.

== Current Operation ==

=== 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 ====

The sign is currently driven by two boarduinos on a solderless breadboard. One controls the left half of the sign, and the other controls the right half.

The old hardware buffer board has 16 power sources that it cycles through in sequence. It goes through each cycle of 16 power sources at about 500 Hz. (So it changes power sources every 1/8000th of a second).

Each boarduino shifts bits out along a serial line controlling 192 shift registers. These shift registers act as controllable current-limited drains.

The LEDs on the display have their anodes connected to the power sources. Each anode is shared by 192 LEDs.

The LEDs on the display have their cathodes connected to the shift registers. Each shift register pin is shared by 16 LEDs.

This gives us 3072 LEDs per half of the display, which are arranged into an array 64 LEDs wide by 48 LEDs tall.

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.

==== Software ====

Though we are using arduino compatible hardware, we are using AVR-GCC to compile native code directly for the atmel mega168 chip on the boarduino. The arduino framework does not perform well enough nor allow us good access to the atmega168 integrated chip features such as SPI and TWI.

We are using lady ada's arduino bootloader. This acts like an atmel stk500 programmer, and allows us to upload software over the wireless connection.

The XBEE wireless chip has virtual transparenet pins configured so we can control the reset pins of the two boarduinos independently, and upload new code to each half of the sign at a time.

The two halves talk to each other using the TWI interface on the atmega168.

=== Pin connections ===

[[Image:ledscreen-schematic.png|500px]]

Here are the pins that need to be connected other than power and ground:

* MOSI (PB3) - this sends serial data to the daughterboard
* SCK (PB5) - this sends lcock signal to the daughterboard
* PB1 - this should be connected to the latch/strobe signal from the old buffer board
* PB0 - this should be connected to the latch/strobe signal going to the daughterboard
* PD7 - this should be hooked up to the left side of one of the power sources on the buffer board through a voltage divider (and small capacitor to stabilize the signal) to bring the 15 volts down to 5 volts. Do not use the output of the power source, since it's not nearly as stable.

It uses the existing STROBE (latch) signal from the buffer board for timing, and reads the state of one of the buffer board's output powers to synchronize where in the sequence of 16 power sources. It captures the latch signal and re-emits it to the daughterboard.

It ignores the serial clock and serial data from the buffer board.

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]]

File:Big LED screen.jpg

2025-03-08T22:42:49Z

Shkoo:

Big LED screen

Moving/Desires

2009-05-04T06:03:44Z

Shkoo:

= List of Requirements as we look for a new space.=

Add to these as you feel like it, and feel free to move them up and down the list; the top of the list is to be considered "most important" and the bottom of the list "least important," so if everybody moves things around we hope to come to some sort of consensus on priorities.

# 24x7 access
# At least 10' ceilings, preferably a loft so that part of the space is double-hight (for projection win)
# At least 3000 square feet of floor space
# under $4K for rent
# The shed must be <del>blue</del> <del>red</del> <del>orange</del> mauve.
# < 1/4 mile from a BART station

Moving/Desires

2009-05-04T00:15:49Z

Shkoo: /* List of Requirements as we look for a new space. */

Meeting Notes 2009 04 28

2009-04-29T04:07:55Z

Shkoo:

= Crew =
* Moderator: nils
* Notes: dr jesus

= Agenda Items =
== Announcements ==
* What Noisebridge is about.
* The Names
* Treasurer's report
=== Project Updates ===

=== What's Going On at Noisebridge ===
* [[Circuit_Hacking_Mondays|Circuit Hacking Mondays]] (8PM, 83c)
* Pyclass (Monday at 6:30PM, 83c)
* [[Machine Learning]] Wednesdays (8PM, 83c)
* Science/Engineering Huddle (8PM Thursdays, 83c)
* Natural Language Corners
* Cyborg Group (Sundays)
* [[OpenEEG]]
* [[Five Minutes of Fame]] now accepting submissions for May
* DC3 Digital Forensics Challenge
* Potential [http://wiki.openamd.org/Main_Page OpenAMD] deployment
* Go on Sunday 3pm

== Consensus Items ==
* Purchasing [[Soldering Badges]] -nils
* [[Removing Membership]] -rachel

=== Membership Binder ===
* Reading Names
* New member approvals

== Discussion topics ==

* Club Mate - Anyone from NB involved?
* What preparedness measures are we taking to protect Noisebridge against the Swine Flu pandemic?
** Require wearing of masks in the space?
** DIYBio fridge returning to hold vaccines.
** Wash all surfaces with bleach or other chemical disinfectant daily?
** Everyone should go vegan!
** Procedure to ban those displaying flu symptoms?
** Keeping bacon in the Noisebridge fridge.
** Cyborg group wants to make a bracelet that vibrates when someone infected is near by.
** Continuing search for new underground location to move Noisebridge into, take up arms.
** New project license Open Sores for Flubuntu 10.4 LTS Sweety Swine.
** Bring religion to 83c to fight the pandemic?
* [[ToorCamp]]!
* [[Soldering Badges]]

= Notes =
* Please follow the format kindly made by [[User:Turkshead|Turkshead]] and used in [[Meeting Notes 2009 04 14]] when adding items.
* At the end of the meeting I'll ask for volunteers to lead the next meeting.
* Christie has volunteered to lead the next meeting.

Meeting Notes 2009 04 28

2009-04-29T02:51:07Z

Shkoo: /* Discussion topics */

= Crew =
* Moderator: nils
* Notes:

= Agenda Items =
== Announcements ==
* What Noisebridge is about.
* The Names
* Treasurer's report
=== Project Updates ===

=== What's Going On at Noisebridge ===
* [[Circuit_Hacking_Mondays|Circuit Hacking Mondays]] (8PM, 83c)
* Pyclass (Monday at 6:30PM, 83c)
* [[Machine Learning]] Wednesdays (8PM, 83c)
* Science/Engineering Huddle (8PM Thursdays, 83c)
* Natural Language Corners
* Cyborg Group (Sundays)
* [[OpenEEG]]
* [[Five Minutes of Fame]] now accepting submissions for May
* DC3 Digital Forensics Challenge
* Potential [http://wiki.openamd.org/Main_Page OpenAMD] deployment
* Go on Sunday 3pm

== Consensus Items ==
* Purchasing [[Soldering Badges]] -nils
* [[Removing Membership]] -rachel

=== Membership Binder ===
* Reading Names
* New member approvals

== Discussion topics ==

* Club Mate - Anyone from NB involved?
* What preparedness measures are we taking to protect Noisebridge against the Swine Flu pandemic?
** Require wearing of masks in the space?
** DIYBio fridge returning to hold vaccines.
** Wash all surfaces with bleach or other chemical disinfectant daily?
** Everyone should go vegan!
** Procedure to ban those displaying flu symptoms?
** Keeping bacon in the Noisebridge fridge.
** Cyborg group wants to make a bracelet that vibrates when someone infected is near by.
** Continuing search for new underground location to move Noisebridge into, take up arms.
** New project license Open Sores for Flubuntu 10.4 LTS Sweety Swine.
** Bring religion to 83c to fight the pandemic?
* [[ToorCamp]]!

= Notes =
* Please follow the format kindly made by [[User:Turkshead|Turkshead]] and used in [[Meeting Notes 2009 04 14]] when adding items.
* At the end of the meeting I'll ask for volunteers to lead the next meeting.

Meeting Notes 2009 04 28

2009-04-29T00:14:15Z

Shkoo: /* Discussion topics */

= Crew =
* Moderator: nils
* Notes:

= Agenda Items =
== Announcements ==
* What Noisebridge is about.
* The Names
* Treasurer's report
=== Project Updates ===

=== What's Going On at Noisebridge ===
* [[Circuit_Hacking_Mondays|Circuit Hacking Mondays]] (8PM, 83c)
* Pyclass (Monday at 6:30PM, 83c)
* [[Machine Learning]] Wednesdays (8PM, 83c)
* Science/Engineering Huddle (8PM Thursdays, 83c)
* Natural Language Corners
* Sense Extension/Sensebridge/Cyborgism Group (Sundays)
* [[OpenEEG]]
* DC3 Digital Forensics Challenge
* Potential [http://wiki.openamd.org/Main_Page OpenAMD] deployment
* Go on Sunday 3pm

== Consensus Items ==
* Purchasing [[Soldering Badges]] -nils
* [[Removing Membership]] -rachel

=== Membership Binder ===
* Reading Names
* New member approvals

== Discussion topics ==

* What preparedness measures are we taking to protect Noisebridge against the Swine Flu pandemic?
** Require wearing of masks in the space?
** Wash all surfaces with bleach or other chemical disinfectant daily?
** Procedure to ban those displaying flu symptoms?

= Notes =
* Please follow the format kindly made by [[User:Turkshead|Turkshead]] and used in [[Meeting Notes 2009 04 14]] when adding items.
* At the end of the meeting I'll ask for volunteers to lead the next meeting.

Meeting Notes 2009 04 28

2009-04-28T20:30:11Z

Shkoo: /* Consensus Items */

2009-04-21T04:21:25Z

Shkoo: /* Operation */

[[User:Edrabbit|Ed]] and [[User:sofauxboho|Reed]] bought the light bar at the Prototype This garage sale in February '09. While it wasn't explicitly stated, it was fairly obvious that the device had been abandoned there by the Navy when they pulled out of Treasure Island in the mid 90s. This was corroborated by the US Navy Property label affixed to it.

Our goal is to get it working for use on Ed's car at 4th of Juplaya and Burning Man. It is available for non-destructive sharing at other times.

We looked it over with Jonathan Moore and Mitch, and were then distracted by other projects.

[[User:shkoo|Nils]] has since been working on it and has discovered the following:

This thing uses all 12-volt logic, which makes sense since it would've been powered off a 12 volt battery.

It is made by "Jetsonic". Here is the manual: [[Media:Lightbar.pdf]].

The guy that was working on it successfully activated some of the lights and the motor to turn the lights by poking at connections internal to the light bar.

== Operation ==

There is a single serial data line that runs into the light bar. It is demultiplexed via a motorola 145029 and a pair of 4099 addressable latches.

The format of serial packets is a sequence of 9 bits:

0: always 0 (used for addressing)
1: always 0 (used for addressing)
2: always 0 (used for addressing)
3: always 0 (used for addressing)
4: when 1, address IC609 (PTT, RADIO, MANUAL, AIR HORN, TAKEDOWN, STROBE, LEFT ALLEY, TAP II)
when 0, address IC608 (switched power(?), SECONDARY, PRIMARY, WAIL, YELP, HI-LO, FLOOD, RIGHT ALLEY)
5, 6, 7: address output within IC609/IC608
8: when 1, enable function
when 0, disable function

The serial bytes are sent in a format documented in the 145026 datasheet. (The trinary/high impedence capabilities of the 145026 are unused.)

The 145026 multiplexer has the following hooked up to the timing pins:

RTC(13) 10 kohm
CTC(12) 470 picofarad
RS(11) 22 kohm

According to that, the multiplexer should run at a clock speed of 1/(2.3 * 10 kohm * 470 picofarad) = about 92.506938 Khz.

The 14029 demultiplexer has the following hooked up to the timing pins:

RI(6) = 12 kohm -> CI(7) -> 1500 picofarad -> ground
R2/C2(10) = 110 kohm, 3300 picofarad

But the datasheet does not give us good timing information for that, but it looks close to the table given in the 145026 datasheet so I believe we're good.

2009-04-07T23:12:55Z

Shkoo:

From what I (Nils) can remember, the light bar came from some decommissioned fire marshal car. I don't remember who it was that brought it in or was working on it.

This thing uses all 12-volt logic, which makes sense since it would've been powered off a 12 volt battery.

It is made by "Jetsonic". Here is the manual: [[Media:Lightbar.pdf]].

The guy that was working on it successfully activated some of the lights and the motor to turn the lights by poking at connections internal to the light bar.

Light bar

2009-04-07T23:11:48Z

== Identifiers ==
=== ssh public key ===
ssh-dss AAAAB3NzaC1kc3MAAACBAPsm6mzSk+/8fiJNt5aH1SGysVHEKXCH/rH+mnpScd5HDgOp5jk0MATsnoirBOMB3/yeYgW/uMelcBHJKSek49QpIsKZ2TZUCV/WyTDYa69TGaKzovvVb++ogDK/hfOpJgZIE7N/O0koXuOoky9wsPPJlGCnQhTvN1a7p2xsyjPDAAAAFQD+tjhO26ayp0CtQgdCPPSEvd4QGwAAAIEAq1Ong2/8Z8//b8yhQ/Ox3Qhf3yyqZM+Knjny4Xx/1yIC3uIW6vzS4/K2jx8LoC3nc1LBREC/PZOFWwC0MYT/r3cEuj9V9aiGtXj2TbOdcMo0zZiMq2rLoWvi0R+1wuoJzMCUNm7UwLnWIC+gpBT9DuTAPMNYsGtCYhT7I9TOuAYAAACBAOtltJRBhx+cDzaNphi+q4+oZ0iJnGDEOYeaFVnifjDv02c77ylfH7S3nBhmgyXTIEc9Y5FfqiajNjj1ohaymKW5SlDWUr7I52dFjuiF3S97WI+Cype7Se4H8v2MIhTiU4gPDUAhMrgw7dZqzN7eYuIQG0/hXZkmOkUoooyBA/wB nils@raisin

=== <tt>/etc/passwd</tt> entry ===
# adduser --shell /bin/bash --gecos "nils" nils
...

[[Category:Keys_Available]]

User:Shkoo

2009-02-26T21:36:41Z

Shkoo:

Meeting Notes 2009 03 03

2009-02-25T05:59:36Z

Shkoo: New page: Category:Meeting Notes == Agenda Items == * What Noisebridge is about. * Regular Happenings ** Circuit Hacking Mondays (8PM, 83c) ** Pyclass (Monday at 6:30PM, 83c) ** Machine Learning...

[[Category:Meeting Notes]]
== Agenda Items ==
* What Noisebridge is about.
* Regular Happenings
** Circuit Hacking Mondays (8PM, 83c)
** Pyclass (Monday at 6:30PM, 83c)
** Machine Learning Wednesdays (8PM, 83c)
** Natural Language Corners
* Treasurer's report
* Project Reports
* Upcoming events
* read membership folder names

Noisebridge

2009-02-25T05:58:51Z

Shkoo: /* Meetings */

__NOTOC__
[[Image:Noisebridge_banner_and_board.jpg|thumb|right|Noisebridge members at 83C]]

''Noisebridge is an infrastructure provider for technical-creative projects, collaboratively run by its members. We are incorporated as a non-profit educational corporation for public benefit.'' 

'''[https://www.noisebridge.net/mailman/listinfo Join the Noisebridge mailing list]''' '''and/or hop on [[IRC]]''' to get involved.

'''[[Noisebridge Membership|Become a member]]!''' -- [[New Member FAQ]]!
 
 
'''[[Donate or Pay Dues| How to Donate money or Pay Membership Dues]].'''
 
 
== Info ==

[[Getting Here]]: We're at '''83C Wiese Street''' between Mission and Valencia just off 16th Street in San Francisco's Mission district. [http://openstreetmap.org/?mlat=37.765600&mlon=-122.420420&zoom=16 (openstreetmap)] [http://maps.google.com/?q=83C+Wiese+St,+94103 (Google Maps)] [http://maps.yahoo.com/#mvt=m&lat=37.765395&lon=-122.420337&zoom=16&q1=83C%20Wiese%20St%2C%2094103 (Yahoo Maps)] [http://www.mapquest.com/maps?city=San+Francisco&state=CA&address=83c+Wiese+St&zipcode=94103-5920&country=US&latitude=37.765274&longitude=-122.42057&geocode=ADDRESS (Mapquest)].

[[Image:noisebridge.jpg|thumb|right|Here is 83C]]

[[Planet Noisebridge]]: [https://www.noisebridge.net/planet/ Our blog aggregation service].

[[The Space]]: home sweet home (including our network drops [[Network]]).

[[Vision]]: Our vision - what our space is all about!

[[Infrastructure]]: Stuff we provide -- servers, bulk parts orders from Digikey/McMaster/Mouser, project spaces, specialized tools, ...

[[Organizational]]: Our organizational decision-making page

[[Library]]: Information pertaining to projects we're working on.

[[Concepts]]: A place to share your project ideas and to find like-minds.

'''[[Donate or Pay Dues]]''': Here is where you can see how easy it is to '''Donate''' to Noisebridge or to pay your monthly '''Membership Dues'''.

[[Finances]]: How to finance it. [[Bank Choices]]: choosing a bank. [[FinancialPolicy]]: how to manage.

[[Identity]]: Logos, stickers, t-shirts and stuff. [[Press Coverage]]: mentions of Noisebridge in the media (both blog and dead tree).

[[Hackerspace Infos]]: Howtos, Background, and friendly Hackerspaces elsewhere

[[Board and Officers]]: Information about our formal organization.

=== Meetings ===
'''Meetings every Tuesday at 8 PM US/Pacific at 83 C Wiese St.'''
* Next: [[Meeting Notes 2009 03 02 | 2009-03-02]]
* Prev: [[Meeting Notes 2009 02 24 | 2009-02-24]]
* ... (more in the [[:Category:Meeting Notes|Meeting Notes Archive]])

=== Events ===

There's lots going on at NoiseBridge. Check out our [[:category:events|Current Events]].

== Get in Touch ==

* [[IRC|IRC channel]] - irc://chat.freenode.net/#noisebridge

* [[Mailinglist]]

* [[People]]

* [https://www.facebook.com/group.php?gid=100998755576 Facebook group]

* [[Twitter]]

== Status ==
We began building Noisebridge in Feb 2007. Since December 2007 we've had regular Tuesday meetings, and as of October 1st 2008, we have a physical space. We are currently in the process of ironing out membership procedures and guidelines.

Meeting Notes 2009 02 24

2009-02-25T02:25:58Z

Shkoo:

[[Category:Meeting Notes]]
== Agenda Items ==
* What Noisebridge is about.
* Regular Happenings
** Circuit Hacking Mondays (8PM, 83c)
** Pyclass (Monday at 6:30PM, 83c)
** Machine Learning Wednesdays (8PM, 83c)
** Natural Language Corners
* Treasurer's report
* Project Reports
** Big LED sign
* TimeScale people
* Upcoming events
* read membership folder names

2009-02-04T02:46:18Z

Shkoo: /* Short Term */

= The Big LED Screen =

=== Overview ===

* Dimensions (in pixels) are 128 by 48
* Originally controlled by a 386; mobo is shot.
* The 386 connects via ISA to a "buffer board" which looks to be a memory buffer and power conditioner.
* The buffer board stores data into a couple memory chips, which are then accessible to the daughterboards which drive the actual LEDs.
* There are four daughterboards, in two chains of length two. Each of these daughterboards is connected to a single "section" of LEDs (ie: there are four big "sections" of LEDs). Each daughterboard runs a section of 32 by 48 pixels.

As of 2009-01-28 I am potentially leaving things connected inside it as I work on it. If you want to work on it, please make sure you either check with me or disconnect the things I added before turning it on. Thanks! --[[User:Shkoo|Shkoo]] 10:04, 28 January 2009 (PST)

=== Motherboard ===

Boring. Broken. Did I mention boring?

=== Buffer board ===

Tonight (2008-12-30) I worked from the backend up a bit, but eventually gave up. I then moved to the ISA frontside and worked down, which was far more productive.

The device appears to sit at ISA IO ports 0x180 through 0x183. The addresses are decoded by U51 (74688 comparator), which then hits the OE2 on U52-19 (74541 driver iirc). This is then used to feed U53 and U54 (both 74574 D-flip-flops). These appear to be there to combat fan-out. I'm not entirely certain where these go, but it seemed like they were going into the RAMs.

The low bits of the ISA address selection sit on the rightmost two pins on the top row of the header, SA1 and SA0, in that order (Just hook the connector up and use the multimeter if that's nonsensical). I haven't traced them through yet; I was in the middle of it when my time ran out. They look to run over to the empty chip socket on the right side of the board. Most traces tend to terminate at this chip socket, so most likely we won't be able to use the display logic on the buffer board.

=== Daughterboards ===

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 receive serial based on the following:

* The long 10-pin pigtails are as follows:
1 - UCN-40 CLK (serial clock)
2 - GND
3 - UCN-4 STROBE (latch driver)
4 - GND
5 - UCN-2 SIN (serial in)
6 - GND
7 - UCN-3 GND
8 - GND
9 - GND

Pin 1 is marked red. When looking into the end of the connector, when the red-marked wire is on the left, odd pins are on top. The keyed edge of the connector is also on top. The top left pin is pin 1.

Per Josh, the grounds do not need to be connected for now.

The serial is daisy chained together. There are two sets of two daughterboards (four daughterboards total) with 3 shift registers on each daughterboard. So, each chain of shift registers includes 6 shift registers for a total of 192 bits per chain.

* The 10-pin ports between the daughterboards (J3 and J2) are wired differently. J3 is:
1 -
2 -
3 -
4 -
5 - ground
6 -
7 - clock
8 -
9 - serial out (j2) / serial in (j3)
10 -

(The existing logic shifts out 200 bits instead of 192; we don't know why).

Looking at the sign doing STROBE: sequences 130us apart, within each sequence, 5 peaks @+5V, 4us each high, otherwise the signal is low.

Looking at CLK: We do a bunch of lcokign, the strobe, etc. 8 CLKs in 5us, entire process takes 125us, appx 200CLKs. This gives an input rate of 1.6MHz(!)

The shift register is rated for 3.3Mhz, so we could conceivably drive it faster than the 1.5Mhz that it's currently running.

== Plan of Nils ==

=== Short Term ===

The short term plan is complete.

The arduino is hooked up to drive one of the chains consisting of two daughterboards on the right half of the sign. [[Big LED Screen/ledtest.c | The software]] does not use the arduino framework; instead, it compiles with avrgcc. The arduino framework doesn't have enough processing power to run fast enough for this application.

Here are the pins that need to be connected other than power and ground:

* MOSI (PB3) - this sends serial data to the daughterboard
* SCK (PB5) - this sends lcock signal to the daughterboard
* PB1 - this should be connected to the latch/strobe signal from the old buffer board
* PB0 - this should be connected to the latch/strobe signal going to the daughterboard
* PD7 - this should be hooked up to the left side of one of the power sources on the buffer board through a voltage divider (and small capacitor to stabilize the signal) to bring the 15 volts down to 5 volts. Do not use the output of the power source, since it's not nearly as stable.

It uses the existing STROBE (latch) signal from the buffer board for timing, and reads the state of one of the buffer board's output powers to synchronize where in the sequence of 16 power sources. It captures the latch signal and re-emits it to the daughterboard.

It ignores the serial clock and serial data from the buffer board.

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.

=== Long Term ===

Get an atmel xmega based solution. It has 4 UARTs that we can use 3 of as following:

* Drive daughter board 1
* Drive daughter board 2
* Drive XBEE wireless chip for communication with the outside world so we don't have to deal with running wires through the case

We also need to control our own power, since it's really tough to synchronize based on the existing board's power so we get a bit of pixel leakage.

The xmega does DMA to its UARTs so we don't have to waste quite so much CPU time copying bytes out.

Unfortunately none of the atmel xmega series have DIP packages, so it's a bit tougher to breadboard them. TQFP 100 seems like the way to go.

If anyone wants to mess around with etching a pcb to support this solution (assuming tests on the short term solution go well), let me know. Otherwise I'll send it off to batchpcb, but that takes a few weeks. -[[User:Shkoo|nils]]