If the nodes that control the power to the light strings and fixtures will be networked, that requires some type of communication medium (wire or wireless) and a protocol for communicating with the nodes.
Most people when they hear you want to network something instantly think ‘Ethernet‘. What many people don’t realize is that there are often better methods to network something in a local environment that doesn’t require Ethernet’s power and speed. Consider what kind of data will go across this network. We’ll be telling the nodes simple things like ‘Channel 4, Level X’ where X might be between 0 and 255. We aren’t transmitting War and Peace. If all we need to transmit are simple channel IDs and light levels, do we really need all the overhead of a normal TCP/IP packet?
Another common setup for controlling lights is the X-10 power line protocol. Signals are sent directly over the powerline to remote modules which can dim lights and turn electrical devices on and off. Many people don’t care for X-10 because they feel it is unstable and prone to false events (lights turning on by themselves, commands never reaching their destination, etc). If you buy a few X-10 modules and toss them in your home, you likely will see this type of behavior. Many modern appliances and electronics inject noise onto your home’s power grid. X-10 signals are also a form of ‘noise’ injected into the power lines of your home so you can see why extraneous noise could cause issues. However, by installing devices like an X-10 bridge, amplifier, and noise filters, you can have a VERY reliable X-10 setup in your home. I have all these devices and control a number of lights with X-10. I can’t recall the last time a light failed to go on when commanded or turned off on it’s own. So X-10 can be setup in a reliable way and could easily be used to control Christmas lights and other things. Another benefit is there’s no need to run control wires since the control signals travel over the powerline.
Why then, don’t we use it for the light display? In a word: latency. X-10 is a SLOW protocol. Bits are transmitted at the zero crossing of the AC power cycle which is 120 times a second (60 Hz and two zero crosses per wave cycle) for a data rate of 120bps. If we want to have the lights going on and off quickly and even flashing, X-10 can’t react fast enough to handle that. You also can only transmit commands one at a time and given the data rate, you couldn’t have lights appear to come on at the same time while still being separately addressable. So X-10 is out.
Wireless control is another possibility. However, the self contained modules tend to be a tad expensive and you also run the risk of interference from other devices on the common frequencies. While not running wires would be cool, there isn’t a pressing need to go wireless since we’ll already have extension cords running all around.
I have some experience in home automation design and will let you in on a secret. One of the most robust and simple signaling networks for controlling ‘devices’ is called RS-485. RS-485 is often mistaken as a protocol when, in fact, it is a signaling standard which various serial protocols are sent with. The standard lays out a signaling method ideal for harsh environments and for data that must travel significant distances without the use of repeaters. Ethernet is good over copper to around 300ft. RS-485 can be used up to 4000ft. It also is a much simpler network to wire. A simple twisted pair of wires is all you need. Instead of having to ‘home run’ the cables like Ethernet, you daisy chain the devices. This makes RS-485 ideal for industrial control networks where devices are spread across a factory floor and in our case where the nodes will be spread across the property. Simply run the twisted pair cable from device to device. Thus each ‘node’ simply needs an AC power feed and a twisted pair control wire from the nearest node.
[RS-485 Network Topology from lammertbies.com]
Another benefit of RS-485 is that it is used for serial protocols. Serial protocols are very easy to implement and significantly reduce the hardware and software overhead involved. Since we’ll have remote devices to control the lights, the simpler they are, the easier they’ll be to design and they’ll be less expensive. If the CPU in the remote device simply needs to receive bits and process the byte data, it can be a fairly lightweight CPU. Ethernet has much more overhead and requires more advanced hardware to process.
Many people don’t like RS-485 because they feel it is unreliable, though it is a defacto standard in industrial control where reliability is paramount. More often than not any instability is due to improper implementation. RS-485 signaling requires the nodes (up to 32) be daisy chained. You cannot have a star or tree topology in RS-485. Sounds pretty limiting. However, you can use devices like RS-485 hubs (see photo) which create individual daisy chained segments on an RS-485 network, allowing for more than 32 total devices and topologies like stars and trees. The network also must be properly terminated at each end of a segment to prevent signal reflections down long cable runs. If proper guidelines are followed in the implementation, RS-485 is a very robust and stable setup. Many of the commercial animated lighting control systems available from places like Light-O-Rama and Animated Lighting use RS-485 between the controller board and the remote light control boards. Much of my automation background involved RS-485 devices so it makes sense to use it in our display.
So we’re looking at an RS-485 network utilizing some type of serial protocol to control lights connected to remote ‘nodes’. Wouldn’t it be nice if someone had already done that?
Turns out, they have. For years, stage lighting systems have utilized a protocol called DMX which is sent via RS-485. The lighting control consoles send commands to remote light control boxes, often far away up on stage, to control the show lights and accessories. Simple twisted pair cable is used and since the remote nodes can be daisy chained, it makes setup a breeze. Imagine having 8 control boxes up in the rafters - it’s much easier to daisy chain them vs. home run them like Ethernet. By utilizing such an established protocol, not only can we rely on a wealth of knowledge out there, we can also leverage an entire markets worth of products (stage/DJ lighting) in our display. This makes using the DMX protocol very appealing.
So what exactly is DMX? It is a surprisingly simple protocol. Up to 512 ‘channels’ are set to a ‘brightness level’ between 0 and 255 where 0 is off and 255 is full on. The channel ‘brightness values’ are sent sequentially over and over. The first byte sent is Channel 1, the second Channel 2, etc. The lighting control packs and other devices are addressable where a 4 channel dimmer pack might be assigned address 008 so it’s channels become 8-11. DMX consoles send out all 512 ‘levels’ to the remote dimmer packs with the level values changing as needed. The dimmer packs ignore all the values except those sent for the pack’s known channels (8-11 in our example) The data is transmitted at 250kbps allowing lights to be ‘updated’ 44 times a second. This means you can easily ‘dim’ a light via DMX by lowering the light’s channel level from 255 to 0 over a period of time. The fast refresh rate means lights can be turned on and off very quickly.
This makes for an amazingly simple control mechanism. 512 bytes of brightness information are sent over and over in a loop with the values changing as needed. A remote node’s processor simply needs to receive the DMX data stream looking for the bytes that correspond to it’s assigned channel addresses and then adjust a channels output based on the received value. Any simple 8-bit microcontroller CPU can handle that. It also means the main controller will be simpler to design, but I’m getting ahead of myself.
So in a nutshell, the display will have a serious of remote ‘control nodes’ that will be controlled by sending ‘brightness levels’ out over a twisted pair cable using RS-485. The simplicity of the protocol means the hardware and software needed to control the lights will be less difficult and expensive to implement. By using an industry standard protocol, we also will be able to leverage and use devices already made for the stage lighting market where do-it-yourself isn’t feasible. The fast refresh rate of DMX means we can change the brightness levels of the lights very quickly allowing for eye catching show sequences.
Next we’ll talk about the types of remote node’s we might use in the display.
Further Reading:
Posting Comment