8051 Microcontroller Propeller Clock

3D DISPLAY WAND:
PERSISTENCE OF VISION DISPLAY
SHAI SCHECHTER
SUPERVISOR: DR. ERNIE HILL
BEng (HONS) COMPUTER SYSTEMS ENGINEERING

WITH INDUSTRIAL EXPERIENCE
APRIL 2013
THIRD YEAR PROJECT REPORT

UNIVERSITY OF MANCHESTER
SCHOOL OF COMPUTER SCIENCE
3D DISPLAY WAND: PERSISTENCE OF VISION DISPLAY
APRIL 2013
SHAI SCHECHTER
ABSTRACT
This report documents the design, implementation and testing process for a “persistence of vision” display:
a system in which LEDs move rapidly to create the illusion of a much higher resolution display.
The report details the design and build process for the hardware, electronics and software of the system,
and the integration of these subsystems into a finished product. The hardware incorporates a Perspex
structure and high-speed brushless motor; the electronics aspect involved designing and manufacturing a
printed circuit board consisting of 64 RGB LEDs; software was then written to address and control these
LEDs from an Arduino microprocessor. Several programs were written for computing/displaying different
images on the LED display.
Overall, the project was a success. Minor issues were identified in testing and subsequently fixed: these are
discussed within the report. Potential improvements to the system (namely wireless connectivity and a
more balanced, stable structure) are also discussed.

3D DISPLAY WAND: PERSISTENCE OF VISION DISPLAY
APRIL 2013
SHAI SCHECHTER
ACKNOWLEDGEMENTS
Thank you to Dr. Ernie Hill for supervising the project and for your valuable help, contributions and
guidance throughout.
Thank you to Dave Bowden, Dr. Jim Garside, Jeff Pepper and Ian Stutt for your valuable help during the final
stages of the project, and to Dave Clark for his brilliant handiwork—and in going above and beyond in
averting a minor electronic disaster.
Thank you also to Malcolm Bailey, Vincent James and Dr. Ognjen Marjanovic of the School of Electrical and
Electronic Engineering for your valuable help with delving into the unknown world of printed circuit boards.
Finally a huge thank you to all my friends for your encouragement with the project and for making my four
years at uni as fantastic as they were, and to Mum & Aba, Orli & co., Vity and Yali for your incredible
support and encouragement throughout this project, and in everything else I do. I couldn’t ask for more.
TABLE OF CONTENTS
1. Introduction............................................................................................................ 1
1.1. Persistence of Vision.............................................................................................................. 1
1.2. Background Review and Design Considerations...................................................................... 1
↳ Resolution and Colours.................................................................................................... 2
1.3. Risk Assessment..................................................................................................................... 3
2. Project Aims and Objectives (Specification)............................................................ 4
2.1. Practical Uses......................................................................................................................... 5
3. Hardware Design, Implementation and Testing....................................................... 6
3.1. Mechanical / Structural Design............................................................................................... 6
3.2. Motor and Electronic Speed Controller.................................................................................. 10
↳ Testing........................................................................................................................... 11
3.3. Transferring Power into Rotating Body.................................................................................. 11
↳ Testing........................................................................................................................... 12
3.4. Display Microprocessor......................................................................................................... 12
↳ Choice of Microprocessor............................................................................................... 12
↳ Microprocessor Location................................................................................................. 13
3.5. LEDs and LED Drivers............................................................................................................. 13
↳ Dedicated LED Driver ICs................................................................................................ 14
↳ TLC5940 Arduino Library................................................................................................. 14
3.6. Display Circuitry.................................................................................................................... 15
↳ Channel Selection (Demultiplexing)............................................................................... 15
↳ Current Requirements.................................................................................................... 17
↳ Circuit Schematic........................................................................................................... 17
↳ Circuit Board.................................................................................................................. 19
↳ Testing........................................................................................................................... 20
3.7. Image Stabilisation................................................................................................................ 21
3.8. Final Testing......................................................................................................................... 21
4. Software Design, Implementation and Testing....................................................... 23
4.1. Persistence of Vision Display Library..................................................................................... 23
↳ Optimising the Library.................................................................................................... 23
↳ Operating Speeds........................................................................................................... 24
↳ Library Usage................................................................................................................. 25
4.2. Image Conversion and Display.............................................................................................. 25
↳ Image Storage / Memory Capacity.................................................................................. 26
↳ Byte-Packing.................................................................................................................. 26
4.3. Text Display and Font Conversion......................................................................................... 27
↳ Custom Fonts................................................................................................................. 29
↳ Testing and Limitations.................................................................................................. 30
4.4. Double-Buffered Graphic Processing Library.......................................................................... 30
SHAI SCHECHTER 3D DISPLAY WAND

↳ Graphics Library and Vector Drawing ............................................................................. 30
↳ Test Strategy.................................................................................................................. 31
↳ Displaying and Animating an Analogue Clock................................................................. 32
5. Results.................................................................................................................. 34
6. Evaluation............................................................................................................. 35
7. Conclusion............................................................................................................ 37
7.1. Potential Enhancements....................................................................................................... 37
↳ Additional Programs....................................................................................................... 37
↳ Mechanical Stability....................................................................................................... 37
↳ Wireless Connectivity..................................................................................................... 38
7.2. Conclusion............................................................................................................................ 38
References................................................................................................................ 39
Appendix A: Existing Persistence of Vision Displays.................................................. 40
SHAI SCHECHTER 3D DISPLAY WAND

1. INTRODUCTION
1.1. Persistence of Vision
Persistence of vision (POV) refers to a phenomenon whereby the human retina retains an after-image of
anything it sees for a short time (approximately one twenty-fifth of a second). This phenomenon renders a
person unable to distinguish between different images viewed in quick succession.
By taking advantage of this phenomenon, it should be possible to produce an electronic display that
appears to have a significantly higher resolution than its hardware would ordinarily dictate, by physically
and rapidly moving the display hardware in space and modifying the display output based on its current
physical position. If the display hardware is moved fast enough, the eye should perceive the visual output
from the hardware at multiple physical positions simultaneously, giving (for example) the perception of a
two- or three-dimensional display even though the physical hardware consists of just a one-dimensional
“wand” of LEDs. The aim of this project is to design and manufacture such a system.
1.2. Background Review and Design Considerations
There are many “persistence of vision displays” in existence, both commercial and non-commercial.
Appendix A shows a number of examples. These persistence of vision displays differ vastly in size, shape
and capabilities1 , but all share the ability to physically move a number of LEDs rapidly in physical space.
The configuration of LEDs, together with the axis of rotation, dictate the shape that the display will be, as
shown in Figures 2 to 4.
Figure 2: 2D oscillating display wand Figure 3: 2D rotating display wand Figure 4: 3D rotating display wand
1 It is, however, worth noting that no evidence could be found online of a three-dimensional POV display showing more than 8
colours. Producing such a system could therefore be an interesting option to explore.
SHAI SCHECHTER PAGE 1 OF 41 3D DISPLAY WAND

The Figures show just three examples of possible POV display shapes. In Figure 2, a small number of LEDs
are oscillated from side to side in order to produce a two-dimensional arc display. This would commonly be
used for displaying text, such as a digital clock [1]. In Figure 3, rotation is used rather than oscillation in
order to produce the perception of a circular display. This could be used to display text, images, video or
any other visual media. Figure 4 is an example of a three-dimensional POV display: a one-dimensional array
of LEDs are still used but these are rotated about an axis parallel to, rather than perpendicular to, the LEDs
in order to produce a cylindrical display (alternatively a sphere could be produced by curving the line of
LEDs). A three-dimensional display has the added benefit of being viewable from any direction around the
system.
Resolution and Colours
The resolution of a POV display is partially dictated by the number of LEDs physically present in the system.
However, due to the persistence of vision phenomenon caused by physical movement of the LEDs, the
perceived resolution in the direction(s) of motion is much greater than the actual number of LEDs present.
For example, if a column of 50 LEDs arranged vertically were to be rapidly moved left and right in two-
dimensional space, and the output of these LEDs were changed 100 times between the left-most and right-
most points of movement (and the complete sweep from one side to the other were completed before the
after-image had disappeared from the retina), the effective (perceived) resolution of the display would be
100px by 50px rather than the 1px by 50px resolution that the system hardware would suggest. In other
words, the resolution in any directions of physical movement is dictated by the number of times the LED
output is modified by software within one twenty-fifth of a second.
Simple POV displays can use single-colour LEDs in order to produce their text, images or other media. This
has the advantage of being significantly easier to wire and program, while limiting the information/media
that can be displayed. At the other end of the spectrum, full-colour (RGB) LEDs are available with three
input channels in order to produce eight colours initially, but millions of colours when utilising techniques
such as pulse-width modulation (discussed in Hardware > LEDs and LED Drivers).

