System Control 101
Automation is the fastest moving sector in our industry. Here’s the basics on staying in control of an AV installation.
24 February 2015
Text:/ Derek Powell
There’s barely an audio or video component that doesn’t come with a remote control. While the ubiquitous hand-held IR remote is fine for controlling a single component like a TV or a DVD player, when we consider an audiovisual system with sources, switchers, displays and more, that’s no longer enough. Today providing a single, simple automated control interface to manage an audiovisual system is an essential part of any integrator’s role.
But for the newcomer, modern automation systems like those made by AMX, Crestron, Extron and others can be difficult to fathom because they use a variety of different electrical technologies to connect to the devices they command. These basic control techniques have been around for a long time though, so let’s try to simplify things and along the way explore a little of the history of remote controls.
LET’S START IN THE MIDDLE
The hub of any control system is the central control unit. It’s the brains of the system and is essentially a simple CPU, like a computer, though it has its own programming language that typically is a lot less user friendly than Windows or IOS programs. If we take a look around the back, where we connect up our controller, things start to look complicated.
In a perfect world, we might expect everything to hook together using something simple like USB connectors but for now at least, things are quite different. Instead, you’ll find a mass of D connectors, RJ45s and Phoenix terminals labelled with an alphabet soup of acronyms from AxLink to ZigBee.
We can halve the complexity though, by splitting these interfaces into two kinds of controls — logical controls (that only provide on/off or yes/no outputs) and numeric controls (that send and receive coded numbers to invoke different functions: play/stop/rewind/zoom and so on).
REGARDING RELAYS
The relay is the most basic electronic control device. It was invented more than 150 years ago at the dawn of electrical communication but it’s still so useful that you’ll typically find relay control outputs on most controller systems. The invention of the relay is claimed both by the British (Edward Davey) and the Americans (Joseph Henry) in 1835. Within a decade, relays were an essential component used to enable the telegraph by allowing the press of a key switch in a local office to operate an electrical buzzer at a remote receiving station.
The relay is an electromagnetic device that allows an electrical current flowing in one circuit to move a set of contacts that allow current to flow in another circuit. Relays not only provide a logical control function (on or off) but they allow the control circuit to be both remote and isolated from the device it controls.
Relays quickly found much wider uses in all sorts of control applications, not least in early telephone exchanges. They remain very useful because we can use a safe, low voltage electrical current connected to our controller to turn on or off a high voltage mains circuit like an electric motor or a bank of lights. Audiovisual control systems often include a number of relay outputs to control mains powered devices that require only a simple on/off switch. Examples are lights, solenoid door locks, and motorised blinds, which commonly use two relays to provide up/down control.
Relay wiring is very simple. Two wires are connected from the relay at the device to be controlled to the switching contacts at the audiovisual controller. When the switch inside the controller closes, a small current flows in the connecting cable and causes the electromagnet in the relay to pull in the mains voltage contacts and switch on the light, motor or whatever is being controlled.
I/O, I/O IT’S OFF TO WORK WE GO
Relay contacts aren’t the only kinds of ‘logical’ electronic components that can switch things on and off. The invention of the transistor by Bardeen, Britain and Shockley at the Bell Laboratory in the 1947 opened the way for some very useful kinds of electronic switching. I/O terminals, found on many kinds of central controllers, use transistors to switch remote circuits on or off, like relay outputs, but they can also be used as ‘logical’ inputs as well. I/O transistor circuits can be used to detect whether a voltage is present or a switch is operated in a remote device, which opens up a range of useful applications. Controllers can use I/O ports to tell if doors are open or closed, if blinds are up or down or if an alarm has been activated.
This is very useful in an automation system. We may wish to check that blinds are closed before operating a screen, for example. In many situations regulations require that audio systems are disabled in the event of a fire alarm so that people can hear emergency announcements. I/O ports on audiovisual controllers are often connected to alarm systems that provide a voltage output for just this purpose.
Like relays, the wiring for I/O ports is quite uncomplicated — typically only two wires to the remote device — but you need to be certain the connected device is suitable. I/O terminals can only handle a limited range of voltage and current so you need to check the switch or circuit at the remote end is compatible, otherwise the port can be destroyed.
BEYOND ON/OFF
It took quite a long time for remote control technology to move beyond ‘logical’ on/off commands to the kind of functionality we find in IR remotes today. In fact the two people credited with co-inventing the wireless TV remote developed ingenious systems but their original work shared absolutely nothing with today’s IR remotes (see sidebar).
The second broad method of control involves sending coded binary numbers from the controller which are decoded by smart circuitry in the device being controlled. Each code refers to a specific function. It might be volume up (or sometimes, set volume to a specific level); change input or even a toggle function like power on/off.
There are three common ways remote commands can be sent and the one to be used depends mostly on the capability of the controlled device. The three are: infra-red (IR); wired serial control; and internet protocol (IP), which can be sent across a network connection. Of course, radio or ultrasonic can also be used as a wireless transmission technology for control instead of IR, but as the control proceess is essentially identical we’ll leave those aside for now.
THE REMOTE CONTROL
US Company Zenith Radio (now owned by LG) pioneered remote controls in consumer television sets. Their first system, dubbed the ‘Lazy Bones’ provided a useful range of control but required a thick umbilical cord attached to the TV, which proved deeply unpopular.
In 1955 Zenith produced the first of two revolutionary ways of implementing true wireless remote control. The Flash-Matic, devised by engineer Eugene Polley was a four-function logic-type device that provided picture and sound mute and channel up or down. A Photocell was located at each corner of the screen and the ‘hand held remote control’ was simply a special torch which the user shone at one or other of the photocells to implement the required function. It worked great until the sun crept through the venetian blinds and shone on the photocells. When that happened, the channels were likely to change unpredictably and uncontrollably — most off-putting!
The next year, they released the futuristically named Space Command remote, that was was not only wireless, it didn’t even need batteries! Invented by another Zenith engineer, Dr Robert Adler, the remote unit was a device of such elegant simplicity as to be pure genius. The remote casing housed four aluminium rods around 60mm in length that were struck by tiny hammers actuated by the control buttons. The rods functioned like tuning forks and were fashioned to resonate at precise frequencies in the ultrasonic range when they were struck by the actuators. At the set, a quite elaborate ultrasonic receiver circuit using no less than six valves responded to each tone by actuating the appropriate function: channel up/down; audio mute or power on/off.
Incidentally, while the ultrasonic notes produced by the Space Command were inaudible, the mechanical action of the hammers produced a distinctive click when activated by the buttons of the remote. To this day, many Americans still refer to modern IR remotes as ‘clickers’ even though the click (and the mechanical hammers) have long disappeared.
Adler and Polley both lived into their nineties when they were somewhat belatedly honoured by the IEEE (in 2007 and 2009) for their pioneering work in developing the first consumer wireless remote controls. You can read more on the web, where there are plenty of sites devoted to early TV, including www.zenith.com/heritage/.
IR: SIMPLE BUT STUPID
Infra-red remotes work by encoding the various control codes onto a stream of pulses generated by rapidly switching an infra-red emitter on and off. The receiver responds to the pulses by decoding the instruction and commanding the device to carry out the instruction (volume up, power on or whatever). So long as we know what codes correspond to the various functions, we can attach a simple IR emitter to our audiovisual controller and have the controller send a sequence of flashes that correspond to the control code for the function we want. Because the numbers are sent as a sequence of flashes, one after another, this method of control is one variation of what is known as ‘serial’ control — we’ll come back to that concept later.
We could leave the IR emitter (sometimes called a ‘blaster’) attached to the control unit and transmit it across the room but it is much more reliable to attach it directly to the receiving window on the unit being controlled to avoid needing everything in line of sight. Wiring is simple, we just need a pair of wires from the IR (serial) output on the controller to the blaster. While that’s mostly reliable, there’s a big problem for automated systems with this kind of control. There’s no feedback to confirm that the device has ‘heard’ the command and done what we asked it to do.
This is a major problem when the command being sent is a ‘toggle’ command such as on/off or up/down. Let’s look at a common example: If we want to play a DVD, we can program our automation system to first issue a ‘power on’ command to the player, then power up the TV and subsequently issue a play command to the DVD. Unfortunately, many devices have a single power button that commands the power. Push once and it turns on, push again and it turns off. If the unit is already on and we send a ‘power’ command, then it will turn off and subsequently fail to play when requested. We can’t simply issue the command twice, just to be sure, because if it was off initially, it will come on, then turn off again. In a complex system this one-way-only communication from controller to device rapidly becomes a big issue, making automated commands totally unreliable.
RS232 TO THE RESCUE
Fortunately, there is a better way. Devices equipped with serial control ports conforming to the RS232 protocol (or its cousins RS422 or RS485) respond to coded instructions from the controller but then go one step further. When the instruction is completed (such as ‘power on’ or ‘set input to HDMI 1’) the receiver then sends a message back to the controller confirming that the power is or the input is ready on and awaits further instructions. Good programming practice is to have the controller wait to receive confirmation that an instruction has been executed before moving on to the next command.
To allow two-way communications, the wiring must be different from the two wires used in IR or relay control. RS232 connections have extra wires (at least three and sometimes more) so that there is a dedicated path to receive instructions and a different path to communicate back to the controller. It goes without saying that devices equipped with two-way serial connections must be ‘smarter’ than most simple IR-controlled devices but in commercial applications the difference in reliability is well worth the extra expense.
TO INFINITY & BEYOND
RS232 does have a few limitations, though. You can’t issue instructions terribly quickly and there is a distance limitation between the controller and the equipment being controlled.
Today, everything from a five-port Ethernet switch to a battery charger (and quite a lot of audiovisual gear) comes equipped with a network port and an HTML interface, as well as the equivalent processing power of the first generation of Space Shuttles. By assigning each piece of equipment an IP address, we can issue instructions (and receive feedback confirming correct operation) across a local network, a wireless network or to equipment located anywhere in the world across the internet.
IP connection is fast and reliable and this is rapidly becoming the default method for connecting and controlling anything more intelligent than a light switch.
CONTROLLING THE CONTROLLER
The last link in the chain of course is the control panel you use to command the central controller. The user interface is often connected via IP to the central controller and may be as simple as a pad with half a dozen buttons that mimics the kind of control found on IR remotes. The difference is that each button could be programmed to fire off a series of commands to different devices. Most installed automation systems these days however use a touchscreen so the user interface can be anything you could imagine — buttons, sliders or even a track pad, and the screen can show many pages to allow in-depth control using deeper menus if you need them. Most systems will support multiple control panels so that you can have control of your system from front-of-house as well as the bio-box and the manager’s office — wherever you can connect to the network.
PER-APPS AN IPHONE IS BETTER?
Given the typical control panel is generally an IP device and a touchscreen, the latest trend is to use an app on a tablet or smartphone to emulate the control panel. It is likely this trend will continue and it’s possible to imagine a future where everything is IP connected and the central controller becomes simply a software service running in the cloud, but that’s a few weeks off yet.
In a single article we can only scratch the surface of this subject of course! Hopefully, though, we’ve explained enough to lighten the darkness somewhat if you haven’t had in-depth exposure to automation systems. We haven’t talked about programming or monitoring and scheduling or what makes a good user interface but we’ll take those matters up another day.
RESPONSES