Lightive - Eviroment Aware Lighting System - Project Report Louis Christodoulou

Although many of the currently available mood lighting products are distinctive when
compared to standard lighting fixtures, there effects can quickly become uninteresting and
repetitive. With no commercially available mood lighting system offering anything but preset animations or static colour the idea and motivation for this project was born. The project
entails the design and build of a mood lighting system which can react and reflect its
environment
offering
automated
operation
yet
maintaining
interest
through
unpredictability. This report is a review of the project to date, outlining the system design,
work covered and development. Also provided is an insight into possible system
improvements noted during the course of the project.
Faculty of Engineering & Physical

Sciences
Department of
Electronic Engineering
I confirm that the submitted coursework is my own work and that all material
attributed to others (whether published or unpublished) has been clearly
identified and fully acknowledged and referred to original sources. I agree that
the University has the right to submit my work to the plagiarism detection service
TurnitinUK for originality checks.
Student Name: Louis Christodoulou
URN: xxxxxxx
Module Code & Title: Level 3 Project
Assignment/Lab Title:
Final Report
Person Responsible for Marking: Dr K Wells
Signature: xxxxxxxxx
Date: 15/05/2011
CONTENTS
1
Project Introduction ....................................................................................................................................... 1

1.1
Aim ........................................................................................................................................................ 1
1.2
The Idea A Personal Note ................................................................................................................... 1
1.3
Documentation ..................................................................................................................................... 1
1.4
Project Gantt Chart ............................................................................................................................... 2
1.5
What is Mood LIGHTING? ..................................................................................................................... 3
1.6
Notable Current Products ..................................................................................................................... 3
Project Design Phase ...................................................................................................................................... 5

2.1
The Lightive System Overview ......................................................................................................... 5
2.1.1
System Design and Functionality ...................................................................................................... 5
2.1.2
Ambient Awareness .......................................................................................................................... 5
2.1.3
Modular Platform ............................................................................................................................. 5
2.1.4
The Arduino Microcontroller platform ............................................................................................. 6
2.1.5
Wireless Communication .................................................................................................................. 6
2.2
Establishing Lightives Wireless Communications System .................................................................. 7
2.2.1
Initial Research ................................................................................................................................. 7
2.2.2
Testing the TRX433S Wireless Modules ............................................................................................ 8
2.2.3
Improving the Acknowledgement mechanism ............................................................................... 10
2.3
The Lightive Driver Design................................................................................................................. 12
2.3.1
Initial Design ................................................................................................................................... 12
2.3.2
SOFTWARE Design .......................................................................................................................... 13
2.3.3
Expanding PWM Using the TLC5940 ............................................................................................... 14
2.3.4
Using MOSFETs ............................................................................................................................... 14
2.3.5
Breadboard Prototype .................................................................................................................... 17
2.3.6
Design Development ....................................................................................................................... 17
2.3.7
Final Designs ................................................................................................................................... 18
2.4
The Lightive Sensor Design ............................................................................................................... 23
2.4.1
Initial Design ................................................................................................................................... 23
2.4.2
Research ......................................................................................................................................... 24
2.4.3
2.4.4
Software Design .............................................................................................................................. 25
2.4.5
Final Design ..................................................................................................................................... 26
2.5
2.5.1
Initial Design ................................................................................................................................... 27
2.5.2
2.5.3
Data Storage ................................................................................................................................... 28
2.5.4
Software.......................................................................................................................................... 28
2.5.5
Breadboard Prototype .................................................................................................................... 29
2.5.6
Final Design ..................................................................................................................................... 30
Project Build Phase ....................................................................................................................................... 32

3.1
Software .............................................................................................................................................. 32
3.1.1
The Lightive SD Card library ............................................................................................................ 32
3.1.2
The Lightive Radio Library ............................................................................................................... 33
3.1.3
Direct Output Functionality ............................................................................................................ 34
3.2
The Lightive Master Design ............................................................................................................... 27
Hardware............................................................................................................................................. 35
3.2.1
Manufacturing the PCBs ................................................................................................................. 35
3.2.2
Soldering Techniques ...................................................................................................................... 36
3.2.3
The Driver ....................................................................................................................................... 38
3.2.4
Led Strips ........................................................................................................................................ 39
3.2.5
The Sensor ...................................................................................................................................... 41
3.2.6
The Master ...................................................................................................................................... 42
The System in Practice / Implementation .................................................................................................... 44

4.1
Key functionality and User Interface ................................................................................................... 44
4.2
Direct Out Functionality Ambilight ................................................................................................... 44
4.3
Soak Testing ........................................................................................................................................ 45
Costs ............................................................................................................................................................. 46
Conclusions ................................................................................................................................................... 47
Bibliography .......................................................................................................................................................... 49
Appendix ............................................................................................................................................................... 51
1 PROJECT INTRODUCTION
1.1 AIM
The project being undertaken is the design and creation of a reactive lighting system whose output is
influenced by elements of its surrounding environment. The systems light output will be on par with what is
considered mood lighting. This will also, by the nature of the specification, make this an interactive system.
The completed system should create a distinct ambient feel in a room through the use of lighting. This is a
method not unknown to interior design. The area in which this system differs from others is the ability to read
its environment via sensors and produce a coordinated output as a result. Certain configurations should
incentivize users to interact with the system, other configurations will allow the system to disappear into the
background and have a more subconscious effect on mood. The system must also offer a standard protocol
rd
whereby 3 party applications can interface with the system via a computer.
1.2 THE IDEA A PERSONAL NOTE

The idea behind the project came through a desire to better understand physical computing and previous
attempts at simple lighting systems as a hobbyist. I have, for a long while wanted to own such a system and
there are no reasonably priced yet capable mood lighting systems available to date. Interior design, especially
with regard to lighting is something I have always paid attention to. I have wanted to enhance lighting in my
own living spaces, allowing it to offer more to its observers. Out of the ordinary lighting installations are often
costly because they have to be designed for purpose, the hope here is to create a flexible system to combat
this. I feel as if my avid interest in photography also allows real appreciation of how the quantity, quality and
colour of light can change the mood of a scene. The reason for wanting to build this project from the ground
up as opposed to combining existing technology is to fulfil a long sought after understanding of
microcontrollers and microcontroller programming. It is hoped once the project is complete this
understanding will have been gained along with a domestically useable reactive lighting system.
1.3 DOCUMENTATION
As the project has a heavy focus on coding it was felt that a hand written log book would not be a logical
solution. In the same light a folder full of files was also not sensible as it has limited points of access. An
internet based solution was decided upon; wordpress a highly flexible blog based content management
system. The blog is easily accessible from any internet enabled device to allow for additions to be made
anywhere. The URL is http://louisc.co.uk/FYP/, and the domain and hosting is owned by myself. There are
many advantages offered over a paper based logbook. Dates and times of posts are automatically added for
reference as well as indexing whole posts allowing for searches on any keyword. Multimedia such as pictures
and video can be added. Code can be pasted and commented easily and neatly.
Page | 1
URN: 6025977
1.4 PROJECT GANTT CHART

Oct 2010
ID
Task Name
Start
Finish
Nov 2010
Dec 2010
24/10 31/10 7/11 14/11 21/11 28/11 5/12 12/12 19/12 26/12
1
2
3
4
5
System Design & Relevant research

Decide on a microcontroller platform and
become comfortable with basics
Decide on a wireless communications
platform
Establish wireless communications link
between two microcontrollers
21/10/2010
31/10/2010
1w 4d
08/11/2010
14/11/2010
1w
08/11/2010
14/11/2010
1w
15/11/2010
21/11/2010
1w
22/11/2010
01/01/2011
5w 6d
Design and build a prototype driver

unit
22/11/2010
05/12/2010
2w
Coding for driver unit
04/12/2010
01/01/2011
4w 1d
Design PCB for driver unit
05/12/2010
18/12/2010
2w
Etch and populate Driver board PCB
Driver Unit
18/12/2010
26/12/2010
1w 2d
10
Exam Period and Mid Project report write

up (Likely Slowed work Rate)
27/12/2010
31/01/2011
5w 1d
11
Master Unit
02/02/2011
19/04/2011
11w
12
Design and build prototype for

master unit
02/02/2011
15/02/2011
2w
13
Coding for Master Unit
15/02/2011
17/04/2011
8w 6d
14
Design, make and populate PCBs for

Master Unit
06/04/2011
19/04/2011
2w
20/02/2011
15/04/2011
7w 6d
20/02/2011
05/03/2011
2w
28/02/2011
13/03/2011
2w
13/03/2011
26/03/2011
2w
26/03/2011
15/04/2011
3w
15
16
17
18
19
Sensor Units
Design, build and code prototype
movement sensor
Design, build and code prototype
Temperature Sensor
Design, build and code manual
remote controller for the system
Design, make and populate PCBs for
Sensors and Remote Controller.
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Duration
20
Minor Tweaks / Issue resolution
11/04/2011
19/04/2011
1w 2d
21
Testing of system / getting 3rd party

opinions
16/04/2011
22/04/2011
1w
22
Final Report write up
05/04/2011
16/05/2011
6w
2/1
9/1
16/1
23/1
30/1
6/2
13/2
20/2
27/2
6/3
13/3
20/3
27/3
3/4
10/4
17/4
24/4
1/5
Page | 2
URN: 6025977
8/5
1.5 WHAT IS MOOD LIGHTING?

Lighting is a key design consideration in architecture and interior design. It can often dictate how many of the
other physical design features are perceived. Mood lighting is the term given to the technique of using lighting
to manipulate or influence the feeling of a space whilst also adding to the immediately visible aesthetics. These
lights are usually distinguishable from the general lighting of a room.
An example of the use of mood lighting we have all likely experienced is in a restaurant. Often ceiling lights are
dimmed and candles or smaller light sources are placed on tables. Another example can be observed in
practically any film; the primary aim of lighting any scene it to subliminally convey the feeling or atmosphere of
the scene to the observer.
When implementing mood lighting, direction, brightness and colour are all qualities of light usually varied to
create the desired feeling and atmosphere. The first quality, direction, has the biggest influence on the
perception of objects. A bare, bright ceiling lamp will create harsh shadows in every direction away from it.
This is often not very aesthetically pleasing. A bright ceiling light through a lampshade will create a soft diffuse
light in a room. Because most objects will receive light evenly reflected off walls shadows are largely
eliminated meaning things look more 2 Dimensional. The size of the light source will often dictate how soft or
harsh shadows are. Bigger light sources can be created by bouncing light off walls or ceilings. Often a nice,
potentially moody combination is directional yet dim and diffuse light.
Brightness is a more obvious quality which is widely used to influence the feeling of a space. Brighter rooms
tend to bring about an alert and awake feeling whereas dimly lit rooms, a more relaxed ambient feeling. The
use of dimmers on general light fittings as well as lamps and candles are common ways of taking down the
brightness of the ambient light to set a mood.
Colour, the third quality, is often used in two different ways to influence mood. The very commonly used but
often unnoticed method uses slight shifts in what is perceived as white light between either yellow and orange
colours or blue. This colour shifted white light is often described in colour temperature. Warmer colours
produced by Incandescent and halogen lights are often used in restaurants as they tend to enrich the colour of
the food, hotel lobbies to create an inviting and relaxing space and in living areas in homes. These warmer
colours have lower colour temperature values. Lights on film sets are often gelled blue or purple to simulate
night time. More saturated colours are also generally considered to influence mood. Interior designers often
choose colours to include in a space to set an appropriate feel and atmosphere for its use.
1.6 NOTABLE CURRENT PRODUCTS

Light modifiers designed to change the aforementioned qualities of lighting have been available for almost as
long as light has been used in indoor environments. Bar a few exceptions, only recently has there been a more
pronounced commercial availability of purpose designed mood lighting products. Prior to these products
becoming available, dedicated mood lighting, even that with simple features such as colour customizability
would come in the form of bespoke systems. These systems usually required professional and hence costly
installation. Professional stage lighting equipment was always another option but it mostly uses the Digital
Multiplexing (DMX) standard and this often comes at a high price and in rugged and unsightly form.
During research it was found that even the most recent products are usually limited to automatic colour
scrolling or pre-set animations. The only observable reactive element used in mood lighting systems was sound
to light functionality where lights would react to music.
Page | 3
URN: 6025977
The widely available Phillips mood lamp is a good example of a recent consumer mood lighting product. Figure
1-1 shows the first generation of Phillips mood lamp which provides a wire free remote for setting colour.
Automated colour cycling is enabled only in an included demo mode. The lamp will also remember the colours
last set and allow definitions for a favourite. Their second generation lamp allows for basic automated colour
scrolling but each lamp is independent so if syncing is required they must all be in range of the remote at the
same time. The first generation uses four LEDs, two Red a green and a blue. The newer lamp uses seven LEDs.
[1]
FIGURE 1-1 - PHILLIPS MOOD LAMP (1ST GEN)

PHOTO: WWW.AMAZON.CO.UK
The only product found during research to be closest in design to that being suggested was a solution by
ChromoFlex. Given the difficulty in track this product down it is nowhere near as widely available as the
Phillips mood lamp. The product requires some knowledge in electronics to set up, in contrast to the Phillips
mood lamp which works out of the box. With no wires needing to be run through walls or floors the wireless
abilities of the system seem to be the biggest factor in setting it apart from requiring professional installation.
Figures 2-2 2-4 show the complete wireless ChromoFlex range. The System can be driven either by a remote
control (FIGURE 1-3) or by software via a USB dongle (FIGURE 1-4). The software is simple and allows for setting
colours or animations. The system requires constant input from the computer in order to run animations.
FIGURE 1-2 - CHROMOFLEX (III) RC

PHOTO:
http://www.xeroflex.com/html/chromoflex_r
c.html
FIGURE 1-3 - REMOTE CONTROL

PHOTO:
http://www.xeroflex.com/html/chromoflex_rc.html
FIGURE 1-4 USB DONGLE

