POV Display: design and implementation blog

 

The purpose of this project is to design and build two persistence-of-vision (POV) displays. The displays work in different ways. Both rely on relative movement between the observer and the display.

1.1 Static display

The physical appearance of the static display is simply a column of 128 RGB LEDs. Each “RGB LED” is actually a package containing three separate colour LEDs (red, green, and blue). See Figure 1 for a close-up.

So how do you draw a full-sized image using only one column of LEDs? This is where the phenomenon of POV comes into play: if you blink an LED fast enough it will appear to be constantly lit. This is because of the afterimage formed on the retina, which takes about 40ms to disappear[2].

If the column of LEDs is dragged from point an arbitrary A to point B then it will appear to produce a streak of light that starts at A and ends at B. If the column displays in succession the columns of an image, then that image will be drawn in distance A to B. Figure 2 shows this effect, using a long camera exposure the simulate the effects of an afterimage.

The same effect will be observed if the display is stationary (or static), and the observer moves from point A to B. This is the scenario in which the static display will be used. See Figure 3.

 

Figure 1[1]
Common-anode Avago LEDs used in the displays.
Each RGB package has three individual LEDs (red, green, and blue), as indicated by the colour arrows.

 

 

Figure 2
The Google logo was downloaded onto a test LED board that has a column of 16 RGB LEDs. The full image was drawn by moving the board in the direction shown. A camera with a long exposure was used to capture the image.

 

Figure 3
Operation of the static display.
 (a) Original image, consisting of alternating cyan and magenta bars, loaded into display.
(b) Display is static with respect to an observer who is moving in the direction shown. The relative movement causes the afterimages to superimpose hence a complete image is observed.

 

1.2 Rotating Display

This display draws an image using the same phenomenon as the static display. However, rather than having a single LED column, it has one or more LED ‘spokes’ that are mounted onto a rotating frame (such as a bicycle wheel). When the frame is spun, the spokes rotate, and an image is drawn which has a radius of an LED spoke. Figure 4 shows how four spokes are mounted onto a wheel. Figure 5 shows a commercial unit that uses one LED spoke.

Both the rotating and static displays can draw arbitrary images. This is possible as the ‘image conversion’ is done by using a custom bit-mapping program (see later).

 

Figure 4
Operation of the rotating display.
(a) Original image loaded into display.
(b) LED spokes will draw the full image when rotated fast enough. This is due to the afterimage formed by each spoke.

 

 

Figure 5[3]
“Spoke POV” display sold by www.adafruit.com.
(a) One LED spoke mounted onto a bicycle wheel.
(b) Image drawn when the wheel is spun.

 

2.0 Design Specification

  • Main processor from Microchip PIC family (preferably PIC18F4520)
  • 3-bit colour display (reproduce colours red, green ,blue, cyan, magenta, yellow, white, black)
  • Display images and text
  • Can be configured to work in two display modes: static and rotating

3.0 Design Decisions

This section discusses some of the preliminary design decisions.

3.1 PCB Design

The static display uses a single column of LEDs, whilst the rotating display uses spokes of LEDs.

Rather than having a separate PCB design for each configuration, a single PCB design that is compatible with both configurations can be produced. This has the following advantages:

  • Development time is reduced, as only a single design needs to be realised for two different configurations
  • Component costs are reduced as identical PCB designs will use the same components

The generic PCB design is an LED module with connectors on either end. This allows modules to be chained together, so that any of the two configurations can be constructed. Figure 6 shows how this is done.

 

Figure 6
Using LED modules to construct realise two display configurations.
(a) Male and female connectors allowing modules to be linked together.
(b) Static display configuration realised by stacking LED modules into a single column.
(c) Rotating display configuration realised by connecting LED modules into spokes

 

3.2 Number of Spokes (rotating display)

The choice of the number of LED spokes is a compromise between the lowest rpm that produces a stable image, and the visual presence of the LED spoke PCBs.

Having few spokes makes them appear invisible when the display is running (see Figure 5), but requires the display to rotate at a high rpm. Having many spokes means the display can rotate at a low rpm, but the presence of the spokes will be more obvious.

The number of spokes chosen for this project is four

4.0 PCB Development

4.1 LED Module

Each LED module has 16 RGB LEDs, equating to 48 individual LEDs per board. The 48 LEDs are driven using three STP16CP05 LED driver ICs, where each driver IC has 16 output channels.

The driver ICs are SIPO shift registers with additional features that make them better suited for handling LEDs. These features include regulated current outputs, programmable current sinks, and an output driving capability that allows several LEDs to be connected in series.

Figure 7 shows the LED module schematic. (opens in new tab)

Connectors on either end of the module Figure 7 (a) and (b) allow power and data to be transferred across a chain of modules.

Each module has an input for a buffered clock signal Figure 7 (c) to avoid the effects of propagation delay through a long chain.

The drivers ICs Figure 7 (d) have a serial data input and parallel outputs for driving the LEDs. They also have a serial data output which allows many of them to be cascaded in series.

Test points are situated on key signal lines, and a serial loopback link Figure 7 (e) allows errors to be detected.

The brightness of the LEDs Figure 7 (f) is controlled by current-set resistors Figure 7 (e) for each driver IC.

 

