RS-232 Serial Wiring & Handshaking Bypass for Modbus

RS-232 pinouts, cable wiring, and handshaking bypass jumper schemes for Modbus serial connections — DB9 configurations, null modem wiring, and common pitfalls.

Categories:

Overview

While most modern Modbus RTU installations use RS-485 for its multi-drop capability and longer cable runs, RS-232 is still common on legacy equipment, building controllers, VFDs, and devices with DB9 serial ports. RS-232 is also used for console/configuration access on many gateways and protocol converters.

This article covers RS-232 wiring for Modbus RTU — pin assignments, cable types, handshaking bypass, and the most common wiring mistakes.

RS-232 point-to-point wiring diagram showing DB9 pinout, TX/RX crossover, and handshaking bypass jumpers

[!NOTE] For RS-485 wiring (the more common physical layer for Modbus RTU bus networks), see the RS-485 Physical Layer Wiring & Termination Reference.

RS-232 vs RS-485

ParameterRS-232RS-485
TopologyPoint-to-point only (2 devices)Multi-drop bus (up to 32+ devices)
Max distance15 m (50 ft) at standard rates1,200 m (4,000 ft)
SignalingSingle-ended (referenced to ground)Differential pair
Voltage levels±3 V to ±15 V±1.5 V to ±6 V differential
Devices per segment1 driver, 1 receiver1 driver, up to 256 receivers (with repeaters)
ConnectorsDB9 (DE-9), DB25Screw terminals (typically)

Key takeaway: RS-232 is point-to-point only. You cannot connect multiple Modbus slaves on an RS-232 bus — use RS-485 for multi-device networks. See the Modbus RTU Multi-Device Daisy Chain Wiring Guide for multi-drop configurations.

DB9 Pin Assignments

The standard DB9 (DE-9) connector for RS-232:

PinSignalDirection (DTE)Description
1DCDInputData Carrier Detect
2RXDInputReceive Data
3TXDOutputTransmit Data
4DTROutputData Terminal Ready
5GNDSignal Ground
6DSRInputData Set Ready
7RTSOutputRequest to Send
8CTSInputClear to Send
9RIInputRing Indicator

[!NOTE] “DTE” means Data Terminal Equipment — that’s your laptop, PC, or master controller. “DCE” means Data Communications Equipment — that’s a modem or some converters. DTE and DCE swap TX/RX pin assignments, which is why null modem cables exist.

The Three Essential Pins

For basic Modbus RTU communication, only three pins are required:

PinSignalPurpose
2RXDReceive data
3TXDTransmit data
5GNDSignal reference ground

All other pins are for flow control (handshaking) and may need to be bypassed — see Handshaking Bypass below.

Cable Types

Straight-Through Cable (DTE to DCE)

Connects pin-for-pin: pin 2 to pin 2, pin 3 to pin 3, etc. Use when connecting a DTE device (PC) to a DCE device (modem or converter).

PC End (DTE)Device End (DCE)
Pin 2 (RXD)Pin 2 (TXD)*
Pin 3 (TXD)Pin 3 (RXD)*
Pin 5 (GND)Pin 5 (GND)

*DCE devices internally swap TX/RX, so a straight-through cable works.

Null Modem Cable (DTE to DTE)

Crosses pins 2 and 3 so that each device’s transmit connects to the other device’s receive. This is the cable you need when connecting two DTE devices — for example, a laptop to a Modbus controller.

Laptop EndController End
Pin 2 (RXD)Pin 3 (TXD)
Pin 3 (TXD)Pin 2 (RXD)
Pin 5 (GND)Pin 5 (GND)

[!TIP] If you connect two devices and the TX LED blinks but you’re getting no data, you almost certainly need a null modem adapter. Carry a small inline null modem adapter in your commissioning toolkit — it’s easier than re-wiring cables on site.

How to Tell Which Cable You Need

  1. If one device is labeled DTE and the other DCE → straight-through
  2. If both devices are DTE (most common: PC to controller) → null modem (crossover)
  3. If you don’t know → try one, and if it doesn’t work, swap pins 2 and 3

Handshaking Bypass Jumpers