1.3. Risk Assessment
Any system that incorporates moving parts has risks involved, and it is vital to ascertain what these risks
could be in order to mitigate against them. The most obvious risk would be that any part mounted on the
rotating body could become disconnected from the system during acceleration or rotation and come into
contact with someone or something in the vicinity. To avoid this:
• Care will be taken to ensure that all parts are secured tightly to the system.
• Rotation hardware will be tested thoroughly without any load (such as LEDs), before the load is
added and retested.
• The system should be designed so as to not rotate when initially powered on, to prevent accidental
rotation. Software and hardware should both be in place to ensure that some kind of intentional
input is required before the system is permitted to rotate at all.
• The system should accelerate to full speed gradually: it should take several seconds to reach full
speed. Additionally, during initial testing a user input should be required at several points during
acceleration before the system is permitted to accelerate further.
• In addition to all of these preventative measures, a transparent but strong protective screen should
be in place around the system in every direction during testing as a final layer of protection in the
event that any part does become detached from the system.
As well as this obvious risk, the typical risks associated with electrical laboratory work must be considered:
all necessary safety precautions should be taken when working with any high voltages, as well as when
handling soldering irons, drills, and other potentially hazardous equipment.

2. PROJECT AIMS AND OBJECTIVES (SPECIFICATION)
The aim of this project will be to design and implement a “persistence of vision display”, as defined above.
The display will physically consist of a one- or two-dimensional array of LEDs, but these LEDs will be moved
rapidly in physical space in order to produce the illusion of a three-dimensional display when viewed from
any of a number of angles. This movement will be in a rotating, rather than oscillating, fashion, and should
be implemented using a motor. A microprocessor should be used to receive and/or compute images to be
displayed.
Power will need to be transferred into the rotating body in order to light the LEDs: a means to achieve this
will need to be considered. If the microprocessor is not mounted within the rotating portion of the system,
a means for transferring the LED data into the rotating body will also need to be considered. The system
should be capable of rotating safely at 24 revolutions per second (1440 RPM) in order to achieve a smooth
virtual image. The system display should, however, be capable of running independently of this revolution
speed: in other words, the system must have some means of determining its current speed in order that
fluctuations in the RPM do not ruin the perceived effect.
The display should be capable of displaying text and low-resolution images such as shapes and cartoon
characters: in order to achieve this the perceived display resolution should be a minimum of 32px by 32px.
Ideally the resolution will be greater than this, but this will be dependent on a number of hardware
considerations which will be investigated during the course of the project. If time and software/hardware
considerations permit, the system could be extended in order to display photographs, animations, video,
and/or include interactivity such as basic games that respond to user input.
The system must be able to interface with a PC in order to receive images for display: this would ideally
take place over a wireless link and allow the system to receive images on-the-fly whilst rotating, but at a
minimum could just be achieved by a physical connection to a PC when the display is not moving.

2.1. Practical Uses
The finished product could be used in the advertising industry, to display company logos, details or
animations in a novel way. Alternatively, the product could be used as an entertainment product in much
the same way as large television displays could be used at various entertainment events. Again, the novelty
of the device would be a key factor here, as well as the potentially reduced cost of the lower number of
LEDs required (although this would likely be offset by the additional hardware required in producing the
physical movement).

3. HARDWARE DESIGN, IMPLEMENTATION AND TESTING
This chapter offers a detailed description of the design and implementation processes for the physical and
electronic aspects of the system.
3.1. Mechanical / Structural Design
The main structure of the system will be manufactured using Perspex as it is both strong and light,
aesthetically pleasing, and the University has facilities to laser-cut the material in-house. The structure
must hold the rotating body firmly in place and allow it to spin with minimal friction: bearings housed
within the Perspex can be used for this purpose.
Initial design sketches were drawn:
Figure 5: Initial sketch of mechanical structure

The sketch, Figure 5, shows a motor (top-left) mounted a couple of centimetres above the Perspex base,
and connected by pulleys and a timing belt to the rotating axle (a 6mm screwed rod). The pulleys are at a
1:3 ratio to increase the torque from the motor. The motor is screwed to the base through elongated screw
holes: these can be used to perfect the distance between motor and axle to ensure sufficient tension of the
timing belt and prevent slipping. The axle is held in place by a bearing at the lower end, and by a
makeshift slip ring (described later in the chapter) at the upper end. A board consisting of the display LEDs
is mounted to this axle (offset several centimetres so as to draw a cylindrical display when the LEDs are
rotated about the axle by the motor). The LEDs are arranged vertically, rather than in an arc, which will
produce a cylindrical rather than spherical display when the motor spins. This is to allow for easier
mounting of the LEDs (and becomes essential if the LEDs are to be mounted on a printed circuit board, as
there was no easy access to flexible circuit boards for this purpose).
Further sketches were drawn to show the design in more details. These sketches also incorporated
approximate dimensions and other details:

Figure 6: Perspex sketches
The sketches were then used to produce a computerised three-dimensional model of the system (Figure 6).
Because of the availability of two heavy metal rods that could be incorporated into the base of the system,
the design was modified to incorporate these rods and move the motor below the Perspex base.
Theoretically this would have allowed for the entire system to be reduced in size as the motor could be
moved much closer to the axle without interfering with the rotating LEDs. However, since the long timing
belt had already been purchased, it was deemed best to leave the distance between the motor and axle
unmodified.

Figure 8: Side view of structure in CAD Figure 9: Another view of structure in CAD
The 3D model was then converted to a file format suitable for laser-cutting from Perspex sheets (Figures 8
and 9), after which the system could be assembled. Initially the system was built without removing the
protective plastic from the Perspex (Figure 10), in order to ensure everything worked correctly without risk
of scratching the transparent Perspex. Once everything had been put together and deemed to be working,
the system was disassembled in order to remove these protective sheets before reassembly.
It was vitally important to ensure that the rotating body was as balanced as possible. This was achieved by
extending the rear of the rotating body (where the microprocessor could be mounted) away from the axle:
in hindsight the horizontal pieces of Perspex would have been made symmetrical to facilitate this, instead
of one vertical piece of Perspex being much closer to the axle than the other. Nevertheless, by utilising
metal extenders and frequently testing by placing the system on its side and seeing which half of the body
was heavier, the rotating body was eventually approximately balanced.

Figure 10: The Perspex structure during construction
The remainder of this chapter describes the design, implementation and testing of various hardware and
electronic aspects of the system in more detail.
3.2. Motor and Electronic Speed Controller
Brushed DC motors are susceptible to increased friction/torque at higher speeds, such as the speed
required for this project. Brushless motors allow for correct behaviour at high speed but are often more
expensive than brushed equivalents, with some brushless motors costing hundreds of pounds. However,
brushless motors are commonly used for toy electronics (boats, helicopter propeller driving, etc) and are
therefore sold very cheaply by shops specialising in this field: a suitable brushless motor was found for just
£9.99 from a web site describing it as “ideal […] on a copter” [9]. The motor was rated at 1000kV (kV is
equivalent to RPM per volt applied with no load), which should be plenty for this project assuming the
rotating body can be kept light and low friction, as several volts can be applied to the motor from the
laboratory power supplies if required.

