Null Modem Cable

Introduction

 

Serial communications with RS232. One of the oldest and most widely spread communication methods in computer world. The way this type of communication can be performed is pretty well defined in standards. I.e. with one exception. The standards show the use of DTE/DCE communication, the way a computer should communicate with a peripheral device like a modem. For your information, DTE means data terminal equipment (computers etc.) where DCE is the abbreviation of data communication equipment (modems). One of the main uses of serial communication today, DTE/DTE communication is not so well defined, especially when it comes to flow control.

 

In the years, practical solutions were developed to let two computers talk with each other using a serial communication line. In most situations, the original modem signal lines are reused to perform handshaking. Handshaking can increase the maximum allowed communication speed because it gives the computers the ability to control the flow of information. High amounts of incomming data is allowed if the computer is capable to handle it, but not if it is busy performing other tasks. If no flow control is implemented, communication is only possible at speeds at which it is sure the receiving side can handle the amount information even under worst case conditions.

 

Original use

 

When we look at the connector pinout of the RS232 port, we see two pins which are certainly used for flow control. These two pins are RTS, request to send and CTS, clear to send. With DTE/DCE communication (i.e. a computer communicating with a modem device) RTS is an output on the DTE and input on the DCE. CTS is the answering signal comming from the DCE.

 

Before sending a character, the DTE asks permission by setting its RTS output. No information will be sent until the DCE grants permission by using the CTS line. If the DCE cannot handle new requests, the CTS signal will go low. A simple but useful mechanism allowing flow control in one direction. The assumption is, that the DTE can always handle incomming information faster than the DCE can send it. In the past, this was true. Modem speeds of 300 baud were common and 1200 baud was seen as a high speed connection.

 

For further control of the information flow, both devices have the ability to signal their status to the other side. For this purpose, the DTR data terminal ready and DSR data set ready signals are present. The DTE uses the DTR signal to signal that it is ready to accept information, whereas the DCE uses the DSR signal for the same purpose. Using these signals involves not a small protocol of requesting and answering as with the RTS/CTS handshaking. These signals are in one direction only.

 

The last flow control signal present in DTE/DCE communication is the CD carrier detect. It is not used directly for flow control, but mainly an indication of the ability of the modem device to communicate with its counter part. This signal indicates the existence of a communication link between two modem devices.

 

No handshaking

 

How to use the handshaking lines in a null modem configuration? The simplest way is to don't use them at all. In that situation, only the data lines and signal ground are cross connected in the communication cable. All other pins have no connection. An example of such a cable without handshaking can be seen in the figure below.

 

Simple null modem without handshaking

 

simple null

 

Compatibility issues

 

If you read about null modems, this three wire null modem cable is often talked about. Yes, it is simple but can we use it in all circumstances? There is a problem, if either of the two devices checks the DSR or CD inputs. These signals normaly define the ability of the other side to communicate. As they are not connected, their signal level will never go high. This might cause a problem.

 

The same holds for the RTS/CTS handshaking sequence. If the software on both sides is well structured, the RTS output is set high and then a waiting cycle is started until a ready signal is received on the CTS line. This causes the software to hang because no physical connection is present to either CTS line to make this possible. The only type of communication which is allowed on such a null modem line is data-only traffic on the cross connected RX/TX lines.

 

This does however not mean, that this cable is useless. Communication links like present in the Norton Commander program can use this cable. This cable can also be used when communicating with devices which do not have modem control signals like electronic measuring equipment etc.

 

As you can imagine, with this simple cable no hardware flow control can be implemented. The only way to perform flow control is with software flow control using the XOFF and XON characters.

 

Loop back handshaking

 

The simple null modem cable without handshaking shows incompatibilities with common software. The main problem with this cable is that there is a possibility for the software to hang if it checks the modem signal lines in a proper way. I.e. with this cable, good written programs will perform worse than badly written programs.

 

To overcome this problem and still be able to use a cheap communication cable with only three lines in it, a fake cable layout has been defined. The null modem cable with loop back handshaking resulted from this.

 

Null modem with loop back handshaking

 

 

The main purpose of this cable is to let well defined software think there is handshaking available, with a cable which has no provisions for it.

 

Compatibility issues

 

Consider first the DSR signal (pin 6). This input indicates that the other side is ready to start communicating. In the layout, the line is linked back to the DTR output (pin 4). This means, that the software doesn't see the ready signal of the other device, but its own. The same holds for the CD input (pin 1). The assumption is, that if software has been written to check the DSR line to test communication availability, it will probably also set the DTR output to indicate its own state. This is true for at least 99% of all serial communication software. This implies that at least 99% of all serial communication software is capable of faking its own DSR check with this cable.

 

