A practical reference for diagnosing RS-232 communication problems in legacy software, industrial equipment and undocumented serial devices.
This guide focuses on a common real-world situation:
The software, device or documentation may be old or incomplete — but the system still needs to work.
When an RS-232 connection does not work, check these first:
- Confirm that both sides are actually using RS-232 electrical levels.
- Verify the correct COM port.
- Check baud rate.
- Check data bits.
- Check parity.
- Check stop bits.
- Verify hardware/software flow control.
- Determine whether the cable should be straight-through or null-modem.
- Verify TX, RX and GND wiring.
- Check whether the application expects specific modem-control signals.
- Capture the serial traffic if communication still fails.
A typical configuration is 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control, usually written as 9600 8N1.
Do not assume that a DB9 connector automatically means RS-232.
Equipment using similar connectors may implement:
- RS-232
- RS-422
- RS-485
- TTL serial
- proprietary electrical interfaces
Connecting incompatible electrical interfaces can cause communication failure and may damage hardware.
For many simple connections only three signals are required:
- TX — Transmit Data
- RX — Receive Data
- GND — Signal Ground
Other systems may also require RTS, CTS, DTR, DSR, DCD or RI.
One of the most common RS-232 problems is using the wrong cable.
A straight-through cable connects corresponding signals.
A null-modem connection crosses the transmit and receive paths:
Device A TX → Device B RX
Device A RX ← Device B TX
Device A GND — Device B GND
Do not determine the required cable from connector gender alone.
The important question is whether each endpoint behaves as DTE or DCE and how its pins are actually assigned.
Both endpoints normally need matching serial parameters.
Common values include:
300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 baud.
A wrong baud rate often produces unreadable or apparently random characters.
Common configurations include:
- 8N1
- 8E1
- 8O1
- 7E1
For example, 8N1 means 8 data bits, no parity and 1 stop bit.
A system may use:
Only the data lines are relevant.
Usually RTS/CTS.
Usually XON/XOFF control characters.
A mismatch can produce a connection that appears to start correctly and then stops transmitting.
Modern Windows systems often assign USB-to-serial adapters dynamically.
Check:
- which COM port Windows assigned;
- whether the legacy application supports that COM number;
- whether another application already opened the port;
- whether the USB-to-serial driver loaded correctly;
- whether reconnecting the adapter changed the COM number.
Some old applications only support low-numbered ports such as COM1–COM4, even though Windows itself supports higher numbers.
Not all USB-to-serial adapters behave identically with legacy equipment.
Differences may include:
- driver behavior;
- timing;
- modem-control signal handling;
- buffering;
- unsupported or counterfeit chipsets;
- behavior after Windows updates.
When troubleshooting a previously working system, always record:
- adapter chipset;
- driver version;
- Windows version;
- assigned COM port;
- serial parameters.
Changing several of these simultaneously makes diagnosis much harder.
When the physical connection appears correct but the protocol is unknown, capture the communication between the original working software and the device.
Useful information includes:
- direction;
- timestamp;
- raw bytes;
- ASCII representation;
- message boundaries;
- response time.
For example:
PC → DEVICE: 02 53 54 41 54 55 53 03
DEVICE → PC: 02 4F 4B 03
Do not immediately assume that captured bytes represent printable text.
Legacy protocols may contain:
- binary fields;
- control characters;
- checksums;
- length fields;
- sequence numbers;
- BCD values;
- little-endian integers;
- fixed-width records.
If documentation is unavailable, avoid changing random settings until something appears to work.
Use a controlled process:
- Preserve the original system if it still works.
- Record its serial configuration.
- Identify the electrical interface.
- Determine the pinout.
- Capture known-good communication.
- Identify message boundaries.
- Compare repeated transactions.
- Change one input or action at a time.
- Observe which bytes change.
- Determine checksums and field encoding only after the basic structure is understood.
This turns protocol discovery into a repeatable engineering process rather than guesswork.
Check:
- wrong COM port;
- TX/RX wiring;
- missing ground;
- wrong electrical interface;
- required handshake signals;
- device power/state.
Check:
- baud rate;
- data bits;
- parity;
- stop bits;
- electrical noise or incorrect signal levels.
Check:
- TX/RX wiring;
- handshake signals;
- application protocol expectations.
Check:
- RTS/CTS;
- XON/XOFF;
- buffer handling;
- protocol acknowledgement requirements.
Compare:
- COM port assignment;
- serial adapter;
- driver;
- Windows version;
- application configuration;
- cable;
- timing behavior;
- handshake lines.
Do not assume the software itself is the problem.
If an old PC still communicates successfully with important equipment, treat it as a reference system.
Before modifying it, preserve:
- application files;
- configuration files;
- database files;
- DLL/OCX dependencies;
- registry settings;
- serial configuration;
- driver versions;
- screenshots;
- cable pinouts;
- captured protocol traffic.
A working old installation may be the best documentation available.
More detailed material on legacy serial systems and software recovery:
- RS-232 Software Development Guide
- RS-232 Device Reverse Engineering
- Capturing RS-232 Traffic
- RS-232 Pinout Troubleshooting
- Unknown Serial Protocol Reverse Engineering
Maintained by Gabor Boglar, legacy software engineer working with VB6, Delphi, serial communication, legacy databases and undocumented systems.