The Problem

In my experience working with RS-232 devices and software written to interact with RS-232 devices, I’ve come across a number of cases where RS-232 serial configuration settings are not configurable or well documented.

Without a clock signal, asynchronous serial communication over RS-232 requires that devices at both ends use the same timing and framing configurations, otherwise the signals are not correctly interpreted and no data, or bad data, is received at the other end.

In addition, multiple serial cable configurations exist. Some are “straight-pin” cables meant for DTE-DCE communication, where the TX pin on one end is connected to the TX pin on the other end. Other cables are “null model” or “cross-pin” cables, often meant for DTE-DTE communication, where the TX pin on one side is connected to the RX pin on the other side. In addition, some cables fully support hardware handshaking signals while others will tie RTS and CTS pins on each side to fake or simulate hardware handshaking.

The Solution

While admittedly this can be a rare problem, a good engineer sees a problem and creates a solution. Even if a business ROI isn’t there, the solution can still be a good learning opportunity.

To solve this particular problem, I started working on Serial Analyzer. The idea is that you connect a serial cable, send sample data from a device, and Serial Analyzer will determine which configurations are possible and which are most likely and present them to the user.