Figure 8 shows the different PCB design revisions of the LED module. It took a couple of revisions to get to the current design. The main reasons for going through these revisions were footprint errors and high-current considerations.

 

Figure 8
Evolution of the LED module PCB (double-sided).
(a) The initial revision was fully autorouted. The LED footprints were incorrect. SOP package ICs were used. The bit-mapping program was not ready, which contributed to the messy routing.
(b) The second revision was manually routed. Notice how much neater it looks! SOP package ICs were used. The bit-mapping program was ready, so routing was much more flexible.
(c) The final revision uses the Vdd power plane for heat-sinking. TSSOP package ICs are used. Flexible routing allows a high degree of symmetry in the layout.

You can see how much neater the manually routed PCBs are, compared to the autorouted versions. I found that it is definitely worth ones time to manually route the entire PCB.

Initial revisions used more surface mount components in a bid to reduce the PCB dimensions. However it was found that using through-hole parts in some cases saves more space than the SMT equivalents.

 

4.2 Control Module

Thus far we have focused on the LED driver circuitry. Now we turn our attention to the brains of the system – the Control module.

Figure 9 shows the Control module schematic. (opens in new tab)

The Control module contains the microcontroller Figure 9 (a), which is where the image data is stored, and where the data and commands which control the LEDs are issued.

An ICSP connector Figure 9 (b) allows the firmware on the microcontroller to be changed without removing the microcontroller from the board.

The data and clock lines are driven by the SPI hardware on the microcontroller (MSSP module). The clock signals are buffered through a 7400 series non-inverting driver (74AHC244) Figure 9 (c). This greatly reduces the capacitive load on the microcontroller’s SCK line.

Data is clocked into the shift registers through the serial data input (SDI) of the first LED module. Control signals issued by the Control module cause data to latch at the correct time, thereby changing the shift register outputs.

In the case of the static display, the chained LED modules form a 128-bit shift register (where each bit corresponds to an individual LED). The Control module is plugged into one end of the LED module chain Figure 9 (d). In the case of the rotating display, each LED spoke is plugged into the Control module (hence four connectors).

As with the LED module, this board has been designed with testing in mind. Serial data from the shift registers feeds back into the microcontroller allowing errors to be detected. A USART port Figure 9 (e) provides support for further debugging and future expansion.

5.0 Embedded Firmware

Each RGB LED has three bits of data associated with it (for red, green, and blue). For the rotating display, having four spokes each with a 32 RGB LED radius, and splitting the circumference of rotation into 256 segments, means 3072 bytes of data are required to store a full image (32 RGB LED packages * 3 bits per package * 256 segments = 3072 bytes). Therefore approximately 10 bitmaps can be stored in the 32KB program memory of a PIC18F4520.

Image bitmaps for the static display have the same memory requirements, assuming images are 64 pixels in width.
    
The firmware on the microcontroller is interrupt based for two reasons:

  • If polling is used then less useful operations can be performed in-between data writes
  • An interrupt-based mechanism can meet strict timing requirements

 
Data writes via the SPI module are fully handled by low-priority interrupts. One or more interrupts are used for timing (depending on the display configuration), and another interrupt is used to write to the SPI module and issue the control signals.

Synchronisation is maintained in the rotating display by using a hall sensor to detect when full revolution occurs.

The power consumption of the displays is reduced by PWM’ing the output-enable active-low (^OE) line of the driver ICs. When the ^OE line is high, the driver IC current sinks are high-impedance. When ^OE is low, the current sinks are low-impedance (i.e. driving the LEDs).

High-priority interrupts are used to implement four-channel software PWM for the rotating display (one channel for each LED spoke/^OE line). The static display has a single ^OE line which is connected to the hardware PWM module on the microcontroller.

6.0 Bit-Mapping Software

The bit-mapping software produces optimised data tables from user-loaded images. The data tables (arrays) are downloaded onto the microcontroller which writes the data to the shift registers.

The images loaded into the bit-mapping software are two-dimensional (2D), whilst the data tables produced are 1D. Compression from 2D to 1D data is necessary as the microcontroller performs 1D reads much more efficiently.

The bit-mapping software produces tables for both the static (Figure 10 (a)) and rotating (Figure 10 (b)) displays. The grids for each mode show how the image will appear on the display. Figure 11 shows examples of converted images.

Clicking the button “Copy to Clipboard” will copy the generated data table to the clipboard, so that it can be pasted into MPLAB for burning onto the microcontroller.

The physical routing of the LED modules can be arbitrary as long as the program is updated with the correct pin mapping. This greatly simplifies routing.

 

Figure 10
Bit-mapping software.
(a) Cartesian map, for the static display.
(b) Polar map, for the rotating display.

 

 

Figure 11
Examples of converted images.
(a) Original image.
(b) Converted image for rotating display.
(c) Converted image for static display. Text was written in the top corner using the pen tool in the program (also used for touching images up).

7.0 Testing

Prototype Control and LED boards were used to test the embedded software and PCB design.  A logic analyser (PICKit 2) was used to probe the signal lines.

The bit-mapping program was debugged using test colour pattern. It was later user to generate test bitmaps that were downloaded onto the prototype boards.

8.0 Current Stage

The design complete and is ready to be assembled. Component order problems have caused the final system release to be delayed.

 

Stay tuned for more updates!

▲ Up to the top