Many serial ports require hardware handshaking signals (RTS/CTS, DTR/DSR) to be asserted before they will transmit or receive data. Modbus RTU does not use hardware handshaking — it relies on timing (3.5-character silent interval) for message framing.

If a device’s serial port is waiting for CTS or DSR before sending data, communication will fail even though the baud rate, parity, and wiring are correct.

The Fix: Jumper Handshaking Signals

Loop the handshaking outputs back to the handshaking inputs on each connector so the device “thinks” it has permission to send.

Standard Bypass Jumper Scheme (DB9)

On each connector, make these jumpers:

JumperPinsEffect
RTS → CTSPin 7 → Pin 8Device’s “request to send” immediately satisfies “clear to send”
DTR → DSR + DCDPin 4 → Pin 6 + Pin 1Device asserts “terminal ready” and immediately sees “data set ready” + “carrier detect”

This tells the port: “the remote device is ready, carrier is detected, you’re clear to send.”

[!WARNING] Don’t skip the DTR → DCD jumper (pin 4 → pin 1). Some devices and drivers will not open the serial port without DCD asserted, even if CTS is satisfied.

Full Null Modem with Handshaking Bypass

For a DTE-to-DTE connection with full handshaking bypass in a single cable:

Side ASide BPurpose
Pin 2 (RXD)Pin 3 (TXD)Data crossover
Pin 3 (TXD)Pin 2 (RXD)Data crossover
Pin 5 (GND)Pin 5 (GND)Ground
Pin 7 (RTS) → Pin 8 (CTS)jumpered locallyBypass on Side A
Pin 4 (DTR) → Pin 6 (DSR) + Pin 1 (DCD)jumpered locallyBypass on Side A
jumpered locallyPin 7 (RTS) → Pin 8 (CTS)Bypass on Side B
jumpered locallyPin 4 (DTR) → Pin 6 (DSR) + Pin 1 (DCD)Bypass on Side B

Software Flow Control (XON/XOFF)

Some devices use software flow control (XON/XOFF) instead of hardware handshaking. This inserts control characters (0x11 for XON, 0x13 for XOFF) into the data stream.

[!CAUTION] Do not enable XON/XOFF flow control for Modbus RTU. The control characters (0x11, 0x13) can appear as valid data bytes within Modbus messages, causing framing errors and corrupted data.

Set flow control to None for all Modbus RTU connections.

Serial Port Settings

Verify these settings match on both the master and slave:

ParameterCommon ValuesDefault
Baud rate9600, 19200, 38400, 1152009600 (most common)
Data bits88
ParityNone, Even, OddNone (N) or Even (E)
Stop bits1, 21
Flow controlNoneNone

[!TIP] The most common Modbus RTU serial settings are 9600, 8, N, 1 (9600 baud, 8 data bits, No parity, 1 stop bit). If the device documentation doesn’t specify, try this first.

Common Wiring Mistakes

SymptomLikely CauseFix
TX LED blinks but no data receivedTX/RX pins need crossingUse null modem adapter or swap pins 2 and 3
Port opens but no communicationHandshaking signals not assertedApply bypass jumpers
Garbled data, framing errorsBaud rate or parity mismatchVerify serial settings match on both ends
Communication works briefly then stopsSoftware flow control (XON/XOFF) enabledDisable flow control — set to None
Intermittent errors on long cablesCable too long for RS-232 (>15 m)Switch to RS-485 or use a shorter cable
No COM port in Device ManagerUSB-to-serial driver not installedInstall the correct driver — see USB driver guide

When to Use RS-232 vs RS-485

ScenarioRecommended
Single device, short cable (<15 m)RS-232 is fine
Multiple devices on one busRS-485 required
Long cable runs (>15 m)RS-485 required
Console/configuration port accessRS-232 (most devices use it for console)
New installationRS-485 preferred for all Modbus RTU

Chipkin Can Help

Need help wiring a serial connection to a QuickServer gateway? Chipkin support can provide wiring diagrams specific to your device model and help troubleshoot serial communication issues.

Need more help?

If this page does not resolve the issue, contact Chipkin support with the product model, protocol details, and any diagnostics you have already captured.

Open Chipkin Support