An accompanying Electronic Speed Controller (ESC) was also purchased to facilitate control of the motor
from an Arduino Uno microprocessor. Once wired up to the motor, bench power supply and Arduino, control
of the motor from the Arduino is accomplished using the standard Arduino Servo library.
Testing
The motor/ESC configuration was tested while at all times adhering to the Risk Assessment documented
earlier in this document: the motor was first rotated with no load applied, before integrating it into the rest
of the system and retesting. At each stage of testing, the ESC was first given its lowest possible input,
before gradually accelerating the motor to the full speed of 1440RPM required by the project. In practice,
testing of many motor speeds identified that the Perspex structure began to vibrate at speeds approaching
700RPM. A decision was therefore made to limit all testing to 660RPM until such time as this balancing
issue was resolved. This would still offer a visible persistence of vision effect, with just a small but rather
insignificant amount of image flicker.
3.3. Transferring Power into Rotating Body
One aspect of the mechanical engineering that requires special consideration is the means of supplying
power to LEDs and LED circuitry. Since these components are part of a rotating medium, it is impossible to
supply outside power directly into these components (a straightforward wire pair would of course tangle
rapidly when the body rotates). Instead, a system is required that is able to maintain electrical connectivity
at all times between a fixed and a moving portion.
Such devices are available commercially, and are referred to as slip rings. Internally these may rely on
stationary graphite brushes pressing against a revolving ring; liquid mercury to maintain contact between a
stationary outer and a revolving inner portion; or a multitude of other mechanisms. However, these
commercial products are typically designed for use in large, expensive, high power systems and as such are
far too expensive for this project (the cheapest are not much cheaper than £100).
Self-made alternatives were therefore considered. A suggestion which arose early on in the design process
was to extract the carbon brushes from within a brushed DC motor, mount these onto the stationary body
of the system, and use these to press against metal rings around the top or bottom of the rotating axle (or
use the axle itself as the ground connection, requiring just one additional ring for the +5V connection). This

idea was then furthered by the suggestion to use a ¼ ” headphone jack to provide the conducting rings
instead of making them from scratch. By mounting the headphone jack to the top of the rotating axle, and
lining it up with a headphone socket mounted in the horizontal Perspex bar across the top of the system,
power is able to be transferred into the rotating body even when it is rotating.
Since the friction between the jack and socket would be too great to allow the rotation speed required,
parts of the socket were removed and replaced by the carbon motor brushes mentioned previously. This
allowed the axle to spin with very little friction, whilst still maintaining contact with the stationary power
supply.
Testing
The “slip ring” was tested by mounted a 9V battery to the rotating body and attaching the anode and
cathode to the two slip ring wires. The voltage across these wires was then measured on an oscilloscope
from the outside of the system to ensure a consistent 9V reading when the motor was spinning. This
proved to be successful: a consistent 9V reading was measured (minor drops were observed during
acceleration, but these were not observed once the motor reached a constant speed).
3.4. Display Microprocessor
Choice of Microprocessor
Three different microprocessor families were identified as potentially suitable for this project: the PIC,
Arduino and Raspberry Pi. Research into the pros and cons of each for this sort of project was largely
anecdotal and contradictory; it did, however, appear that the School of Computer Science had far more
experience with (and support for) the Arduino family. In particular, many Arduino Uno microprocessors
were available within the School itself which would allow for a lower total cost for the project if used. The
Arduino Uno has a 16 MHz processor, which should be fast enough to display at least rudimentary images
on the persistence of vision display. While it is true that the Raspberry Pi has greatly improved technical
specifications when compared to the Arduino, many of these enhanced capabilities are entirely unnecessary
for this project. The Raspberry Pi also weighs more than the Arduino Uno (45g [10] compared to 28g [11]),
which is important to note if the µPC is mounted within the rotating portion of the system as mass here
should be kept to a minimum for rotation.

Microprocessor Location
In the interest of keeping the rotating body as light as possible in order to allow for rapid rotation, it would
be sensible to investigate the feasibility of positioning the microprocessor in the base of the system and
passing data through the headphone-jack slip ring described in the previous subsection. Two issues arise,
however:
• Noise added to the signal passing through the slip ring may be unavoidable: a non-smooth power
connection is not a significant issue, especially if smoothed with a capacitor on the inside/receiving
end of the slip ring, but for a digital signal the noise could cause incorrect behaviour
• Multiple control signals will be required between the microprocessor and the LED display, not just a
simple data line. These would all need to be passed through the slip ring, which is simply not
feasible: the slip ring designed earlier allows for three signals including power and ground, and it is
unlikely that an alternative slip ring design allowing for multiple signals could be produced cheaply
and reliably.
For these reasons, the microprocessor will be mounted in the rotating body of the system and receive a 5V
supply through the slip ring in the same manner as the LEDs.
3.5. LEDs and LED Drivers
In order to address the red, green and blue channels of 64 RGB LEDs, (3 x 64 =)192 LED driving lines are
required. Connecting these lines directly to the µPC is of course impossible (a typical microprocessor used
in this sort of project provides just a fraction of the 192 digital outputs required here; the Arduino Uno
offers ~15), instead necessitating the inclusion of a serial-in-parallel-out interface into the display system.
In addition, for more than three-bit colour depth (i.e. more than eight distinct output colours), some form
of pulse-width modulation (PWM) is required on these lines.
One option would be to use a simple serial-in-parallel-out shift register to address this quantity of LEDs
using just one µPC output line for the data and a second for the clock (or potentially a few data lines in
parallel sharing one clock). This configuration would allow for addressing of all 192 channels from the
Arduino Uno, but the LEDs closer to the µPC would flicker with the data designated for further away, as the
data was shifted through the LED array. This quick flickering would likely lead to an amalgamation of colour
on each LED, perceived as white LEDs throughout and the desired image not being visible at all. For this
reason, hardware would have to be implemented to blank the LEDs while data was being shifted and only

light the LEDs when shifting was complete, thus allowing only the intended colour to ever show on each
LED. PWM (to achieve >3-bit colour depth) would still be impractical with this configuration: either the data
for each channel would have to be re-shifted for every pulse of the PWM (which would be significantly too
slow for the processor to handle, and result in the LEDs being blanked almost all the time) or alternatively
multiple SIPO shift registers would be required in parallel (one for each bit of each colour channel) resulting
in a huge amount of repeated hardware.
Dedicated LED Driver ICs
Instead, research was conducted into dedicated LED driver integrated circuits (ICs), which integrate
hardware for serial-in-parallel-out shifting, current limiting, LED blanking, multi-bit PWM, and so on. The
Texas Instruments TLC5940 was chosen as it interfaces well with the Arduino Uno, has a relatively low price,
and offers a multitude of useful features for driving (common-anode RGB) LEDs. Specifically, the IC provides
a 16-channel output, but the IC can be daisy-chained allowing for 12 ICs to provide the 192 output channels
the system requires. The IC also provides 12-bit PWM, which theoretically provides a 36-bit colour depth, or
almost 70 billion different colours (in practice such a huge depth is unnecessary but unavoidable, and in
any case will likely be limited to 24-bit or less by the image files/compressions used). Since the IC is
primarily designed for LED driving, numerous additional features are provided that will be useful for this
project: these include a feedback loop for controlling LED current (reducing the number of current-limiting
resistors required from 192 to just 12) as well as a dot-correction feature allowing for any discrepancy in R/
G/B LED brightness to be corrected in software. The datasheet indicated that the IC would be more than
capable of handling the data transfer rates necessitated by the system’s persistence of vision requirement.
TLC5940 Arduino Library
Conveniently, Arduino recommend a GPL-licensed software library for controlling the TLC5940. However, the
library did not appear to be primarily designed for persistence of vision applications (and in particular not
for POV applications with such a high number of output channels), in that it was not optimised to provide
the high data transfer speeds required by this project. To give one example, the library requires each LED
channel output to be set using a separate function call, significantly slowing down the data setup process
for displaying each column of the display. Based on the 16 MHz clock of the Arduino Uno, there are simply
not enough clock cycles available to afford this kind of function call overhead (an entire column of 192
channel outputs must be computed and output in less than a millisecond in order to achieve the data

output rate necessitated by the persistence of vision requirement of the project). The only solution, while
still adhering to the Requirements Analysis for the project, is to write a custom TLC5940 Arduino library,
from scratch, for high-speed persistence of vision displays. The design, implementation and testing of this
library will be discussed in the following chapter (Software > Persistence of Vision Display Library).
3.6. Display Circuitry
Manually wiring 64 RGB LEDs would be impractical: a printed circuit board (PCB) will therefore be designed
and manufactured instead. Surface-mount components would be used in favour of through-hole technology
where possible in order to keep the rotating body of the system as light as possible, and because RGB LEDs
with a diameter less than 5mm are only available as surface-mount devices. The board will be
manufactured in the School of Electrical and Electronic Engineering at the University, and Altium Designer
will be used to design the circuit schematic and board layout as it is the only software supported for
manufacturing within the School.
Channel Selection (Demultiplexing)
Depending on the data transmission protocol used between the microprocessor and display circuitry, there
is a possibility that there will only be one pin of the microprocessor on which serial data can be sent2 . To
accommodate this possibility, the display circuitry should be designed to include demultiplexing hardware:
this would allow data to be transmitted down one wire, alongside a channel selection bus (three wires:
SELR, SELG, SELB) to allow the demultiplexer to route the serial clock to the relevant channel (red, green or
blue). This ensures that the serial data for each colour is clocked only into that channel (Figure 11).
By using three distinct selection bits instead of encoding the three possibilities (R/G/B) into just two bits,
the circuit benefits from reduced hardware complexity. The demultiplexing schematic shown in Figure 11
can be implemented using just one IC (a Texas Instruments SN74HCT08 / quad two-input AND gate). By
setting any one of SELR/SELG/SELB to be logic high, only the channel for the corresponding colour will
receive the data being clocked in from the microprocessor.
2 Specifically that if the SPI module of the microprocessor is used, there will be only one pin on which data can be sent. The
decision of which transmission mechanism to use is made in the following chapter (Software).