The same trick is used with the CTS input. In the original use, RTS is set, and then CTS is checked before starting the communication. By setting the RTS output (pin 7) the CTS input on the same connector (pin 8) is receiving clearance immediately. There is no possibility of a software hangup because of dangling RTS requests.

 

Other issues to consider

 

The null modem cable with loop back handshaking is often advised as the best low cost available cable. But, is it really so good? The simple cable without handshaking has the disadvantage that it does not permit proper written software to communicate with it. Software which is aware of the lack of handshaking signals can however use it without problems.

 

The cable with loop back handshaking can be used with more software, but it has no functional enhancements over the simple cable! There is no way both devices can control data flow, other than by using XON/XOFF handshaking. If the software is designed for using hardware flow control it seems to work with this cable, but on unpredictable moments, data loss may occur. This means that the cable allows communication as long as no flow control is needed, but when data speeds reach the limit the receivers can handle, communication may stop immediately without an assignable reason. Therefore, although this cable is cheap and easy to make, use it with care! Despite these warnings, this type of cable has been successfully used between Windows 95/98 computers with a Direct Cable Connection.

 

Partial handshaking

 

The simple null modem cable and the cable with loop back handshaking are useful, but have no provisions for hardware flow control. If it is absolutely necessary that hardware flow control is used, the null modem with partial handshaking can be an alternative.

 

Null modem with partial handshaking

 

Compatibility issues

 

This cable is the best of two worlds. There is the possibility of hardware flow control without being incompatible with the original way flow control was used with DTE/DCE communication. Let us first consider the RTS/CTS flow control lines present on pins 7 and 8. As with the loop back cable, these signals are not connected to the other device, but directly looped back on the same connector. This means, that RTS/CTS flow control is allowed to be used in the software, but it has no functional meaning. Only when the software at the other side checks the CD signal at pin 1, the RTS information will reach the other device. This would however be only the case in specifically developed software which uses the CD input for this purpose.

 

More important however is the cross connection of the DSR (pin 6) and DTR (pin 4) lines. By cross connecting these lines, their original function is simulated pretty well. The DTR output is used to signal the other device that communication is possible. This information is read on the DSR input, the same input used for this purpose with modem communication. Because of this cross connection, the DTR output line can be used for simple flow control. Incomming data is allowed when the output is set, and blocked if the output is not set.

 

Software using only the RTS/CTS protocol for flow control cannot take advantage of the partial handshaking cable. Most software however will also check the DSR line and in that case, using the null modem cable with partial handshaking, the best possible hardware flow control can be achieved which is still compatible with the original use with modems.

 

Full handshaking

 

The most expensive null modem cable is the cable suitable for full handshaking. In this cable, seven wires are present. Only the ring indicator and carrier detect signal are not linked. The cable is shown in the following figure.

 

Null modem with full handshaking

Compatibility issues

 

The null modem cable with full handshaking does not permit the older way of flow control to take place. The main incompatibility is the cross connection of the RTS and CTS pins. Originally, these pins are used for a question/answer type of flow control. When the full handshaking cable is used, there is no request anymore. The lines are purely used for telling the other side if communication is possible.

 

The main advantage of this cable is, that there are two signalling lines in each direction. Both the RTS and DTR outputs can be used to send flow control information to the other device. This makes it possible to achieve very high communication speeds with this type of cable, provided that de software has been designed for it. Because of the high possible connection speed, this cable can be used with Interlink to connect two MS-DOS PC's.

 

Null modem selection table

 

The right null modem cable to choose mainly depends on the application and the software that will be used. As a general guide line, I would advise the following.

 

Choose your null modem cable

 

Use

Simple cable

without

handshaking

Cable with

loop back

handshaking

Cable with

partial

handshaking

Cable with

full

handshaking

Software flow

control only

+++

++

+

+

DTE/DCE compatible

hardware flow control

at low speeds

-

+++

++

-

DTE/DCE compatible

hardware flow control

at high speeds

-

+

+++

-

High speed

communication

using special software

-

-

++

+++

 

+++

++

+

-

Recommended cable

Good alternative

Works, but not recommended

Does not work

 

The cable with partial handshaking works in most cases. If you are developing software which must work with all kinds of cables, it is best to use only software flow control and ignore all modem control inputs.