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.