Product Review
 

The Universal Translator for Communication Between RS-232 Ports on A/V Components

Part IV

February, 2006

Colin Miller

 

In Practice

I procrastinated quite a bit after reading the manual, not because it sounded difficult, but rather because my experience has taught me that making this kind of stuff work in real world scenarios can be tedious and occasionally frustrating. I was correct. I don't blame the Universal Translator or the associated gear for this, but the fact is that even well-designed components aren't necessarily designed to work together, and it often requires a bit of discovery and creativity in implementation. To its credit, the Universal Translator had enough flexibility in design to make it work, despite the non-optimal combination.

After doing my detective work and figuring out how everything 'should' work, from baud settings to string sequences to appropriate cabling, I set about to use the Universal Translator to connect the Anthem AVM-30 SSP to the DVDO iScanHD+ Video Processor. I have the DVD player on the DVI input, the TiVo on the composite video input, and the VCR on the S-Video input.

The actual programming of the Universal Translator is actually quite painless considering that we have to do it through a terminal type program, and the menu navigation is relatively intuitive. Configuring the UT to operate in a way that would have worked in an ideal world, once we had our homework done on the associated devices, was relatively quick. But, my equipment rack apparently didn't live in an ideal world.

The Universal Translator worked great getting the iScanHD+ to follow the AVM-30 when it came to power on and power off, but it wouldn't initially switch the inputs on the iScanHD+ when the AVM-30 switched its own.

I rechecked the string values coming from the AVM-30. No problem there. Whenever an input changed, the AVM-30 sent out information regarding the current input in the format I had understood, as well as other information regarding the current status of the SSP. I then compared this information to that assigned to the input string in the Universal Translator, and couldn't find a problem.

On a hunch, I then programmed the UT to run with the poll operation on, and set the polling string to one that asked for the input status exclusively. That worked fine. It seems that the Universal Translator can't distinguish a string of particular bytes when immediately preceded or followed by other bytes. As a result, getting information before and after the relevant input status information confused the UT, which saw it as one big, different string. By asking for the input exclusively during the polling process, the response contained only the relevant string, and the Universal Translator made a nice clean match. The only downside was a greater delay between the AVM-30 switching inputs and the corresponding input change on the iScanHD+.

In the few seconds that the AVM-30 takes to switch inputs, configure the appropriate decoder, and set all parameters to their default values, the unit doesn't return polling information. It make sense, since everything is in flux anyway, and the SSP had just sent most everything we'd want to know about as in that large sequence of bytes following its input change. As a result, we have to wait for the AVM-30 to finish reconfiguration before it responds to the query. It wasn't a deal breaker, but since my standard controller sends commands to every relevant device simultaneously, in comparison, the lag time in video switching it seemed a little clunky, but it worked.

While I'm being spoiled, I would like to mention one more limitation I ran into while playing with the Universal Translator.

The Universal Translator cannot send multiple, separate set-up strings from the output given a single input string. Not that anybody claimed it could, but it would have been nice. I tried to trick it by entering the same input string twice, setting the output delay to 3 seconds, and then entering the input command string on one of the input strings, and the default aspect ratio command on the second identical input string. However, it seems that the device quits looking after it finds its first match, as opposed to rolling through the rest of the input strings and dumping the corresponding output string into the output queue. If the controlled device connected to the output port has enough of a buffer to take multiple commands strings tied together as a single packet (like the wonderful AVM-30), we can get around this by simply putting one string after another, just like it was a single string. However, most gear A/V gear isn't that robust.

A corresponding problem may occur with some items that require multiple commands to execute a single function with a delay between commands. It may not be fair to blame the Universal Translator for the short-sightedness of another manufacturer's design, but it's worth making a mention of this fact merely for reference in potential implementation.

Conclusions

Overall, I think it's pretty safe to say that the Universal Translator is a unique product that performs pretty much as promised. The exact value will depend on the scenario, and to some degree, when pressed, the ingenuity of the user. Regardless, I think it's a widget worth keeping in the back of one's noggin for future applications. For anyone looking to link the operation of a video processor, video display, video switch, or similar switching device to an SSP or A/V receiver via their respective serial ports, the Universal Translator may just be the key to that outcome. Keep it in mind, and should circumstances suggest it, give it a try.
 