PHOTO:
http://www.xeroflex.com/html/chromoflex_r
c.html
Although many of these more reasonably priced domestic solutions shared some features with the system
proposed, there were none found which offered it in its entirety.
Page | 4
URN: 6025977
2 PROJECT DESIGN PHASE

2.1 THE LIGHTIVE SYSTEM OVERVIEW
2.1.1 SYSTEM DESIGN AND FUNCTIONALITY
It was decided the system needed a name, after some brain storming Lightive was decided upon. It is a play
on the words reactive and lighting. The Lightive system will collect information from an array of wireless
sensor units placed around a given space. The system will then react to these inputs using predefined settings
by the user. This reaction is displayed visually via the systems wireless LED driver units. The centrepiece,
running the show, will be the master unit. This will provide a central point for system setup and management.
All driver and sensor units will require an initial registration with the master and declaration of their presence
thereafter. Figure 2-1 shows an overview of a typical system setup. This example setup has 4 sensor units and
a single driver unit. These three individual units and their functionality will be further explained in the
following sections.
FIGURE 2-1 - LIGHTIVE SYSTEM, TYPICAL SETUP SHOWING MULTIPLE DRIVER AND SENSOR
UNITS COMMUNICATING WITH A SINGLE MASTER
2.1.2 AMBIENT AWARENESS

The primary concept setting the proposed system apart from others is its ability to reflect selected aspects of
its environment with minimal user input. The idea is to move away from the pre-set animations and colours
offered by currently available solutions. The system should bring subtle elements of surprise and
unpredictability to users even with its pre-set reactions to environmental changes.
2.1.3 MODULAR PLATFORM

An important design consideration is the modularity of the system. If it is to remain scalable to a multitude of
environments there must be enough flexibility in the system to add or remove light bars and sensors as
required with no adverse effects or heavy duty setup required. In order to implement a modular system,
protocols must be designed and adhered to throughout. Suggested protocols must offer support for sensors
currently planned but also be viable for use with future additions. The general ethos is to design and develop a
platform which can be built upon with relative ease.
Page | 5
URN: 6025977
2.1.4 THE ARDUINO MICROCONTROLLER PLATFORM

The Arduino was chosen after research into many of the leading microcontroller platforms and their respective
offerings. The platform is completely open source and the ethic of its growing online community is based
around sharing solutions and libraries to interface it with hardware. This means there is a vast collection of
libraries and support materials freely available. This project is almost completely reliant on a microcontroller
and associated programming. With no prior experience in any microcontroller platform it was important to
select one which would allow for the completion of the project within the allocated time and with the desired
level of functionality.
FIGURE 2-2 - ADRUINO DUEMILANOVE WITH ATMEGA 328P MICROCONTROLLER (IMAGE: WWW.ARDUINO.CC)
The Arduino platform is based on the Atmel AVR processor. To simplify the process of programming and using
the microcontroller, it is installed on a board which presents and clearly marks each input and output pin.
Figure 2-2 shows the Arduino Duemilanove with an ATMEGA328P microcontroller installed. These chips are
capable of self-programming. The Arduino team have developed a clever boot-loader which sits on the chip
and allows it to be programmed via its hardware serial connection. Most demo boards offer a USB to serial
interface meaning they can be programmed using a single USB connection. This is done via Arduinos own
integrated development environment (IDE) with the language based on C++. Included libraries make common
input operations easier. This removes the need for expensive chip programmers and software [2]. With the
hardware design being open source, schematics are easily available and can be modified and integrated into a
custom PCB for the project.
The Arduino environment and boot-loader are only compatible with a limited number of Atmel Chip models.
This limits the processors which can be used in the project. Fortunately the processors selected are very
capable and if purchased without the boot-loader preinstalled, competitive in price. The decision was made to
use the Atmel ATMEGA328P as it offers the greatest power versus price ratio of the Arduino enabled line.
2.1.5 WIRELESS COMMUNICATION

Despite the added complexity of basing the system on wireless communications, doing so will allow quick and
easy system setup. It also makes possible configurations which were previously unavailable due to cabling
restraints. Wireless abilities can also offer much more flexibility on devices which can interact with the system.
Handheld control devices can be wireless giving freedom to control the system from anywhere within the
room. Sensors could be placed outdoors allowing the system to react to external elements such as outdoor
light colour or temperature.
One factor to be considered when adding wireless communication is cost. Ideally a wireless solution will add a
minimal component count and not be disproportionate to the cost of the device itself.
Page | 6
URN: 6025977
2.2 ESTABLISHING LIGHTIVES WIRELESS COMMUNICATIONS SYSTEM

The wireless communications are at the base of the whole system. For this reason the protocol must be
described before the individual units which lay on top can be.
2.2.1 INITIAL RESEARCH

P ICKING THE RADIO HARDWARE AND STANDARD
Initially a variety of wireless options were explored. The first were the popular Bluetooth and well established
ZIGBEE protocols and hardware. Both standards, due to their popularity, have an abundance of support on
any of the microcontroller platforms. Bluetooth was quickly dismissed due to its limited range. The ZIGBEE
units offered lots of relatively easy to use features and also a proven and tested platform. With cost being a
considering factor, despite easy access to functionality the ZIGBEE modules were still not enough of a clean
and obvious choice to stop further research.
Whilst searching through UK electronic component suppliers radio modules the Alpha RF Transceiver from
RS stood out. It offered a far superior specification than anything else in its price range. At 3.90 per module
compared to a ZIGBEE compatible 21.46 per module this was a very affordable and capable unit. This cost
saving did come at a price; the support for the Alpha unit seemed limited. After purchasing and receiving the
module subsequent research discovered that the Alpha module is in fact a rebranded RFM12B module. Further
research uncovered an Arduino library by JeeLabs [3] supporting the RFM12B. After successfully testing the
library, work on creating an interface for the module from scratch was abandoned and the library was instead
adopted.
These modules have a small, square footprint of only 16mm. The package is classed as surface mount; this is
reflected in the 2mm pitch between the pins. The datasheet states the modules are capable of up to 115Kbps
at a maximum of 300m [4]. The 2.2-5.4 volt operating range also means there is no need to create a second
power rail at 3.3 volt like many other transceivers. All functionality of the modules can be accessed via the SPI
interface. All parameters are set to their defaults after power up; the only way to retain the settings is to put
the unit into a sleep state. For this reason, on power loss of any unit using the transceiver, the initialization
routine will have to reconfigure the wireless module with the required settings.
T HE J EE L ABS RF12 L IBRARY

The RF12 library implements an interrupt driven driver for the RFM12B module made by HopeRF [5]. Key
features include packet verification with 16-bit CRC, node ID capabilities built into library as well as code to
store and load node ID from EEPROM.
Software at JeeLabs has been released under the MIT Licence which grants permission to free of charge,
copy, modify, merge, publish, distribute, sublicense and/or sell copies of the software. The only real clause is
that the copyright notice and permissions notice shall be included in all copies or substantial portions of the
software. This has been quoted for absolute clarity from the Open Source Initiative [6].
The JeeLabs RF12 library builds a packet based on the data you give a command named rf12_sendStart(). The
structure of the built packet is show in Figure 2-3. The first Byte is the header. This contains the destination
address as well as other flags for dealing with acknowledgement requests. The next byte, Length, defines the
length of the payload which follows in bytes. This payload can be up to 66 bytes in length per packet. This is
finished off with a cyclic redundancy check (CRC) which covers the whole packet.
Page | 7
URN: 6025977
FIGURE 2-3 - PACKET STRUCTURE
2.2.2 TESTING THE TRX433S WIRELESS MODULES

On successful completion of this test it was felt the next step should be a test of range. This would quickly
identify any major issues early on. In order to carry out this wireless range test one unit had to be powered via
its DC input jack as it would not be within proximity of a computer for USB power.
P ROTOTYPING WITH THE A LPHA RF T RANSCEIVERS

The first requirement was the ability to prototype with the TRX433S modules. Their restrictive 2mm pitch
meant no way of mounting them to a breadboard. An intermediary adaptor board was required which would
present the modules pins at a standard pitch. Using strip board and some male SIL headers an adaptor was
built and the module soldered on. This adapter is shown in Figure 2-4. A total of two adaptor boards were
made. Using the default connections found in the library they were each connected to an Arduino which was
programmed with the Demo Application included in the library. The demo application included a test option
which sent a full sized packet and requested an acknowledgement. The test packets were transmitted and
received between both units along with the acknowledgements.
FIGURE 2-4 - TRX433S SOLDERED TO ADAPTOR BOARD
P ROBLEM - F AULTY A RDUINO BOARD

The jack on the Arduino Duemilanove demo board being used has limits from 6 20 Volts. A 12 volt bench
power supply was used to power the board up. When no reply was received from the board despite repeated
attempts at various distances, a closer inspection was made. All communications with the board failed via both
USB and wireless. The Arduino demo board was found to be faulty. The voltage regulator circuitry was
applying the full 12 volt supply voltage to the 5 volt rail. This had caused extensive damage to the wireless
module and the ATMEL microprocessor. In turn this caused a setback as a second microcontroller had to be
ordered and another wireless module soldered to an adaptor. Although no mistake was made, now voltages
are checked on all circuits prior to plugging in any sensitive components. Once the repairs were made an
experiment on range could be carried out.
Page | 8
URN: 6025977
T HE R ANGE E XPERIMENT
The aim of the experiment was to set up two wireless modules and, using the Demo application provided with
the library, test reliability and robustness of the signal at range. A secondary aim is to gain an understanding
into how the library is driving the modules to aid in decisions on how to implement them.
The specification states the modules are capable of transmission over a maximum distance of 300m, this is
assumed to be in ideal conditions with no obstacles and minimal interference [4]. The testing conditions for
the experiment were far from this. The testing will be carried out in University of Surrey undergraduate
laboratories. These are densely filled with electronic equipment and cables. Performance in these conditions
will define the lower boundary of what to expect from these modules. Some calculations were performed to
work out the optimum antenna length for the transceivers. Each antenna was made from a single strand, 22
gauge wire at a length of 165mm, 6mm shorter than a quarter of the signal wavelength.
The experiment setup used the default pin connections between the Arduino and the wireless module (Listed
in APPENDIX FIG 1 ). Two identical Arduino units with wireless modules were setup. One unit was left at a
workstation powered by a bench power supply. The other was USB powered via a laptop for mobility. This unit
was sending the test packets and waiting for an acknowledgement of their receipt. For a diagram of the setup
please see Figure 2-5.
The methodology used was simple. The mobile unit was moved away at set lengths from the fixed units. Each
time the mobile unit was moved, 10 full sized (66 byte) packets were sent, one every second and each with an
acknowledgement request. As the unit is set up in a corner of the room the signal will be checked at distances
in two directions.
FIGURE 2-5 - DIAGRAM OF RANGE TEST EXPRIMENT SETUP
The results were impressive and exceeded personal expectations for the testing environment. The link showed
no real signal loss till over 25 meters away in the worst case. At this point the signal was travelling through an
office and across a second lab filled with computers. In both directions the only observable deterioration was
only once several walls had been passed. The results can be seen on a graph in Figure 2-6, this has been
plotted from the table of results which can be found in APPENDIX FIG 2. There was a case where a single
packet was dropped at 6 meters in direction 1. This was likely caused by interference. Direction 1 allowed
further distance to be travelled without going through any walls.
Page | 9
URN: 6025977
Link Reliability over Distance

10
Packet Errors (10 transmitted)
Direction 1
Direction 2
7
6
5
4
3
2
1
0
0
10
15
20
25
Approximate Distance (Meters)
30
35
40
FIGURE 2-6 - PLOTTED RESULTS - LINK RELIABILITY OVER DISTANCE
C ONCLUSIONS
These wireless modules have performed above and beyond the specification required. The library found, once
implemented abstracts much of interface complexity during use. This allows more concentration on coding
functionality for the system as opposed to low level interaction with hardware. Although this abstraction is
helpful, for complete comfort in using the library some time was spent understanding how its functions have
been implemented.
A potential issue could arise if a repeat example of a dropped packet due to interference should be
encountered. This could result in an LED bar remaining the wrong colour. It is therefore important to
implement some kind of automatic repeat request (ARQ) system to handle dropped packets due to
interference spikes.
All in all no reason could be found not to continue with this as a solution to wireless communication.
2.2.3 IMPROVING THE ACKNOWLEDGEMENT MECHANISM

The existing acknowledgement (ack) system has been designed to be extremely power efficient and as a result
is a little limited. The reasoning behind this is many of the JeeLabs devices are battery or even solar powered,
with a high traffic connection even one byte less data to transmit per packet can become beneficial. All of the
ack processing in the current mechanism is done using the header byte; this is shown in Figure 2-7. There are 3
settable flags in the header:
CTL - control flag which, when set, is used to denote packet is an ack response
DST If set denotes the Node ID field contains the packets desired destination node. If clear
denotes the packet is a broadcast and Node ID contains the ID of the broadcasting node.
ACK set if an ack reply is required
Page | 10
URN: 6025977
The functionality of these flags will become clearer in the following examples.
FIGURE 2-7 - INSIDE THE HEADER BYTE
The table in Figure 2-8 shows how these flags and the Node ID field are used in any given scenario.
FIGURE 2-8 - HEADER CONFIGURATION FOR DIFFERENT SCENARIOS
To demonstrate the libraries ack mechanism a packet requiring an ack will be transmitted and the sequence of
radio events which follow documented. Figure 2-9 displays the headers exchanged between two nodes. First, a
packet containing some information is sent from node 1 to node 2 and requires an ack. The header will have
the ACK flag set, denoting an ack response is required. The DST flag will also be set along with the value in the
node ID field being set to the address of the receiving node, in this case, node 2.
Once Node 2 receives this packet the ACK flag in the header is examined. If the flag is set an ack packet with
the appropriate header is created. This header will differ slightly depending on the kind of initial transmission
being responded to. In our example Node 1 is transmitting directly to Node 2, in this case the header will have
nothing but the CTL flag set. Should Node 2 have been responding to a broadcast, the response would have
simply included its own Node ID.
FIGURE 2-9 JEELABS UNMODIFIED RADIO TRANSACTIONS FOLLOWING A SENT PACKET WITH ACK REQUEST
Page | 11
URN: 6025977
The first noticeable issue with the header byte is there is only space for a single node ID. If we are transmitting
to a particular node, this will have to be the ID of the destination. If an ack is requested, the receiving node
does not have a return address for the ack packet. This is combated by simply broadcasting the ack packet to
all. This could be problematic if multiple systems are run alongside each other.
R EDESIGNED L IGHTIVE A CKNOWLEDGEMENT SYSTEM

