Embedded Processing

I recently changed how I receive television programs. The change included switching out my existing set-top boxes for new ones. It also meant switching remote controls. The newer remote control supports up to four different devices—perfect for my setup.

Remote controls for entertainment electronics are not a new concept. In fact, Zenith Radio Corp introduced the first remote control, intended to control a television, in the 1950s. The first such device, known as the "Lazy Bones," used wires between the remote and the television. Remote controls that did not require wires appeared shortly after that, and the industry has been evolving and improving them ever since. According to the remote control entry in Wikipedia, Steve Wozniak started a company called CL9 that introduced one of the first remote controls, in 1987, which could control more than one type of device.

Each time I have received a new "universal remote," I have tried to squeeze all of the control functions that I needed into a single remote control. To date, I have never been able to get below needing two remotes to adequately control everything. In this latest case, I need the second controller because the new remote control does not speak the same language as my home theater system—which is odd because the same company manufactured them both. Neither the company that provided me with the controller nor the company that manufactures it for them, has been able to help me get the two devices talking to each other in a useful way (turn the system on/off, volume up/down, and switch video and audio input source).

Another shortcoming of the new remote is that despite the explicit support for DVD devices, it does not implement track skip forward/backward, even though there are two buttons directly below the fast-forward and rewind buttons that are available and that intuitively would fill that need. My first gut reaction is to wonder how the software and device development team could allow such a simple and easily fixable oversight to make it through to the finished product. Does anyone test these devices for usability, or is there something more, like non-obvious design trade-offs, to it?

With decades of production experience for these "relatively simple" devices, the naive observer might wonder why universal remotes are not simpler to configure and use. I am now currently in the process of researching the design considerations and constraints for wireless remote controls. My goal is that this research will yield several informational items that could be of interest to you. I am planning to share the non-obvious design considerations for remote controls in an upcoming Prying Eyes feature this October [Editor's note: please see "Perusing a universal remote" (10/25/2007)]. Hopefully this research will also help out in using a wireless remote control as part of my December hands-on project involving robotic platforms.

When I speak with other people, my experience seems to be on par for the industry. It seems that the people who have solved this problem did so by buying expensive universal remotes. Somehow this does not seem reasonable for a device that, at least at first glance, appears to be very simple. I encourage you to share your insights (or informational resources) into the considerations that can affect the engineering and design decisions for remote controls.