Today’s solid state lighting market is moving rapidly, as the demands of lighting control systems have changed from controlling luminance for a single LED to controlling three (RGB) or four (RGBW or RGBA) LEDs. The challenge that this brings with it is not only the control of luminance, but also that of color balance between the 3 or 4 LEDs within the lighting system. To help designers achieve this, Freescale Semiconductor has produced a lighting reference design consisting of both embedded hardware and a PC/Windows- based GUI, allowing color balance selection via either sRGB or CIE 1931 color spaces and direct control of the LEDs.
Source: Freescale Semiconductor
The embedded hardware consists of three printed circuit boards: the LED controller board, based on a Freescale ColdFire MCF52259 MCU, the LED driver board, based on a Freescale MC13213 MCU, delivering up to 1.5A of constant current per LED (max. 4) via the National Semiconductor LM3406, and the LED daughter-board, based on four (RGBW) Philips Lumileds Luxeon Rebel LEDs that plug into the LED driver board, complete with optical diffuser and reflector assembly.
In Figure 1, the LED controller board uses a USB interface (black cable shown top right) to connect to the PC-based lighting reference design GUI and also acts as a supply power to the LED controller board.
The software for the application consists of three parts:
The LightingDemo.exe application running on the PC.
The software running on the Controller board
The software running on the LED driver board
The software on the Controller and LED driver boards can be modified to use only the DMX-512A-RDM protocol, or only the DALI protocol.
Some source code files are shared between Controller and LED driver board implementations. For example, the file dmx_support.c contains support routines used by both boards for DMX-512.
DMX-512A and RDM implementation The DMX-512A protocol can be divided into two parts. In standard DMX-512A, each slave device has a start address in the range 1 – 512, and a footprint of one or more ‘slots’. Primary control is achieved by the controller broadcasting NULL Start-Code packets containing up to 512 slot values.
For added reliability, DMX-512A controllers can interleave the NULL Start-Code packets with System Information Packets (SIPs), which allow a checksum to be appended to the NULL Start-Code data.
The Remote Device Management protocol (RDM) is an extension to standard DMX-512A. It allows the controller to send multi-byte messages to an individual slave, and also to get multi-byte replies. In addition, it allows the controller to discover which devices are connected to the DMX-512A network.
The application software on the controller board implements both DMX-512A with SIP support, and RDM. RDM is used to find out which slave devices are connected, asks them for detailed information about their capabilities, and assigns DMX-512A start addresses.
See Freescale lighting reference design details
A DMX-512A/RDM slave consists of a Root device and optionally, one or more sub-devices. The LED driver board software implements one sub-device, used to control a single multi-color LED package. In principle, the software could easily be adapted to support multiple sub-devices.
The DMX-512A/RDM implementation on the LED driver board supports two RDM personalities:
(a) PERSONALITY_xyY_CONTROL When configured via RDM to use this personality, the LED driver board has a footprint of a single DMX-512A slot. The controller uses the slot to send a CIE 1931 Y luminance value (0 – 255), and sends the (x,y) chromaticity values using a separate RDM command.
(b) PERSONALITY_DIRECT_CONTROL In this personality, the LED driver board has a footprint of up to four DMX-512 slots, one for each channel that the LED supports. For example, a LED with three primaries Red, Green and Blue will have a footprint of three slots. The values in the DMX-512 slots are in the range 0-255 and correspond to 0 – 100% duty cycles.
DALI implementation on the Controller and Slave Boards On both controller and LED driver boards, DALI data is sent and received using a GPIO port. Data is sent using a routine which tightly controls the timing of the generated bi-phase signal to match the DALI specification.
Data is received by using an interrupt service routine which over-samples the signal. The signal has a frequency of 1200 bits per second, but it is bi-phase encoded, so there are 2400 phases per second. The interrupt frequency is 9600 sample per second, 4 samples per phase. Software compares the samples to ensure that they match. Because the received signal may vary slightly in frequency or duty cycle, software considers a match of 3, 4 or 5 samples to be acceptable.
The DALI protocol is really designed for controlling single-color lights, which it calls ‘ballasts’. The controller can instruct individual ballasts to light up, change to a specified power level and fade up or down. Ballasts can also be addressed as groups instead of individually, or added to pre-set scenes. The DALI protocol also includes a means for the controller to discover which DALI slaves are connected.
DALI commands from controller to slave are two bytes long, and replies from slave to controller are a single byte (many commands don’t result in a reply). Each DALI slave has a unique Short Address in the range 0 – 63.
The DALI implementation used by the controller and slave is standard in all respects except for one extension; the standard DALI protocol does not include any way for a controller to instruct a LED to change color rather than brightness, so a way is needed to achieve this. Since this is the way all DALI devices work, it is possible to use a Freescale DALI controller with non-Freescale DALI slaves, and it means that a Freescale slave looks like a standard ballast to non-Freescale controllers.
In order to convey chromaticity information, the Freescale implementation uses a backdoor route to extend the command set. The backdoor makes use of a standard DALI command DATA TRANSFER REGISTER and is invisible to non-Freescale DALI devices.
Because DALI commands are only two bytes long, all DALI slaves implement a Data Transfer Register (DTR). In order to program a setting such as the power-on level of a ballast, the DALI controller sends two 2-byte commands:
Store 99 in the DTR DATA TRANSFER REGISTER, 99
The backdoor command to set chromaticity information relies on the fact that setting the DTR to one value and then another (without any intervening commands), is both harmless and pointless. No other DALI controllers are likely to do it and it has no effect on normal DALI slaves.
In order to send chromaticity information, the controller sequences the DTR through a secret multi-character backdoor key to alert the LED driver that a chromaticity command is coming. It then uses the DTR to communicate the (x,y) chromaticity coordinates to the LED driver.
When invoked, the lighting reference design GUI checks the status of a DALI/
DMX-512A switch on the LED controller board. This switch defines whether the DALI or DMX-512A interface will be used to communicate to any LEDs connected to the controller board. The DALI specification allows for a theoretical maximum of 125 LEDs to be attached, whereas the DMX-512A specification, as the name suggests, allows up for up to 512 LEDs to be controlled. The GUI will then scan the system to see how many LEDs are present.
Each LED daughter-board contains a thermistor placed as close as possible to the LED array. Using manufacturer-provided data, the LED junction temperatures can then be calculated on the MC13213 and the LED controller board can limit the power delivered to each LED to maximize LED lifetime. The real-time thermistor data is collected via the ADC module on the MC13213 and updated over DMX-512A/RDM around once a second.
The lighting reference design details—schematics, bill of materials, source code and PC-based software—are all available on either the Freescale website or element14.