The ack mechanism was improved to ensure that the transmitter and receiver send their own addresses but
within the payload not the header. This way both ends know which nodes they are receiving communications
from. Initially the first byte of the payload was always going to be the Lightive command , this has now been
shifted along a byte to accommodate the devices own ID first. This is shown in Figure 2-10.
FIGURE 2-10 - PACKET PAYLOAD LAYOUT WITH IMPROVED ACK SUPPORT
The Lightive system was also given an ACK command which can be transmitted when replying to an ack
request. Although the original ack system can still be used all Lightive units will be checking for the ACK
command and not the header flag. This ACK commands is also no longer broadcast as in Figure 2-9 but
transmitted back to the requesting unit using the address provided in the received packet. The receiving unit
also verifies the ID on the incoming ACK command to ensure its from the unit it was requested.
2.3 THE LIGHTIVE DRIVER DESIGN

The driver will be at the output end of the system. Once registered to a master it must wirelessly accept
process then output basic fading commands to RGB LED bars.
2.3.1 INITIAL DESIGN

Each driver will consist of an Atmel ATMEGA328P Microcontroller chip, an FM transceiver, an LCD display, a
sixteen channel LED driver chip and an array of MOSFETs on the output stage. As each driver will require a
microcontroller and wireless module, in order to keep costs reasonable it was decided each LED driver should
be capable of driving multiple LED bars. A block diagram showing the interconnectivity of these components is
shown in Figure 2-11
The microcontroller has limited pulse width modulation (PWM) capable ports. The TLC5940 by Texas
Instruments was chosen to expand the PWM capable outputs of the Drivers microcontroller. This is better
explained below in Section 2.3.3 titled Expanding PWM Using the TLC5940.
With the driver boards key role being pulse width modulation of relatively high currents, some serious
consideration needs to be given to noise interference on the board. Through research it was discovered that to
effectively de-couple any noise on the power rails, de-coupling capacitors are best placed on every IC as close
as possible to its power inputs [7] . This will be designed into the schematic and PCB from the very start.
Page | 12
URN: 6025977
Alpha-TRX433S
433 Mhz Wireless
FM Transceiver
MOSFETs
r
Output
To LED
BAR 1
g
b
SPI
r
Atmel
ATMEGA328
Microprocessor
SPI
TLC5940
16-channel
PWM LED
Driver
.
.
.
r
g
LCD Display (HD44780)
Output
To LED
BAR 2
Output
To LED
BAR 5
FIGURE 2-11 - INITIAL DRIVER DESIGN BLOCK DIAGRAM
2.3.2 SOFTWARE DESIGN

The driver will be designed to accept and process basic fading commands for each bar. A flowchart for the
proposed behaviour of a driver is shown in Figure 2-12. Each command will be identified by a number and
consist of an ID of the bar to be faded, the end value for red green and blue and time duration to reach that
value. The driver will then calculate, based on the current value, what it needs to do to get to the requested
result within the requested time period. Once a fade command is successfully received it will not actually be
acted upon until a shift command is sent from the master. This will allow the master controller to pass
instructions to every bar on each driver successively then globally broadcast a shift command for synchronised
changing. A direct access mode will also be available whereby each channel on the TLC5940 LED driver can be
accessed with very basic commands and as little latency as possible. This low latency mode will allow time
1
sensitive sound to light or Ambilight style effects.
Display completed
command on LCD
Start
Initialization
Routine
Register with
Master
Check Radio for

packet
CRC Fail or nothing
received
Fix state and reenter radio loop
Received
Yes
Check CRC value
Command
Processing Finished
?
Pass (CRC = 0)
Display
Error on
LCD
No
No
Master Ack ?
Return Ack to
master
Pass Data to and

Perform Command
Display address and

successful registration on LCD
Place packet data into

recCmd array
Process packet and call

correct command
FIGURE 2-12 - LED DRIVER PROPOSED SOFTWARE DESIGN - SYSTEM FLOWCHART
Ambilight projects a glow of light from the back of a TV onto the wall, matching and enlarging the picture on
the screen for a truly immersive experience [25]
Page | 13
URN: 6025977
2.3.3 EXPANDING PWM USING THE TLC5940

The chosen microcontroller has only 6 hardware enabled PWM ports. Unfortunately 3 of these ports are lost
to the hardware SPI interface being used by the wireless module. With only 3 ports remaining only a single LED
bar can be driven, this is not a cost effective use of the hardware. A solution to this is to increase the PWM
ports using a dedicated IC. The TLC5940 by Texas Instruments is such an IC. With support for 16 channels it will
allow for control of 5 bars independently. This is a purpose built LED driver IC with an array of features, one of
the most prevalent being 12 bit (4096 Step) PWM control. This very high resolution permits very precise
control of each colour channels duty cycle, giving a more comprehensive range of colours on output. The chips
also support daisy chaining which allows for drivers to support even more outputs should the need arise. The
chip communicates via a serial interface loosely adhering to the SPI standard. The use of the TLC5940 will also
alleviate stress placed on the microcontroller whilst performing PWM duties.
The TLC5940 also has some neat built in features by design. One of these is the way it handles the PWM
signals. In many PWM controlled systems LEDs are triggered simultaneously on all channels as the data is
usually just shifted out in parallel. The TLC5940 uses delays to sequence its outputs; this is shown in Figure
2-13. Each of these delays is fixed at 20ns where OUT0 has no delay, OUT1 has 20ns, OUT2 40ns etc. There is a
maximum delay time from OUT0 to OUT15 of 300ns [8]. This delay helps to avoid large current pulses. This in
turn reduces noise down rails and helps keep current flow continuous.
FIGURE 2-13 TLC OUTPUT DELAY FEATURE
A little research on the Arduino website surfaced a library written for control of the TLC5940 via an Arduino. It
was written by Alex Leone and is available under the GNU General Public Licence [9]. This allows for
modifications of the software along with redistribution of the modified software [10]. The library offers control
over all of the core features of the chip which are likely to be used as well as supporting daisy chaining and
retrieval of currently set channel brightness. On receipt of a TLC5940 sample from Texas Instruments it was
connected using the default pins found in the Basic Use example. The unit worked perfectly with the library
and supports everything required for the application in hand.
With the IC chosen the next step was to decide how the LED bars will be driven. The specifications state that
an LED supply voltage up to 17 volts can be used, well within the 12 volts required for the strips. When the ICs
supply voltage is greater than 3.6 volts each channel can support a maximum of 60mA. Each channel on a
meter of RGB LED strip may require up to 200mA. It was clear to see that a driving method which will support
this higher current would need to be developed. A likely solution will use MOSFETs, this solution is explored
below in section 2.3.4 Using MOSFETs.
2.3.4 USING MOSFETS

Each driver will require the ability to drive up to 200mA per channel and therefore require something between
the PWM controller and the strip which is capable of this. The most logical solution for this is the use of
MOSFETs which allow for fast switching and low resistances whilst on.
PWM technology allows for very power efficient dimming control of LEDs. This is because no power is
dissipated through the dimming components. Instead the appearance of dimming is simply an exploitation of
the limitations of human vision. By operating at a frequency above that of persistence of vision, the high speed
switching being performed becomes invisible to the human eye, instead a dimming effect is observed.
Page | 14
URN: 6025977
There are some key properties of MOSFETs which must be properly configured to use them efficiently and
ensure they are only handling power they are rated for. A circuit diagram showing how the MOSFETS will be
connected is shown in Figure 2-14. It can be seen in this figure that the TLC5940 is a pull down device which
effectively discharges the gate of the MOSFET turning it off. The resistor R1 then acts to pull up the gate and
recharge it enabling the MOSFET to turn on. The gate can be thought of much like a capacitor. When the gate
is discharged and a positive potential is first applied it will begin to charge, drawing the most current when the
voltage is applied and tailing off as it becomes charged. This is identical to the discharge scenario except now
the gate will source the current. This means that it takes time to charge as well as discharge the gate. The
reason this is a concern is because whilst the gate is neither fully charged nor discharged the MOSFET will not
be fully on or off. This can result in a resistance and hence power dissipation across it which, if outside of its
absolute maximum ratings, could cause permanent damage to the device. We can deduce from this that the
amount of current allowed to flow into the gate at the time it is charged or discharged will determine how
quickly the MOSFET turns on or off. On the discharging side the TLC5940 has built in current limiting circuitry
which can be set using a resistor from ground to its Iref pin. This built in current limiting also means there is no
resistor required between the TLC5940s output and the gate of the MOSFET. The charging side will have its
current limited by the pull up resistor in place.
+12V
LED Strip
PULL UP RESTISTOR
The TLC5940 is a current sink
device only so this turns the
transistor back on at the end of
Simplified View, this would

be one of the red, green or
R1
blue channels.
a pulse.
TLC5940
OUT X
MOSFET
N-channel
TLC5940 OUTPUT
Any one of 15 driver output pins
from TLC chip
FIGURE 2-14 - CIRCUIT DIAGRAM OF MOSFET CONNECTION TO TLC5940
Although initially some MOSFETs (IRF610s) were supplied by the undergraduate labs for prototyping and
testing it quickly became clear they were incorrect for this application. After some research MOSFETs of model
number ZXMN2A01FTA by manufacturer DiodesZetex were decided upon. They offered a specification
exceeding the requirements for the project and were only 10 pence each. They were also surface mount which
meant a considerable space saving when 15 are required per driver. The datasheet explains these MOSFETs
Combine the benefits of low on-resistance with fast switching speed. This makes them ideal for high
efficiency, low voltage, power management applications [11]. To allow the ability to test and prototype they
were mounted to some proto board, this, along with a size comparison is shown in Figure 2-15.
Page | 15
URN: 6025977
FIGURE 2-15 - SMD (SURFACE MOUNTED DEVICE) MOSFETS,

LEFT - A UK 20 PENCE COIN BESIDE SMD MOSFET, RIGHT - 3 SMD MOSFETS READY FOR TESTING
Some calculations were performed to establish safe values for gate charge and discharge values. An
experiment was then performed picking components around the calculated values which showed the best
response in the experimentation. A 10K pull up resistor was decided upon as a safe pull up value. The CRO
traces in Figure 2-16 clearly show effects introduced by the gate capacitance of the MOSFET. The complete
charging time can be deduced from Figure 2-16 as 30 micro seconds although the transistor is fully on for the
required current draw of 200mA by the time the gate voltage has exceeded 1.5 Volt. This was determined
from the MOSFET data sheet, the graph used can be seen in APPENDIX FIG 3.
FIGURE 2-16 - CRO TRACES SHOWING OUTPUT OF TLC5940 WITH AND WITHOUT MOSFET LOADING DIFFERENCE SHOWN IS GATE CHARGING
Page | 16
URN: 6025977
2.3.5 BREADBOARD PROTOTYPE

In order to test the driver design theory before beginning the PCB design the system was prototyped on a
breadboard. The completed breadboard can be seen in Figure 2-17. For this prototype the ATMEL
microcontroller is mounted on a purpose built aftermarket breakout board which includes all the timing
components and relevant connections for base processor operation. All of the input and output lines are
presented on headers which push into the breadboard. Although only one of the five output channels have
been constructed with the MOSFETs everything else in the block diagram shown in Figure 2-11 has been
connected. This should be sufficient for testing.
FIGURE 2-17 - DRIVER BREADBOARD PROTOTYPE
2.3.6 DESIGN DEVELOPMENT

As the project progressed and designs were realised in the form of prototypes certain developments were
made to the driver design.
It seems there would be two distinct scenarios for driver use. One would be, hidden, out of sight and
controlled exclusively by wireless communication. The second would be as another piece of electronic
equipment, on display, much like a radio would be. These have been named the installation model and
countertop model respectively. The latter unit will require a user interface in the form of buttons and an LCD
display. The electronics industry often supports multiple models and versions of, essentially, the same device.
Often the hardware for a top of the range model is included in lower specification models but turned off in
software. The same approach should be adopted for the Lightive system. For this reason the base PCB designs
must accommodate both models.
During testing it was realised that there is more merit in having the MOSFETs on each LED bar instead of
within the driver. Firstly this will allow future LED bars of greater specification to be used with the driver
without any hardware modifications. The second benefit is the smaller level of interference created whilst
Page | 17
URN: 6025977
running the lower power signal through lengths of wire. Thirdly it could also permit the use of devices other
than LED strips on driver outputs making for interesting future expansion.
The decision was also made during design development to use surface mount technology (SMT) anywhere
possible to reduce both size and cost. This would bring challenges to soldering and PCB design and
manufacture but it was felt this could be achieved.
The decoupling added was as initially suggested with a small capacitor of 0.1uF for each IC and radio module
and a larger 100uF across the entire rail to absorb slightly larger fluctuations.
2.3.7 FINAL DESIGNS