Figure 11: Circuit schematic for demultiplexing the clock to the correct colour channel
For full-colour output each of the three selection lines should be set high in turn, and the data clocked in
for that channel whilst its selection line is high. For single colour output (useful when the microprocessor
does not have enough time and/or memory to compute full RGB data), only one set of data must be
clocked through by setting one or more selection lines high and clocking data for all 64 LEDs (allowing a
single colour of red, green, blue, yellow, cyan, magenta or white – or a darker shade of any of these
colours).
In addition to the five signals shown (global data, global data clock and three channel selection bits) and
two power lines (V+ and ground), the following signals are also required:
• VPRG – to select between ‘data transfer’ and ‘dot-correction setup’ modes of the LED driver ICs
• BLANK – to blank the LEDs whilst the next column of LED data is transferred from driver memory to
LED output. Also resets the PWM counter to 0, ready to display the next column
• XLAT – to latch the data from driver memory to LED output during the time that BLANK is set
• GSCLK – clock for pulse-width modulation of the LED output. This will simply be linked to a timer
interrupt pin of the µPC to provide an 8 MHz square wave
This gives a total requirement of 11 input pins to the display circuit board. A standard 12-pin header will
therefore be used.

Current Requirements
The absolute maximum current permitted for the LEDs being used is 50mA for red and 25mA for both green
and blue [12]. However, when testing the LEDs it was clear that these values would be far too bright (and
even uncomfortable) for the viewer. Much lower values were therefore tested instead: even as low as 2mA
still offered a fairly bright display and, since the current range supported by the TLC5940 driver IC is
5-120mA, 5mA was chosen as the current per LED channel for the system.
This per-channel current meant that the maximum theoretical3 current consumption for all the LEDs in the
system combined would be (0.005 x 64 x 3 =) 0.96A. The total current rating for the board would therefore
be a little higher than this (to account for the 16 driver ICs and other circuitry). Research online [13][14] and
conversation with the project supervisor indicated that the circuit board tracks handling this amount of
current should be thicker than the 0.25mm signal tracks: a track width of 1mm was instead selected for the
routing from V+ to the LEDs and back to GROUND.
This power can be provided by a bench power supply: the supply has a customisable-voltage output which
will be used for the electronic speed controller and motor, and a second supply fixed at 5V which will be
used for the display microprocessor and LEDs.
Circuit Schematic
To simplify schematic circuit design, and to take advantage of the repeating/modular nature of the circuit,
the design was separated into four repeated subsystems (Figure 12), each containing 16 of the LEDs and
their corresponding drivers and other circuitry (Figure 13).
3 Maximum current would be when all 64 LEDs are white in colour.

Figure 12: Circuit design of overall system (including four instances of 16-LED subsystem, in green)
Figure 13: Circuit design of each 16-LED subsystem

The capacitors across the power pins of every IC are to decouple them from the rest of the circuit to
provide some degree of spike protection [15]. The resistors for each driver IC are necessary to set the
current provided to each LED; the value of the resistor is calculated using the equation given in the TLC5940
datasheet for setting current (Imax) based on VIREF (fixed at 1.24V) and the resistor value chosen. Based on
the desired 5mA per channel chosen earlier:
7.8kΩ resistors were therefore used, as this was the closest available resistor value.
Circuit Board
After ensuring that the subsystem design and overall schematic were correct, the design was then mapped
to a circuit board layout, and positioning and track routing was performed. Although the TLC5940 IC had a
footprint library available on the Texas Instruments web site, the LEDs themselves did not have any
footprint library available online or from the manufacturer. A library was therefore produced manually using
the tools provided in the software and physical data obtained from the LED datasheet.
The component placement was completed manually in order to ensure that the LEDs were all aligned
vertically, and that there was sufficient space for track routing around the components. Initial routing was
also completed manually to ensure that power to the LEDs was through thicker tracks than the signal lines
in order to (as explained earlier) accommodate the current consumption of the LEDs; the remainder of the
signal routing was then conducted by the built-in software auto-router. The completed board design is

shown in Figures 14 (2D view) and 15 (3D view). Once the routes had been placed (and drill holes marked),
the board was ready to be manufactured.
Figure 14: Completed board design (2D view)
Figure 15: Completed board design (3D view)
Testing
There were a few problems with the first board manufactured:
• The pads for one of the LED driver ICs was missing (due to a mistake by the technicians when
transferring the design to a new file)
• The ICs did not have holes for heat dissipation, as recommended by the datasheet
• The LED pads were a little too short to be surface-mount soldered by hand.

A second board was therefore manufactured that rectified these issues.
3.7. Image Stabilisation
The system needs a means of tracking rotation speed in order to stabilise the displayed image: in order for
the viewer to perceive a static image (rather than the image being drawn at a different position around the
cylinder on each rotation), the software needs a frame of reference: some means of identifying the exact
speed at which the rotating body is rotating. This can be achieved using a Hall effect (magnet) sensor and
magnet. The magnet will be mounted to the static body of the system, and a latching Hall effect sensor
connected to a digital input pin of the Arduino. The sensor (a US1881 CMOS Hall effect latch) latches to a
logic high voltage on encountering a magnetic north pole, and logic low for magnetic south. By placing a
north pole followed by a south pole in the path of the sensor during rotation, and configuring the Arduino
input pin to interrupt on a falling edge, the system is able to recognise when it has passed the specific
static reference point at which the magnet has been placed.
This information could be stored and compared to previous interrupt times in order to calculate a rotation
speed. In practice, however, this solution is more complicated than necessary. Instead, by simply resetting
the ‘column index’ variable to zero on each Hall sensor interrupt, the image should stabilise itself since
image position is directly correlated to these column indices: if each indexed column always occupies the
same physical space, the image will appear stabilised.
3.8. Final Testing
Once the hardware and electronics had been designed and implemented, and individual subsystem testing
had been completed where appropriate, the various parts of the system were integrated and tested as a
whole.
The final display software had not yet been written at this stage, but prototype software from earlier in the
design process had been. This prototype software was therefore used to test the display circuitry: the
software simply lights N LEDs in a given colour (e.g. green), where N is the index of the current column
being displayed i.e. one LED in the first column, two in the second column, and so on. When rotating, this
should be perceived as one or more right-angled triangles on the POV display.

