Hubbry Logo
Null modemNull modemMain
Open search
Null modem
Community hub
Null modem
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Null modem
Null modem
Null modem
View on Wikipedia
from Wikipedia
A null modem adapter

Null modem is a communication method to directly connect two DTEs (computer, terminal, printer, etc.) using an RS-232 serial cable. The name stems from the historical use of RS-232 cables to connect two teleprinter devices or two modems in order to communicate with one another; null modem communication refers to using a crossed-over RS-232 cable to connect the teleprinters directly to one another without the modems. It is also used to serially connect a computer to a printer, since both are DTE, and is known as a Printer Cable.

The RS-232 standard is asymmetric as to the definitions of the two ends of the communications link, assuming that one end is a DTE and the other is a DCE, e.g. a modem. With a null modem connection the transmit and receive lines are crosslinked. Depending on the purpose, sometimes also one or more handshake lines are crosslinked. Several wiring layouts are in use because the null modem connection is not covered by the RS-232 standard.

Origins

[edit]

Originally, the RS-232 standard was developed and used for teleprinter machines which could communicate with each other over phone lines. Each teleprinter would be physically connected to its modem via an RS-232 connection and the modems could call each other to establish a remote connection between the teleprinters. If a user wished to connect two teleprinters directly without modems (null modem) then they would crosslink the connections. The term null modem may also refer to the cable or adapter itself as well as the connection method.[1] Null modem cables were a popular method for transferring data between the early personal computers from the 1980s to the early 1990s.

Cables and adapters

[edit]
A null modem cable

A null modem cable is a RS-232 serial cable where the transmit and receive lines are crosslinked. In some cables there are also handshake lines crosslinked. In many situations a straight-through serial cable is used, together with a null modem adapter. The adapter contains the necessary crosslinks between the signals.[2][3]

Wiring diagrams

[edit]
DB-25 null modem wiring diagram
DE-9 null modem wiring diagram
See also: Serial port: Pinouts

Below is a very common wiring diagram for a null modem cable to interconnect two DTEs (e.g. two PCs) providing full handshaking, which works with software relying on proper assertion of the Data Carrier Detect (DCD) signal:[2]

One side Signal
direction 		Other side
Signal and abbreviations DB-25 pin DE-9 pin DE-9 pin DB-25 pin Signal
Frame Ground FG 1 — Common — 1 FG
Transmitted Data TxD, TD 2 3 → 2 3 RxD
Received Data RxD, RD 3 2 ← 3 2 TxD
Request To Send RTS 4 7 → 8 5 CTS
Clear To Send CTS 5 8 ← 7 4 RTS
Signal Ground SG 7 5 Common 5 7 SG
Data Set Ready DSR 6 6 ← 4 20 DTR
Data Carrier Detect DCD, CD 8 1
Data Terminal Ready DTR 20 4 → 1 8 DCD
6 6 DSR

Applications

[edit]

The original application of a null modem was to connect two teleprinter terminals directly without using modems. As the RS-232 standard was adopted by other types of equipment, designers needed to decide whether their devices would have DTE-like or DCE-like interfaces. When an application required that two DTEs (or two DCEs) needed to communicate with each other, then a null modem was necessary.[4]

Null modems were commonly used for file transfer between computers, or remote operation. Under the Microsoft Windows operating system, the direct cable connection can be used over a null modem connection. The later versions of MS-DOS were shipped with the InterLnk program. Both pieces of software allow the mapping of a hard disk on one computer as a network drive on the other computer. No Ethernet hardware (such as a network interface card or a modem) is required for this.[5] On the Amiga computer, a null modem connection was a common way of playing multiplayer games between two machines.