Some final designs were realised before entering the build phase where they would likely see further
modification and improvement. The design for the more complex of the potential drivers was established first.
PCB D ESIGNS
Once the breadboard prototype was tested with the design developments and deemed to be working
correctly, work started on a PCB design. The software package used to complete these designs was
DesignSpark PCB which is offered completely free of charge by RS [12].
Many of the components required were not in DesignSpark PCBs libraries and had to be created. The process
of creating a component was wizard driven and the information required could be found in the devices data
sheet under the package specifications. Figure 2-18 shows, to the left, a screen grab of the wizard used to
create the components. Values are simply entered defining pin pitch, pad width and height among other
defining dimensions. The wizard also requests naming of the pins as well as mapping from the schematic to the
PCB symbol. On the right of Figure 2-18 is a photograph taken whilst checking the newly created component
for size with the actual device. This photo shows perfect alignment of the pins with, what will become the
solder pads on the PCB.
FIGURE 2-18 - LEFT - PARTS WIZARD CREATING TLC5940 COMPONENT RIGHT - TESTING AN SMD PACKAGED TLC5940 ON PRINTOUT OF CREATED PART
Once all the components required were added to the library the final driver schematic design was created, this
is shown in APPENDIX FIG 4 - Driver PCB Schematic. This schematic was then used to create the PCB layout.
The auto-route functionality of the PCB design software was unable to successfully route the design so it was
completed manually. As the designs were to be produced in house by the University of Surrey EE technical
Page | 18
URN: 6025977
services certain limitations were in place. This included the inability to add vias to the PCB. Larger holes and
pads were created for vias which will require manual soldering during the build phase. The final PCB design is
shown in Figure 2-19 along with annotations of key components and features. The entire board is 80x44mm,
this would have been considerable larger without the use of surface mount components and connectors as
both the ATMEGA Microcontroller and TLC5940 are in large 28pin P-DIP packages.
FIGURE 2-19 - FINAL LIGHTIVE DRIVER PCB DESIGN - KEY FEATURES AND COMPONENTS ANNOTATED
The design features a front panel header situated at the top of the board which will be compatible with a
Lightive Front Panel. This front panel will contain a 16x2 alphanumeric LCD display as well as 4 control
buttons. For the more advanced unit this front panel will be mounted allowing extra features to be accessed
from the driver unit itself. Also included is an Output Extension Header situated in the bottom right of the
board. The TLC5940 allows itself to be daisy chained whereby the serial out of one device can be connected
through to the serial in of the next. This header includes all the various enable and clock lines which need to be
extended across the chain. This once again allows for simple expansion of the driver unit with only a software
update and small driver board. Furthermore, this opens up possibilities of higher end and more advanced
models.
In order to allow LED strips to be connected and disconnected easily and without tools a second board would
be required which could be mounted on the enclosure providing externally accessible ports. This solution was
also implemented with HARWIN connectors which were offered free under their free connectors for
students promotion. This breakout board simply provides somewhere to mount the female side of the
connectors which have a nonstandard 2mm pitch. The PCB design is shown in Figure 2-20.
Via - A plated through hole (PTH) in a Printed Circuit Board that is used to provide electrical connection
between a trace on one layer of the Printed Circuit Board to a trace on another layer. Since it is not used to
mount component leads, it is generally a small hole and pad diameter. [28]
Page | 19
URN: 6025977
FIGURE 2-20 - LIGHTIVE LED BAR CONNECTOR BOARD WITH KEY COMPONENTS ANNOTATED
To allow for greater flexibility the earlier decision to move the MOSFETs to the strips themselves was kept and
custom PCBs which would solder directly to the end of the strips were designed. These included the 3
MOSFETs, pull up resistors and a small capacitor to reduce noise created down the power line. The PCB
schematic is shown in APPENDIX FIG 5. Figure 2-21 below shows the completed PCB design along with an
illustration of how the cable and LED strip will connect. Key design features and components have been
annotated. The PCB is slightly wider than the LED strip but still compact at only 16.5mm wide by 42.2mm long.
FIGURE 2-21 - LIGHTIVE LED BAR DRIVER PCB DESIGN WITH CABLE AND LED STRIP CONNECTION ILLUSTRATIONS
- KEY FEATURES AND COMPONENTS ANNOTATED
The final PCB required for the driver is a step down voltage regulator to take the 12 volt supply for the LED
strips down to the required 5v for the driver PCB. A switching regulator was decided upon over the more
Page | 20
URN: 6025977
standard three pin linear regulators. The LM2575T is such a regulator with an input voltage ranging from 8-40v
and current handling of up to 1A, far beyond the requirement of the Driver PCB. The biggest advantage of such
a regulator is the lack of requirement for a bulky heat sink due to its greater efficiency. Other features offered
are thermal shutdown and current limit protection which are handy safety nets to have included in the event
of a fault condition presenting it self. The regulator requires only 4 external components, an inductor, 2
capacitors and a schottky barrier rectifier [13]. The power supply PCB design is shown in Figure 2-22 and its
schematic can be observed in APPENDIX FIG 6. The schematic is based on the "typical application schematic
in the LM2575Ts datasheet [13].
FIGURE 2-22 - POWER REGULATOR PCB WITH ANNOTATIONS
E NCLOSURE D ESIGNS
After an initial brainstorm of design ideas and sketches on paper, a design for both the advanced countertop
model and more discreet installation model were established.
The discreet model, for more permanent installation, will be designed to fit into a white 2 gang pattress box
with corresponding blanking plate. This is a standard electrical installation box and will unlikely look out of
place on a skirting board or wall.
FIGURE 2-23 - A - 2 GANG PATTRESS BOX

PICTURE: HTTP://WWW.QVSDIRECT.COM/
FIGURE 2-24 - B AN ILLUSTRATION OF THE LIGHTIVE DRIVER

MOUNTED TO A SKIRTING BOARD
Page | 21
URN: 6025977
The countertop model design drew inspiration from many of the modern DAB radio designs which incorporate
a mix of modern electronics, brushed aluminium and wood or wood effect. Figure 2-25 below shows a fully
dimensioned orthographic projection of the design.
FIGURE 2-25 - ORTHOGRAPHIC PROJECTION OF FINAL COUNTERTOP DRIVER MODEL

(DESIGN FULLY MODELLED IN AUTODESK INVENTOR)
The front and back will constructed of 3mm ply or MDF with the outward facing side of the wood veneered
with, most likely, a light coloured Birch or Ash veneer depending on availability. The top arc is to be formed of
brushed aluminium with two arcs cut in the flat ends to allow cables in and out when the back is against a flat
surface. All connectors will be presented underneath the unit. To gain better idea of what the finished product
may look like a 3D render has been created. This is shown in Figure 2-26 below.
FIGURE 2-26 - 3D RENDER OF COUNTERTOP DRIVER MODEL DESIGN
Page | 22
URN: 6025977
The LED strips will be housed, with their

driver in strips of Mini Trunking which
is widely available and used in electrical
installations in buildings. It has a
removable pop on cover which will be
kept on the end housing the driver to
hide it. A small piece of cover will also
be kept on the opposing end to sustain
rigidity. The final assembly is shown
illustrated in Figure 2-27.
FIGURE 2-27 ILLUSTRATION OF HOW THE LED STRIPS WILL BE HOUSED.
2.4 THE LIGHTIVE SENSOR DESIGN

There will be a variety of sensors available for the Lightive system. Sensors can be added depending on the end
user requirement or desire for system functionality. Initial sensors to be integrated will be movement, sound,
temperature and light although the system must be designed to accept further sensors, easily, in future
development.
Each sensor will run on the same microcontroller used in the Driver units, an ATMEGA 328P. Much like the
drivers this will be connected to an Alpha FM transceiver for wireless communications. The sensor type for the
unit will also be connected to the relevant port on the microcontroller. A block diagram of the initial design can
be found in Figure 2-28 below. The sensors will be setup completely remotely via wireless so require no form
of user interface. They should be thought of as set and forget devices. All power management should also be
done via the master controller.
Alpha-TRX433S
433 Mhz Wireless
FM Transceiver
SPI
Ambient Light
Sensor
Or
PIR Motion Sensor
Atmel
ATMEGA328
Microprocessor
Or
Sound Level Sensor
Or
Temperature Sensor
FIGURE 2-28 - SENSOR UNIT BLOCK DIAGRAM OF INITIAL DESIGN
Page | 23
URN: 6025977
2.4.2 RESEARCH
Research was required into how each sensor type was to be built and what relevant components were
required.
T EMPERATURE S ENSOR
There are many different kinds of temperature sensor components with an array of interfaces and packages.
Having many free analogue ports available on the microcontroller, the use of a more expensive digital
temperature sensing component seemed unnecessary so the analogue path was chosen. A very popular range
seems to be the LM35, namely the LM35DT. This is a Precision Centigrade Temperature Sensor; it has three
pins, supply voltage pin, ground pin and an output pin. Its output is linearly proportional to the temperature in
Celsius to a quarter of a degree at room temperature; this is accuracy beyond anything required for this
application [14]. The output voltage, in millivolts, is simply proportional to the current temperature, for
example, at 250mV the temperature is 25C.
Realistically, only temperatures in the range of 0-100C require measurement. This, on the output of the
LM35DT will equate to a range of 0 to 1 volt. The way the ATMEGA328 calculates values on its analogue pins is
by dividing the resolution of its 10-bit ADC between ground and a reference voltage. The reference voltage can
be externally defined via a pin on the microcontroller, or, its own internal reference of 1.1V can be used. This
internal range works out almost perfectly for the predefined range of 0-100C as 91% of the ADCs (Analogueto-Digital Converter) range is being used giving the highest resolution with no extra external components.
Figure 2-29 shows how simple connecting one up should be.
FIGURE 2-29 - ONLY A SINGLE DIRECT CONNECTION REQUIRED FOR CONNECTION OF LM35DT TO MICROCONTROLLER
Every time a reading is required the sensor will be polled around 20 times and an average taken. This will
drastically reduce the chance of any anomalies from noise or other interference affecting the output of the
system.
PIR M OTION S ENSOR

A PIR or Passive Infrared Sensor simply detects
the movement of any heat emitting objects
moving within its detection area. The sensing
device, a Pyroelectric Sensor, has two elements
connected in an arrangement which cancels
detection of broad temperature sensors and
sunlight. This works by only affecting an output
when there is a difference in the reading
between the two horizontally placed detectors.
There is often a lens placed in front of the
sensor called a Fresnel lens which helps to
broaden the range as well as focus signals off
any heat emitting objects onto the detector
[15].
FIGURE 2-30 - DEMONSTRATION OF PIR DETECTOR

IMAGE: HTTP://WWW.GLOLAB.COM/PIRPARTS/INFRARED.HTML
Page | 24
URN: 6025977
PIR sensor modules are available with all of the control electronics already built in. These detect movement
and nearly all activate an output for a set time period. Due to this set time period the final PIR sensor unit will
need to take an average over a fairly large timespan, most probably in the range of around 20 seconds before
an initial value is produced.
A MBIENT L IGHT S ENSOR

Ambient light detection will simply be performed using an
LDR or Light Dependant resistor within a potential divider.
The output will be sampled by an analogue pin on the
microcontroller and an average light intensity value
calculated.
FIGURE 2-31 - A LIGHT DEPENDANT RESISTOR

IMAGE: HTTP://WWW.THECOLLEGEROAD.COM/
S OUND L EVEL S ENSOR

Although initially a sound level sensor was to be built, research
uncovered a pre-built sound sensor module for only 5USD or
around 3. It was simply impractical to build one when they
are available at this price. The units found were being sold by
an eBay seller called e-qstore and although the English used
to write the advert is poor, there are some code snippets
which show what output to expect from the device [16]. They
seem to consist of an electret condenser microphone and
amplifier in the form of a transistor. There also seems to be a
voltage regulator for taking down the input voltage to the
FIGURE 2-32 - SOUND SENSOR MODULE FROM EBAY
SELLER "E-QSTORE"
correct level for the microphone and amplifier circuit. The
output header at the end consists of 3 pins, 12v, GND and
OUTPUT. If they work as described they should be extremely simple to use, simply plugging the output straight
into a microcontroller analogue pin and supplying the unit with power.

With the ATMEGA328 microprocessor being quite a capable component it was felt that only allowing one
sensor type per sensor unit was underselling the units potential. For this reason the design changed to allow
single sensor units multiple sensor types. The surface mount version of the ATMEGA328P microcontroller has
8 analogue pins so can support 8 analogue sensors. The decision was made to make a default sensor consisting
of light, temperature, movement and sound sensors. A total of four sensor units will be built for the
demonstration of the system.
2.4.4 SOFTWARE DESIGN

The first thing to note in the software design is, without being registered to a master the sensor is missing
many of its settings. If the sensor is known to the master it will automatically send a request for registration
when it is turned on. This negotiations following this request will include the setting required including the
scale of colours to fade to and from for a given scenario. A flowchart showing the sensors high level
functionality is shown in Figure 2-33.
Page | 25
URN: 6025977
Start
Initialization
Routine
Update Attached
Sensor Values
Nothing
Finished
Check Radio for

packet
Received
Enter Registration
Mode
Yes
Register
Request ?
Send current Values
Yes
Value
Request ?
CRC Fail
Check CRC value

Process Command
Pass (CRC = 0)
Return Ack to
master
Place packet data into

recCmd array
FIGURE 2-33 - LIGHTIVE SENSOR SOFTWARE SYSTEM DESIGN FLOWCHART
The sensor will continually keep its sensor data up to date and will provide the last read and calculated sensor
values when requested. The sensor must not be occupied for too long without checking the Radio for a packet.
Where an average value is required for the PIR or
other devices which present only an on and off
state the easiest way to average activity over a
timeframe is by switching single bits in a variable
then take an average of on bits to off. This is better
explained in Figure 2-34 which shows how the
process would work with a 2 Byte or 16 bit variable.
Once the 16th bit of the variable is reached
sampling goes to the beginning and continues. This
is a first in first out system meaning the result is
always based on the last 16 readings in time. The
1s are then counted and mapped to a 12 bit
lighting value from 0-4095.
CurrentBit = 0
(Set CurrentBit counter equal to 0)
Set CurrentBit
to 1
Yes
Is PIR
Triggered ?
Set CurrentBit
to 0
No
no
CurrentBit == 16 ?
Yes
CurrentBit + 1
(Go to next bit)
FIGURE 2-34 FLOWCHART

