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.