Unfortunately, an issue arose during this testing in which the LEDs suddenly started to light incredibly
brightly, followed by smoke being emitted from one of the LED driver ICs. The power supply was
immediately switched off to prevent any further damage. The problem was identified: the LEDs were being
powered from a separate supply than the microprocessor, despite signals being sent from the latter to the
former and no connection being made between the two grounds. This had allowed for mismatches between
the power and signals of the LED drivers, and had sent their outputs into a positive feedback loop that
ended up drawing extremely high current from the power supply. Once the damaged IC had been removed
and a replacement re-soldered, the solution was simple: the system setup was modified to power the
microprocessor and PCB from the same 5V supply.
The LED circuitry then worked correctly. However, the LEDs and microprocessor would frequently lose power
for a fraction of a second (enough to reset the microprocessor). This was resolved using a large electrolytic
smoothing capacitor across the power lines once they enter the rotating body.

4. SOFTWARE DESIGN, IMPLEMENTATION AND TESTING
This chapter offers a detailed description of the design and implementation processes for the software and
associated libraries written to run on the display microprocessor.
4.1. Persistence of Vision Display Library
The POV Display library (pov.h) controls all interfacing between the µPC and the display circuitry. The library
was written specifically for this project as an alternative to the publicly available TLC5940 Arduino library
(for reasons mentioned in Hardware Design > LEDs and LED Drivers, above), and includes code that can:
• configure and control the TLC5940 (LED driver ICs)

• transmit LED data to LED driver memory
• clock the LED PWM controllers
• keep track of system state (column indexing)
• stabilise image position by monitoring rotation speed
Optimising the Library
In order to draw at least 64 RGB columns of the image in less than 42ms (to permit 24 complete rotations
per second), the library must run fast enough to enable a column to be output in (1 / 24 / 64 ≈) 650µs. To
do this, certain manual optimisations must be performed: for example, bit-setting and bit-clearing
preprocessor macros are used instead of calls to predefined Arduino functions (reducing such operations
from approximately 12 processor instructions to just one).
In addition, the SPI (Serial Peripheral Interface) module of the Arduino can be used to transmit data to the
LED drivers: this module allows byte-data to be transmitted down a serial link with accompanying clock (the
exact configuration used by the TLC5940 LED drivers) at a much faster rate than manually transmitting
through digital output pins. Prototype software was written to measure the performance increase: SPI
allowed a full column of RGB LED data to be transmitted in 342-600µs4 , compared to 4000µs with manual
transmission. Manual transmission would therefore be capable of supporting a theoretical maximum of just
ten columns per rotation (less in practice, due to time needed to compute the column data prior to
4 The discrepancy here is due to there being a number of ways to determine when one SPI byte transfer has been completed before
beginning the successive transfer. Maximal performance (342µs) can only be achieved by issuing the correct number of assembly-
language NOP (no operation) instructions to the processor while waiting for the SPI byte transfer to complete (instead of waiting for
the “SPIF” interrupt flag to be set, indicating a completed transfer). This works reliably because the SPI clock is driven from the
main system clock and number of clock cycles taken is therefore predictable – but results in extremely inelegant (and more difficult
to maintain) code.

transmitting it), compared with up to 122 columns per rotation with SPI (again, less in practice due to
computation time, but still allowing the specification of >64 columns to be met).
Operating Speeds
The PWM (pulse-width modulation) controller of the TLC5940 IC requires a continuous clock input to enable
it to compute and output its pulse-width modulated signals to the LEDs. Once 4096 pulses of this clock
signal (known as GSCLK in TLC5940 documentation) have been sent, the entire PWM for one column has
been displayed and the LEDs should be blanked in order for the subsequent column data to be latched to
the LEDs and the process to repeat: in other words, all data for a subsequent column must be clocked to
the driver ICs in less than 4096 x GSCLK pulse time.
To have any chance of accomplishing this, the GSCLK signal must come from some Arduino hardware that
does not require interrupting the processor flow of execution, as the processor will otherwise not have
enough time to compute and transmit all the data for a subsequent column to the drivers. Thankfully this is
achievable by configuring the timer interrupts to output to one of the digital output pins on timer overflow,
without any interrupt handler needing to be executed at all [16, pp.106-112].
Since the Arduino Uno has a clock speed of 16MHz, this is clearly the fastest speed at which a GSCLK pulse
can be generated without the use of an additional oscillator. The Arduino does allow this 16MHz system
clock to be output directly to pin 8 (CLKO) by reprogramming one of its fuses, and this could be connected
to the GSCLK input of the driver ICs. However, this would mean that the data for a column must be
computed and transmitted within (4096 / 16MHz =)256µs. Since it has already been established that a full
column of RGB data takes a minimum of 342µs to transmit, this GSCLK rate is clearly too fast.
The next fastest practical speed of 8MHz, however would provide a suitable time of 512µs in which to
compute and transmit RGB data using the Serial Peripheral Interface. This is therefore the speed that will be
used. An 8MHz clock can be output on pin 3 of the Arduino Uno by configuring the Timer0 interrupt to use
no pre-scaler and overflow after just one clock pulse, toggling pin 3 (OC2B) [16, page 159] as the timer
counter alternates between zero and one at 16MHz and therefore producing an 8MHz output.
Using this information it is possible to calculate the number of columns to display on the LEDs per complete
rotation. Since the computation/transmission time allocated for each column is 512µs, 1953.125 columns

can be drawn per second. Since 24 complete rotations are expected per second, the number of columns per
rotation is equal to 1953.125 divided by 24, or 81.38 columns per rotation. For simplicity, this will be
rounded to 80 columns, giving a display resolution of 80px by 64px.
Library Usage
The library is designed to be included into an application, and can be initialised by a single call to
initializePov(). The povDraw(uint8_t columnNo) method can then be overridden from
within the application in order to implement drawing of each column of the image. This implementation is
what controls the actual image to draw, and could specify the drawing of images, text, or other media as
described in the remainder of this chapter.
4.2. Image Conversion and Display
One use of the system is to display colour images (including low resolution photographs) using the
persistence of vision technique. These images could be simple shapes, drawings (illustrations; cartoon
characters) or even low resolution (80px x 64px) photographs. Using the POV library described above,
drawing such images is straightforward:
1. Store the image data for each channel separately as a two-dimensional array of channel
intensities, organised by column, then pixel (byte) data
2. On each execution of povDraw(uint8_t columnNo), for each colour channel, use the
columnNo parameter as an index to the data array for that colour. Simply iterate through every
byte of the column data transmitting each, in turn, to the SPI.
The significant stage in the process of displaying images on the POV display is therefore not in
transmission, but in the (pre-)compile-time phase of generating these two-dimensional byte arrays. This
was achieved by writing a Java application, povconvert, designed to take a regular image file (PNG, JPEG,
etc) as input, resize it to fit within a 80px by 64px box, and iterate through the raw pixel data of the image
in order to output a C header file containing the byte data for each column of each colour channel. The
algorithm for resizing into this bounding box is given here:
width = original image width

height = original image height
if image is too large to fit within bounding box:
calculate aspect ratio (width / height)
if aspect ratio is wider than bounding box aspect ratio:
resize image proportionally so that image width = bounding box width