- TIME SAMPLING TWO STATE SENSORS USING BITS
2.4.5 FINAL DESIGN

It was decided that the sensor board should not incorporate the sensors but allow them to be easily added as
modules. This will allow for easy customization, testing and expansion later in the project. The final PCB design
is shown in Figure 2-35 . All free digital and analogue pins have been made available via headers around the
sensor board. These headers as well as the 4 power headers splitting the input power will allow sensor
modules to be added and removed to customize the sensor unit as a whole. There is the inclusion of a status
LED and Power LED to help troubleshoot the unit as well as let the user know what operations are being
performed. This has been added due to the lack of an LCD display on this unit to relay this data. Timing
components were moved to the back of the board to ensure it is compact as possible.
Page | 26
URN: 6025977
FIGURE 2-35 LIGHTIVE SENSOR PCB DESIGN KEY DESIGN FEATURES AND COMPOENENTS ANNOTATED
2.5 THE LIGHTIVE MASTER DESIGN

The master unit will essentially sit at the centre of the system coordinating data retrieval from its various
sensors and forwarding the relevant information to the correct drivers for output. This allows the user a
central place to configure and control the system.
The initial system would wait for a value from a sensor and either store or instantaneously forward this out to
the relevant bars. The master would also keep an up to date set of values from each sensor and calculate and
map these to colours. This would rely on sensors sending their data at regular intervals which, on paper with a
single sensor would work. In practice this idea could easily result in multiple sensors transmitting at the same
time and destroying each others transmissions in the process. Combating this would require some kind of
random retransmission algorithm. It was quickly decided a rethink of this method was required.

In light of the discovery of potential operational issues which could arise from the initial design a new design
was developed. This takes a more system wide view to ensure the operations from one end to the other are as
smooth and unified as possible.
The first design development was the biggest, this looked into not only how data would flow around the
system but when. The idea was based around the fact that the Master is at the centre of the system and has a
vantage point through which it can reach, communicate and keep track of every unit. With this unique vantage
point why not make the Master unit run the show. With all radio communication governed by a single unit
there is little chance modules can communicate over each other. This new design brought the originally
chaotic system operation down to a fully controlled robust system setup. The idea behind it is simple, the
master unit polls through connected sensors gathering values, it then polls through each bar on all attached
drivers forwarding the correct sensor value to each. The code for this design more clearly illustrated how it will
work and is described in section 2.5.4.
Page | 27
URN: 6025977
2.5.3 DATA STORAGE

From early on in the conception stages of the project it was decided to make the system as independently
running as possible. The system should be capable of running and producing an output without the need for a
computer at any stage. Realistically this does impose limits to how customizable the system can be made using
only a single 2x16 digit alphanumeric display and 3 buttons. Different methods of setting up the system via a
computer were brainstormed. The minimum criteria for any ideas were not requiring this computer
connection be maintained for running. Ideas included concepts of
an Ethernet or WIFI based web interfaces or a USB connection with
a serial converter chip for direct microcontroller communication.
Strangely the answer to this issue came whilst troubleshooting
where data was to be stored for the menu system.
Initially EEPROM was to be used for the menu text which would
rarely change. This did not solve the issue of settings storage during
unit power down. EEPROM was technically capable of having these
settings values written but its designed with a write few times
read many times approach and not ideal for the longevity of the
system. Whilst looking at external components for non-volatile
memory the idea for removable media such as an SD card (Figure
FIGURE 2-36 - A FLASH MEMORY BASED SD CARD 2-36) came to mind. This thought quickly developed into an almost
ideal solution. Removable flash media, due to its popularity, offered
the greatest value in price per unit storage of any other reasonable
solution. With the ability to remove it from the Master unit and
read it on very readily available hardware on a computer suddenly also solved the earlier issues faced with
setup. The SD card could be used via a small piece of software to configure the unit on a computer. It would
then simply be plugged into the master and all the settings can be read off. This would also make it easy to
clone, backup and restore Master setups.
SD cards can communicate via an SPI interface. We are already using the hardware SPI interface on the ATMEL
Microcontroller for the wireless module. Luckily, as described in section 2.3.3 on page 14 more than one
device can share the interface by using a SS or Serial Select pin for each. Another issue to be addressed is that
SD cards operate at 3.3V whereas all of the Lightive system runs on 5V. This includes the ATMEGA328Ps
output pins. A device called a Line Level Translator will be required to take down the microcontrollers 5V
lines to 3.3. A linear voltage regulator will also be required to provide the 3.3 Volt rail for power.
2.5.4 SOFTWARE
This section describes the software after the design developments mentioned previously. The masters units
ultimate aim is to route the required data from sensor to driver. Under the new design the first task is polling
registered and connected sensors and storing their values. The master will then sequentially update the
drivers by sending them the data of the sensor which is mapped to their bars. This is better explained by the
flowchart in Figure 2-37.
The new design requires communication via an SD card. Using the SD card as a raw data store is fairly straight
forward and only requires sending a few commands down the SPI line. The problem is that the SD card then
cannot be easily read by a computer as it has no file system. Ideally the system should be able to read a file
system on an SD card and open or write files to it. Writing code for this from scratch would be extensive as the
file system which requires interfacing with would have to be heavily studied for an in depth understanding.
Whilst looking for others wanting the same a library was discovered for SD card communications and the
Page | 28
URN: 6025977
Arduino. It turns out this library already used the widely supported FAT file system and was written by William
Greiman [17] and is available under the GNU General Public Licence.
Start
Initialization
Routine
Run Items function

Item
Load Settings from

SD
Timeout
Update Connected
Drivers
Button Pressed ?
Menu
Item Selected ?
Load Main Menu
Button != Menu Button
Poll Connected
Sensors
Triggered
Poll Timer ?
No
FIGURE 2-37 MASTER UNIT SOFTWARE DESIGN FLOWCHART
2.5.5 BREADBOARD PROTOTYPE

In order to test the systems design theory before PCB design began a prototype was created on a breadboard,
this is shown in Figure 2-38. A line level translator along with a linear 3.3 Volt Regulator had to be researched
and purchased to support the SD card. The TXB0104 by Texas Instruments was decided upon as a Level
Translator as it was reasonably priced and met all requirements. The Voltage regulator chosen is also a Texas
Instruments part with part number UA78M33. Both were purchased in surface mount packages so were
modified for use on the breadboard. The breadboard prototype was successful and carried the project through
much of the software build phase.
FIGURE 2-38- MASTER UNIT BREADBOARD PROTOTYPE KEY COMPOENENTS ANNOTATED
Page | 29
URN: 6025977
2.5.6 FINAL DESIGN

After successful testing with the breadboard prototype the PCB designs were realised. A final block diagram,
including all system developments, is shown in Figure 2-39.
16x2 Alphanumeric LCD

Display
User Interface
Buttons
SD Card
Front Panel Header
Atmel
ATMEGA328
Microprocessor
Alpha-TRX433S
433 Mhz Wireless
FM Transceiver
3v
3V3 Voltage
Regulator
SPI
Line Level
Translator
3v
FIGURE 2-39 - BLOCK DIAGRAM OF FINAL MASTER DESIGN
The above design along with help from the breadboard prototype was used to create the master schematic
which is shown in APPENDIX FIG 7. Much like in the previous PCB designs the components and their solder
footprints had to be created using the datasheets.
Before the design of the PCB can begin an idea of how the front panel board will look is required. A design of
the front panel board was established. This board must also be compatible with the front panel header on the
Lightive Driver PCB described in section 2.3.7 (page 18). The buttons and LCD display to be used were
modelled in Autodesk Inventor accurate to within one half of a millimetre. These were then laid out onto a
PCB within the application and measurements taken to help establish size and positioning. The results of the
modelling are shown below. Figure 2-40 shows an orthographic projection of the proposed layout to clearly
establish its size. Figure 2-41 is an isometric view which helps establish an idea as to what the interface will
look like.
FIGURE 2-40- ORTHOGRAPHIC PROJECTION OF PROPOSED FRONT PANEL PCB

LAYOUT
FIGURE 2-41 - RENDERED ISOMETRIC VIEW OF FRONT PANEL

PCB DESIGN
Page | 30
URN: 6025977
Once a physical layout was confirmed the PCB design work for the front panel was completed. The schematic
for the front panel can be found in APPENDIX FIG 8. Figure 2-42 shows the final PCB design for the front panel.
This is a single sided board with no surface mount components so should be simple to create and put together.
FIGURE 2-42 - LIGHTIVE FRONT PANEL PCB KEY DESIGN FEATURES AND COMPOENENTS ANNOTATED
The circuit schematic for the Master unit PCB could now be used along with the front panel designs above to
complete the Masters PCB layout. Figure 2-43 below shows the final PCB design. The footprint of the board
exceeds that of the actual circuitry because it must mount to the front panel board. The four holes which will
mount the master PCB are the same four which also go through the display. Once put together these holes
going straight though should provide plenty of support for the 3 PCBs.
FIGURE 2-43 - FINAL LIGHTIVE MASTER PCB DESIGN - KEY FEATURES AND COMPONENTS ANNOTATED
Page | 31
URN: 6025977
3 PROJECT BUILD PHASE

The build of the project did overlap heavily with the design phase. They have been separated to allow more
clear presentation of the progress throughout the year. As unit PCBs were designed they were being
submitted to the department for manufacture. This was because only two prototyping microcontroller chips
and boards were available. This lack of available units to prototype on did begin causing issues as the first
PCBs took a while to create. The time taken to design PCBs drastically reduced as the software was learned
and components were created and could therefore be reused.
With the very broad band of areas covered by this project there is not enough scope in this report to cover all
aspects in detail. For this reason the software has been well commented and the software section focuses on
snippets of each library to give an idea of the kind of functionality being used and how they are managing data.
Far more attention has been paid to the build where, unlike code, the process cannot be commented and
explained as easily afterwards.
3.1 SOFTWARE
The coding and developing of the Lightive software for each unit was running continually throughout the
entire project. As this report is written the current total line count stands at more than 1500. This does not
include any content from third party libraries. The code written to date forms a usable foundation to which
functionality can easily be added. This section aims to summarise the functionality of this code above and
beyond what was explained in the design section to allow an insight into how the system is processing data.
3.1.1 THE LIGHTIVE SD CARD LIBRARY

The Lightive SD card librarys core functionality is wrapped around the Arduino SD card library. This has been
developed by the Arduino community and is released into the public domain [18] so there is absolutely no
limits or restriction on how the code can be modified or used. The Lightive system has its own method of
storing data to files which essentially adds an address to each line using a prefix. This library was written as a
standard interface for easy writing and retrieval of this data. It is used on the master unit for menu display and
loading as well as saving settings.
Before explaining how the library works here are a few examples of
the files it interfaces with. Figure 3-1 shows a menu file. This
contains a list of menu items to be displayed. The file begins with a
4, this is unique to the menu system and tells it how many menu
items are present. On the lines after the 4 is where this library will
begin reading. Each item is prefixed with a number, in this case 0 3,
FIGURE 3-1 - FILENAME: 0.M
*.M DENOTES THAT THIS IS A MENU FILE AND
THE 0 DENOTES IT IS THE FIRST OR MAIN MENU
then a *. The library is designed to be passed a line number to read,

it scans through the file until it finds the given number followed by
the *. In this file all the data is ASCII and hence readable but each
character can effectively be thought of as a byte of data.
This is how the settings for drivers and sensors are stored to files on the SD card. As the bytes of data are not
necessarily visible characters in the ASCII standard a normal text editor cannot be used to read or write the
files. Instead a raw editor which shows the
actual contents of each byte is used. Figure 3-2
shows the driver settings file currently used by
the master unit. If the first three settings are
taken, these are DRVR_REG, DRVR_ADD,
DRVR_BARS we can see the corresponding FIGURE 3-2 - THIS IS THE DRIVER SETTINGS FILE CURRENTLY BEING USED BY
THE SYSTEM THERE IS A SINGLE DRIVER REGISTERED, DRIVER 0
Page | 32
URN: 6025977
values after 0* are 01, meaning the driver has been registered, 01 which is the drivers address and 05 which
is how many bars are available on the driver. The beauty behind this system is that a relatively simple piece of
software can be written to run on a computer which writes these files with selected settings making system
setup extremely quick and efficient without any need to have access to the system.
Unfortunately due to the large scope of content which must be covered it is not possible to explain the code
behind the entire library in this report. The code has instead been appropriately commented. One function
was chosen for explanation as it has many elements which others share. This was the readline() function and
its while loop, which gives it most of its functionality, is shown in Figure 3-3.
FIGURE 3-3 - WHILE LOOP FROM READLINE() FUNCTION
This loop uses peek() to check what the next character is without actually reading it. If the value it is peeking
at is not the end of line character it then jumps into the loop and reads that character into a string. Once a
character is read the position in the file is incremented by one so the loop will then peek at the next value.
Other conditions for the loop include open_file.available() which ensures that the open file is still accessible
and we have not reached the end. There is also a counter who variable is named count which increments
with every loop. This moves along the array which the read characters are being placed into. Because this
string array is passed in as a pointer its size must not be exceeded so the count variable is also checked against
size in every loop iteration.
3.1.2 THE LIGHTIVE RADIO LIBRARY