- Colin Miller -

Response from Shawn Fogg of Switch-box.com:

"As you mentioned for those with full blown automation systems such as the AMX or Crestron systems the functions of the UT can certainly be handled in those other systems. But for those looking for simpler needs such as integrating a video processor or video switch with their pre-pro then purchasing, installing and programming an AMX or Crestron system is expensive and overkill for a simpler intergration need. The UT is targeted for those looking for simpler RS-232 automation needs at much lower cost.

Macros in a good IR remote can accomplish switching between audio and video but only when you use that specific remote. If one walks up to their pre-pro and selects an input or turns it on or off the remote can do nothing to help automate the system. The user is back to square one of having the audio and video devices being out of sync with each other. The UT doesn't care how you control the pre-pro, it will still keep the two devices in sync.

Colin mentioned the use of a null-modem cable in the review. That is one way of connecting two like devices together (DTE to DTE or DCE to DCE). The jumpers in the UT that Colin mentioned change each RS-232 connection from DTE to DCE or vice versa so that null modem cables are not required. Of course if one already has a null-modem cable it is fine to use that too as it accomplishes the same goal.

The question about why Input String 1 and 2 are suggested to be used for On and Off for the polling mode is as follows. In the polling mode the UT tracks the last input that was selected so that it doesn't send input change commands repeatedly to the device being controlled. On power state changes the UT resets the tracking of the last input selected so that when the unit turns back on again the UT will resend the input command to the device being controlled after power on. This is done just in case the device being controlled doesn't automatically turn back on set to the same input as it was when shut off. As such the UT needs to know what match strings are for power changes to reset the input tracking. The UT also uses this to track the power status separate from the input status again for the same reason of not sending multiple on or off commands to the device being controlled.

I'm not sure why the UT wasn't working for Colin with the AVM-30 in its normal non-polling mode. The UT does in fact look within a packet for matches to the strings so it can handle the situation of looking inside a larger packet for the match string. Bytes ahead or behind the match string is not a problem. There are a few possibilities of why the matching wasn't finding the strings in Colin's case but without having the AVM-30 in front of me it is a little difficult to say exactly what was going on. One possibility is if an unrelated packet was sent from the AVM30, then a pause, then the actual input status packet was sent it is possible the UT may have missed the input status change message while it was processing the first packet depending upon the timing of the above. If that was what was occurring adjusting the read/polling timer parameter may have rectified this by setting it larger so that the UT would capture both packets, then timeout and look in the two packets for the match string.

As Colin noted for situations where the UT isn't able to work with the status messages the polling method is another option and I'm glad to see it worked for him. From all the pre-pros I have looked at one query message is enough to get the needed information. If a pre-pro turns up that needs more then a single string I will see about addressing that.

Because Colin was in the polling mode his trick for sending multiple commands by defining duplicate input match strings will not work.  That is by design and a necessary limitation so that the UT can properly track the selected input for the reasons noted above. In non-polling mode that limitation is not in place and the unit will in fact send multiple commands exactly as outlined by Colin. There is a configurable delay that can be set between commands specifically for the case where a controlled device's RS-232 protocol needs delay between each command.

As far as having the UT factory programmed I can't actually promise that it will always work right out of the box for setups that I haven't had in front of me to test ahead of time. As Colin noted, systems vary greatly with regards to serial control so with all the combinations out there some work by the user may well be required until I get a list of tested/working setup configurations. For those that are afraid of that possibility, then configuring/programming any automation product may not be the right choice for them."

© Copyright 2006 Secrets of Home Theater & High Fidelity

Go to Table of Contents for this Issue.

Go to Home Page

 

About Secrets

Register

Terms and Conditions of Use
 

PAGEFEEDBACK
Our Vault pages may have some display quirks. Let us know if we need to take a look at this page or fix a bug.
SUBMIT FEEDBACK
Connect with us
  • Instagram
  • Google+
  • YouTube
  • LinkedIn
  • Pinterest
Secrets "Cave"
Facebook
Close