RS-232 is a tried and true control protocol, which is still widely used today in pro AV. While most devices these days can be controlled using some sort of network control, RS-232 has the distinct advantage that it is a dedicated bus to communicate with and control your device. If the network goes down or if there is an IP conflict, local RS-232 will continue to function, while network control can stop working.
However, RS-232 can be tricky to set up if you are not familiar with the cabling or the things to watch out for.
While RS-232 cables can support up to 9 conductors (think of the traditional DB-9 connector with 9-pins), RS-232 generally uses 3 conductors: transmit (TX), receive (RX), and ground (Gnd). This corresponds to pins 2, 3 and 5 on a DB-9. There may be other conductors required, consult with the device manufacturer's manual to be sure.
Ground will always connect to ground on both ends. The other 2 conductors may either be straight through (TX to TX, RX to RX), or crossover (TX to RX, RX to TX).
Physical connectors can also vary, you will typically find DB-9, TRS (tip, ring, sleeve; like a 3.5mm headphone connector), a Euroblock-type connector (commonly referred to as a Phoenix connector), or possibly other proprietary connectors. All connectors will typically be male, but DB-9 connectors can potentially be male or female. As you can imagine, this often leads to cabling headaches if you are on site and do not have the proper cable or adapters.
Aurora offers TRS to DB-9 cables in 4 configurations, combining variations of straight and crossover, and male and female. See the diagram a the bottom.
Finally, RS-232 has a definable data transmission rate (baud rate) and other settings such as data size, parity, stop bits, and handshaking. It is important to make sure the controller and device have matching settings. Generally the baud rate is the only thing you may need to change, but check with the device manual for other setting requirements.
Here are some troubleshooting tips for RS-232 communications:
- First, verify that Gnd (ground) is going to Gnd (pin 5 on DB-9). Inside the cable, the ground conductor is often (but not always) a bare, uninsulated conductor. A simple continuity test on a multimeter can verify this.
- Check that your baud rate on the controller matches the baud rate of the device you are controlling.
- Next, power on the device and test communication with the power off command. Projectors and displays are notorious for eco power savings modes that disable RS-232 once powered off. Often these are enabled by default. Also, RS-232 may be disabled by default, check with the device manual to verify default settings.
- Now, if you send a command, even if the syntax is wrong, you should get some data back. Make sure you send the proper termination character (often carriage return, line feed, or both).
- If you did not receive an acknowledgement or feedback data, and the device did not execute the command, then your command may not include the proper termination character. In this case, it is possible that the command will not execute and not send feedback because it was not recognized as a complete command, and may not even respond with an error. Try manually turning the device on or off to see if any data comes in.
NOTE: though uncommon, some devices or command modes (like when using a broadcast ID) will not respond with an acknowledgement or feedback data. - If you did not receive an acknowledgement or feedback data, and the device did not execute the command, then it is likely a wiring issue. Swap the TX and RX (pins 2 and 3 on the DB-9) or add a null modem adapter. If you don't have a DB-9 connector or a null modem adapter, this may involve resoldering the DB-9, changing terminals on a terminal block connector, or cutting the cable and rewiring. Inside the cable, the TX and RX conductors are often (but not always) red and white. A simple continuity test on a multimeter can verify this.
- Test your command again. If the command worked, you are all set, stop here.
- If the command did not work, and response shows an error that you can read (responses are not always human readable), it is likely a command error.
- If the response is a bunch of unintelligible data, you likely have the wiring correct, and the baud rate is mis-matched.
In order to bypass and rule out any issues with your control system or programming, it can be helpful to connect a serial port on your PC to first verify your commands and settings. In the case of a dedicated Serial over IP (SoIP) device, such as those found on Aurora's VLX, VLX, IPX, ReAX controllers, and other products, you can connect to the dedicated TCP port using a TCP/Telnet client to talk to the serial port directly across the network. Make sure that SoIP is enabled and configured on these products.
Likewise, it can be helpful to connect you PC to your controller to see if the commands you are sending are being received as anticipated. While this may not definitively rule out your cabling, it will test verify your commands and can help to rule out others settings.
If you have any questions about hexadecimal data, please read this KB article: https://support.auroramultimedia.com/blog/reax-control-systems-3/how-do-i-work-with-hexadecimal-data-in-a-reax-system-5
Below is the pinout information for the Aurora CA0052-X TRS to DB9 serial cables.