This is an important library as it is used by all Lightive units. It essentially handles all of the radio
communications. It is wrapped around the JeeLabs library described in section 2.2.1 which handles much of
the low level communication with the hardware. Its main functions are check(), which checks if there is a
command available, transmit() which significantly simplifies the transmission process, delayforack() which
checks the radio continually for a specified time listening for an ack and finally, plclear() which clears the
payload variable used for transmissions.
Once again it is not possible to describe the code of the entire radio library in this report, instead the largest
function, transmit() was chosen for description. The transmit() function accepts two variables, a byte for
the destination ID and a bool for whether an ack is required. The ultimate aim for this function is to provide
the JeeLabs library with the information it requires to instruct the radio module to transmit. This is a valid
header, a pointer to the base address of a payload and the size of that payload. The only real value which
requires any processing at this stage is the header byte.
The layout of the header byte was described in section 2.2.2, and is shown in Figure 2-7 on page 11. The first
of the flags to be set is the ack flag. This is simply done by putting the whole of the header byte equal to
0x20 which sets the ack flag to 1 should an ack be required. If no ack is
required the whole header byte is set equal to 0. The next part of the
header to be filled is the destination. If a destination other than 0 has
FIGURE 3-4 CODE FOR SETTING THE
been set the header is subject to the following binary formulae:
DESTINATION FLAG AND ADDRESS
= 040 which has been derived from the
code in Figure 3-4. This simply adds the destination, which can only be a
Page | 33
URN: 6025977
maximum of 5 bits (0-31) to the 5 Least Significant Bits (LSB) of the header byte, sets the dest flag to 1 and
then ORs this with the original header byte to carry along any flags which have been set so far.
Once the header byte has been setup the payload is essentially ready to be transmitted. Before transmission
can begin the radio module must confirm it is ready. The JeeLabs library function called rf12_canSend()
returns whether the module is ready or not. Some code must be setup to allow a timeout if the radio does not
become ready within a time window. This is simply done here by creating a retry counter. Every time the radio
is checked the counter is incremented, if it exceeds a certain amount of attempts the entire function returns 0,
specifying the packet transmission failed. If the rf12_canSend() function returns 1 then the packet may be
transmitted.
One the packet has been transmitted there are two options, if no ack was requested the function is finished
and returns a success. If an ack was requested the function the calls another Lightive radio library function
called delayforack(), this checked the radio for a given window and runs check on incoming packets. If a
packet is deemed to be the correct ack then this function returns true and consequently do does the
transmit() function. Should an ack fail to be received the packet will be re-transmitted and the checks
performed once again. This process also has a timeout in the form of number of attempts. Should the
maximum number of attempts is exceeded the function returns a failure. This concludes the functionality of
the transmit() function.
3.1.3 DIRECT OUTPUT FUNCTIONALITY

rd
The original aim of the project specified the system must have an ability to allow 3 party, computer based
software to be written which can interface with the system. An example given was the ability to use the
system as an Ambilight ( section 2.3.2, page 13 ) where low latency was essential. This is where the Direct
output functionality comes into play. It reads data, in a defined protocol via the serial line on the master then
transmits this, with minimal delay to a driver unit where the output change is instantaneously effected.
The serial line is read in on the master once it has been put into the direct output mode. Upon placing the
master in direct output mode the drivers are also wirelessly placed into this mode. This then simply waits for a
preamble of 0xAA which was chosen because of its uncommon binary sequence. After this preamble it will
read a specified number of bytes and load these into a payload. These bytes correspond to each output
channel on the other end. Figure 3-5 shows this functionality. This payload is then transmitted to the specified
driver which instantly works to effect the changes required.
The values will be fed in via serial here. They will

contain an AA prefix and, starting with Bar 1 will
cycle through RGB values of each Bar.
Serial Connection (Via USB to Serial Converter)

Example Serial Stream
...etc | Bar 2: Red |Bar 1: Blue | Bar 1: Green |Bar 1: Red |AA
(please read serial stream right to left)
Wireless Link
Master Unit in Direct Output Mode

Master unit in this mode places the values after
the prefix into a packet and sends it along to the
driver.
Driver Unit in Direct Output Mode

The Driver unit sequentially maps the data from
the packet to the outputs. EG, packet 1 will go to
output 1 after its 8 bit value (0-255) has been
mapped to a 12bit value (0-4095).
FIGURE 3-5 IMPLEMENTATION OF DIRECT OUTPUT FUNCTIONALITY
Page | 34
URN: 6025977
3.2 HARDWARE
3.2.1 MANUFACTURING THE PCBS
As the PCBs were being made in house the process was followed for a better understanding. The process used
here at the University of Surrey Electronic Engineering department is a Photo etching method onto photo PCB
which has a photo-resist layer on one side. To speed up the completion of the PCBs hole drilling and trimming
were completed whilst the technical staff were extremely busy. This section aims to briefly show and describe
the process used as is not intended as a guide.
S TEP 1 P RINT THE PCB DESIGN TO A TRANSPARENCY .

Double sided boards require one printed for both sides. By taping
them together in alignment a pocket can be formed allowing the
PCB to be slipped in, this is shown in Figure 3-6. This also keeps the
top and bottom in alignment as holes must obviously meet the pads
on both sides. It is best to print the transparencies at the highest
resolution available on the printer, this should deepen the blacks
S TEP 2 E XPOSURE
FIGURE 3-6 - DRIVER UNIT PCB

TRANSPARENCIES TAPED TOGETHER
This step involves exposing the photo sensitive PCB layers to strong UV light. The
transparency will mask the areas of copper to be kept. The areas exposed to UV
will react with the PCB developer in the next stage and be removed. Figure 3-7
shows the UV exposure box, the yellow tinge on all the photos is the safelight.
FIGURE 3-7 - BOARD BEING EXPOSED
TO UV THROUGH TRASPARENCIES
S TEP 3 D EVELOP
This stage will remove the photoresist that has been exposed to
the UV light. The PCB is simply soaked in the developer for a few
minutes then brushed to help remove the remaining photo resist.
This is shown in Figure 3-8.
FIGURE 3-8 - BRUSHING OFF REMAINING
PHOTORESIST
S TEP 4 R INSE THE B OARD

The board must now be thoroughly rinsed to remove all of the developer and
any bits of stray photoresist. The driver board being rinsed is shown in Figure
3-9.
FIGURE 3-9 - RINSING BOARD
S TEP 5 - E TCHING
The board is placed into a machine which sprays an etchant, in our case ferric
chloride at it continually. This etchant attacks the areas of copper which are
not protected by the photoresist and eats away at the copper. The etchant is
also warmed up which makes it more effective and shortens the time required.
Once all the exposed copper has been removed the board is once again rinsed.
Figure 3-10 shows the tank etching the PCB in action.
FIGURE 3-10 - ETCHING THE
PCB
Page | 35
URN: 6025977
S TEP 6 R EMOVE REMAINING PHOTORESIST

The remaining photoresist can now be removed. This was done simply using some
acetone and a cloth. The board was once again rinsed one final time.
S TEP 7 L ACQUER THE BOARD

For this step some SK10 flux solution was sprayed on to form a protective layer above
the board. This not only stops corrosion on the board but also acts as a flux which helps
bind the solder when soldering. A heat gun was used to reduce the drying time
required by the sk10. Figure 3-11 shows the SK10 spray can.
FIGURE 3-11 SK10 FLUX
BASED LACQUER
S TEP 8 D RILL THE HOLES

The department had a foot operated drill press which projects and
magnifies the PCB and places a cross hair directly over the drill piece. This
makes drilling holes accurately a fast and easy process. Figure 3-13 shows
the drill press used. Over 1000 holes have been drilled for the entire
project.
S TEP 9 C UTTING TO SIZE

The PCBs can now be trimmed to size.
This is simply done using a guillotine.
The PCB manufacture is now complete
and the board is ready for soldering.
FIGURE 3-13 -FOOT OPERATED
PCB DRILL PRESS
FIGURE 3-12 CUTTING PCB TO SIZE WITH

A GUILLOTINE
3.2.2 SOLDERING TECHNIQUES

Being the first time soldering surface mount components or double sided boards some techniques were
researched and developed to aid the process. These have been summarised here and were used to build the
units in the sections following.
V IAS
Although not unique to surface
mount boards vias were found to
be one of the most time
consuming and fiddly tasks when
soldering. One technique developped was to coil a strip of wire as to
make a kind of torsion spring then
use the tension between the ends
to hold it in place whilst it is
soldered. This technique is
pictured in Figure 3-14. The tricky
part was stopping the wire falling
through whilst soldering the
opposing side.
FIGURE 3-14 - TECHNIQUE DEVELOPED FOR KEEPING WIRE IN PLACE WHILST SOLDERING VIAS
Page | 36
URN: 6025977
S URFACE M OUNT IC S
Several techniques were tried when soldering surface mount ICs but one was found to be fastest and the most
precise. The first step was to ensure a generous helping of flux was on the board. Using tweezers the IC was
aligned then pushed down where the tackiness of the flux would help to hold it in place. Two opposing pins
were then tack soldered to hold the IC in place. Please observe Figure 3-15 which shows an ATMEL
microcontroller tagged to a driver board using this method. Now each side of the IC remaining were heated
and solder was applied across the whole side. By pulling the soldering iron away from the IC down the tracks
most solder bridges could be avoided. Any bridges which do occur had excess solder soaked up with some
solder wick which was heated over the bride and also dragged away from the IC down the tracks before lifting.
FIGURE 3-15 - ATMEL ATMEGA328P WITH OPPOSING PINS TAGGED TO DRIVER BOARD - SURFACE MOUNT IC SOLDERING TECHNIQUE
S INGLE I N L INE H EADERS

Single in Line (SIL) headers had to be soldered on both sides of the PCB as they had connections to tracks on
both sides. This posed a problem as the plastic mounting both the female and male header connectors came in
prevented soldering of the top side. This was overcome by soldering the back then carefully removing the
plastic casing to expose the conductive sockets. These were then soldered and the plastic casing reapplied.
The technique was repeated for the male connectors with its insulated spacer. The exposed pins of a female
header are shown in Figure 3-16.
FIGURE 3-16 - FEMALE SIL HEADER WITH PLASTIC CASING REMOVED TO EXPOSE PINS
Page | 37
URN: 6025977
3.2.3 THE DRIVER

The Driver was the first board to be created and soldered. It has a total of 42 vias which, due to limitations in
available equipment, had to be soldered manually using the aforementioned technique. A total of two driver
boards were created and apart from an issue where a via on the reset line was missed, all boards worked
flawlessly first time. One of the driver boards was mounted in a two gang pattress as described in the design
stage (See section 2.3.7). A photo of the complete prototype is shown in Figure 3-18. This is to demonstrate
the concept works in reality and can create a neat and fairly inconspicuous unit.
FIGURE 3-18 - ASSEMBLED LIGHTIVE DRIVER PROTOTYPE INSTALLATION MODEL TOP RIGHT SHOWS VIEW WITH LID ON
The only real and considerably time

consuming issue came when creating
the connectors for the bars off the
PCB. Without the proper crimp tool
these had to be crimped manually.
They are extremely small for
connectors which make them very
fiddly; a size comparison can be seen
at the top of Figure 3-17. After many
issues with wires pulling out when
moving units it was decided a
solution was necessary. Harwin, the
providers of the connectors were
contacted for some pre crimped
FIGURE 3-17 EXAMPLE OF BAR OUTPUT CONNECTORS WHICH PROVED VERY SMALL AND
cables but they would be made in FIDDLY. TOP IMAGE SHOWS CONNECTOR AND PINS BESIDE A UK 20 PENCE COIN. BOTTOM
Asia which would mean a large and
IMAGE SHOWS HOW PROBLEM WAS SOLVED.
unaffordable delay. After a few
different attempts a solution was found. A piece of heat-shrink tubing was heated till it was just gripping the
connector. This was then filled with hot glue and sculpted to shape. Once set the connector became solid
which aided with plugging and unplugging as well as stopping wires pulling out or splitting; shown at the
bottom of Figure 3-17. In hindsight these connectors should not have been acquired without the appropriate
crimping tool available.
Page | 38
URN: 6025977
3.2.4 LED STRIPS

The LED strips, as described in the design (section 2.3.7 ), consist of a driver board with the LED strip soldered
directly onto it. The driver board requires a 12V power line, 0V line and three PWM signals for red, green and
blue channels. There were no large issues with these boards; the only modification which had to be made was
due to a printing error where the PCB boarder remained on the board. As this risked shorting the tracks on the
LED strip it was removed with a craft knife.
FIGURE 3-19 - LED BAR DRIVER PCB SOLDERED AND READY TO BE ATTACHED TO STRIP. VISABLE ARE 3 MOSFETS AND THEIR PULL UP
RESISTORS
Figure 3-22 shows the 10 driver PCBs which have been completed and had 1 meter of LED strip attached. The
next task was to mount the strips into trunking, solder on the wires and their connectors. The connectors used
to connect the bars to the driver were Harwins L-Tek range and are friction latched to avoid them just falling
out. The cables were soldered to the connector and then heat shrink wrapped for protection. How the
connectors look before and after the heat shrink is applied can be seen in Figure 3-21.
FIGURE 3-22 - 10 1METER LED STRIPS SOLDERED

TO DRIVER BOARDS
FIGURE 3-21 - SOLDERED THE HEAT SHRINK WRAPPED L-TEK