else:
resize image proportionally so that height = bounding box height
This algorithm guarantees that the image fits entirely within the bounding box dimensions. The resized
image is then positioned in the centre of a black canvas and a C header file generated based on the raw
pixel data of the (newly resized) image. The header file can then simply be ‘#include’d into the Arduino
application and compiled.
Image Storage / Memory Capacity
The Arduino Uno has 2KB of RAM [17]. The amount of memory required to store an eight-bit-per-channel
image for display within this system:
= rows * columns * number of channels * bits per channel
= 64 * 80 * 3 * 8
= 122,880 bits
= 15 KB.
Even if the number of bits per channel were reduced to just two (which would reduce the number of
colours available to just 64) the image would still not fit in RAM.
Fortunately, since the image data does not need to be modified at runtime, it is possible to store the data
in flash memory (where the program code is also held) instead of in RAM. The Arduino Uno has 32KB of this
memory, of which 0.5KB is used by the bootloader [17] and a little more will be used by the program code
and POV library, leaving plenty of available memory for the image data itself (even if the image were stored
at up to 16 bits per channel). Utilising flash memory instead of RAM simply involves use of the PROGMEM
keyword, prog_uint8_t data type, and pgm_read_byte method for reading back the data [18][19].
Byte-Packing
Although the original image files used have eight bits per pixel per channel, and the SPI module of the
Arduino is designed specifically to transmit data as eight-bit words, the LED driver ICs require a 12-bit word

