Once we've got our information together, we’re ready to program the translator. The configuration process requires a terminal program, such as HyperTerminal, but I used Crestron's Viewport, as I like it as much as a terminal program. After connecting to the Input port on the Universal Translator and starting the terminal program with the correct baud settings, pressing M after a prompt immediately following plugging power into Universal Translator allows navigation though a simple menu system by entering numbers associated with each menu item, and when necessary, numbers and letters to enter the hexadecimal values of the strings. I won't get into the specifics of the process, as you can read all about it in the manual. The reading is pretty dull if you’re not actually using it, unless you’re just into these kinds of things.

The most pertinent information is that we can have the Universal Translator perform up to 20 translation operations on input strings to generate output strings. For most purposes, we simply enter string values for a particular input (1-20), and then enter the string values we want to output to the respective output number. This means a single string in for one single string out. For the sake of the polling operation (described later), the manual says that the input strings for On and Off notification should be assigned to 1 and 2 respectively, for reasons I didn’t see, but conceded to be safe.

On the output menu, we can configure a delay between the output strings, to provide time for the device connected to the output to finish the last command before taking the next. This is actually quite useful, as a lot of equipment will just ignore a command if it was followed too closely by the previous command.

But wait, there’s more.

Some devices send notification through their serial ports whenever a given parameter changes, even if they're not asked. This is preferable in almost every case. For instance, if the volume goes up, a device may send strings indicating the current volume. Some devices can, but only if they're configured to do so. Some devices need to be told to connect via their serial port before they'll do anything else. The UT has a provision for these less than optimal cases. The menu allows a startup string that's sent to the input port, allowing the UT to give the SSP or whatever device an initial command, to either enable instant notification and/or further communication. Should power fail, resulting in an SSP that might need reconfiguration upon power restoration, the Universal Translator will reinitialize the SSP or other device on the input port. If the system needs the input port device to be reconfigured on a more regular basis, say upon system turn on, power can be supplied to the UT via a switched outlet, or have power run through a voltage-controlled relay, or whatever the situation requires. Be creative!

If the SSP or other device on the input port does not send notification of changes, the Universal Translator also has the ability to poll, or rather send a string on a regular basis that requests information regarding a particular state of the input device. For instance, if the SSP doesn't tell the Universal Translator what input its on when it wakes up or changes inputs, the UT can simply ask on a regular basis. If the answer doesn't match the last string that the Universal Translator received and recognized, it knows that something changed and that the corresponding output string must be sent. It only sends an output string if something changed because otherwise it'd be sending a string every time it received a response to the poll query, every second or so.

The polling frequency can also be adjusted. However, you only get one polling string, so if you can’t get all the information you need (say you need to poll for both power and input status) with a single string (either a complete status query, or two different queries sent sequentially as a single string), you’re hosed.

There’s also a debugging tool available in the menu, which lets us watch the input strings actually coming from the connected device (typically the SSP) with the PC's serial port connected to the output port, and shows them to us in hexadecimal format (converted to ASCII text so that our terminal program can show them to us with standard text). As a result, we can check the actual output vs. what we think we know from the documentation.

Click Here to Go to Part IV.