One Sept 10-14, 2007, I reverse engineered a large LED sign that had been donated to Freegeek and built new electronics to allow it to controlled via a serial port. Previously the sign had been designed for only a floppy disc. The company that made the software had long gone out of business, so it was basically unusable. Well, not anymore!!
Inside, the sign has 4 large LED boards on the front, and each as a small shift register board attached to the back of it.
Originally these were controlled by a frame buffer board and a 286 PC motherboard, which are mounted to the back cover.
Though the sign is 128 by 48 LEDs, from an electronic perspective it is really two signs, each 192 by 16. The frame buffer board drives +5 volt power to 1 of 16 columns, and two 192 bit shift registers (six UCN5832 chips) use open collector drivers to pull down on 384 rows.
I kept the frame buffer board's column driver, and I connected to 2 of the signals to detect when it is in a brief 10.8 µs blanking time between columns, and also which column it is driving. I designed a new controller to shift out the row data... so most of the circuitry on the old frame buffer board isn't used anymore! The 286 is completely disconnected.
This new controller listens for image updates on a serial port. The baud rate is 115200 bits/sec. Here is example code which reads and ASCII graphic file and sends the data to the display:
The serial data format is very simple, just a 16 byte preamble, followed by the 768 byte image data. The new data begins displaying immediately upon the 784th byte being received.
This is the 16 byte preamble:
0xd9, 0x39, 0x8c, 0xed, 0x93, 0x36, 0x60, 0x80 0x11, 0x6c, 0x4a, 0x24, 0x0a, 0x50, 0x2b, 0xd8
There is a 38 ms timeout (where it flushes its buffer and begins waiting for the preamble), so all 784 bytes should be composed in a buffer and sent to the serial port at the same time, ideally with a single call to the kernel's write function. See the source code for details.
Overheating Problem: when I put the back panel back on, a problem with overheating started to occur. The current limiting resistors for the LEDs are on the shift register boards, right next to the UCN5832 chips. If many LEDs are left on for some time, the resistors can heat the chips to the point where some pixels will start to flicker. Ideally, one or more fans should be mounted inside so air is blown BETWEEN the 4 shift register boards and the LED panels. Blowing air at the back side of the shift register boards will be less effective. The sign probably does not need vent holes... simply circulating air inside will probably disperse the heat buildup from right next to the heat-sensitive shift registers to the rest of the case.
Originally, the frame buffer board shifted out the row data at about 1.5 Mbit/sec. Because my little board emulates the original functionality using firmware (or at least my best guess of its original function), and because the SPI serial port in the AVR microcontroller is unbuffered, I had to use about 2.4 Mbit/sec to get all 192 bits shifted in the required time (approx 138 µs), due to the small delays between each byte. The UCN5832 is supposed to work up to 3.3 MHz, but in reality with the heat buildup and noise on the power supply lines (worst case of zero to 35 amp transitions as 384 LEDs turn on and off at 90 mA 1/16 duty cycle), in a warm room with many LEDs on continuously, they start to have trouble at 2.4 MHz.
In other words, it could be said I overclocked the sign and now when operating under heavy load in a warm room it requires extra cooling!
