In Theory

The Universal Translator is available programmed at the factory to work with a variety of components, but for the sake of being thorough, it was deemed more appropriate that I be able to explore the functionality and flexibility that comes with a configurable architecture.

From the perspective of being a journalist, this probably was a good idea. However, I think that considering the time involved in reading the manual, digging up and interpreting serial protocol, trouble-shooting hardware, and debugging, there is most definitely significant added value in having the item simply work out of the box. It took me somewhere between 3-4 hours for the whole process.

While much of it was the learning curve and discovering the idiosyncrasies of the interaction of multiple devices, and not necessarily applicable to predicting the experience of others, this process is very much within the realm of my day job, doing integration work in residential and commercial environments. So, even though it would be much quicker process to do it again for somebody else with the same gear, or different gear that happened to be an easier fit, the time I spent probably isn't unrealistic, and in fact may be on the low side for someone only casually involved with serial communication.

Don’t get me wrong. The documentation for the Universal Translator is pretty good, and the process, following the directions, isn't complicated. But, it's hardly a cut and paste procedure. Let me 'quickly' run though it . . . .

First we determine the baud information of the connected devices (speed, length of data bytes, number of stop bits, and parity bit if any), the strings (sequence of data bytes) we'll be receiving and sending from each, and the physical type of connection for each serial port. This will probably involve obtaining protocol documentation from the respective manufacturers of the devices. Sometimes, however, that documentation either proves difficult to interpret, is outright lacking information, and is occasionally wrong. Even worse, sometimes the technical support for the manufacturers of the devices have no idea what you’re asking. But, if you’ve got products from manufacturers that actually actively support the use of serial communication with their products, you'll get there, even if only after jumping through a few hoops.

The UT is pretty flexible in terms of baud rate. However, it doesn’t support parity bits at all if the bytes have 8 data bits (as opposed to 7). The manual says that's okay when receiving strings on the input, as it ignores the parity bit, but this might be a problem when it sends strings. Even though most devices don't use the parity bit, some do, so it's something to look for.

Once we figure out the strings we'll be sending, if they're not already in hexadecimal format, (for instance, plain text) we'll have to find out the hexadecimal equivalents to the ASCII text.

Hexadecimal numbers are based on 16, instead of 10. So, instead of 0-9, we have 0-F, such that a decimal 13 would be a hexadecimal 0D, for example. ASCII text has a number assigned to each symbol, often represented in hexadecimal format as an alternative. Despite it being somewhat of a pain, it's actually necessary to provide hexadecimal string entry, as some devices require bytes for which there are no text characters. It would have been nice to allow entry as either, but given only a single option between ASCII and hexadecimal string entry, the hexadecimal option was the best choice. The manual provides a link to a conversion table, www.lookuptables.com. The manual also provides a work sheet so we can lay out which strings go where.

Regarding the physical connectors, on the Universal Translator, the Input port is similar to a PC's port (Receive on pin 2, transmit on pin 3), and the Output port is like that of a modem (transmit on pin 2, and receive on pin 3). If the connection between the UT and the other device involves two ports that are different, use a straight-through type serial cable. If they're the same, use a null modem type serial cable. If it's not a standard DB-9 port on the connected equipment, you're going to have to do a pin to pin list, and maybe make your own cable. Tx goes to Rx, Rx goes to Tx, CTS goes to RTS, RTS goes to CTS, and ground goes to ground. Good luck! The manual mentions that you can reconfigure the connections on the Universal Translator with some jumper connectors. I keep a handful of adapters around, so I just threw in an adapter when necessary.

I had worked with the serial interfaces for both the AVM-30 and the HD+, and so leveraged my prior experience. To get the hexadecimal values from the AVM-30, I put the Crestron Viewport terminal program into a Display as Hexadecimal mode, and watched the strings that the AVM-30 spit out, and referred to the AVM-30 documentation to identify the string section that contained the current source information. For the HD+, I connected to my controller in debug mode while it generated the strings, including calculating checksums, according to a subroutine I had written a few months ago, and copied the strings that went to the unit for particular functions. All in all, relatively painless.

Click Here to Go to Part III.