Projects/Big Ass-LED Display

The "Big-Ass" LED displays (also called Uberdisplays) 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.

XKCD (C) Randall Munroe

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. We therefore have three apparently working units, and a bunch of modules and parts from a scrapped unit, plus casing and other small parts (likely to be scrapped soon.)

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 to the panel which then decodes it. The use of fibre-optic 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.

As part of the reverse engineering effort a new control board was designed in Altium CircuitMaker which replaces both FPGA boards inside a display. The board takes 10/100 Ethernet and exposes a UDP video sink and a Telnet terminal which can be used to send simple commands.

Current panel specifications

thumb

Early prototype demonstration video so the resolution / performance is apparent: https://www.youtube.com/watch?v=2aTxlZVE2Hg

Parameter	Rating	Notes
Dimensions	~1.2m x ~1m
Weight	Estimated >60kg
Input	90~265V AC, 16A Ceeform	Recommend 240V only due to current rating. Probably can't run it off a genset but maybe?
Resolution	80 x 60 pixels
Subpixel resolution	160 x 120 pixels
Total pixel count	4.8Kpix	Genuine 4K display
Refresh rate	60Hz / 70Hz
Network frame rate	min 60Hz
Bit depth	12 bit / 10 bit	Depends on display refresh rate, switchable on demand
Number of colours	1 billion+
Min. power consumption	114 watts	Inefficient Lambda power supply pulls 50 watts idle!
Avg. power consumption	270 watts	For a typical image sequence
Max. power consumption	625 watts	Worst case - every pixel set to white. Will quickly trigger average brightness limiter.
Control board power	2.5 watts	Varies depending on image, drive voltages & CPU usage

Controller board

The board was designed in CircuitMaker and is designed to interface with a Texas Instruments EK-TM4C129EXL development board; this was chosen to reduce soldering issues with the 128 pin TQFP and speed up the development process. The development board has built in Ethernet, a 120MHz processor with 256KB of SRAM and 1MB of flash, and plenty of IOs which are required to drive the panel latches, data and control signals.

Design files for the board can be found on the CircuitMaker cloud under "LEDExpander".

Software for the controller board will be published soon.

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 2.5 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 set to one, 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 np 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.

1. GND
2. Data, Green "B"
3. GND
4. Output Enable, Blue
5. GND
6. Data, Blue
7. GND
8. Output Enable, Green (A & B)
9. GND
10. Module Odd/Even bit, low selects top row, high selects bottom row (top = components facing up)
11. GND
12. Module Address Bit 2
13. GND
14. Module Address Bit 1
15. GND
16. Module Address Bit 0
17. GND
18. Data, Green "A"
19. GND
20. Output Enable, Red
21. GND
22. Global Latch
23. GND
24. Global Clock
25. GND
26. Data, Red

Polarities & notes

Data sampled on clock rising edge. Drive data on falling edge to avoid insane setup/hold requirements.

Clock polarity not critical.

Max device clock is 20MHz but from 3.3V practical limit is 10-11MHz. With 5V drive a clock of 15MHz is possible with some occasional pixel glitches, 12MHz is perfect. We are aiming to reach 13.3MHz with some software tweaks.

Latch is level sensitive, high latches data, low does not latch. Use of latch is vital in subfield driving mode, but MAY be kept high permanently for small modules and fast writes. As long as OE is held high during write, no blur will occur. Latch polarity has been reversed from previous documentation. A single panel will latch data correctly with either polarity in a pulse, but multiple panels must use the correct latch polarity (d'oh.)

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.

The 4-bit data bus is ideal for a Quad-SPI capable microcontroller. This technique is used by the PCB to control the panels. Driving the panels with a single SPI port is not possible as different clocks would be generated, unless clocks can be somehow synchronised. Bit-bang IO is probably the best approach for an MCU that lacks a quad SPI port.

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

Essentially, imagine that you want to display pixels of a value from 0 - 4095. The current implementation of the display controller supports 12 bit colour (plus 4 bits of dithering for ~16 bits colour depth.) Recall that each pixel in a panel can only be ON or OFF. There is no PWM control available so it would be necessary to implement PWM via individual writes. If pure PWM were used, with say a 60Hz refresh frequency and 4095 levels, it would be necessary to write to the panel around 245,000 times a second! For a resolution of 160x120 for one panel, this would require over 4.7 billion pixel writes per second. That's more in the range of GPU territory! Not something a simple microcontroller can do. (Not to mention, the 10-12MHz pixel clock limit would really restrict your write speed.)

Instead, writes are broken down on a per-bit level and instead of using fields of the same length - as a PWM method would use - variable-width on-times are used. A simple approach is to take the binary value of each pixel and examine each bit. If a bit is set in that position, then the pixel is on in that subfield. The length of the subfield is proportional to the value of that bit. For example, if our pixels had value "1500", then they would be divided into a field of 1024, 256, 128, 64, 16, 8 and 4. So the pixel would have an apparent value of 1024+256+128+64+16+8+4 = 1500. It's important to note that fields are global, so all pixels set in a given subfield are displayed at the same time.

To accomplish this, the panel needs to be written once for each bit: on-times are created by using delays between individual bits and the width of the output enables. To achieve a reasonable, flicker-free refresh rate, the subfields are refreshed at 60Hz, for 60 full fields per second, each with 12 subfields. This means the panel and controller only needs to achieve a refresh rate of 720Hz, which is much smaller than the 245kHz that the PWM method would require.