Original ArticleInternational Journal of Fuzzy Logic and Intelligent SystemsVol. 13, No. 2, June 2013, pp. 106-115http://dx.doi.org/10.5391/IJFIS.2013.13.2.106

ISSN(Print) 1598-2645ISSN(Online) 2093-744X

Design of Bi-directional RDM-DMX512Converter for LED Lighting ControlHung Nguyen Manh and Chang-Hoon LeeDepartment of Electronic Engineering, Pai Chai University, Daejeon, Korea

Abstract

LED lighting control system using unidirectional DMX512 (digital multiplex with 512 piecesof information)) protocol has been the most popular. Nowadays, the user’s consumption hasbeen upgrading to the more intelligent system but the upgrading process does not affect theexisting infrastructure. There were many researches use the additional communication forthe feedback communication way such as WiFi, Controller Area Network (CAN), PowerLine Communication (PLC), etc but all researches had inherent disadvantages that createdthe independent feedback with the existing DMX512 system. Our paper represents the novelmethod that uses the remote device management (RDM) protocol to associate the additionalfeedback with existent DMX512 infrastructure in the one system. The data in DMX512 framesending to the DMX512 client is split and repacked to become the RDM packet. This RDMpacket is transferred to the RDM monitor console and the response RDM packet is convertedto the DMX512 frame for control DMX512 client devices. This is the closed loop controlmodel which uses the bidirectional convertibility between RDM packet and DMX512 frame.The proposed method not only upgrades the feedback control function for the old DMX512system without changing the existent infrastructure, but also solves compatible problemsbetween new RDM devices and old DMX512 devices and gives the low cost solution forextending DMX512 universe.

Keywords: LED, Lighting control, Bi-directional converter, DMX512, Remote devicemanagement

Received: Jun. 8, 2012Revised : Sep. 18, 2012Accepted: Jun. 21, 2013

Correspondence to: Chang-Hoon Lee(naviro@pcu.ac.kr)©The Korean Institute of Intelligent Systems