per LED channel. The Java application accommodates this discrepancy by shifting the original eight-bit
image data four bits to the left to produce a 12-bit intensity value, then packing this 12-bit data back into
eight-bit words for the C array. For example, where a string of eight letters (e.g. AAAAAAAA) represents the
eight bit value of the red channel of each pixel:
redData = { AAAAAAAA, 0000BBBB, BBBB0000, CCCCCCCC, 0000DDDD, DDDD0000, …, …, …
Since the LED drivers accept 12-bit values, this data will be recognised for display on the LEDs as—
AAAAAAAA0000
BBBBBBBB0000
CCCCCCCC0000
DDDDDDDD0000
...
—resulting in the intended pixel intensities being displayed on each LED. This works due to the absence of
any word start/stop bits in the SPI protocol used here: the TLC5940 ICs will simply assume the first twelve
bits received to be the first word, and so on, even if the sender is sending them in eight-bit chunks.
Although the storing of so many zeroes is technically redundant, it allows for increased computation
performance at runtime as the data can be sent to SPI as-is. The potential downside to this is the increased
memory requirement, but it was shown above that the flash memory of the Arduino Uno is large enough to
hold these 12 bits per pixel per channel.
4.3. Text Display and Font Conversion
As well as images, one of the Project Objectives was for the persistence of vision display to be capable of
displaying text. Although this could technically be achieved by uploading an image containing text and
running the image display program discussed previously, a full text displaying engine would certainly be
preferable.
To display text, the system needs to store some kind of letter data: this can be implemented as a look-up
table (array) of individual letters, each of which is itself an array containing column data for the letter. For
example, the pixel data for an uppercase E is shown in Figure 16.

11 10 9 8 7 6 5 4 3 2 1 0
Figure 16: Pixel data for uppercase E in look-up table
Due to the relatively low resolution of the display, anti-aliasing would offer little benefit and can therefore
be disregarded. This means that each pixel has one of just two possible states (on or off) and can therefore
be encoded as one bit; each column of each letter can therefore be packed into a 16-bit integer. For
example, column 5 in Figure 16 would be encoded as 1100000110000011 (binary) = C183 (hexadecimal).
Columns should be stored from right to left, as the rotating body will be rotating clockwise and therefore
will be drawing the right-most column first.
In order to allow display of variable-width characters (the letter I occupying fewer pixels horizontally than
the letter M, for example), a letter-terminating code (0xFFFF) will be added as the final column data of each
letter: when this is encountered, the engine will move to the next letter of the message to display
(technically, the previous letter as messages will be written from right to left due to the LEDs rotating
clockwise). Otherwise, it is simply a case of overriding the povDraw(uint8_t columnNo) method of
the POV Display Library and drawing the next column of the current letter of the message to be displayed.
Two pointers are maintained: one to the current letter of the message, and the other to the current column
of that letter. In order to make the display more visually exciting, on moving to the next letter to be
displayed, a new colour is chosen from a look-up table of four different colours (yellow, green, magenta
and blue), although this can easily be changed from within the code.

Custom Fonts
To further the text display capabilities of the project, a custom font feature was added to the text engine. In
the context of the engine, using a different font simply refers to modifying the look-up table of character
data for each character, to resemble the character in that new font. To assist in generating this font data,
the povconvert Java application used to generate images for display in the system was extended to also
generate font character look-up tables from a given input font. The output was once again a C header file
that could be included into the Arduino C program. The Java converter worked by iterating through the
columns of an image that displayed the string ABCDEFG….[etc] in black on a white background, and
producing a C array of this column data for each character. When one or more adjacent white columns were
encountered (i.e. the boundary between one character and the next) the character termination code was
added to the C array.
Writing a message in a specific font could then be achieved by:
• If the font had not yet been converted to the POV display-readable format, create a readable font
using povconvert
• Set the FONT_FILE constant to be the path to the font with which to display the message
• Set the MESSAGE_TEXT constant to be the string to display
• Compile and download the Arduino program to the display microprocessor
The output of the system for the word “SPINNING” is shown in Figures 17 (stationary) and 18 (rotating).
Figure 17: Output for the word “SPINNING” when stationary Figure 18: Output for the word “SPINNING” when spinning

Testing and Limitations
Testing of a variety of messages and a variety of fonts all proved successful. However, the results were not
ideal when long message were used (messages that could not fit within the 80 columns of the display) as
the beginning of the message would be absent. Furthermore, only one row of text could be displayed using
this method of displaying text. There limitations both stem from the fact that the computation of how to
display the text was performed on a column by column basis as the data was output to the LEDs. A much
better mechanism would be to calculate exactly where the text should be in advance, store this in a buffer,
and output the column data once this had been calculated. This would allow long messages to scroll
(animate), span multiple lines, etc. This could be incorporated into the graphic processing library described
next.
4.4. Double-Buffered Graphic Processing Library
During the design and implementation stages of the text display engine, it quickly became apparent that
there were inherent limitations to coupling the computation of data with the transmission of that same
data. In order to use the system to its maximum potential, some kind of display buffer was required that
could be used to compute LED data once, and this data would subsequently be fed to the LEDs column by
column as the data was required.
This mechanism would solve the limitations described in the previous section (Text Display) because the
system would then have knowledge of the entire display canvas when making drawing decisions, rather
than making these decisions in an on-the-fly (column by column from right to left) manner.
Graphics Library and Vector Drawing
The library written to achieve this goal, povGraphics.h, was fairly straightforward. The library provides
an 80px by 64px canvas of 1-bit pixels (implemented as a two-dimensional array, packed into bytes), and
pixels can be set or cleared by calling the POVG_SET_PIXEL and POVG_CLEAR_PIXEL functions
respectively (technically pre-processor macros rather than functions, for efficiency). In addition, higher-level
functions are provided for drawing more complex arrangements of pixels: internally these functions simply
compute pixel locations and make calls to POVG_SET_PIXEL.

One of these functions, povgDrawLine, was used to draw lines onto the canvas between two specified
points. The line-drawing algorithm used was a C implementation of Bresenham’s Line Algorithm, an
extremely efficient algorithm utilising only integer addition, subtraction and bit-shifting (all cheap single-
cycle operations on the Atmel AVR processor of the Arduino Uno). A circle-drawing algorithm, using the
same three operations, was also implemented and could be executed by calling povgDrawCircle with
the centre coordinates and radius of the desired circle. Again, this function internally calls
POVG_SET_PIXEL for each pixel location it computes.
At its simplest level, the library functions would simply be used in a setup function when the system is
first powered on, in order to compute the canvas that will be drawn throughout the time that the system is
running. However, with some additional work it seemed feasible to extend the library to allow for non-static
images (animation) to be displayed, by creating a second canvas (buffer) in memory. The system would
create one “thread” to handle transmission of column data to the LED drivers/LEDs from one canvas (the
“front buffer”) while the remaining idle time of the processor is used to compute a subsequent frame to
display, using the “back buffer”. Once the back buffer has been fully computed and a fixed period of time
has elapsed (determined by the desired frame rate of the animation), pointers to the two buffers can be
swapped in order that the newly computed canvas is now being drawn to the LEDs, while the other buffer
(now the “back buffer”) can be written to during processor idle time.
Test Strategy
The double-buffering system was first tested by hard-coding two distinct canvases (one with alternating
rows of on-pixels and off-pixels, and the other with a rectangle in the centre) and programming the system
to swap between the two buffers every 24 rotations (approximately once per second). Once this was
working, the system was extended to implement some computation rather than hard-coded values: a
horizontal line was drawn in the top-most row of the canvas, and every second this line moved down by
one pixel (returning to the top once the bottom was reached). This test also worked as expected. Similar
tests involving diagonal lines, circles and so on were also conducted, and passed.
Since the two 80px by 64px canvas buffers combined occupy 1.25KB of system, and the Arduino Uno has
just 2KB of RAM [17], it becomes impossible to increase the colour resolution of the graphic processing
system beyond 1-bit per pixel (without reducing the canvas size). The graphics library will therefore only be

able to draw in one colour at a time. The colour used can be specified at compile-time, but it would be
trivial to implement an input to the microprocessor to allow for colour changes at runtime (such as a
button to cycle through a range of different preset colours).
Displaying and Animating an Analogue Clock
The animation and vector graphic drawing components of the POV Graphics Library described here provides
everything required for the implementation of an analog clock on the POV display. This can be achieved by
setting the frame rate of the double-buffering to be one second, and on each iteration of the drawing
algorithm the number of elapsed seconds can be incremented (with an overflow at 60 seconds to increment
minutes, and at 60 minutes to increment hours).
The clock face can be drawn using the circle drawing function for the clock face, and the hand end-points
(or the hand angle, implicitly) retrieved from a lookup table of end-point values: lookup would be based on
the number of hours, minutes and seconds elapsed and would then be used to draw the hands by calling
povDrawLine from the centre of the clock face to the hand end-point. Only one quadrant of end-point
values (15 values) need be stored: the remaining three quadrants can be calculated be swapping and/or
negating values from the top-right quadrant. A function, getHandEndPointOffset, was written to
implement this process based on a hour/minute/second input value from 0-59. To avoid overcrowding the
clock face, the seconds will be displayed as a single pixel around the outside of the clock face rather than
as a line from the centre. Figure 19 shows the clock program when running.

Figure 19: System output for analog clock in red (showing time 12:47:02)
Currently, the clock program requires the starting time to be hard-coded, as the system has no means of
keeping time when power is removed. However, this could be corrected relatively easy: one method would
be to purchase a radio clock receiver (such as the DCF77), and connect this to the Arduino Uno in order to
ascertain the current time on system startup (and potentially at regular intervals after this).

5. RESULTS
This chapter shows a range of sample images output by the system. The images were captured by
increasing the exposure time on a Panasonic digital camera.
Figures 20–26: photographs of sample system outputs

6. EVALUATION
This chapter offers an evaluation of the project: particularly to what extent the final system adheres to the
initial project specification.
• The aim of this project will be to design and implement a “persistence of vision display”.
✓ A persistence of vision display was successfully built and implemented.
• The display will physically consist of a one- or two-dimensional array of LEDs, but these LEDs will be
moved rapidly in physical space in order to produce the illusion of a three-dimensional display when
viewed from any of a number of angles.
✓ The system consists of a one-dimensional array of LEDs, moving rapidly in physical space in order to
produce the illusion of a three-dimensional (cylindrical) display.
• This movement will be in a rotating, rather than oscillating, fashion, and should be implemented using a
motor.
✓ The display is rotational.
• A microprocessor should be used to receive and/or compute images to be displayed.

✓ The Arduino Uno mounted to the rotating body computes images to be displayed, and transmits the
computed images to the LED drivers/LEDs.
• Power will need to be transferred into the rotating body in order to light the LEDs: a means to achieve
this will need to be considered.
✓ The DIY “slip ring” consisting of a headphone jack/socket was used to achieve this power transfer.
This worked successfully.
• If the microprocessor is not mounted within the rotating portion of the system, a means for transferring
the LED data into the rotating body will also need to be considered.
[Not applicable – the microprocessor was mounted within the rotating body.]
• The system should be capable of rotating safely at 24 revolutions per second (1440 RPM) in order to
achieve a smooth virtual image.
๏ The system began to look and feel unstable when the motor was accelerated above approximately
10 revolutions per second (600 RPM). This was due to a slight imbalance between the mass/shape
on each side of the axle, and unstable angle connectors between the vertical and horizontal Perspex
of the stationary body.
• The system must have some means of determining its current speed in order that fluctuations in the RPM
do not ruin the perceived effect.

✓ The Hall effect sensor achieves this successfully.
• The display should be capable of displaying text and low-resolution images such as shapes and cartoon
characters.
✓ Text, shapes and cartoon characters can all be displayed on the persistence of vision screen.
• The perceived display resolution should be a minimum of 32px by 32px. Ideally the resolution will be
greater than this […].
✓ The vertical resolution of the system is 64 pixels, and the perceived horizontal resolution of the
system is 80 pixels (easily increasable in software, depending on rotation speed).
• If time and software/hardware considerations permit, the system could be extended in order to display
photographs, animations, video, and/or include interactivity such as basic games that respond to user
input.
๏ Photographs work, but dark photographs are perceived to be poor quality due to the lack of colour
differentiation at dark LED colours. Animation was implemented successfully. Interactivity could be
implemented in future, as could video if the microprocessor were replaced to have more memory,
processor speed, and/or wireless connectivity.
• The system must be able to interface with a PC in order to receive images for display: this would ideally
take place over a wireless link and allow the system to receive images on-the-fly whilst rotating, but at a
minimum could just be achieved by a physical connection to a PC when the display is not moving.
✓ Due to hardware limitations of the µPC, wireless communication was not possible. Images and
programs can, however, be downloaded from a computer using a USB A–B cable when the display is
not rotating.

7. CONCLUSION
This chapter details significant potential enhancements that could be made to the system moving forward,
before presenting a final conclusion of the project.
7.1. Potential Enhancements
Additional Programs
As well as the software detailed in this report, additional programs could be written to enhance the
capabilities of the system. For example:
• Implementing basic input to allow for interactive selection of what text to display
• Increasing the frame rate of the animated clock animation to allow for smooth animated vector
graphics, such as scrolling messages or more advanced animations
Both of these examples could be implemented using the existing hardware.
Mechanical Stability
As noted in the Evaluation, the system became slightly unstable as the motor exceeded 10 revolutions per
second (600 RPM), and would likely have become very unstable (even unsafe) at speeds approaching the
desired 1400 RPM. This was likely due to the weak angle supports used at the top of the system, as well as
a slight imbalance between the mass/shape on the two sides of the axle.
The first of these could be rectified by replacing the weak angle connectors with much stronger Perspex
corner wedges: this was in fact the intention in the original designs, but was never implemented due to the
unavailability of the correct thickness of Perspex. The second issue is slightly more difficult to modify, but
would be achieved by remanufacturing the rotating body to make the central axle equidistant from the PCB
and microprocessor and precisely balancing the vertical positions and masses of these system components.
With these two changes made, it is likely that the system would be significantly more stable at higher
speeds.

Wireless Connectivity
The second major enhancement would be to allow wireless transmission of images to the system. This
would allow for increased processing power, as processing could be achieved on an external computer and
the resultant images/frames transmitted to the POV display. Video or interactive games, for example, could
then be easily implemented within the system: all heavy lifting would be performed at the computer level
and the POV system would effectively become a wireless display monitor.
The reason this was not implemented was that the only practical way to achieve wireless communication
with the Arduino Uno is to use the Wireless SD shield, which requires use of the SPI module of the Arduino.
Since the SPI module and pins are already required for transmitting LED data to the LEDs, they were
unavailable for use in wireless communication. A different microprocessor may allow for simultaneous use
of wireless protocols and SPI transmission for LEDs: this would likely allow for the desired wireless system
as discussed (dependent on transmission speeds: a buffer would likely be required, which would require
sufficient on-board memory to operate).
7.2. Conclusion
Overall, the project was an overwhelming success. As shown in the Evaluation, every aim of the project
specification was met at least partially, with the vast majority being met fully. The finished product is
certainly eye-catching, making it potentially useful for the entertainment and/or advertising industries as
speculated at the beginning of the project. The cost of production was fairly high (estimated at around
GBP50), but this is often the case when working on a single prototype: in practice if making many copies of
the product the cost would be reduced. The project involved the learning of many new skills and
technologies (designing PCBs; mechanical construction; programming microprocessors using C and the
Arduino IDE), all of which are valuable skills to possess.

REFERENCES
(1) "The Propeller Clock." YouTube. 14 Oct. 2012 <https://www.youtube.com/watch?v=CYVK8Jmjy0E>.
(2) "LED Oscillating Clock." YouTube. 14 Oct. 2012 <https://www.youtube.com/watch?v=ZKCFyEtJh3Q>.
(3) "POV Display - Electronics Club." 15 Oct. 2012

<http://www.eee.manchester.ac.uk/undergraduate/electronicsclub/POV/>.
(4) "Awesome POV (Persistence of Vision) COLOR Display!" YouTube. 9 Oct. 2012
<https://www.youtube.com/watch?v=QAGnpKz7zvY>.
(5) "POV Globe using Arduino (ATmega328P) and 72 SMD LEDs." 18 Oct. 2012
<http://code.google.com/p/povglobe/>.
(6) "Rotating LED Display." 14 Oct. 2012 <http://akikorhonen.org/projects/rotating-led-display/>.
(7) "RGB LED Globe - POV - 40 x 200." YouTube. 14 Oct. 2012

<https://www.youtube.com/watch?v=cQhBm_EgB0w>.
(8) "Full-Color Video on a Spinning POV Display." 2 Nov. 2012

<http://hackaday.com/2012/09/11/full-color-video-on-a-spinning-pov-display/>.
(9) "Brushless Motor 1000kV from Cool Components." 25 Feb. 2013

<http://www.coolcomponents.co.uk/catalog/brushless-motor-1000kv-p-669.html>.
(10) "FAQs | Raspberry Pi." 30 Nov. 2012 <http://www.raspberrypi.org/faqs>.
(11) "Arduino Uno R3." 30 Nov. 2012 <http://www.pololu.com/catalog/product/2191/specs>.
(12) “Cree® PLCC4 3 in 1 SMD LED.” 12 Jan. 2013 <http://www.farnell.com/datasheets/1489780.pdf>.
(13) “PCB Trace Width Calculator.” 12 Jan. 2013 <http://circuitcalculator.com/wordpress/?p=25/>.
(14) “ANSI PCB Track Width Calculator.” 12 Jan. 2013

<http://www.desmith.net/NMdS/Electronics/TraceWidth.html>.
(15) "Parts: 0.1uF Decoupling Capacitors." 12 Mar. 2013

<http://hackaday.com/2008/09/29/parts-01uf-decoupling-capacitors/>.
(16) “ATmega328P Datasheet.” 30 Nov. 2012 <http://www.atmel.com/Images/doc8161.pdf>.
(17) "Arduino Uno." 12 Nov. 2012 <http://arduino.cc/en/Main/arduinoBoardUno>.
(18) "Arduino - PROGMEM." 9 Dec. 2012 <http://www.arduino.cc/en/Reference/PROGMEM>.
(19) "Program Space Utilities." 9 Dec. 2012

<http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html>.

APPENDIX A: EXISTING PERSISTENCE OF VISION DISPLAYS
Photograph Description / Comments Reference
Two-dimensional oscillating display. Single colour LEDs. [1]
Single-colour LEDs (either red or blue, but not both from the [2]
same LED). Two-dimensional circular perceived display.
Single-colour LEDs. Large two-dimensional circular perceived [3]

display using bicycle wheel.
RGB LEDs (but no pulse-width modulation, so 8 possible [4]

colours). 2D circular display, much higher pixel resolution than
the previous examples.
Three-dimensional display (curved array of LEDs producing [5]

sphere when rotated). Single colour. Uses headphone jack and
socket to transfer power into rotating body.

Photograph Description / Comments Reference
Three-dimensional, cylindrical display (vertical line of RGB LEDs). [6]
Three-dimensional spherical display, again with 8 possible [7]

colours.
Two-dimensional display, but with pulse-width modulation of [8]

LEDs for full-colour display. Runs Linux on a Gumstix board
allowing for full video to be decoded and displayed on-the-fly.

8051 Microcontroller Propeller Clock

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

8051 Microcontroller Propeller Clock

Caricato da

Copyright:

Formati disponibili

3D DISPLAY WAND:

PERSISTENCE OF VISION DISPLAY

BEng (HONS) COMPUTER SYSTEMS ENGINEERING

THIRD YEAR PROJECT REPORT

images on the LED display.

more balanced, stable structure) are also discussed.