CONNECTORS
The mini trunking used was purchased from Rapid electronics and is manufactured in the
UK by MITA [19]. The size chosen had a channel width of 25MM and height of 16MM. It
was only available in 3 meter lengths which unfortunately meant, since each bar would be
just over a meter with the driver, there would be some waste with only 2 bars being
produced per strip. After pieces of trunking were cut to length the RGB LED strip was stuck
directly down the middle of the trunking using the 3M adhesive tape the strips were
supplied with. The driver board was secured using a tie-wrap (Figure 3-20) then some hot
glue in each corner to stop any movements or impacts fracturing its connection with the
FIGURE 3-20 - LED
DRIVER ABOUT TO BE
TIE-WRAPPED
Page | 39
URN: 6025977
LED strip. Finally the wire was also tie wrapped down for security and the end of the trunking was capped with
some hot glue. The finished assembly, shown in Figure 3-23 formed a solid and durable feeling LED light bar.
FIGURE 3-23 - ASSEMBLY AT DRIVER END OF A LIGHTIVE LED BAR
The amount of wastage left over for each 3 meter strip prompted an idea to use of the remaining trunking as a
stand for the bars as shown in Figure 3-24. These stands tilt the bars which allow them to be placed facing flat
surfaces such as walls to create a wash of light.
FIGURE 3-24 - RE-USING WASTE TRUNKING AS A STAND
The final part of the driver is the PCB which translates the 12V required for the LED bars to the 5V required by
the control circuitry. This is a high efficiency switching regulator so requires some external components. There
was a small issue with this board where the gaps between the pads for the regulator legs were too tight to
have been reproduced correctly on the PCB. This was solved by running a craft knife between the edges of the
pads. This seemed to work flawlessly. The completed driver board is shown in Figure 3-25.
FIGURE 3-25 - COMPLETED 12V TO 5V SWITCHING REGULATOR
Page | 40
URN: 6025977
3.2.5 THE SENSOR

The sensor module was by far the easiest module to solder. It was the smallest and least complex. Due to its
modular format it had to have many connectors and some external boards made up for it. All of the sensors
are individually detachable. So far two sensors boards have been built and tested although a total of 4 PCBs
have been manufactured. The two completed sensors are shown in Figure 3-26.
FIGURE 3-26 TWO COMPLETE LIGHTIVE SENSORS. THE BOARD ON THE RIGHT IS SHOWN CONNECTED TO A
BATTERY PACK FOR POWER AND WITH A PIR, TEMPERATURE AND LIGHT SENSOR ATTACHED
As the PIR is an aftermarket standalone unit it is connected separately. It requires a 5V, ground and signal line.
The heat sensor and light dependant resistor have been soldered to a piece of proto board which has power
and a signal line for each sensor. The sensors are shown in Figure 3-27.
FIGURE 3-27 - PIR, TEMPERATURE AND LIGHT SENSORS WITH CABLE HARNESSES FRONT, TOP AND RIGHT VIEW
Although there has not been enough time to complete the last two sensor boards before the writing of this
report the sensors have not suffered from any issues.
Page | 41
URN: 6025977
3.2.6 THE MASTER

The master unit was the most complex of the three consisting of 4 PCBs which require soldering and
interconnecting cables to be made. The first PCB to be built was the control board; this is shown in Figure 3-28.
There was a small defect with the design of this board which was easily rectified with a piece of wire. This was
the grounding of the 3V3 voltage regulator and occurred due to a last minute change in component
positioning. This issue did not stop the board from functioning but meant the SD card was inaccessible till the
problem was rectified.
FIGURE 3-28 - FULLY SOLDERED MAIN LIGHTIVE MASTER PCB
The next PCB to be built was the SD card board. This simply allowed the SD card holder to be mounted on a
corner of the master unit enclosure for access externally. The capacitor seen attached across the back of the
board allows it to be mounted either way around.
FIGURE 3-29 - COMPLETE SD CARD BOARD
FIGURE 3-30 - COMPLETE FRONT PANEL BOARD
The second from last PCB required was the front panel board. This mounts the front panel LCD display and
interface buttons as well as containing all of the components for them. There is a small resistive pot on the
board which controls the contrast on the LCD display. This is set prior to board installation as it becomes
inaccessible once the board is mounted to the enclosure. Spacers cut to length are compressed between the
LCD and front panel board by nylon screws and nuts keeping it at the correct height. PCB pillars are then
attached to the bottom of these nylon screws and the Master PCB is mounted through them. A complete front
panel board is shown in Figure 3-30.
Page | 42
URN: 6025977
The final board is the power supply. This is the same board pictured in Figure 3-25 in the Driver section above.
This has been mounted to the enclosure (Figure 3-32) and the DC socket for the power supply has been
mounted for external access (Figure 3-31).
FIGURE 3-32 - POWER SUPPLY MOUNTED TO MASTER

ENCLOSURE
FIGURE 3-31 - EXTERNALLY ACCESSABLE DC PLUG WILL

ACCEPT ANYTHING FROM 8V TO 40V DC
An acrylic mount for the project box the Master unit is in was made. The acrylic was cut to size and a square
hole was made. The acrylic was then heated with an electric heat gun and slowly formed to the right shape.
This creates a comfortably viewed and easily accessed control interface for the system. The complete master is
shown in Figure 3-33. For standard system operation this driver unit will only require power so has minimal
cables. Due to late delivery the FTDI USB to serial converter for this unit has yet to be fitted.
FIGURE 3-33 - COMPLETED DRIVER UNIT
Page | 43
URN: 6025977
4 THE SYSTEM IN PRACTICE / IMPLEMENTATION

With the issues faced throughout the project a complete setup of the system as to get social feedback could
not be completed before the writing of this report. For this reason this section will focus primarily on the
technical aspects of the system to date.
Unless explicitly stated all testing was performed with one fully loaded driver (all 5 bars attached) using the
power supply purchased for the unit. The final master controller, assembled and in its enclosure. A single
sensor board, battery powered with only the PIR movement sensor attached.
4.1 KEY FUNCTIONALITY AND USER INTERFACE

The user interface is simple and intuitive requiring only 3 buttons to operate. During testing settings were
being saved to the SD card but were not being loaded. This meant the system was setup via the menu many
times and the system never behaved unexpectedly.
Once registered the changes from the sensor and attached PIR were seen to be accurately resulting in the
specified colour changes in the bars. The designated colours were changed on the SD card via a computer.
These changes were seen to be working flawlessly in system which confirms sensors are receiving their values
wirelessly from the SD card in the master.
Tests were performed to see how the system would react to powering down the sensor or driver, both in
standard operation and whilst registering them. In every case the system dealt with these scenarios well
although it was noticed the driver may not respond to an open menu request on the first attempt. This is
believed to be because retry values in the wireless library are too large resulting in the wireless module getting
hung up retrying transmissions to an unavailable device.
4.2 DIRECT OUT FUNCTIONALITY AMBILIGHT

The aforementioned direct out functionality was tested turning the system into a very large Ambilight. The
results were simply astonishing. The system kept up with the software flawlessly creating a fare more
immersive experience that originally thought.
The software used on the computer to send the serial data was called boblight [20]. This is very customizable
and a configuration file was written to support the system. The configuration file has very little documentation
available so was modified simply by logically and methodically changing values. It is
clearly split into 3 sections, device, light and colour.
[device]
name
output
channels
type
interval
prefix
rate
lightive
"com1"
9
momo
20000
AA
57600
FIGURE 4-1 - DEVICE SECTION

IN CONFIG FILE
The Device is what the system is outputting to and so contains the connection
information required. Figure 4-1 shows the device section in the configuration file.
The type field has been set to momo. Although there is limited information
available on this it seems to be very similar to the proposed protocol in that it
sends a prefix followed by lighting values. This was discovered by using a device
called a bus pirate which can sniff data down a serial line. Both the prefix and the
order of values can be customized and were changed to suite the Lightive system.
The colour section allows the user to specify colours the system would require. The
colour section from the Lightive configuration can be seen in Figure 4-3. The
minimum required information is a name and RGB value. The RGB value was formatted as RRGGBB and
required values presented in HEX. When boblight scans the screen it is these colours it then makes a
comparison with. If it scans a section of the screen and sees red, it will add value to the red colour. The
Page | 44
URN: 6025977
[color]
name red
rgb
FF0000
[color]
name green
rgb
00FF00
adjust 0.8
adjust values seen in the configuration were added to calibrate the system and
produce a more accurate colour output. This is because the red LEDs on the strips
seem to have a weaker output than the blue or green. Subsequently the green LEDs
are also perceivably weaker than the blue. These values were obtained through a
progression of logical trial and error.
[light]
The light section brings the other two sections
name left
together. This is where the actual physical bars are
color
red
lightive 1
defined. The configuration for one of the three
[color]
color
green lightive 2
lights is shown in Figure 4-2. After the name, in the
name blue
color
blue lightive 3
case of Figure 4-2 this is the left bar, there is three
rgb
0000FF
hscan 0 33
lines which begin with colour. These lines map a
adjust 0.5
vscan 0 100
colour to a devices output. If we take the red
colour in Figure 4-2 we are mapping any red
FIGURE 4-2 - ONE OF THREE LIGHT
FIGURE 4-3 - COLOUR
SECTIONS IN CONFIG FILE
colours,
as
define
in
the
colour
section,
to
the
SECTION IN CONFIG FILE
Lightive device. The 1 on the end denotes its the first value to leave the serial port.
The hscan and vscan fields define how much of the screen this light will scan and represent. Figure 4-4 more
clearly describes how these horizontal and vertical allocations work.
Computer
screen
(With Boblight Software running)
33
100
66
Right
Left
100
[Lights]
Left
Top
33
[Device]
Serial
Lightive
System
Top
Right
FIGURE 4-4 - DIAGRAM RELATING DIFFERENT SECTIONS AND FIELDS IN THE BOBLIGHT CONFIG (PLEASE VIEW IN COLOUR SUPPLEMENT)
To help bringing these fields together we can take an extreme example to demonstrate how they would work.
Looking at Figure 4-4 we can see that the complete right hand side of the screen is red. Boblight will scan the
area inside what is defined as the right light which, as the diagram shows is anything from 66-100% in the
horizontal axis and 0-100% in the vertical. As it scans the area it will compare it to the colours which have been
defined and create an average for each. In the case of the example it will see that, as the field is pure red the
averages for green and blue will be 0 and red will have a value of 255. As the red colour, within the right bar is
th
assigned to the lightive device as value 7, it will be the 7 value down the serial line.
Although no official survey was performed, individuals who had a chance to experience the system in action,
within a few minutes agreed it faded into the background creating the illusion of watching a far larger display.
They did not find it a distraction which implies data is travelling smoothly through the system at a fast enough
pace. A video of the system in action can be found on YouTube at http://www.youtube.com/user/louisc123.
4.3 SOAK TESTING

