This article describes the development of a two-wire home LED
lighting control system as a reference design to help explore
opportunities for using control technology to make designs more
sustainable.
The system was to be programmed using standard PC interfaces, but
we also set ourselves the challenge of creating an iPhone
application as an alternative. The project also demonstrates the
efficacy of a power line control protocol that runs over a 24Vdc
line.
The design brief was to develop a low-voltage LED colour lighting
system that could be retro-fitted into existing standard housing as
a replacement for, or enhancement to, conventional lighting. The
system was required to use only two wires both for the low-voltage
power supply and the control signals.
Hardware architecture
The system is operated using one or more master controllers which
address a number of slaves, and each slave controls clusters of
three RGB/white LEDs. As part of the development, we produced both
PC and iPhone applications to address the master via a wireless
LAN.
The slaves are connected to the master using a two-wire 24V supply,
and each slave is capable of controlling the colour and brightness
of up to 50W of LED illumination from data command signals
superimposed on the power line. A master unit injects control data
onto the low-voltage supply line controlling the slaves using the
PLC protocol. Each master can control two strings, each with 16
slaves.
These strings can be wired in parallel, so that each slave produces
the same colours, or in series, allowing slaves to produce
different output colours. No earth is required, and there are no
separate control lines.
The PLC protocol can be implemented over a number of different
hardware platforms. For example, using a Cypress Semiconductor
power programmable system on chip (PPSoC) the slave could offer
shared conductors for power and control.
As a PPSoC has four channels it would be possible to drive four
LEDs from a single device (red, green, blue and white) – previously
this would have required four separate LED drivers and a control
IC.
On-chip FETs are used to drive the LEDs, and the integrated
processor core is used for housekeeping and decoding the MLE
control signals. An on-chip buck converter allows the PPSoC to be
powered directly from the low-voltage wiring.
The master units feature an Atmel ARM 9 implementation driving a
Cypress PSoC that interfaces directly to the slave units.
iPhone application
We selected the iPhone as the basis for this particular technology
demonstrator, partly based on the flexibility of its user
interface.
The design exploited the fun side of the user interface in this
application. It uses touch-sensitive sliders to set different
colour levels, and uses the accelerometer feature to create random
shake effects and to offer a tilt control as an alternative to the
sliders. Colour wheel combinations were also available.
To carry out the development, designers must be registered as an
iPhone App Developer – providing access to development support from
Apple, such as APIs and example code. iPhone development can only
be done on an Apple Macintosh, so the project was developed in an
OS X environment and written in the Apple version of Object
Oriented C.
Before taking an iPhone App to market, there is the necessary step
of registering it with the Apple iStore.
Although it is an additional piece of work, the iStore is a
marketing gateway to a huge base of potential customers.
Other smartphone options
We also considered extending the application to other smartphone
environments.
Symbian applications can be written in C++ or Java, so the main
challenge would be working with the constraints of the device and
building something that can be supported on most of the phone and
PDA hardware on the market, despite varying performance, screen
size and input methods.
The Blackberry is the next biggest player, and the Java application
could potentially be ported into the RIM Blackberry device, though
this device has its own Java Virtual Machine, so some development
effort would be required. Blackberry hardware is more standard than
Symbian, though there are a number of variations in this
platform.
The Java application could also be ported to Windows Mobile, or
alternatively parts of the PC application could be reused. The PC
application we built for our demonstration would not be directly
portable to Windows Mobile as it was written using .Net.
Some parts of the PC application (the libraries and some of the
code) could be reused, although the user interface that would need
to be redesigned completely, again taking into account a range of
different hardware platforms.
An emerging alternative is Google’s Android OS. Over the coming
months there will be more phones released running Android.
Android’s development is based on Java, so some of the code may be
portable from a Symbian implementation.
Another approach would be to design a web-based application so that
any device capable of web browsing would be able to use it.
However, this would eliminate the opportunity to implement the
“cool” features of our iPhone app.
There are a number of emerging development environments that allow
developers to target multiple phone environments with minimal
effort. However, the extent to which they are suitable for a
control environment requiring access, for example, to the
hardware’s wireless LAN interface remains to be seen.
Were we to take the reference design forward into a real project,
we could readily develop an application targeting some or all of
these additional environments if required.
Authors are Carl Matthews, a senior software engineer, and Jon
Reece, a software engineer, at
ML Electronics.