cc© This is an Open Access article dis-tributed under the terms of the CreativeCommons Attribution Non-Commercial Li-cense (http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduc-tion in any medium, provided the originalwork is properly cited.

1. Introduction

The light is one of the most important elements of life and lighting technologies using LEDhave become our present and near future. DMX512 (digital multiplex with 512 pieces ofinformation) was the preferable control protocol for LED lighting control. However, over theyears, the user’s consumptions have been trending to be more intelligent and efficient system[1, 2]. These systems have been identified as critical research areas by the US Departmentof Energy which uses the bidirectional protocol with the feedback control loop. DMX512 isonly the unidirectional protocol. Hence, there were many researches that use the additionalmedia communication for the feedback control such as WiFi, Controller Area Network (CAN),Power Line Communication (PLC) or etc to improve the DMX512 system. Our researchgives a novel method using remote device management (RDM) protocol without affecting theDMX512 system. RDM is a protocol developed by Entertainment Services and TechnologyAssociation Technical Standards. RDM is the protocol enhancement to DMX512

| 106

International Journal of Fuzzy Logic and Intelligent Systems, vol. 13, no. 2, June 2013

that allows bi-directional communication between a lightingsystem controller and attached RDM compliant devices overa standard DMX512 line. Nowadays, more and more deviceshave been supporting RDM protocol.

The upgraded process arise problems about the compatibilitybecause there are both DMX512 devices and RDM devices inthe one system, namely, DMX512 devices cannot control RDMdevices and RDM devices also cannot control DMX512 devices.Therefore, the system needs the solution that makes the compat-ibility between two kinds of different equipments. This paper isa novel principle that focuses on discovering and applying newmethods of control and feedback in the DMX512 network. Themethodology is based on bidirectional converter between RDMpacket and DMX512 packet, the research designs devices thatmake the RDM devices and DMX512 devices to work togetherin the one system. Moreover, we have an additional solutionto extend the DMX512 universe. This solution is a lower costand simpler than others. It is suite for small number of theuniverse. Furthermore, this research also makes the new way toimprove the existent DMX512 network without changing theinfrastructure.

2. LED Lighting Control System

2.1 LED Lighting Control Protocols

A lighting control system consists of devices that controls elec-trical lighting and devices, alone or as a part of a daylight har-vesting system, for a public, commercial, or residential buildingor property, or a theater. In fact, most of LED lighting systemconsists of many lighting hence the system needs a protocol toconnect elements to become the network. There are a lot of theconnecting protocols for LED lighting control system [4].

KNX is a standardized, open source initiative (OSI)-basednetwork communications protocol for intelligent buildings andlighting control is the basic function. The KNX system is builtup by technically complex system parts which can be quiteexpensive. In most cases, special software is required whichincreases the installation cost. LonMark/LonWorks is a generalpurpose network using the LonWorks protocol and the Neuronchip but this protocol is not popular because it is the proprietaryand hardware is specific. BACnet is a data communicationprotocol for building automation and control networks for ap-plications such as heating, ventilating air-conditioning control,lighting control and their associated equipment. The systemis technically advanced and the need for specific knowledgeby the installer as well as specialized software is needed. Zig-

Data - 8

MTBP

IDLEBREAK

MAB

START BIT

STOP BIT

MTBP

START BIT

8 DATA BITS

STOP BIT

OTHER

CHANNELS

START CODE CHANNEL 1

Figure 1. DMX512 timing diagram. MTBT, Mark Time BetweenFrames; MAB, Mark After Break.

Bee is a wireless network standard, based on IEEE 802.15.4physical layer (PHY) and medium access control (MAC) sub-layer. The ZigBee network technology is based on the sevenlayer OSI model. Zigbee or any wireless protocol is not alwaysmore robust than the wired. Digital Addressable Lighting In-terface (DALI) is a digital communication protocol designedspecifically for lighting systems. DALI defines the system’smaximum size as 64 single units (individual ad-dresses), 16groups (group addresses) and the topology of the system canbe bus, star or a combination of these two, but a ring topologyis to be avoided. Power line carrier is a system for carryingdata on a conductor that is also used for electric power trans-mission. The distance, speed and interference in the power linecommunication technology have been developing.

Furthermore, DMX512 and RDM are two protocols whichare the most popular and dedicated for LED lighting control.

2.2 DMX512

The DMX512 standard, henceforward simply called DMX512or DMX, describes a data stream protocol over a balanced ca-ble pair. The data is sent from the master or a transmitter tothe slave or receiver. There can be multiple slaves, but onlyone master. One DMX master can send up to 512 channels ofdata. The combination of these channels is known as a frame.The DMX bus that connects the master to all slaves is calleda universe. When more than 512 channels of data are needed,additional universes (physical DMX ports) are needed. Thechannel numbers continue to add up further with each new uni-verse namely, universe 1 is from channels #1 to 512, universe 2is from channels #513 to 1024, etc.

The timing diagram at the Figure 1 shows that the bus isalways in one of these states. Idle state is no communication,the bus will be high. Break state is DMX frames beginningwith a negative transition of the bus after which the bus muststay low for 88 µs or more. Since one bit is normally 4µs,this is the equivalent of 22 low bits. DMX implementations

107 | Hung Nguyen Manh and Chang-Hoon Lee

http://dx.doi.org/10.5391/IJFIS.2013.13.2.106

Figure 2. Structure of the remote device management (RDM) packet[1].

would recognize the frame. Mark After Break (MAB) statefollows immediately the break signal. It is a high signal withthe duration of 2 bits. The start code and each of the channelsare 11 pulses wide including one start bit and 2 stop bits. Theinformation itself are 513 bytes, the first one being the start code,the next 512 bytes represent the DMX channels: one low bit(the start bit); eight bits of data, representing a number between0 and 255; two high stop bits. In a normal DMX system, thestart code data is all zeroes. The Mark Time Between Frames(MTBF) is the idle time with a high signal between channels.This pause is not required, but it is allowed to last as long asone second.

2.3 Remote Device Management

RDM (Remote Device Management) is a protocol enhance-ment to United States Institute for Theatre Technology (USITT)DMX512 that allows bi-directional communication betweenlighting with a system controller and attached RDM compliantdevices over a standard DMX line. This protocol will allowconfiguration, status monitoring, and management of these de-vices in such a way that does not disturb the normal operation ofstandard DMX devices that do not recognize the RDM protocol.

The Figure 2 shows that the Start code is 0xCC and Sub startcode field (1 byte) is 0x01. Message length field (1 byte) isthe length of the RDM packet. Destination UID field (6 bytes)is the destination address. Source UID field (6 bytes) is thesource address. Transaction number field (1 byte) is the number

Table 1. XLR-5 pinout

Pin Signal Description

1 Signal common Primary data link

2 Data 1- Primary data link

3 Data 1+ Primary data link

4 Data 2- Optional secondary data link

5 Data 2+ Optional secondary data link

of the transaction. Port ID/response type (1 byte) is the indexof the device’s port or the type of response packet which isACK, response packet, etc. Message count filed (1 byte) is theindex of the message in the session. Sub-device field (1 byte)is the description of the device in group. Message data blockfield is the data field. Check sum (2 bytes) is the check sum ofthe RDM packet. RDM communication can be broken downinto three types: discovery; uni-cast communication; broadcastcommunication.

2.4 RDM vs. DMX

We analyze similar and different points to find the convertiblemethod. The first similarity is timing and this is one of the mostimportant features of protocols. The DMX and RDM transmitdata over the bus at 250 kbit/sec. Therefore, every bit is 4µslong.

Similarities are about connector, electrical, cable and bothprotocols use types of the connector. The XLR-5 connector inthe Table 1 is more popular than RJ11 or XLR-3 connector. Theelectricity is EIA-485 voltage. These similarities make RDMand DMX512 to work together.

There are many differences between RDM and DMX. We listthem in the Table 2. The difference about the start code makesRDM devices and DMX devices can to interfere between themwithout collisions. DMX devices ignore the frame which has thedistinctive start code with 0x00 and RDM devices also ignorepackets which have the distinctive start code with 0xCC. Thebidirectional feature of RDM protocol is a improvement withunidirectional DMX so new functions such as status monitoring,automatic device discovery are only in RDM.

3. Bi-directional RDM-DMX Converter

www.ijfis.org Design of Bi-directional RDM-DMX512 Converter for LED Lighting Control | 108

International Journal of Fuzzy Logic and Intelligent Systems, vol. 13, no. 2, June 2013

Table 2. RDM vs. DMX512Index Feature DMX RDM

1 Start code 0x00 0xCC

2 Direction Unidirectional Bidirectional

3 Method Broadcast Broadcast, unicast

4 Address Slot DestID, sourceID

5 Networkdevice

No Yes (PortID, . . .)

6 Checksum No Yes (2 bytes)RDM, remote device management; DMX, digital multiplex.

0xCC Dest[0..5] Source[0..5] ParID DATA (<= 486 Bytes) CS(H) CS(L)

0x00 DATA (<= 486 Bytes)Additional

DATA(<=26Bytes)

CONVERTER

RDM

packet

DMX

frame

Figure 3. Remote device management (RDM) to digital multiplex(DMX).

3.1 Bi-directional Convertible Mechanism

When users upgrade the DMX system, there are many chal-lenges. The upgraded system needs the bi-directional commu-nication which has the closed feedback control loop but thisupgraded system does not affect the existing DMX512. More-over, when we upgrade the system DMX512 to the RDM, thereare two types of the independent devices in one system. Theasynchronous system is not good actuator. Hence, we proposethe convertible method between RDM packet and DMX512frame. If the convertible process is the RDM to DMX512, itreceives the RDM packet input, splits the data filed, repacksand transmits DMX512 frame output. If the convertible pro-cess is the DMX512 to RDM converter function, it receives theDXM512 frame input, splits the data from the slot, repacks andtransmits RDM packet output. The address of the converter canbe set by a hard switch or firmware.

The media communication of the RDM protocol is broadcastand unicast. If the convertible device is the RDM to DMX, ithas the RDM address for the communication with other RDMdevices in the system.

The RDM address includes 6 bytes for destination addressand 6 bytes for source address. When the converter receives

0xCC Dest[0..5] Source[0..5] ParID CS(H) CS(L)

Slot #512

DATA[0]

Slot #10x00

CONVERTER

Slot #i

RDM

packet

DMX

frame

Figure 4. Digital multiplex (DMX) to remote device management(RDM).

the RDM packet, the converter checks the type of packet. Ifthe type of packet is specification such as Discovery, Identify,Ack, etc the converter will reply by Respond DISCOVEY() orRespond msg(). The Discovery packet is the broadcast packetand its destination address is 0xFFFFFFFFFFFF. Identify, Ack,the others specific packet has the specific value of the CmdClsand ParID field. The other type of RDM packet is converted toDMX frame as shown in Figure 3. The RDM data field is split,repacked by DMX frame. However, the maximum number ofchannel in the DMX universe were 512 channels but in theRDM, 24 bytes were for the header and 2 last bytes were forcheck sum so maximum number of DMX byte contained inRDM data field which are 486 data bytes. Hence, we addressDMX slots from 1 to 486. We can change the DMX512 addressbut the number of address must be less than 468. The Figure4 demonstrates visually the process. The additional data isoptional.

If the convertible device is the DMX to RDM, the converterworks as DMX512 client and it also uses the DMX512 addressto receive the data. This address is set by a hard switch ora firmware. The DMX512 data is split from the slot that iscorresponsive with the setting address, repack by RDM packetto send to the RDM destination device. The Figure 4 showsvisually the method. RDM is the bi-directional protocol andit uses the method that is a session communication with replypacket.

We propose the algorithm to implement the converter. Thegeneral flowchart is showed in the Figure 5. Packets on thenetwork are captured by the converter. The structure of thepacket is analyzed and converted by the above principles. Thisfunction is selected by the hard switch or the firmware. Theconverter works as the RDM device or DMX device hence, wecan keep the existing infrastructure.

109 | Hung Nguyen Manh and Chang-Hoon Lee

http://dx.doi.org/10.5391/IJFIS.2013.13.2.106

DMX_to_RDM =

true

DMX_to_RDM_Converter()

SC = 0x00

RDM()

SC = 0x00

RDM_to_DMX_Converter()DMX()

-

+

+

- -

+

Figure 5. General flowchart of the converter.

DMX()

RDM_data[0]=DMX_data

RDM_transmit()

Figure 6. Digital multiplex (DMX) to remote device management(RDM) converter().

If the function of the device is DMX to RDM and the startcode is 0x00, DMX to RDM converter() function implementsthe convertible process for packet from DMX to RDM (Figure6):

DMX() function is the DMX transceiver (Figure 7). Re-ceived DMX data by DMX() assigns to the first RDM databyte. RDM transmit() function transmits RDM packet to thenetwork.

If the function of the device is not DMX to RDM and thestart code is 0x00, RDM to DMX converter() function is calledto convert from the RDM packet to DMX frame (Figure 8).

RDM() function is the RDM transceiver (Figure 9). ReceivedRDM data by RDM() assigns to the DMX frame by adding startcode 0x00. DMX transmit() function transmits DMX frame tothe network.

In this function, type of packet is detected by Destination ID(DestID) or parameter ID (ParID). If DestID = 0xFFFFFFFFFF,the packet is discovery packet and the RDM() responds byRespond DISCOVERY() function but if the packet is IDEN-TYFY or the others, the RDM() is responded by Respond msg()function that has a ACK packet so there is the problem that isthe RDM information output is slower than DMX informationinput. The proposed solution uses the FIFO buffer for DMX

BREAK = true

SC = 0x00Transmit_status

= true

DMX_transmit()

DMX_data =

DMX_Receive(Slot)

My_DMX_Addr = Slot

-

+

-

+

-

+

-

+

Figure 7. DMX() function.

RDM()

DMX_frame[]=0x00+RD

M_data_field[0..N]

DMX_transmit()

Figure 8. Remote device management (RDM) to digital multiplex(DMX) converter().

frame input to solve this problem.

3.2 Control and Monitoring

Although the DMX LED lighting control devices are avail-able as popular and commercial products, almost current sys-tems only provide actuation and do not exploit feedback controlusing monitor by the sensor data. We believe that it is importantand the upgraded DMX system needs the other media commu-nication for the feedback monitor. There are many researchesused the media communication as WiFi [5], PLC [6], CAN [7]or etc but it is not perfect. WiFi technology have disadvantagesabout the power supply, distance, noise. PLC technology havedisadvantages with the short circuit, noise, distance. The othersneed the additional infrastructure for communication. This isnot feasible in the practical. Moreover, all of them make theindependent feedback communication with DMX system andcannot become the intelligent closed loop control, namely, thelight at the area usually is created by many sources or DMX

www.ijfis.org Design of Bi-directional RDM-DMX512 Converter for LED Lighting Control | 110

International Journal of Fuzzy Logic and Intelligent Systems, vol. 13, no. 2, June 2013

BREAK = true

SC = 0xCC

Transmit_statu

s = true

RDM_transmit()Respond_DISCOVERY()

DestID[0..5]=

0xFFFFFFFFFF

ParID =

IDENTIFY

Respond_msg()

ParID = ACK

ACK_status = true;

-

+

-

+

-

+

-

+ +

-

+

Figure 9. RDM() function.

DMX controller DMX client Load

Sens

ors

RDM-

DMX512

converter

RDM controller

Figure 10. Model for proposed monitor: the node and network.

clients. The sensor data only shows the change of the lightwithout detecting which is a changeable source. The proposedconverter can upgrade the monitor function to create the intelli-gent closed loop control system for DMX512 system withoutchanging infrastructure (Figure 10).

This application also can be useful for many illuminationpurposes, such as indoor office, home and museum lighting oroutdoor lighting for a stadium and advertisements with multipurposes such as energy saving, art color render. The closedloop control system is monitor system which has the generalmodel.

The data from sensors are collected and data in DMX512frame transmitting from DMX512 controller to DMX512 clientalso are received by RDM-DMX512 converter. All of the dataare repacked to RDM packet and sent to the RDM monitorconsole. RDM monitor console can control DMX512 clientby inserted DMX512 frame. We propose the structure of thepacket as follow (Figure 11):

The data field includes N+3 byte for: 2 Bytes for the DMX512client address, 1 Byte for the data of the DMX512 client, NBytes for the collected data from the sensor. The number of databyte depends on every application, sensor and our applicationis 8 Bytes. This is one of the most different points of the paper

0xCCDest

[0..5]

Source

[0..5]ParID Data[0] Data[N+2] Checksum

Figure 11. Structure of RDM packet for the monitor.

because it can collect the data from every client DMX512 frameand the data from the sensors to support the closed loop control.

Hence, we combined the DMX to RDM method and thecollected sensor data to monitor the old DMX system withoutchanging existent infrastructure.

In the LED lighting control applications [8], we also proposethe method using light sensor to collect vital parameters of thelight as color temperature, intensity. The X, Y, and Z tristimulusvalues characterize color and they are linear-light quantities,proportional to optical power, that incorporate the wavelengthsensitivity of human vision but the almost light sensor onlygives R-G-B values so we compute the value X-Y-Z in the colorspace from the RGB information by the following equation:

X

Y

Z

=

0.3568 0.2889 0.2132

0.1173 0.9000 −0.06110.0095 −0.5294 1.6196

∗ R

G

B

(1)

The optimum transform for the ColorChecker illuminated byCIE D65 is determined to be this:

X

Y

Z

=

0.4287 0.4489 0.0493

0.1450 0.9623 −0.11670.0095 −0.4059 1.4191

∗ R

G

B

(2)

And then, we compute the x, y values for the Color Tempera-ture by equation:

x =X

X + Y + Z(3); y =

Y

X + Y + Z(4)

And then, based on the graph we can calculate the colorvalue [9].

McCamy’s formula [10] can be used to determine the cor-related color temperature (CCT) from the chromaticity coordi-nates.

CCT = 449n3 + 3525n2 + 6823.3n+ 5520.33, (5)

111 | Hung Nguyen Manh and Chang-Hoon Lee

http://dx.doi.org/10.5391/IJFIS.2013.13.2.106

DMX512 Client

#1

DMX512/RDM

Converter

#1

DMX512/RDM (RS485)

DMX512 Client

#2

RDM Client

#2

DMX512/RDM

Converter

#N

RDM Client

#N

DMX512

Console

RDM Monitor

Console

Figure 12. Network model of the application for the compatibility.

wheren =

x− 0.3320

0.1858− y. (6)

CCT is basically a description of whether the light is bluish-white, neutral, or reddish white.

The frequency sent to us by the chip correlates to a particularamount of radiant energy being received by it. We need toconvert it to a more useful representation, and the target isa measurement of micro-watts (uW) per centimeter squared(cm2

).

This application can solve many practical problems. For ex-ample, when a zone contains more than one workplane, lightingfrom Illumination Fields may overlap and influence other work-planes. Consider the simple scenario for a zone which havetwo workplanes. The first workplane requires 500 lux and thesecond workplane requires 350 lux. When the first workplaneturns on, the sensor at the second workplane detects 88 lux, sowe need to provide 262 lux for the second workplane to archive350 lux but this spill over to the first workplane becoming 550lux. Therefore, we will compute value until the required levelsare reached for both workplanes using small increasing steps.

3.3 Crossover Control and Extending

In fact, almost user can not upgrade all DMX512 devices inone time. Hence, there are usually both DMX512 and RDMdevices in the network. Although DMX512 devices have nocollision with RDM devices, they cannot transfer the informa-tion together, for instance, DMX512 devices cannot control orreceive the command with RDM devices. RDM devices alsocannot control or receive DMX512 frame. So, there are twosub-systems in the one infrastructure. Now there is no solutionto solve this problem but the proposed converter can do this.The DMX512 console device transmits DMX512 frames tothe converter. The converter splits and converts this DMX512frame to RDM packet and transmits it to the RDM client device.Hence, DMX512 console can control the RDM client via theconverter (Figure 12).

Similarly, the RDM console device transmits RDM packet

DMX512

device

DMX512/RDM (RS485)

RDM/DMX512

converter #N

RDM/DMX512

converter #1

RDM Console

DMX512

Client #N-N

DMX512

Client #N-1

DMX512

Client #1-N

DMX512

Client #1-1

DM

X5

12

DM

X5

12

DMX512

universe(<=

486 channels)

Figure 13. Network model of the application for extending.

to the converter. The converter converts the RDM packet toDMX512 frame and retransfers to the network. All devices inthe system become compatibly together. In this application, wecombined RDM to DMX and DMX to RDM function in onedevice.

Over the years the requirements about number of devicesin DMX512 system grew up more than 512. There are twosolutions to solve this. The first solution uses the multi-universeDMX512 console devices such as Chamsys MagicQ MQ200pro up to 32 universes, stand 200 plus or etc. The secondsolution is DMX512 with other high speed protocols such asArtnet, CAN, etc. The console device uses the high speedstream such as WiFi, Ethernet, etc which includes many lowspeed DMX512 stream inside. The converter gives additionalsolution to solve the problem. If we separate the RDM inputand DMX512 output of the converter, we can extend the numberof the DMX512 universe. RDM console device send the RDMpacket which includes DMX512 data inside to the converter.The converter transfers DMX512 frames to the other universe.Compared with the other solution, this solution is simpler, lowercost than others. It can accommodate applications that havefew DMX universes. We apply RDM to DMX method but weseparated the RDM input and the DMX output (Figure 13).

4. Experiments

4.1 Experiment 1: RDM to DMX

To test this experiment, we use the model (Figure 14).DMX console is DMX transmitter with the 0 value (other

value is OK) which transmits a DMX frame to the converter. Inthe paper, we use the open source DMX console for the standard

www.ijfis.org Design of Bi-directional RDM-DMX512 Converter for LED Lighting Control | 112

International Journal of Fuzzy Logic and Intelligent Systems, vol. 13, no. 2, June 2013

RDM monitor

DMX console: Mode: Send-Refresh rate = 1 Hz. DMX Value = 0

DMX frame RDM packet

DMX/RDM network

uC = ATmega8

Max485

Tx Dir Rx

Figure 14. Model and result of experiment 1.

DMX frameRDM packet

DMX/RDM network

uC = ATmega8

Max485

Tx Dir Rx

DMX monitor

Figure 15. Model and result of experiment 2.

test. The RDM monitor is the terminal software to display theRDM packet on the screen of the PC. We can see bytes ofRDM packet: Start code of packet (SC) is 0xCC, address of thedestination device (DestID) is 0x194164FF0000 and addressof the source device (SourID) is 0x011200000000, etc, DMXdata value is 0x00, two bytes for check sum are 0x02E1. Itmeans that the DMX data converts to the RDM packet by theconverter.

4.2 Experiment 2: DMX to RDM

RDM transmitter is the above converter or Open RDM softwarewhich transmits the standard RDM packet to the uC module.uC module receives the RDM packet, splits the data field andrepacks to become the DMX512 frame. We can look at theright side of the figure to see that the DMX data which is insidethe RDM data field showed by DMX monitor (Figure 15).

4.3 Experiment 3: Monitor

In this application we use the light sensor that is TCS3200D tomeasure vital parameters of light (Figure 16).

The datasheet of TCS3200D [11] shows us a graph of thespectral responsiveness. The graph shows us that at a wave-length of 640nm, and 1x sensitivity and the relationship betweenuW/cm2 and the frequency is a ratio of 1:10. The energy is1/10th the frequency-uW/cm2 = Freq/10. An important point isthat the actual sensor has an area of about 0.0092 cm2.

R, G, B and

Area of sensor ~

0.0092 cm2

Color measure

Multi-wavelength

Energy measure

(Lux, . . . )

Exposure value

caculation

Figure 16. Applications of the light sensor.

Figure 17. Network model and the result of experiment 3.

The testing modules are TCS3200 sensor and microcontroller.The light source is seven 5mm red LEDs and the distance isabout 2.5 cm (Figure 17).

The result shows that the experiment can receive the datafrom the light sensor and send it to the RDM monitor by RDMpacket. The frequency of red-blue-green is 290 cd*m2 - 60cd*m2 - 130 cd*m2 because the sample duration is 0.1s. Wecalculate XYZ by the Eq. (2), [X Y Z] = [151.8979 84.617162.884]. And we have x and y values by Eq. (3) and Eq. (4), x= 0.380316; y = 0.021186. By using the Chromaticity Diagramwith Planckian Locus [9], we can see the color of the lightsource is the red. By applying to Eq. (5) and Eq. (6), we cancalculate the CCT of the light source is that n = - 1855, CCT ˜1198 K.

In this model, the power of LED module is controlled byDMX512 client and light parameters as R-G-B frequencies aremeasured by the light sensor - TCS3200D. Parameters are sentto the RDM monitor console by the RDM packets. We canadd or remove the additional monitor system without effect toDMX512 devices.

113 | Hung Nguyen Manh and Chang-Hoon Lee

http://dx.doi.org/10.5391/IJFIS.2013.13.2.106

DMX512

Analyzer

(Transmitter)

DMX512/RDM

Converter

#1

DMX512/RDM (RS485)

DMX512

monitor

software

RDM Monitor

Console

Figure 18. Network model for experiment 4.

uC

(Atmega8A)UART-

485

R

D

DIR

Rx

Tx

Ctrl

A

BRS485 bus

DMX512/RDM

packet

RDM/

DMX512 packet

Figure 19. Converter, DMX512 analyzer and the result of experiment4.

4.4 Experiment 4: Crossover Control

We use the experimental network model with 4 elements totest the experimental cross control (Figure 18). If there aremore than 4 elements, the system works well but the result isobserved difficultly.

In this model, DMX512 analyzer (transceiver): open DMX512hardware which transmits DMX512 data to the network.

DMX512 monitor is the open source client software withUSB dongle. This software shows the received DMX512 dataon the screen of the PC.

RDM monitor console is the proposed software to displaythe received RDM data on the screen.

RDM-DMX512 converter is the proposed hardware (Figure19).

The result shows that the DMX512 data is converted to theRDM packet by the converter and the data field of the RDMpacket is converted to the DMX frame. It receives the DMX512data from slot 11 (data = 131) to convert the DMX512 datato RDM packet and sends the RDM packet to network. Theconverter works as the transponder with one port for RDMpackets and DMX frames.

4.5 Experiment 5: Extension

We also use the model with four elements to test the experimentabout the DMX512 universe extension (Figure 20).

RDM controller

DMX512/RDM (RS485)

RDM/DMX512

Converter #2

DMX512

Client #2-N

DMX512

Client #2-1

DM

X5

12

(RS

48

5)

Figure 20. Network model for the experiment 5.

uC

ATmega128UART0

UART1

UART-

RS485

UART-

RS485

Figure 21. Converter and result of experiment 5.

We use Atmega128 because the microcontroller has twoUART ports (Figure 21). In this experiment test, we use UART0to receive RDM packet input and transfer the DMX512 frameoutput by UART1 port. In this application, we use the 2048bytes for the input buffer.

We transmit the RDM packet which includes DMX512 data(value = 35). We split, repack and show the data on the screen ofthe PC. It means that we extended the number of the DMX512universe.

5. Conclusion

The paper represents the novel method to convert the structureof DMX512 frame and RDM packet. In the monitor application,

www.ijfis.org Design of Bi-directional RDM-DMX512 Converter for LED Lighting Control | 114

International Journal of Fuzzy Logic and Intelligent Systems, vol. 13, no. 2, June 2013

the convertible process between RDM packet and DMX frameis combined with the light sensor to upgrade the unidirectionalDMX system to the intelligent bidirectional system withoutchanging the existent infrastructure. Moreover, the flexibleapplication of the bidirectional convertible method betweenRDM packet and DMX frame also solves the compatibility andextension of the DMX universe. Experimental result showsthat the proposed method has many meaningful applicationswhich we can apply for the LED lighting control system. Thismethod also opens the new direction to upgrade new intelligentfunctions for DMX512 system without changing the existentinfrastructure.

References

[1] ANSI E1.20-2010.Entertainment Technology-RDM-Remote Device Management over USITT DMX512Networks, January, 2011.

[2] J. N. Choi, J. Y. Baek, and S. K. Oh, “A study on intel-ligent dimming converter of fluorescent lamp,” Journalof Korean Institute of Intelligent Systems, vol. 17, no. 4,pp. 540-545, Aug. 2007. http://dx.doi.org/10.5391/JKIIS.2007.17.4.540

[3] S. K. Oh, S. J. Lim, C. M. Ma, and J. Y. Kim, “Devel-opment of RGBW dimming control sensitivity lightingsystem based on the intelligence algorithm,” Journal ofKorean Institute of Intelligent Systems, vol. 21, no. 3, pp.359-364, Jun. 2011. http://dx.doi.org/10.5391/JKIIS.2011.21.3.359

[4] The IES Controls Protocols Committee, “Lighting con-trol protocols,” Available http://www.ies.org/PDF/Store/TM-23-11 FINAL.pdf

[5] H. Park, J. Friedman, P. Gutierrez, V. Samanta, J. Burke,and M. B. Srivastava, “Illumimote: multimodal and high-fidelity light sensor module for wireless sensor networks,”IEEE Sensors Journal, vol. 7, no. 7, pp. 996-1003, Jul.2007. http://dx.doi.org/10.1109/JSEN.2006.886999

[6] C. Li, J. Wu, and X. He, “Realization of a general LEDlighting system based on a novel power line communi-cation technology,” in 2010 24th Annual IEEE AppliedPower Electronics Conference and Exposition (APEC),

Palm Springs, CA, 2010, pp. 2300-2304. http://dx.doi.org/10.1109/APEC.2010.5433557

[7] F. Tian, X. Wu, and J. Liu, “Research and realization ofLED display system based on combining CAN bus withDMX512 standard,” in Proceedings of 2008 InternationalConference on Audio, Language and Image Processing,Shanghai, 2008, pp. 813-818. http://dx.doi.org/10.1109/ICALIP.2008.4589986

[8] Y. K. Kim, O. S. Kwon, Y. W. Cho, and K. S. Seo, “Ge-netic programming based illumination robust and non-parametric multi-colors detection model,” Journal of Ko-rean Institute of Intelligent Systems, vol. 20, no. 6, pp. 780-785, Dec. 2010. http://dx.doi.org/10.5391/JKIIS.2010.20.6.780

[9] C. Poynton, “Sensing color with the TAOS TCS230,”Available http://www.ams.com/jpn/content/download/251588/993243/version/1

[10] C. S. McCamy, “Correlated color temperature as an ex-plicit function of chromaticity coordinates,” Color Re-search & Application, vol. 17, no. 2, pp. 142-144, Apr.1992. http://dx.doi.org/10.1002/col.5080170211

[11] Texas Advanced Optoelectronic Solutions Inc.,“TCS3200, TCS3210 programmable color light-to-frequency converter,” Available http://www.dfrobot.com/image/data/SEN0101/TCS3200%20TCS3210.pdf

Hung Nguyen Manh received the M.E de-gree in electronic from Pai Chai university,Korea, in 2012. His current research inter-ests are control hardware design and sen-sor network in embedded system. E-mail:hungnm@pcu.ac.kr

Chang-Hoon Lee received the Ph.D de-gree in system science from Tokyo Insti-tute of Technology, Japan, in 1999. He iscurrently an associate professor in the De-partment of Electronic Engineering at thePai Chai University.

Research Area: lighting control system, robot auditory system,human-robot interaction, soft computing, embedded system.E-mail: naviro@pcu.ac.kr

115 | Hung Nguyen Manh and Chang-Hoon Lee