The popularity and availability of faster information exchange systems such as Ethernet made the use of null modem cables less common. In modern systems, such a cable can still be useful for kernel mode development, since it allows the user to remotely debug a kernel with a minimum of device drivers and code (a serial driver mainly consists of two FIFO buffers and an interrupt service routine). KGDB for Linux, ddb for BSD, and WinDbg or KD for Windows can be used to remotely debug systems, for example. This can also provide a serial console through which the in-kernel debugger can be dropped to in case of kernel panics, in which case the local monitor and keyboard may not be usable anymore (the GUI reserves those resources and dropping to the debugger in the case of a panic won't free them).

Another context where these cables can be useful is when administering "headless" devices providing a serial administration console (i.e. managed switches, rackmount server units, and various embedded systems). An example of embedded systems that widely use null modems for remote monitoring include RTUs, device controllers, and smart sensing devices. These devices tend to reside in close proximity and lend themselves to short run serial communication through protocols such as DNP3, Modbus, and other IEC variants. The Electric, Oil, Gas, and Water Utilities are slow to respond to newer networking technologies which may be due to large investments in capital equipment that has useful service life measured in decades. Serial ports and null modem cables are still widely used in these industries with Ethernet just slowly becoming a widely available option.

Types of null modem

[edit]

Connecting two DTE devices together requires a null modem that acts as a DCE between the devices by swapping the corresponding signals (TD-RD, DTR-DSR, and RTS-CTS). This can be done with a separate device and two cables, or using a cable wired to do this. If devices require Carrier Detect, it can be simulated by connecting DSR and DCD internally in the connector, thus obtaining CD from the remote DTR signal. One feature of the Yost standard is that a null modem cable is a "rollover cable" that just reverses pins 1 through 8 on one end to 8 through 1 on the other end.[1]

No hardware handshaking

[edit]
Wiring pinouts for DB-25 (left) and DE-9 (right) connectors

The simplest type of serial cable has no hardware handshaking. This cable has only the data and signal ground wires connected. All of the other pins have no connection. With this type of cable flow control has to be implemented in the software. The use of this cable is restricted to data-traffic only on its cross-connected Rx and Tx lines. This cable can also be used in devices that do not need or make use of modem control signals.[1]

Loopback handshaking

[edit]
Wiring pinouts for DB-25 (left) and DE-9 (right) connectors

Because of the compatibility issues and potential problems with a simple null modem cable, a solution was developed to trick the software into thinking there was handshaking available. However, the cable pin out merely loops back, and does not physically support the hardware flow control.[1]

This cable could be used with more software but it had no actual enhancements over its predecessor. The software would work thinking it had hardware flow control but could suddenly stop when higher speeds were reached and with no identifiable reason.

Partial handshaking

[edit]
Wiring pinouts for DB-25 (left) and DE-9 (right) connectors

In this cable the flow control lines are still looped back to the device. However, they are done so in a way that still permits Request To Send (RTS) and Clear To Send (CTS) flow control but has no actual functionality. The only way the flow control signal would reach the other device is if the opposite device checked for a Carrier Detect (CD) signal (at pin 1 on a DE-9 cable and pin 8 on a DB-25 cable). As a result, only specially designed software could make use of this partial handshaking. Software flow control still worked with this cable.[1]

Full handshaking

[edit]
Wiring pinouts for DB-25 (left) and DE-9 (right) connectors

This cable is incompatible with the previous types of cables' hardware flow control, due to a crossing of its RTS/CTS pins. With suitable software, the cable is capable of much higher speeds than its predecessors. It also supports software flow control.[1]

Virtual null modem

[edit]

A virtual null modem is a communication method to connect two computer applications directly using a virtual serial port. Unlike a null modem cable, a virtual null modem is a software solution which emulates a hardware null modem within the computer.[6][7] All features of a hardware null modem are available in a virtual null modem as well. There are some advantages to this:

  • Higher transmission speed of serial data, limited only by computer performance and network speed
  • Virtual connections over local network or Internet, mitigating cable length restrictions
  • Virtually unlimited number of virtual connections
  • No need for a serial cable
  • The computer's physical serial ports remain free

For instance, DOSBox has allowed older DOS games to use virtual null modems.

Another common example consists of Unix pseudoterminals (pty) which present a standard tty interface to user applications, including virtual serial controls. Two such ptys may easily be linked together by an application to form a virtual null modem communication path.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Null modem

View on Grokipedia
from Grokipedia
A null modem is a specialized serial cable or adapter designed to facilitate direct communication between two (DTE) devices, such as computers or terminals, by crossing the transmit (TX) and receive (RX) signal lines, thereby simulating a modem-to-modem connection without requiring actual data communication equipment (DCE). This configuration allows for point-to-point data transfer, file sharing, and between compatible devices using standard serial ports. The concept of the null modem originated in the early days of , stemming from the need to connect terminals directly to each other without modems, leveraging the standard established in 1962 by the (EIA). Historically, was intended for DTE-to-DCE connections, but practical adaptations like the null modem emerged to enable DTE-to-DTE links, becoming widespread in the and for tasks such as , , and local networking before Ethernet dominance. Its name derives from "nullifying" the modem in the communication path, a technique that reused existing cabling infrastructure for efficient, low-cost direct serial links. Technically, a null modem cable typically features a DB-9 or DB-25 connector. For DB-9, the transmit signal (pin 3) is crossed to receive (pin 2) and vice versa, with ground (pin 5) connected straight-through. For DB-25, transmit (pin 2) is crossed to receive (pin 3) and vice versa, with ground (pin 7) straight-through. Additional handshaking lines, such as RTS/CTS or DTR/DSR, may be crossed or looped depending on the variant (e.g., for DB-9, RTS on pin 7 to CTS on pin 8; for DB-25, RTS on pin 4 to CTS on pin 5) to support flow control and ensure reliable data transmission, practically up to 115.2 kbps over short distances despite the standard's 20 kbps limit. Common applications included early PC-to-PC file transfers via protocols like XMODEM or Kermit, connecting terminals to mainframes, and interfacing industrial equipment, though its use has declined with the rise of USB, Ethernet, and technologies. Modern equivalents, such as USB-to-serial adapters with null modem emulation, preserve its utility in legacy systems and embedded applications.

Fundamentals

Definition and Purpose

A null modem is a specialized cable or that facilitates direct communication between two (DTE) devices, such as computers or terminals, using the serial interface standard. It achieves this by crossing the transmit data (TxD) and receive data (RxD) lines, effectively emulating the role of a (DCE) intermediary, like a , without requiring actual hardware. This crossover inverts the conventional DTE-to-DCE wiring, where TxD from one device connects directly to RxD on the other, and vice versa, while sharing a common signal ground. The primary purpose of a null modem is to enable point-to-point serial transfer, , and device control between compatible DTEs over short distances, bypassing the need for lines, modems, or broader network infrastructure. In early environments, where devices were inherently designed for DTE-to-DCE connections, this setup addressed the fundamental incompatibility of direct DTE-to-DTE links by simulating the intermediary DCE functionality. Common applications include between legacy systems, terminal emulation, and protocol testing in industrial or embedded setups. Key benefits of null modems include their simplicity in design and implementation, low cost compared to full modem-based systems, and high reliability for reliable, low-latency communication at data rates up to 115,200 bps. They are particularly suited for short-distance connections, with the standard specifying a maximum of 15 meters (50 feet) at typical speeds to maintain . This makes null modems an efficient solution for direct, unmediated serial interactions in scenarios where modern networking options are unavailable or impractical.

RS-232 Protocol Overview

The standard, formally known as EIA-232 and later revised as TIA/EIA-232-F, is a widely adopted protocol for serial binary data communication between (DTE), such as computers, and (DCE), such as modems. It specifies the electrical characteristics, signal timing, functional meanings of interchange signals, and mechanical connectors to enable reliable point-to-point links over asynchronous or synchronous modes. Originally developed in the early by the Electronic Industries Association (EIA), the standard has undergone multiple revisions to address evolving needs in data interchange, with the 1997 version (TIA/EIA-232-F) incorporating updates for compatibility with modern transceivers while maintaining backward compatibility. Central to RS-232 are its defined signals, which facilitate data transmission, control, and status monitoring. The primary data signals include Transmit Data (TxD or TD) for sending information from DTE to DCE and Receive Data (RxD or RD) for incoming data. Control and handshaking signals encompass Request to Send (RTS) to initiate transmission, Clear to Send (CTS) to acknowledge readiness, (DTR) to indicate DTE operational status, Data Set Ready (DSR) for DCE readiness, (DCD) to signal an active carrier, and Ring Indicator (RI) for incoming calls. All signals reference a common Signal Ground (GND) to establish a shared . These signals are assigned to specific pins on connectors designed for DTE devices, typically using a 25-pin (DB-25) connector for the full set of up to 25 signals or a more compact 9-pin variant (DE-9 or DB-9) that supports the most common subset, including TxD (pin 3), RxD (pin 2), RTS (pin 7), CTS (pin 8), DTR (pin 4), DSR (pin 6), DCD (pin 1), RI (pin 9), and GND (pin 5). Electrically, employs unbalanced, with bipolar voltage levels to represent binary states: a logic 0 (space) uses +3 V to +15 V, while a logic 1 (mark) uses -3 V to -15 V, with a transition region between -3 V and +3 V treated as invalid. Transmitters must drive signals within ±5 V to ±15 V, and receivers tolerate inputs up to ±25 V for robustness against . Timing is governed by rates, which define bits per second; common rates range from 110 to 115,200 , though the standard caps reliable operation at 20 kbps over specified cable loads. The protocol primarily operates in asynchronous mode, where start and stop bits frame each byte without a separate clock line, though synchronous modes use additional timing signals like Transmitter Clock (TC). Despite its ubiquity, has inherent limitations that constrain its performance. The unbalanced signaling is susceptible to and ground potential differences, making it less suitable for noisy environments compared to balanced alternatives like RS-422. Cable length is restricted by capacitive loading and signal attenuation, typically to about 15 meters (50 feet) at lower baud rates like 19.2 kbps, dropping to shorter distances at higher speeds due to the 2,500 pF maximum load specification. Additionally, the requirement for dual-rail power supplies (±12 V nominal) adds complexity, and while enhancements allow rates up to 1 Mbps, practical deployments often adhere to lower speeds for reliability.

Historical Development

Origins

The null modem concept emerged in the 1960s as a practical adaptation of the newly standardized serial communication protocol, which was introduced in 1962 to facilitate connections between (DTE) like teletypewriters (TTY) and for telephone-based data transmission. In environments where devices such as teleprinters needed to communicate locally within the same facility, using a full setup was inefficient and costly due to the need for telephone lines and associated hardware. Instead, engineers developed a simple cable configuration that crossed the transmit (TX) and receive (RX) lines, effectively simulating the role of a without the actual device—hence the term "null modem," originating from early efforts to connect teleprinters directly without . This approach allowed direct, short-distance connections for asynchronous serial data exchange, leveraging the voltage levels and signaling without remote transmission overhead. Early motivations for null modems stemmed from and settings during the and , where cost savings and simplified setup were paramount for interconnecting TTYs and teleprinters in newsrooms, research labs, or government offices. Early vendor documentation outlined interface specifications that could bypass modems for local loops, emphasizing reliable control signal handling like request-to-send (RTS) and clear-to-send (CTS) for error-free data flow. The technique gained traction amid the rise of systems, where direct cabling reduced expenses compared to dial-up modems. By the 1970s, null modems were popularized among early computer hobbyists and users for linking terminals directly to host systems, avoiding the expense of proprietary modems from vendors like . A notable early example was their use in Digital Equipment Corporation's PDP-11 s, introduced in 1970, where null modem cables facilitated console connections between the CPU and operator terminals for and system control in university and research environments. This hands-on adoption by hobbyists, often documented in technical newsletters and user groups, underscored the null modem's role in democratizing serial communications before the widespread availability of personal computers.

Adoption in Computing

The adoption of null modems surged in the alongside the proliferation of personal computers, enabling direct serial connections for file transfers between devices like the IBM PC and Commodore 64. These cables facilitated protocols such as XMODEM and Kermit, which allowed users to exchange data without modems or telephone lines, addressing the limitations of early drives and storage capacities. Null modems proved useful for local setups in hobbyist and educational environments. In the , null modems expanded into broader networking applications before Ethernet became dominant, supporting printer sharing and remote access in resource-constrained setups. They were integrated into operating systems like through utilities such as INTERLNK, which used null modem cables to link computers for drive and printer redirection, enabling without dedicated network hardware. This era saw null modems as a cost-effective bridge for small-office and home users transitioning from standalone PCs to interconnected systems. The decline of null modems began in the late 1990s and accelerated through the 2000s, driven by the rise of USB for peripherals, Ethernet for networking, and TCP/IP protocols that rendered physical serial links obsolete for most consumer applications. By 2004, major PC manufacturers ceased including ports as standard features, shifting reliance to USB-serial adapters for legacy needs, though support persisted in industrial and embedded systems. Key milestones included the evolution of null modem practices within EIA standards, starting with in 1962 and refined through revisions like EIA-232-D (1986) and TIA/EIA-232-F (1997), which formalized serial interfacing and indirectly supported null modem wiring for DTE-to-DTE connections. The last significant hardware advancements, such as improved cabling for higher rates, occurred around 2000, coinciding with the final wave of integration in consumer PCs.

Physical Implementations

Cables and Connectors

Null modem cables are constructed with shielded twisted-pair wiring, where multiple conductors—typically 24 AWG stranded tinned copper—are arranged in twisted pairs to reduce and , enclosed in an overall foil or braid for protection. These cables adhere to electrical specifications, with typical lengths ranging from 1 to 10 meters to maintain within the standard's limit of 2500 , equivalent to approximately 15 meters at rates up to 9600. Longer lengths risk signal degradation due to increased and . The primary connectors for null modem cables are the DB-25, which supports the full 25-pin standard, and the DE-9 (commonly called DB-9), a 9-pin variant used in simplified implementations for personal computers. These are usually configured as male-to-female to facilitate direct DTE-to-DTE connections, though male-to-male versions exist and require gender changers—short adapters that swap connector genders—for compatibility with standard serial ports. Insulation materials for null modem cables commonly include PVC for the outer jacket, offering flexibility, durability, and resistance to abrasion in general-purpose applications, while Teflon (PTFE) provides superior heat resistance up to 260°C and chemical inertness for specialized or harsh environments. Off-the-shelf null modem cables in these specifications are readily available from vendors like StarTech and C2G, often featuring molded hoods for strain relief and gold-plated contacts for reliable connectivity. These cables are optimized for RS-232 serial ports on legacy hardware such as older computers, terminals, and industrial equipment, ensuring direct peer-to-peer communication without a modem. In modern setups, USB-to-RS-232 adapters with built-in null modem options extend compatibility to USB-equipped devices, supporting the same wiring and length constraints.

Wiring Diagrams

Null modem wiring diagrams illustrate the internal connections required to cross over key signals between two (DTE) devices, effectively simulating the intermediary role of a . The fundamental crossover involves swapping the Transmit Data (TxD) and Receive Data (RxD) lines while maintaining a straight connection for Signal Ground (GND), enabling direct bidirectional communication. For the basic configuration without hardware handshaking, the wiring crosses TxD from one connector to RxD on the other and vice versa, with GND connected straight through. On a DE-9 (DB-9) connector, this means pin 3 (TxD) connects to pin 2 (RxD) on the opposite end, pin 2 (RxD) to pin 3 (TxD), and pin 5 (GND) to pin 5. Similarly, for DB-25 connectors, pin 2 (TxD) connects to pin 3 (RxD), pin 3 (RxD) to pin 2 (TxD), and pin 7 (GND) to pin 7. This minimal setup supports asynchronous serial data transfer at standard voltages, typically ±3 to ±15 V. A full DE-9 null modem diagram, including optional flow control lines, is shown below in table form for clarity:
Pin (End 1)SignalPin (End 2)Signal
2RxD3TxD
3TxD2RxD
5GND5GND
7 (optional)RTS8 (optional)CTS
8 (optional)CTS7 (optional)RTS
This configuration assumes male-to-male or female-to-female cabling, with the optional Request to Send (RTS)/Clear to Send (CTS) swap on pins 7 and 8 for basic hardware flow control compatibility. The DB-25 equivalent diagram follows the same crossover principle but uses the original 25-pin specification:
Pin (End 1)SignalPin (End 2)Signal
2TxD3RxD
3RxD2TxD
7GND7GND
4 (optional)RTS5 (optional)CTS
5 (optional)CTS4 (optional)RTS
Here, pins 2 and 3 handle the data lines, with optional pins 4 and 5 for RTS/CTS. Textual representations like can approximate these for quick reference, but physical implementation requires precise or crimping to avoid shorts. Safety considerations are paramount when constructing or using null modem cables: ensure all devices operate within voltage tolerances to prevent damage from or ground loops, and verify polarity before connection, as improper wiring can lead to or . Frame ground (pin 1 on DB-25) should be included where possible for protection.

Adapters and Variations

Null modem adapters provide modular solutions for adapting standard serial connections to null modem configurations, often incorporating crossover wiring internally to swap transmit and receive lines without requiring full cable replacement. Common types include DB-9 to DB-25 converters, which bridge the two prevalent connector standards used in interfaces, such as those featuring built-in null modem crossovers to facilitate compatibility between devices with mismatched pin counts. Gender changers, available in male-to-female (M/F) configurations, address mismatches by combining gender conversion with null modem functionality, allowing direct attachment to devices with opposite connector genders while crossing key signal lines. Variations extend to inline adapters that transform existing straight-through serial cables into null modem setups by inserting crossover logic at the connection point, typically using compact DB-9 male-to-male or female-to-female designs for seamless integration. USB null modem adapters emulate ports via USB interfaces, often employing chipset-based modules to provide a null modem DB-9 endpoint, enabling legacy on modern USB-equipped systems without native support. Custom builds offer flexible alternatives for specialized needs, such as DIY assemblies using RJ45 connectors over Cat5 cabling paired with DB-9 to RJ45 null modem adapters, which repurpose inexpensive Ethernet infrastructure for serial links up to 100 feet while maintaining . Loopback plugs, configured as short null modem-style connectors that internally route transmit to receive pins, serve as diagnostic tools for testing functionality by simulating a remote connection and verifying data . These adapters and variations remain widely available from suppliers, with modern products from manufacturers like USconverters and retailers such as Amazon typically priced between $5 and $20, depending on connector type and build quality.

Types Based on Handshaking

No Hardware Handshaking

The no hardware handshaking null modem represents the most basic implementation of a null modem cable, relying exclusively on the transmission lines without any involvement of control signals for flow . In this configuration, the transmit (TxD) line from one device is crossed over to the receive (RxD) line of the other device, and vice versa, while the signal ground (GND) lines are directly connected to provide a common reference; all other pins, including those for Request to Send (RTS), Clear to Send (CTS), (DTR), and Ready (DSR), are left unconnected or ignored. This minimal setup requires only three wires, making it suitable for direct device-to-device communication over short distances. This type of null modem is typically employed in low-speed, error-tolerant applications where reliable data exchange does not depend on hardware signaling, such as basic terminal emulation programs or interfacing with electronic measurement equipment that lacks control capabilities. It supports at baud rates low enough to prevent overwhelming the receiver, often using software-based pacing like XON/XOFF if any flow control is needed, and is ideal for scenarios requiring just 3-4 wires total. The key advantages of this configuration lie in its simplicity and cost-effectiveness, as it eliminates the need for additional wiring or circuitry associated with handshaking signals, thereby avoiding potential issues with incompatible flow control protocols. No hardware flow control means there are no delays or interruptions from signal assertions, allowing straightforward, uninterrupted data transfer in environments where the communicating devices operate at matched, conservative speeds. Despite these benefits, the absence of hardware handshaking provides no mechanism to pause transmission when a receiver's buffer approaches overflow, leading to potential or at higher data rates. Consequently, it is limited to slow asynchronous data transfers or applications with inherent , such as those using software oversight to manage throughput, and may cause hangs in software that expects carrier detect or other control signals to be present.

Loopback Handshaking

Loopback handshaking in null modems involves internally looping key control signals at each end of the connection to simulate a constant "ready" state, allowing direct communication between two (DTE) devices without requiring an intervening modem. In this configuration, the (DTR) signal is looped to both the (DCD) and Data Set Ready (DSR) pins on the same connector, while the Request to Send (RTS) signal is looped to the Clear to Send (CTS) pin, creating an "always on" status for these lines. The transmit data (TxD) and receive data (RxD) lines are crossed between the two ends, with the signal ground connected straight through. For a standard DE-9 (DB-9) connector, the wiring at each end includes connecting pin 4 (DTR) to pin 1 (DCD) and pin 6 (DSR), as well as pin 7 (RTS) to pin 8 (CTS), while the cross-connections between ends handle pins 2 (RxD) to 3 (TxD) and vice versa, with pin 5 (ground) shared. This setup tricks the connected devices into believing a is present and perpetually ready, which is particularly useful for legacy software or applications designed to interact with full modem control protocols under the standard. The primary purpose of handshaking is to ensure compatibility with programs that check for asserted control signals before initiating communication, preventing hangs or errors in environments assuming presence. However, it provides no genuine hardware flow control, as the looped signals do not dynamically respond to data flow between devices; instead, any necessary throttling must rely on software-based methods like XON/XOFF. Consequently, this approach carries risks of data loss or buffer overflows during high-speed transfers where actual handshaking would otherwise regulate throughput.

Partial Handshaking

In partial handshaking null modems, the transmit data (TxD) and receive data (RxD) lines are crossed between the two devices to enable direct communication, while the request to send (RTS) and clear to send (CTS) lines are crossed to support basic hardware flow control for pacing data transmission. The data terminal ready (DTR) and data set ready (DSR) lines are also crossed to indicate mutual readiness, and the carrier detect (DCD) line is connected to the RTS and CTS lines of the opposite device to simulate carrier presence based on flow control signals. For DE-9 (DB-9) connectors, the typical wiring diagram is as follows:
Pin (Connector 1)Connection to Connector 2Function
1 (DCD)7 and 8 (RTS/CTS)Carrier detect tied to opposite flow control
2 (RxD)3 (TxD)Receive Data
3 (TxD)2 (RxD)Transmit Data
4 (DTR)6 (DSR)Data Terminal Ready
5 (GND)5 (GND)Ground
6 (DSR)4 (DTR)Data Set Ready
7 and 8 (RTS/CTS)1 (DCD)Request/Clear to Send tied to opposite carrier
Pin 9 (ring indicator) is typically unused. This arrangement ensures compatibility with standards while providing limited control signals for flow and status. The primary advantage of partial handshaking is the provision of RTS/CTS for reliable data pacing and DTR/DSR crossing for readiness, which reduces the risk of buffer overflows at moderate speeds (e.g., up to 38.4 kbps) compared to configurations without handshaking, yet it avoids the added complexity of full signal emulation. This makes it suitable for applications where full status monitoring is unnecessary, such as direct connections to printers for output pacing or to modems requiring only basic flow control without extensive signaling. The RTS/CTS mechanism, as outlined in protocol specifications, allows one device to signal readiness before sending data, enhancing reliability in these scenarios.

Full Handshaking

The full handshaking null modem cable provides the most comprehensive emulation of modem-to-modem communication by crossing all primary data and control signals between two (DTE) devices, enabling robust direct serial connections under the standard. This configuration ensures that hardware flow control and status signaling operate as if each device were connected through a , supporting applications that rely on complete signal negotiation. In this setup, the transmit data (TxD) line is crossed with the receive data (RxD) line, the request to send (RTS) with clear to send (CTS) for flow control, and (DTR) with data set ready (DSR) for device readiness indication. The carrier detect (DCD) signal is often unconnected or optionally looped back locally to DSR at each end to simulate persistent carrier. Signal ground is directly connected between both ends to maintain a common reference. For a standard DE-9 (DB-9) connector, the typically involves seven wires and follows this pinout, where connections are made from Connector 1 to Connector 2:
Pin (Connector 1)SignalPin (Connector 2)Signal
2TxD3RxD
3RxD2TxD
4DTR6DSR
5Ground5Ground
6DSR4DTR
7RTS8CTS
8CTS7RTS
DCD (pin 1) at each end may be looped to pin 6 (DSR) locally if needed for carrier simulation; otherwise, it is unused. This diagram aligns with recommendations for full duplex operation. The primary purpose of full handshaking is to mimic the complete modem handshake process, including carrier detect assertion and bilateral readiness checks, which allows software designed for modem-mediated links—such as utilities or terminal emulators—to function without modification. This setup is particularly suited for environments requiring reliable status monitoring, as it prevents communication halts due to unasserted control signals. Advantages include full support for hardware flow control via dual signaling paths (RTS/CTS and DTR/DSR), enabling higher data rates without overruns, and comprehensive compatibility with legacy applications that enforce strict protocol adherence. It is ideal for complex serial applications, such as direct PC-to-PC networking in environments, where partial configurations might fail due to missing signal assertions.

Virtual and Software Implementations

Software Emulators

Software emulators, often referred to as virtual null modems, enable the simulation of a null modem connection entirely in software, eliminating the need for physical cables while allowing two applications or processes to communicate as if linked via an serial interface. These tools typically function through kernel-mode drivers that generate paired virtual COM ports—such as COM1 and COM2—on the same system, where data transmitted from one port is received by the other, mimicking a direct hardware crossover. Key features of these emulators include the replication of critical null modem behaviors, such as the interchange of Transmit Data (TxD) and Receive Data (RxD) signals, along with emulation of handshaking lines like (DTR), (DCD), Request to Send (RTS), and Clear to Send (CTS). They also accommodate standard parameters, including selectable baud rates (e.g., 9600 to 115200), parity options (none, even, odd), data bits (7 or 8), and stop bits (1 or 2), ensuring seamless integration with software expecting physical serial hardware. The widespread use of software null modem emulators emerged in the mid-2000s, driven by the availability of open-source Windows drivers that provided a reliable, hardware-free alternative for testing legacy serial-dependent applications during the transition to modern operating systems. A notable example is com0com, an open-source kernel-mode virtual serial port driver for Windows released under the GPL license, which supports unlimited pairs of virtual COM ports and includes utilities like hub4com for routing data and signals between ports. On Linux and other Unix-like systems, socat offers a command-line-based approach to creating virtual serial links via pseudo-terminals (PTY), facilitating null modem emulation for inter-process communication with configurable flow control and termios settings.

Modern Tools and Applications

In contemporary computing environments, virtual null modem tools have evolved to support software-based emulation of pairs, enabling seamless testing and development without physical hardware. FabulaTech's Virtual Serial Port Kit, for instance, creates unlimited pairs of virtual serial ports connected via a virtual null-modem cable, emulating full behavior including custom pinouts and overlapped operations. Released in version 5.9.5 on October 15, 2025, it runs as a Windows system service with command-line control for scripting automation. The tool supports baud rates up to 921600 bps, facilitating high-speed data transfer emulation suitable for modern debugging scenarios. Complementing proprietary solutions, freeware options like Free Virtual Serial Ports provide unlimited local port pairs using software null-modem emulation, with support for , , and standards. It includes features such as line signal emulation (DTR/DSR/CTS/RTS/DCD/RI), TX buffer overflow simulation, and serial noise generation for robust testing. As of 2025, it is enhanced for on ARM64 architectures, alongside x86/x64 compatibility, and offers an SDK with /COM and .NET components for scripting integration and data logging. All standard rates, including up to 921600 bps, are configurable, with automatic port restoration on reboot. Eltima's (now Electronic Team) Virtual Serial Port Driver further extends these capabilities by creating virtual COM ports paired through null-modem connections, with explicit support for managing hardware signal lines and emulating real port settings. Latest version released on November 14, 2024, it accommodates Windows 11/ARM platforms and integrates with USB-to-serial workflows via companion tools like USB Network Gate, allowing remote hardware access over Ethernet. Logging of serial data and scripting via API are built-in, supporting baud rates up to 921600 bps for development and QA processes. On systems, open-source alternatives address legacy gaps in proprietary coverage by providing kernel-level and user-space solutions. The tty0tty kernel module emulates null-modem pairs as virtual TTY devices under /dev/tty0tty*, enabling direct software connections without additional drivers, and has seen ongoing maintenance into 2025 for compatibility with recent kernels. For IP-to-serial bridging, ser2net facilitates TCP/UDP connections to physical or virtual serial ports, supporting RFC 2217 remote control and encryption via gensio libraries; its Docker image allows containerized deployment for isolated testing environments. Cross-platform scripting is achievable through Python's pyserial library, which interfaces with virtual ports on Windows, , and macOS, supporting baud rates up to 921600 bps and logging via custom scripts. These tools collectively enable scalable, hardware-agnostic serial emulation in 2025 pipelines.

Uses and Applications

Historical Applications

Null modem cables found widespread historical applications in computing during the late through the , enabling direct between devices in an era when network infrastructure was limited. One of the most common uses was for between personal computers, particularly in the and early , where they allowed two machines to connect directly via ports to exchange data using protocols like ZMODEM, which provided error detection and recovery for reliable transfers over low-speed serial links. This method was essential for users without access to modems or early networks, facilitating software sharing and backups in home and small office environments. In the realm of bulletin board systems (BBS), null modem cables enabled local direct connections between a user's computer and a host machine running BBS software, bypassing telephone lines and modems to simulate dial-up access. This was particularly popular in the among hobbyists and early online communities, allowing file downloads, message posting, and within schools, clubs, or shared spaces without incurring phone charges. Null modems were also critical for debugging and system maintenance tasks. For instance, they supported remote kernel debugging with tools like KGDB on systems, connecting two computers via so one could step through and inspect the kernel code of the other during development or . Similarly, they provided serial console access for loaders and headless servers, allowing administrators to monitor boot processes, enter commands, or recover systems without a local display or keyboard. In industrial and device control contexts of the , null modem cables interfaced computers with peripherals like printers and CNC machines in factories, enabling direct command transmission for operations such as printing reports or controlling machining processes over RS-232. For printers, which are typically DTE devices, null modems with like XON/XOFF were often employed to manage one-way data flow from host to printer. In early local area networks, they served as proxies by connecting user terminals or computers to serial ports on terminal servers, providing access to shared resources before widespread Ethernet adoption.

Contemporary and Legacy Uses

In contemporary applications, null modems continue to serve critical roles in across various industries. In industrial control environments, they facilitate direct between programmable logic controllers (PLCs) and remote terminal units (RTUs) using protocols like RTU over , enabling reliable data exchange in setups where modern networking is not yet implemented. For instance, null modem cables are commonly employed to connect PLCs for configuration, monitoring, and troubleshooting in and utility sectors. Similarly, in aviation simulators, null modems support interconnection between simulation hardware and input devices, such as in real-time flight systems where they ensure proper handshaking for control signals, often as part of ongoing for older training setups. In legacy equipment , technicians use null modems to link diagnostic tools directly to devices via ports, allowing for firmware updates and error logging without intermediaries. Modern niches have adapted null modems to bridge older serial interfaces with current hardware. In (IoT) deployments, devices like the act as serial gateways to connect sensors and legacy equipment, where null modems or adapters convert signals for integration into networked systems, such as or remote . USB-based null modems have become prevalent for legacy , providing a plug-and-play solution to emulate connections on computers lacking native serial ports; for example, FTDI's USB null modem cables enable direct PC-to-PC transfers or device emulation in development environments. Software emulators have largely supplanted physical null modems in application development and retrocomputing. Tools like DOSBox-X support virtual serial ports with null modem emulation, allowing developers to test DOS-era applications over simulated links, including network-based connections for multiplayer or scenarios. This virtual approach dominates in and hobbyist projects, offering flexibility without hardware dependencies. Despite these uses, null modems are declining in favor of alternatives like serial adapters, Ethernet, and , which provide higher speeds and easier integration in new systems. However, they persist in utilities and embedded applications requiring robust, low-level where compatibility with existing infrastructure is essential.

References

  1. https://www.assured-systems.com/faq/what-is-a-null-modem-cable/
  2. https://www.usconverters.com/null-modem-cable-pin-out
  3. https://www.sfcable.com/blog/features-null-modem-cables
  4. https://www.lammertbies.nl/comm/info/rs-232-null-modem
  5. https://www.analog.com/en/resources/technical-articles/fundamentals-of-rs232-serial-communications.html
  6. https://www.showmecables.com/blog/post/what-is-a-null-modem-cable
  7. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9w0SAC&l=en-US
  8. https://www.maxlinear.com/appnote/ani-14_dteordce_120406_b.pdf
  9. https://www.ni.com/docs/en-US/bundle/ni-serial/page/rs-232-dte-versus-dce.html
  10. https://www.eltima.com/article/what-is-null-modem-cable/
  11. http://www.nullmodem.com/NullModem.htm
  12. https://tripplite.eaton.com/products/rs-232-serial-to-usb-adapters
  13. https://www.ti.com/lit/an/slla607/slla607.pdf
  14. https://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
  15. https://support.biamp.com/Biamp_Control/Biamp_Control_Technologies/RS-232_Everything_you_need_to_know
  16. https://www2.advantech.com/ia/newsletter/ADAMLink/August2004/ADAM%2520FAQ%2520-%2520What%2520is%2520Null%2520Modem.htm
  17. http://bitsavers.org/pdf/dec/unibus/DEC-11-HDCD-D_DC11_Asynchronous_Line_Interface_Sep73.pdf
  18. https://stewart.sdsu.edu/SDSU/SCRUNCH/94Nash-SCPCs.pdf
  19. http://www.columbia.edu/cu/computinghistory/dec20.html
  20. https://ia801204.us.archive.org/33/items/msdos_manual_622/msdos_manual_622.pdf
  21. https://www.volersystems.com/blog/news/63-usb-ports-replacing-serial
  22. https://www.auvik.com/franklyit/blog/history-of-serial-cables/
  23. https://www.ti.com/lit/an/slla037a/slla037a.pdf
  24. https://www.belden.com/products/cable/electronic-wire-cable/multi-conductor-cable/9502
  25. https://www.awcwire.com/data-and-communication-cable/computer-cable/low-capacitance-multi-paired-foil-shield-rs-232
  26. https://www.lammertbies.nl/comm/info/rs-232-specs
  27. https://www.cablematters.com/Blog/Computer-Accessories/what-is-rs232
  28. https://www.virtual-serial-port.org/article/what-is-serial-port/rs232-pinout/
  29. https://www.showmecables.com/db9-female-to-db25-male-null-modem-serial-cable
  30. https://www.electroprep.com/blog/pvc-vs-teflon-insulated-wire/
  31. https://www.startech.com/en-us/cables/scnm9fm
  32. https://www.cablestogo.com/cables/pc/serial-rs232-cables/25ft-7-6m-db25-male-to-db9-female-serial-rs232-null-modem-cable/p/cg-03023
  33. http://www.columbia.edu/kermit/cable.html
  34. https://zytrax.com/tech/layer_1/cables/tech_rs232.htm
  35. https://www.l-com.com/d-sub-slimline-db9-or-db25-null-modem-and-reversers-communicate-without-modems
  36. https://www.serialcomm.com/serial_and_fiber_optic_accessories/serial_gender_changers.aspx
  37. https://www.eagleg.com/products/db9-m-m-null-modem-adapter
  38. https://ftdichip.com/products/usb-nmc-2-5m/
  39. https://tripplite.eaton.com/null-modem-serial-rs232-modular-adapter-kit-2x-db9f-to-rj45f~P450000
  40. https://www.passmark.com/products/loopback/index.php
  41. https://www.usconverters.com/db9-null-modem-adapter
  42. https://www.amazon.com/Null-Modem-Adapter-Male-Pack/dp/B07GV5PGJ5
  43. https://www.ti.com/lit/ug/tidua07a/tidua07a.pdf
  44. https://www.cisco.com/c/en/us/support/docs/dial-access/asynchronous-connections/17719-9.html
  45. https://www.network-serial-port.com/network-serial-port-kit-help/using-different-null-modems.html
  46. https://qsupport.quantum.com/pf/18/webfiles/RS232_straight_through_versus_Null_Modem_serial_cables.pdf
  47. https://www.virtual-serial-port.com/virtual-serial-port-kit-help/using-different-null-modems.html
  48. https://www.raveon.com/ApplicationNotes/AN236(SerialComm).pdf
  49. https://sourceforge.net/projects/com0com/
  50. https://sourceforge.net/p/com0com/news/2007/06/null-modem-emulator-com0com-v1800-released/
  51. http://www.dest-unreach.org/socat/
  52. https://www.fabulatech.com/virtual-serial-port-kit.html
  53. https://freevirtualserialports.com/
  54. https://www.virtual-serial-port.org/
  55. https://www.eltima.com/virtual-com-port-windows-10/
  56. https://github.com/lcgamboa/tty0tty
  57. https://github.com/cminyard/ser2net
  58. https://hub.docker.com/r/jippi/ser2net
  59. https://pyserial.readthedocs.io/en/latest/pyserial.html
  60. https://www.jamesfmackenzie.com/2016/02/13/use-rs232-serial-cable-and-zmodem-to-transfer-files-from-pc-to-st/
  61. https://www.linuxjournal.com/article/4525
  62. https://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/
  63. https://www.lammertbies.nl/comm/cable/rs-232-serial-printer
  64. https://www.usenix.org/legacy/publications/library/proceedings/usenix98/freenix/matheson.pdf
  65. https://maplesystems.com/tutorial/how-to-set-up-your-maple-plc-as-a-modbus-rtu-master-device/
  66. https://www.crossco.com/blog/communicating-modbus-over-cell-modems/
  67. https://apps.dtic.mil/sti/tr/pdf/ADA230469.pdf
  68. https://bering-uclibc.zetam.org/wiki/Bering-uClibc_7.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_a_Raspberry_PI_as_a_net_to_serial_gateway
  69. https://www.compulab.com/products/iot-gateways/iot-gate-rpi-industrial-raspberry-pi-iot-gateway/
  70. https://www.startech.com/en-us/cards-adapters/icusb232ftn
  71. https://dosbox-x.com/
  72. https://dosbox-x.com/release-0.83.21.html
  73. https://hhdsoftware.com/virtual-serial-ports
  74. https://www.sfcable.com/blog/db9-serial-cable-vs-null-modem-understanding-key-differences-and-applications
  75. https://www.flywing-tech.com/blog/what-is-rs232/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.