Projects/Big Ass-LED Display: Difference between revisions
No edit summary |
No edit summary |
||
Line 27: | Line 27: | ||
The address bits multiplex the latch signals to the shift registers. Data and clock is continuously passed to the ICs but new data is only latched when both the LATCH line to the module goes low AND the address and odd/even bits are matched. Clock lines for all ICs are in parallel, and data is in parallel for two chips. This makes driving many modules a pain. Much buffering and fanout is required. | The address bits multiplex the latch signals to the shift registers. Data and clock is continuously passed to the ICs but new data is only latched when both the LATCH line to the module goes low AND the address and odd/even bits are matched. Clock lines for all ICs are in parallel, and data is in parallel for two chips. This makes driving many modules a pain. Much buffering and fanout is required. | ||
=== Module | === Module pinout === | ||
Pins are on a 26-way IDC connector, which is the same as used by the original Raspberry Pi so connectors are cheap. Every other pin is ground, which is vital for signal integrity. If using a board to drive, make sure to ground as many pins as possible - preferably all of them! If using wires ground as many as possible but expect performance to suffer. | Pins are on a 26-way IDC connector, which is the same as used by the original Raspberry Pi so connectors are cheap. Every other pin is ground, which is vital for signal integrity. If using a board to drive, make sure to ground as many pins as possible - preferably all of them! If using wires ground as many as possible but expect performance to suffer. |
Revision as of 20:51, 17 September 2017
The "Big-Ass" LED displays are a pair of four 80 x 60 pixel RGBG panels (160 x 120 total subpixels) which were originally installed in the O2 Academy Leeds. These can be stacked to create a 320 x 240 subpixel display, approximately 10 ft x 10 ft across. Total power consumption varies depending on the image, but is estimated around 400 watts for the whole setup for average video content in the original configuration.
At some point during the repair of one display module, some connectors were accidentally transposed. This led to the shorting of one of the 5V, 170A power supplies inside the units causing the destruction of modules and wiring harnessess. Phil, a member, donated them to the space after the Academy scrapped them.
Each panel is composed of 150 separate display modules which are essentially giant shift registers. Driving the display is not trivial. The original design uses a complex board with an FPGA, CPLD and several kilobytes of SRAM to drive just half of one panel. A control cabinet, a 4U rackmount unit, converts composite (CVBS) video into AMD TaXiCHIP format (yes, that AMD, before they focused on just making CPUs and GPUs.) This data is sent over a fibre-optic link - this is presumed to eliminate ground loops as the data rate is not that fast and coax would have been sufficient.
The 4U rackmount cab has an issue, where the 3.3V rail is low on power on. So it will not display video for about 30 minutes until it has warmed up. It will display only a blue screen for no signal, or black when signal is input, in this state. The 3.3V LED on the front of the unit will also be visibly dimmer than the other LEDs. Once warmed up however the unit appears to work okay save for some excessive noise on the video signal though this may be due to the choice of CVBS test sources and poor, unterminated cabling. There is a basic serial terminal at 9600 baud but it has no test pattern functions or methods to load data into. The rack contains several more FPGAs and framebuffer/control ICs. It is supposed this rack sends converted, possibly gamma corrected data to the panels, which then convert it into subfields which are eventually displayed on the panel.
It appears the units date from the late 90's, approximately 1996 to 1997. The manufacturer is presumably Gearhouse ([1]), with parts being marked "GEARHOUSE SPECIAL PROJECTS", however no documentation can be found for the actual units themselves. They appear to be semi-custom engineered, as there are a remarkable number of botch-jobs and hacks to make the units work. There are more than 10 bodge wires on each of the main PCBs and connectors are sanded down on each of the 150 modules to make components fit. There are no custom plastic parts; casing is created from bent and cut sheet metal. Some parts are stamped, which is probably about the limit for tooling on the individual units. These units likely cost a fortune when they were purchased; estimate easily £50,000 in 2017 money for the full set up. Nowadays such a basic unit could be had from China for several thousand pounds! There are slight changes and differences on some module and control PCBs, but none significant.
Module information
Each display panel contains 150 modules, and each module is a separately addressed shift register with dedicated latch and data inputs. There are a total of 128 pixels on each module; 32 red, 32 blue and 64 green. There are four data inputs: red, green "A", blue and green "B". Note that there are twice as many green pixels as red or blue; this improves the apparent panel resolution with the large LEDs. Clock is shared; this becomes a significant limitation in terms of data rate. Each module has eight shift register chips each driving LEDs continuously, there is no multiplexing of actual output levels on the modules, which is a benefit, because it means that with some clever sub-field calculations (described later) very high brightness displays are achievable.
Each module operates off 5V DC. If every LED, with a constant current of about 20mA is enabled simultaneously, and no output enable strobing is used, the modules can pull 20 amps each. This is not a misprint. These things are *hungry*. They will also rapidly overheat if driven in this mode. Keep any full power operation down to very short duty cycles; less than one minute. If the module overheats, pixels will permanently die due to shift register transistor failure. Pixels will usually begin to flicker before this occurs, but failure can just occur suddenly.
Each module is configured into two halves, which are referred to in this documentation as the "odd half" and "even half". The modules also have a 3-bit address ID exposed on a 4-way DIP switch. The function of one of the DIP switches is not fully established but it must be set to zero. If it is not set, the panel will not work. The modules are connected into supergroups of up to eight modules which are addressed separately.
The shift registers are TB62726F or similar.
Note that these are just shift registers. They have NO pulse width modulation capability; to drive these panels with greyscale video content, rather than just 1-bit video, it requires some creative use of the output enable signals. If you want to drive them with an Arduino please consider that you will need to write to the modules at around 600Hz or more to get acceptable greyscale. This may be practical for just a couple, but quickly becomes unmanageable. On the other hand, for just text or other 1-bit content, they are trivial to drive and require relatively few IOs.
The whole panel is configured with a resolution of 160 subpixels wide (which is five modules of 32 pixels across) by 120 subpixels high (which is 30 modules tall.) Note that 30 is NOT a multiple of 8. If the panel had 32 modules tall this would work as four groups of eight modules, but for some unusual reason the panel is addressed in sections that vary in height. The first group, starting from the top left of the panel is 8 modules deep, but the second is 7, followed by 8, followed by 7. This makes 30 vertical modules and one very confused hacker who needed to visit the hackspace at midnight to try and figure out how 150 is factored into blocks of eight while on a twelve-hour coding binge.
The address bits multiplex the latch signals to the shift registers. Data and clock is continuously passed to the ICs but new data is only latched when both the LATCH line to the module goes low AND the address and odd/even bits are matched. Clock lines for all ICs are in parallel, and data is in parallel for two chips. This makes driving many modules a pain. Much buffering and fanout is required.
Module pinout
Pins are on a 26-way IDC connector, which is the same as used by the original Raspberry Pi so connectors are cheap. Every other pin is ground, which is vital for signal integrity. If using a board to drive, make sure to ground as many pins as possible - preferably all of them! If using wires ground as many as possible but expect performance to suffer.
- GND
- Data, Green "B"
- GND
- Output Enable, Blue
- GND
- Data, Blue
- GND
- Output Enable, Green (A & B)
- GND
- Module Odd/Even bit, low selects top row, high selects bottom row (top = components facing up)
- GND
- Module Address Bit 2
- GND
- Module Address Bit 1
- GND
- Module Address Bit 0
- GND
- Data, Green "A"
- GND
- Output Enable, Red
- GND
- Global Latch
- GND
- Global Clock
- GND
- Data, Red
Polarities
Data sampled on clock rising edge. Drive data on falling edge to avoid insane setup/hold requirements.
Clock polarity not critical.
Latch is level sensitive, low latches data, high does not latch. Use of latch is vital in subfield driving mode, but MAY be kept low permanently for small modules and fast writes (there will be some pixel "blur" as a result, but none too significant.)
Data is normal polarity, a high bit turns on a pixel, low turns it off.
Output enables are active low, they should be kept low to keep each colour on. Ideally keep high during write to avoid data bleed through; even when latches are high, written "off" pixels seem to bleed on slightly possibly due to ground bounce. Modulating the output enables is used to create subfields, described later.
Subfield driving scheme
Since the panels have no inherent greyscale capability they must be written rapidly. A similar technique to plasma display panels is used, known as subfield multiplexing or address-display separate mode. A patent describing one technique is here: http://www.google.sr/patents/US7158155