There are several pinout schemes of virtual null modems. Three lines null modem (without handshaking) is simplest where only the data lines are cross connected in the null modem communication. It’s simplest and can’t be used in all circumstances because there is a problem, if either of the two applications checks the DSR or DCD inputs. These signals normally 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. As you can imagine, with this simple null modem 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. Virtual Serial Port Kit doesn’t use simplest null modem.
Loop Back Handshaking
The main purpose of this virtual null modem is to let well defined software thinks that there is handshaking available, with a null modem which has no provisions for it.
DSR signal indicates that the other side is ready to start communicating. In the layout, the line is linked back to the DTR output. This means, that the software does not see the ready signal of the other application, but its own. The same occurs for the DCD input. 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 means that at least 99% of all serial communication software is capable of faking its own DSR check with this null modem. The same way 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 to the CTS input there is no possibility for software hang up because of dangling RTS requests.
The null modem with loop back handshaking can be used with more software, but it has no functional enhancements over the simplest null modem. There is no way both applications 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 null modem, but on unexpected moments, data loss may occur. This means that the null modem 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 visible reason.
In this scheme DTR to RI and DTR to DCD connections are optional.
Partial-1 Handshaking
Partial-2 Handshaking
This null modem scheme with partial handshaking can be setup if it’s absolutely necessary that hardware flow control is used. In general Partial-2 handshaking scheme is used more frequently.
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. As with the loop back handshaking scheme, these signals are not connected to the other application, 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 DCD signal, the RTS information will reach the other application. This would however be only the case in specifically developed software which uses the DCD input for this purpose.
More important however is the cross connection of the DSR and DTR lines. By cross connecting these lines, their original function is simulated pretty well. The DTR output is used to signal the other application 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. Incoming 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 null modem scheme. Most software however will also check the DSR line and in that case the best possible hardware flow control can be achieved.
In those schemes DTR to RI connection is optional.
Full Handshaking
The main advantage of this scheme is, that there are two signaling lines in each direction. Both the RTS and DTR outputs can be used to send flow control information to the other application. This makes it possible to achieve very high communication speeds with this type of null modem, provided that the software has been designed for it.
At the same time the null modem 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 lines. Originally, these lines were used for a question/answer type of flow control. When the full handshaking null modem is used, there is no request anymore. The lines are purely used for telling the other side if communication is possible.
In this scheme DTR to RI and DTR to DCD connections are optional.