Null modem, an 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 where no modem is involved—a serial null modem configuration with DTE / DTE communication—is not so well defined, especially when it comes to flow control. The terminology null modem for the situation where two computers communicate directly is so often used nowadays, that most people don't realize anymore the origin of the phrase and that a null modem connection is an exception, not the rule.
In history, practical solutions were developed to let two computers talk with each other using a null modem serial communication line. In most situations, the original modem signal lines are reused to perform some sort of 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 in the null modem connection, 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 of RS232
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.
Null modem without 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 null modem communication cable. All other pins have no connection. An example of such a null modem cable without handshaking can be seen in the figure below.
Connector 1 Connector 2 Function
| 2 | 3 | Rx | Tx | |
| 3 | 2 | Tx | Rx | |
| 5 | 5 | Signal ground |
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 null modem cable is useless. Communication links like present in the Norton Commander program can use this null modem cable. This null modem 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 null modem 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.
Null modem with 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 null modem cable, good written programs will perform worse than badly written programs.
To overcome this problem and still be able to use a cheap null modem communication cable with only three lines in it, a fake null modem cable layout has been defined. The null modem cable with loop back handshaking resulted from this.
Connector 1 Connector 2 Function
| 2 | 3 | Rx | Tx | |
| 3 | 2 | Tx | Rx | |
| 5 | 5 | Signal ground | ||
| 1 + 4 + 6 | - | DTR | CD + DSR | |
| - | 1 + 4 + 6 | DTR | CD + DSR | |
| 7 + 8 | - | RTS | CTS | |
| - | 7 + 8 | RTS | CTS |
The main purpose of this null modem cable is to let well defined software think there is handshaking available, with a null modem 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 null modem 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 null modem cable. But, is it really so good? The simple null modem 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 null modem 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 null modem cable, but on unpredictable moments, data loss may occur. This means that the null modem 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 null modem cable is cheap and easy to make, use it with care! Despite these warnings, this type of null modem cable has been used successfully between Windows 95/98/ME computers with a Direct Cable Connection.
Null modem with partial handshaking
The simple null modem cable and the null modem 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.
Connector 1 Connector 2 Function
| 1 | 7 + 8 | RTS 2 | CTS 2 + CD 1 | |
| 2 | 3 | Rx | Tx | |
| 3 | 2 | Tx | Rx | |
| 4 | 6 | DTR | DSR | |
| 5 | 5 | Signal ground | ||
| 6 | 4 | DSR | DTR | |
| 7 + 8 | 1 | RTS 1 | CTS 1 + CD 2 |
Compatibility issues
This null modem 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 null modem 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 null modem cable. Most software however will also check the DSR line and in that case—when 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.
Null modem with full handshaking
The most expensive null modem cable is the null modem cable suitable for full handshaking. In this null modem cable, seven wires are present. Only the ring indicator RI and carrier detect CD signal are not linked. The cable is shown in the following figure.
Connector 1 Connector 2 Function
| 2 | 3 | Rx | Tx | |
| 3 | 2 | Tx | Rx | |
| 4 | 6 | DTR | DSR | |
| 5 | 5 | Signal ground | ||
| 6 | 4 | DSR | DTR | |
| 7 | 8 | RTS | CTS | |
| 8 | 7 | CTS | RTS |
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 null modem 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 null modem cable, provided that the software has been designed for it. Because of the high possible connection speed, this null modem cable can be used with Interlink to connect two MS-DOS PC's.
This is the type of cable Microsoft recommends for the direct cable connection in their knowledge base article . For the DB9 connector they also added a connection of DTR to CD on each connector but they didn't define this connection for the DB25 connector version and they also didn't mention the CD input in the descriptive text, so it is safe to leave the CD input disconnected.
Null modem layout 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.
Cable withouthandshaking Loop backhandshaking Partialhandshaking Fullhandshaking
|
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 null modem 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 software flow control only and ignore all modem control inputs.
Software for file transfers
The main use of null modem cables is file transfer between two computers. Several software is available for this task, but if you haven't made a choice yet, I would like to recommend the WinXFer program from Willies Computer Software Co. The software is capable to run in three modes. An easy Windows user interface can be used for interactive file transfer. There is also a command line version of the utility available which can be run in the background by batch files, schedulers etc. and the program is shipped with DLL's which can be linked to your own programs to make your own file transfer applications. The API can be used both by Visual C/C++ programs and Visual Basic. Beside transfer over a direct serial null modem line, the program is also capable of file transfer between computers which are connected using a telephone lines and Hayes compatible modems.
If you are interested you can buy this software on-line here . The product is available for immediate download!
**************************************
**************************************
Null modem
From Wikipedia, the free encyclopedia
Null modem is a communication method to connect two DTEs ( computer , terminal , printer etc.) directly using a RS-232 serial cable . The RS-232 standard is asymmetrical as to the definitions of the two ends of the communications link so it assumes 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 a standard .
Contents[ hide ] |
[ edit ] Origin of the term
Originally, the RS-232 standard was developed and used for teletype machines which could communicate with each other over phone lines. Each teletype 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 teletypes. If a user wished to connect two teletypes directly without modems (null modem) then they would crosslink the connections. The term null modem may also refer to the cable or adaptor itself as well as the connection method.
[ edit ] Null modem cables and adapters
A null modem cable is an 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.
[ edit ] Null modem cable pin mapping
This is one very common mapping which will work with software that relies on proper assertion of the CD signal.
| Signal Name | DB-25 Pin | DE-9 Pin | DE-9 Pin | DB-25 Pin | ||
| FG (Frame Ground) | 1 | - | X | - | 1 | FG |
| TD (Transmit Data) | 2 | 3 | - | 2 | 3 | RD |
| RD (Receive Data) | 3 | 2 | - | 3 | 2 | TD |
| RTS (Request To Send) | 4 | 7 | - | 8 | 5 | CTS |
| CTS (Clear To Send) | 5 | 8 | - | 7 | 4 | RTS |
| SG (Signal Ground) | 7 | 5 | - | 5 | 7 | SG |
| DSR (Data Set Ready) | 6 | 6 | - | 4 | 20 | DTR |
| CD (Carrier Detect) | 8 | 1 | - | 4 | 20 | DTR |
| DTR (Data Terminal Ready) | 20 | 4 | - | 1 | 8 | CD |
| DTR (Data Terminal Ready) | 20 | 4 | - | 6 | 6 | DSR |
[ edit ] Applications
The original application of a null modem was to connect two teletype 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 DTE's (or two DCE's) needed to communicate with each other, then a null modem was necessary.
Null modems are 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.
The popularity and availability of faster information exchange systems such as Ethernet made the use of null-modem cables less common. Nowadays, such a cable can still be useful to kernel hackers though, 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 ). ddb or KGDB can be used to remotely debug BSD systems, for instance. 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 X11 server reserves those resources if a GUI is used, and dropping to the debugger in the case of a panic won't free them).
[ edit ] Types of null modem
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.
[ edit ] No hardware handshaking
The most simplistic 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.
[ edit ] Loop back handshaking
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.
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.
[ edit ] Partial handshaking
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.
[ edit ] Full handshaking
This cable is the most expensive of the serial cables because it has full wiring and pin-outs. 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.
[ edit ] Virtual null modem
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. 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 by computer performance only).
- Virtual connection over network or Internet is possible, mitigating cable length restrictions.
- An unlimited number of virtual connections is possible.
- No serial cable is needed.
- 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 pseudo terminals (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.
[ edit ] See also
- Crossover cable
- Rollover cable
- Serial cable
- Direct cable connection
- InterLnk
- Debugging
- Serial Line Internet Protocol (SLIP)
- LapLink cable (can be seen as a parallel equivalent to a serial null modem cable)
[ edit ] External links
- http://ourworld.compuserve.com/homepages/harburg/Link2PCs.htm
- http://www.angelfire.com/ma/mantasdos/interlnk.html
- http://www.daniel-hertrich.de/rs232/
- http://www.nullmodem.com/NullModem.htm
- http://www.lammertbies.nl/comm/info/RS-232_null_modem.html
- http://www.hardwarebook.info/Nullmodem_(9-9)
- http://sourceforge.net/projects/com0com
- http://adtpro.sourceforge.net/connectionsserial.html#MiniDIN8
- http://developer.berlios.de/projects/n8vbvcomdriver/
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長非常感激您！手機(jī)微信長按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