This was a fairly simple test. The system was left functioning through an extended period of 32 hours during a
weekend. The sensor was on rechargeable batteries whilst the rest of the system was function off its own
dedicated power supply units. The unit was working flawlessly whenever observed throughout the soak test
Page | 45
URN: 6025977
time period. Whilst on the sensor unit was moved to other areas of the house and the lighting system was
observed changed when activity occurred in the given areas. By the end of the 32 hour test the TLC could have
been barely been described as moderately warm. The driver units were warm but this seemed to be heat
conductance from the LED strips themselves as they felt warm to the tip of the meter length. The only reason
the system was turned off at 32hours was because it has to be moved to the undergraduate laboratories. Here
the system had been plugged in and ran for the rest of the day. It has, on several occasions, run for times
exceeding 5-6 hours in the undergraduate laboratories and shown no issues.
Two feature length films have also been watched using the Direct Output mode and Boblight and the system
coped with the drastic light changes and flashes with no issues at all.
There have been no stability issues presented by the system to warrant further testing in this field.
5 COSTS
This section summarises the average actual cost per prototype unit. These are the prices that items were
purchased at for this project and are therefore at the retail end of the price range. Many of these can be
heavily reduced by buying in bulk and are in no way representative of the final prices which things can be built
in manufacture.
Items with no price were acquired as samples. Components such as resistors and capacitors have not been
included and are available from the undergraduate labs and are of very low value.
Driver Unit
Part Number
Item Description
Supplier
ZXMN2A01FTA
MOSFET N-CH
RS
N/A
16MHZ SMD CRYSTAL (RC)
M30-4010346
Quantity
Unit Cost
Line Cost
16
0.10
1.60
Rapid
0.29
0.29
Harwin Connectors
Harwin
0.00
0.00
TLC5940
16-Chan PWM Driver
Texas Instruments
0.00
0.00
TRX433S
Alpha RF Transceiver
RS
3.51
3.51
ATMEGA328P-AU
Atmel Microprocessor
Farnell
2.22
2.22
N/A
Driver PCB (In House)
Univ of Surrey
1.16
1.16
N/A
Bar Driver PCBs (In House)
Univ of Surrey
0.21
1.05
T4483ST
Power Supply 12v 5A
Rapid
13.09
13.09
N/A
RGB LED Strip 5M
eBay
19.00
19.00
Total:
41.92
Sensor Unit
Part Number
Item Description
Supplier
N/A
Rapid
TRX433S
RS
ATMEGA328P-AU
N/A
Quantity
Unit Cost
Line Cost
0.29
0.29
3.51
3.51
Farnell
2.22
2.22
Sensor PCB (In House)
Univ of Surrey
0.81
0.81
N/A
PIR Sensor
eBay
2.93
2.93
LM35DT
Temperature Sensor
Rapid
0.93
0.93
N/A
LDR - Photoresistor
Rapid
0.18
0.18
Total:
10.86
Page | 46
URN: 6025977
Master Unit
Part Number
Item Description
Supplier
N/A
Rapid
TRX433S
ATMEGA328P-AU
N/A
Quantity
Unit Cost
Line Cost
0.29
0.29
RS
3.51
3.51
Farnell
2.22
2.22
Master PCB (In House)
Univ of Surrey
1.99
1.99
N/A
Front Panel PCB (In House)
Univ of Surrey
1.24
1.24
PB61302BL
Laser Etched buttons
RJS Electronics
1.58
6.32
85-3736
9vdc 15watt UK psu
Rapid
5.04
5.04
DM1AA-SF-PEJ(72)
SD card holder
RS
1.64
1.64
UA78M33CDCY
Lin Regulator 3.3V 0.5A
RS
0.24
0.24
TXB0104DG4
Voltage Level Translator
RS
1.16
1.16
PC1602ARS
Alphanumeric LCD 16x2
Rapid
6.17
6.17
Total:
29.81
The predicted costs in the midterm report were not too far out considering how much the project has evolved.
The cost of a driver unit was predicted at 37.17 where as it came in at 41.92. The reason for this is actually
because the prediction did not include the cost of the power supply which was 13. In theory the unit itself has
actually come in under the predicted cost. The sensor unit was estimated to cost 8.81 but this was with no
sensors. The total cost with sensors was a reasonable 10.86. The master unit sees the biggest cost difference
with predicted costs being at 13.07 and actual costs coming in at 29.81. This was down to the purchase of
some Laser Etched Buttons at sample prices which added 6.32 and the inclusion of a power supply adding
5.04.
For a system with a two sensors, a master and a driver with 5M of LED strip the total price is 93.45.
Considering a single Phillips mood lamp costs 92.99 online and offers nowhere near the functionality and light
output of the proposed Lightive setup above, its fantastic value for money. If these could be produced to even
a small scale the cost saving benefits would fall meaning they could probably retail at around that price range
and hypothetically return a profit.
6 CONCLUSIONS
The primary aim for this project has been achieved. Even in its unfinished state the system is reacting to
environmental changes from wirelessly connected sensors. With the system just sitting on a bench in a fully lit
lab it was wonderful to see people gravitate towards it and watch it change colour. Several students and
academics were seen trying to work out what was invoking the colour changes. Once they had discovered it
was based on movement they were observed standing still then exaggeratedly moving to prompt colour shifts.
The ideas of subtle interactivity laid out in the aim feel to have been fulfilled although no structured user
questionnaire was carried out due to a shortage of time.
The specification laid out in the aim also stated the desire for the ability to use the system with applications
developed on a computer. The Ambilight software test was a perfect demonstration of this concept and why it
was an important addition. As far as research suggests this is the first wireless Ambilight capable system to
date. It can easily be adapted to run with visualization software as well as have plugins developed for popular
music players such as iTunes. An example of where this flexibility could be invaluable is in a hotel venue where
perhaps some of the dining suites or halls serve multiple functions. Whilst gusts are dining the lighting system
can provide ambiance, perhaps even reacting with customized colours to fit with a weddings colour scheme.
Page | 47
URN: 6025977
Then when the disco rig kicks in the system can become part of the disco rig controlled by software. The
possibilities with this level of flexibility are unparalleled for a system at this price point.
The problems experienced were few but they were crippling with regards to time. Ultimately due to delays in
designing the PCBs there was a shortage of equipment to prototype on. No prior experience in many of the
fields, namely PCB design and Microcontroller development mean any real estimation of time was always
going to be limited in accuracy. It is now evident the project was extremely ambitious from the start with such
a limited time frame.
There are several improvements that could be made to Lightive v2.0. The first is a rethink of the driver design.
The idea of having one driver running multiple bars remains valid with regards to cost reduction. Expensive
items such as wireless modules and capable microprocessors cannot be justified on single bars. Instead it
would be great to have a single receiving unit which could process the data and present a serial or two-wire
bus onto which the LED bars could sit. Each bar in turn would have a much cheaper low power microcontroller
capable of PWM to read this bus and create the desired output. This would mean bars could be daisy chained
along with small, 4 core cable. This would reduce the need to run individual cables back through to a single
point. Another smaller improvement would be the addition of bar detection. This would essentially allow the
driver to know if a bar is connected. This way only the bars which are connected to a driver will be presented
as available at the master.
A personal note; when I embarked on this project I began with a small interest in lighting systems and a desire
to step into the ever more powerful world of microcontroller electronics. I feel I have ended up with so much
more. From technical skills such as PCB design and manufacture, surface mount soldering, object oriented
programming, microcontroller development, system design and wireless communications through to soft skills
such as time management and dealing with suppliers, this project has equipped me with an array of priceless
real world skills. To see the Lightive system go from its inception, as a series of sketches on paper, to a working
almost breathing system reminds me why I decided on the engineering pathway. This project, although
stressful and frustrating at times has been a joy to complete.
Page | 48
URN: 6025977
BIBLIOGRAPHY
1 PHILIPS. Philips. [Internet]. [cited 2010 Dec]. Available from:
http://www.philips.co.uk/c/livingambiance/livingcolors-anthracite-6914367pu/prd/?t=specifications.
2 Arduino. [Internet]. [cited 2010 Dec]. Available from: http://www.arduino.cc/.
3 Wippler JC. JeeLabs. [Internet]. [cited 2011 Apr]. Available from: http://jeelabs.org/.
4 QUASAR UK. ALPHA RF Transceiver Datasheet. [Internet]. [cited 2010 Dec]. Available from: http://docseurope.electrocomponents.com/webdocs/0d06/0900766b80d0644d.pdf.
5 Wippler JC. RF12 library. [Internet]. [cited 2011 Apr]. Available from:
http://jeelabs.net/projects/cafe/wiki/RF12.
6 Open Source Initiative. OSI - The MIT Licence. [Internet]. [cited 2011 Apr]. Available from:
http://www.opensource.org/licenses/mit-license.php.
7 Cook M. De-Coupling. [Internet]. [cited 2011 Jan]. Available from:
http://www.thebox.myzen.co.uk/Tutorial/De-coupling.html.
8 Texas Instruments. DATASHEET - TLC5940. [Internet]. [cited 2011 Apr]. Available from:
http://focus.ti.com/lit/ds/symlink/tlc5940.pdf.
9 Leone A. TLC5940 - Arduino TLC5940 Library. [Internet]. 2009 [cited 2010 Dec]. Available from:
http://students.washington.edu/acleone/codes/tlc5940arduino/html_r012/group__CoreFunctions.html.
10 GNU.org. Licenses - GNU Project. [Internet]. [cited 2010 Dec]. Available from:
http://www.gnu.org/licenses/.
11 ZETEX Semiconductors. N-CHANNEL ENHANCEMENT MODE MOSFET Datasheet [Internet].
12 RS. DesignSpark PCB. [Internet]. [cited 2011 Apr]. Available from: http://www.designspark.com/pcb.
13 National Semiconductor. LM1575/LM2575/LM2575HV SIMPLE SWITCHER 1A Step-Down Voltage
Regulator Datasheet [Internet]. 2011 Mar.
14 National Semiconductor. LM35 Precision Centigrade Termperature Sensor Datasheet [Internet].
15 Glolab Corporation. How Infrared motion detector components work. [Internet]. [cited 2011 Apr]. Available
from: http://www.glolab.com/pirparts/infrared.html.
16 e-qstore. eBay My World: e-qstore. [Internet]. [cited 2011 Mar]. Available from:
http://myworld.ebay.co.uk/e-qstore/.
17 Greiman W. sdfatlib - A FAT16/FAT32 Arduino Library for SD/SDHC cards. [Internet]. [cited 2011 Feb].
Available from: http://code.google.com/p/sdfatlib/.
18 Arduino. References - SD. [Internet]. [cited 2011 Apr]. Available from: http://arduino.cc/en/Reference/SD.
Page | 49
URN: 6025977
19 Rapid Electronics. Cables & Connectors. [Internet]. [cited 2011 Apr]. Available from:
http://www.rapidonline.com/Cables-Connectors/Cables/Conduit-And-Trunking/Miniaturetrunking/74246/kw/04-5571.
20 boblight. Boblight - google code. [Internet]. [cited 2011 Mar]. Available from:
http://code.google.com/p/boblight/.
21 topbrightledstore. [Internet]. [cited 2010 Dec]. Available from: http://stores.ebay.com/topbrightledstore.
22 AP15N03H datasheet. [Internet]. [cited 2010 Dec]. Available from:
http://www.alldatasheet.com/datasheet-pdf/pdf/134269/A-POWER/AP15N03H.html.
23 RS Components. RF-Solutions - ALPHA RF Transceiver Module 433MHz. [Internet]. [cited 2010 Dec].
Available from: http://uk.rsonline.com/web/search/searchBrowseAction.html?method=getProduct&R=6666757.
24 RS Components. Wireless Solutions - XBee RF Module with Whip Antenna. [Internet]. [cited 2010 Dec].
Available from: http://uk.rsonline.com/web/search/searchBrowseAction.html?method=getProduct&R=0102721.
25 Philips. [Internet]. [cited 2010 Dec]. Available from:
http://www.philips.co.uk/c/televisions/33092/cat/#/difference/ambilight.
26 Philips. [Internet]. [cited 2010 December]. Available from:
http://www.philips.co.uk/c/televisions/33092/cat/#/difference/ambilight.
27 Wippler JC. About - The JeeLabs Shop. [Internet]. [cited 2010 Dec]. Available from:
http://jeelabs.com/pages/about.
28 speedyPCB.com. PCB Terminology. [Internet]. [cited 2011 Apr]. Available from:
http://www.speedypcb.com/pcb-knowledgeBase/pcb-terminology.htm.
Page | 50
URN: 6025977
APPENDIX
// ATmega328, etc.
#define RFM_IRQ 2
#define SS_PORT PORTB
#define SPI_SS 5
#define SPI_MOSI 11
#define SPI_MISO 12
#define SPI_SCK 13
APPENDIX FIG 1 - DEFAULT PINOUTS - EXTRACT FROM JEELABS RFM12 LIBRARY
0
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
8
10
10
10
10
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
no
no
no
no
no
no
no
no
no
0
0
0
0
0
0
0
0
0
0
0
0
0
6
5
10
8
10
10
10
10
Line of Sight
Direction 2
Packets Lost / 10
Line of Sight
Packets Lost / 10
Distance (m)
Direction 1
yes
yes
yes
yes
yes
yes
no
no
no
no
no
no
no
no
no
no
no
no
no
no
no
APPENDIX FIG 2 - TABLE OF RESULTS FOR WIRELESS RANGE EXPERIMENT
Page | 51
URN: 6025977
APPENDIX FIG 3 - MOSFET TRANSFER CHARACTERISTSICS GRAPH [11]
APPENDIX FIG 4 - DRIVER PCB SCHEMATIC
Page | 52
URN: 6025977
APPENDIX FIG 5- LED BAR POWER BOARD PCB SCHEMATIC
APPENDIX FIG 6 - STEP DOWN VOLTAGE REGULATOR PCB SCHEMATIC
APPENDIX FIG 7 - MASTER PCB SCHEMATIC
Page | 53
URN: 6025977
APPENDIX FIG 8 - FRONT PANEL PCB SCHEMATIC
Page | 54
URN: 6025977
THE PHOTOGRAPHY RIG

Here is a photo of the rig setup to take shots of the finished products:
I thought it may be of interest.
URN: 6025977

Lightive - Eviroment Aware Lighting System - Project Report Louis Christodoulou

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lightive - Eviroment Aware Lighting System - Project Report Louis Christodoulou

Uploaded by

Copyright:

Available Formats

Although many of the currently available mood lighting products are distinctive when

Faculty of Engineering & Physical

Student Name: Louis Christodoulou

Module Code & Title: Level 3 Project

Person Responsible for Marking: Dr K Wells

Project Introduction ....................................................................................................................................... 1

The Idea A Personal Note ................................................................................................................... 1

Project Gantt Chart ............................................................................................................................... 2

What is Mood LIGHTING? ..................................................................................................................... 3

Notable Current Products ..................................................................................................................... 3

Project Design Phase ...................................................................................................................................... 5

The Lightive System Overview ......................................................................................................... 5

System Design and Functionality ...................................................................................................... 5

Ambient Awareness .......................................................................................................................... 5

Modular Platform ............................................................................................................................. 5

The Arduino Microcontroller platform ............................................................................................. 6

Wireless Communication .................................................................................................................. 6

Establishing Lightives Wireless Communications System .................................................................. 7

Initial Research ................................................................................................................................. 7

Testing the TRX433S Wireless Modules ............................................................................................ 8

Improving the Acknowledgement mechanism ............................................................................... 10

The Lightive Driver Design................................................................................................................. 12

Initial Design ................................................................................................................................... 12

SOFTWARE Design .......................................................................................................................... 13

Expanding PWM Using the TLC5940 ............................................................................................... 14

Using MOSFETs ............................................................................................................................... 14

Breadboard Prototype .................................................................................................................... 17

Design Development ....................................................................................................................... 17

Final Designs ................................................................................................................................... 18

The Lightive Sensor Design ............................................................................................................... 23

Initial Design ................................................................................................................................... 23

Design Development ....................................................................................................................... 25

Software Design .............................................................................................................................. 25

Final Design ..................................................................................................................................... 26

Initial Design ................................................................................................................................... 27

Design Development ....................................................................................................................... 27

Data Storage ................................................................................................................................... 28

Breadboard Prototype .................................................................................................................... 29

Final Design ..................................................................................................................................... 30

Project Build Phase ....................................................................................................................................... 32

The Lightive SD Card library ............................................................................................................ 32

The Lightive Radio Library ............................................................................................................... 33

Direct Output Functionality ............................................................................................................ 34

The Lightive Master Design ............................................................................................................... 27

Manufacturing the PCBs ................................................................................................................. 35

Soldering Techniques ...................................................................................................................... 36

The Driver ....................................................................................................................................... 38

Led Strips ........................................................................................................................................ 39

The Sensor ...................................................................................................................................... 41

The Master ...................................................................................................................................... 42

The System in Practice / Implementation .................................................................................................... 44

Key functionality and User Interface ................................................................................................... 44

Direct Out Functionality Ambilight ................................................................................................... 44

Soak Testing ........................................................................................................................................ 45

1.2 THE IDEA A PERSONAL NOTE

1.4 PROJECT GANTT CHART

System Design & Relevant research

Design and build a prototype driver

Coding for driver unit

Design PCB for driver unit

Etch and populate Driver board PCB

Exam Period and Mid Project report write

Design and build prototype for

Coding for Master Unit