averting a minor electronic disaster.

SHAI SCHECHTER 3D DISPLAY WAND

SHAI SCHECHTER 3D DISPLAY WAND

1.1. Persistence of Vision

person unable to distinguish between different images viewed in quick succession.

1.2. Background Review and Design Considerations

SHAI SCHECHTER PAGE 1 OF 41 3D DISPLAY WAND

Resolution and Colours

output is modified by software within one twenty-fifth of a second.

SHAI SCHECHTER PAGE 2 OF 41 3D DISPLAY WAND

contact with someone or something in the vicinity. To avoid this:

handling soldering irons, drills, and other potentially hazardous equipment.

SHAI SCHECHTER PAGE 3 OF 41 3D DISPLAY WAND

fluctuations in the RPM do not ruin the perceived effect.

SHAI SCHECHTER PAGE 4 OF 41 3D DISPLAY WAND

SHAI SCHECHTER PAGE 5 OF 41 3D DISPLAY WAND

3.1. Mechanical / Structural Design

within the Perspex can be used for this purpose.

Initial design sketches were drawn:

Figure 5: Initial sketch of mechanical structure

SHAI SCHECHTER PAGE 6 OF 41 3D DISPLAY WAND

approximate dimensions and other details:

SHAI SCHECHTER PAGE 7 OF 41 3D DISPLAY WAND

SHAI SCHECHTER PAGE 8 OF 41 3D DISPLAY WAND

was heavier, the rotating body was eventually approximately balanced.

SHAI SCHECHTER PAGE 9 OF 41 3D DISPLAY WAND

electronic aspects of the system in more detail.

3.2. Motor and Electronic Speed Controller

laboratory power supplies if required.

SHAI SCHECHTER PAGE 10 OF 41 3D DISPLAY WAND

insignificant amount of image flicker.

3.3. Transferring Power into Rotating Body

at all times between a fixed and a moving portion.

SHAI SCHECHTER PAGE 11 OF 41 3D DISPLAY WAND

3.4. Display Microprocessor

should be kept to a minimum for rotation.

SHAI SCHECHTER PAGE 12 OF 41 3D DISPLAY WAND

3.5. LEDs and LED Drivers

of pulse-width modulation (PWM) is required on these lines.

SHAI SCHECHTER PAGE 13 OF 41 3D DISPLAY WAND

in a huge amount of repeated hardware.

Dedicated LED Driver ICs

TLC5940 Arduino Library

SHAI SCHECHTER PAGE 14 OF 41 3D DISPLAY WAND

3.6. Display Circuitry

manufacturing within the School.

Channel Selection (Demultiplexing)

receive the data being clocked in from the microprocessor.

SHAI SCHECHTER PAGE 15 OF 41 3D DISPLAY WAND

SHAI SCHECHTER PAGE 16 OF 41 3D DISPLAY WAND

routing from V+ to the LEDs and back to GROUND.

used for the display microprocessor and LEDs.

their corresponding drivers and other circuitry (Figure 13).

3 Maximum current would be when all 64 LEDs are white in colour.

SHAI SCHECHTER PAGE 17 OF 41 3D DISPLAY WAND

Figure 13: Circuit design of each 16-LED subsystem

SHAI SCHECHTER PAGE 18 OF 41 3D DISPLAY WAND