THE COMPUTER NETWORK OPTIMIZATION EXPERTS !

 

Connecting DTE's     

Compendium Index Up

CONNECTION BETWEEN TWO DTE DEVICES

With the preceding thoughts in mind, you can realize that a problem will exist if we try to connect two DTE devices directly to each other. A "sending" pin on one device will be sending a signal (control, timing, or data) to a corresponding "sending" pin on the other side. This isn't going to work!

Let's power up two computers and use the breakout box to cross connect them. This is the classic DTE-to-DTE connection. If you would like to use this section as a "self study", you can scroll so that you only see the questions, or cover up the screen with a piece of paper as you read. Each time you are asked a question, the answer is given in the following paragraph. You are encouraged to use this approach the first time you read this section -- you can challenge yourself with the material.

Breakout box graphic

You have set the switches on the breakout box to disconnect the #1 DTE from the #2 DTE (on the breakout box the #2 DTE is connected to the DCE side of the box -- no matter -- it's just that that's the way the breakout box is marked. Notice that the switch connections are removed from the picture, indicating that there is no connection between the two sides.

Notice that both DTE's are asserting DTR -- they are both operational. What should the right hand DTE be receiving from a DCE (if a real DCE were connected?)

The DTE is expecting DSR in response to DTR. How can a DSR signal be supplied to the DTE? Where can we derive an asserted signal line that would make sense to substitute for the missing DSR?

You can cross-connect the DTR on the left to the DSR on the right, and vice-versa. It's no accident that the RS-232 spec provides a way to cross connect two DTR's. Instead of a real DSR signal, let's connect the left hand DTE's signal on the DTR line across to the DSR on the right. We'll do the same thing in the reverse direction. In this way both DTE's will believe that they are getting DSR from a DCE. In fact, they both will simply be observing the other one's DTR line.

Breakout box graphic

The breakout box provides a way to cross connect any pin to any other pin. We have now cross connected DTR and DSR. The breakout box shows that the DSR line is active on both sides. This is because the DSR line is being asserted (powered) from the DTR lines to which they are cross connected.

Now that the #1 DTE (on the left) has perceived the assertion of DSR, what other change has occurred? Examine the breakout box to see the effect of giving DSR to the DTE.

The #1 DTE is now indicating that it has data to send; it has asserted the RTS line on the right. What does the right hand DTE need before it can send its data?

It needs CTS to be asserted. Where can we get an asserted signal that would be reasonable to connect back to CTS to provide the handshake?

Let's connect RTS back to CTS on the right hand side. We'll do this on both sides and both sides will simply provide a looped-back CTS to themselves. The breakout box will now be configured as shown below.

Breakout box graphic

All right, look at the breakout box and reflect on what you see. Why is CTS now asserted on the right hand side?

Because you have connected RTS to CTS the RTS signal is asserting the CTS line. Now, why is the TD light active on the DTE on the right?

The DTE has seen CTS asserted and it is now trying to send data on the Transmitted Data line. Remember that "transmitted" means "transmitted from the DTE to the DCE". Where will the transmitted data line be connected?

Breakout box graphic

The transmitted data coming from the DTE on the right (through the TD line) will be received by the DTE on the left on the RD pin. From the perspective of the DTE on the left the "other side" is the DCE. Consequently, from the viewpoint of the DCE, data is transmitted on the TD line. A DTE is constructed to receive data from a DCE on the TD line.

By cross connecting TD and RD we have provided a bi-directional data path for both DTE's to talk to each other. The TD light on the right goes on as the data is sent across.

What we've just done is to build a Null Modem connection between the two DTE's. By wiring a cable in conformance with the cross connects we discovered using the breakout box we can install a permanent interconnection between the two DTE's. There is a concern here, however. What will happen when one side of the connection runs significantly faster than the other side. With a modem, the transmission speed (on the phone line) is controlled by the interface speed on the RS-232 line. The computer can't send faster than the phone line because the whole implementation is speed controlled from computer to phone line. On the other hand, when sending data to a printer there comes a time when the printers buffer fills up and the flow of data must be shut off (while the page is printed). If we were to interface a printer using the above described null modem cable there would be no way for the printer to say, "Enough!".

When the hardware control signals are used to manage data flow the rule is that a DTE may not transmit until CTS is asserted. One common implementation is to use RTS on the DTE to cause a modem to start the dialing process. Once the modem has synched up with its partner it asserts its Carrier Detect (CD) line. The CD line is cross connected from Pin 8 (CD) on the DCE to Pin 5 (CTS) on the DTE. Sometimes the modem is configured with a timer that simply waits some number seconds between receiving RTS and asserting CD. The time delay is selected (by configuration) to be long enough to allow the modem to reasonably establish communications.

DSR (Pin 6) is normally used to mean that the DCE is on-line and not in a self-test mode -- the DCE is "ready". If DSR means "ready" then CTS means "go ahead and send". On the other hand, DSR may be used to indicate a "modem off hook" indication. Also, an autoanswer modem may assert DSR when a call comes in. It's all up to the designer of the software. It's the device driver software that is configured for the particulars of the handshaking. The RS-232 circuitry can respond in a wide variety of ways, depending on its configuration.

The essence of RS-232 troubleshooting is the correlation of configurations between the two ends of the connection. Not only must the simple configurations match (like word length, start/stop bits, parity, baud rate) but the handshaking must be agreed upon as well.

Instead of using the RS-232 hardware to control the flow of data, a software flow control structure could be implemented in the device driver. One common approach is to use the ASCII characters called XON (pronounced "EX-ON") and XOFF (pronounced "EX-OFF"). The XON character is an ASCII code number 19 (Control S) and the XOFF character is ASCII code 17 (Control Q). When the DTE that's receiving data wants to stop the flow it transmits an XOFF character back to the other DTE. When it's ready to receive again, it transmits an XON. You will discover that one of the configurations that you must typically specify when you setup an RS-232 connection is whether you want Hardware or Software handshaking. Hardware handshaking implies that the cable must be properly configured. Software handshaking implies XON/XOFF through a null modem cable.

When you are configuring a device, you may encounter several options for hardware handshaking. One option could be to use only DTR and DSR as the complete flow control mechanism. In this situation the devices turn DTR on or off to control the flow using a DTR/DSR cross connected cable. After you have studied the documentation for your RS-232 device you should be able to implement the appropriate interconnections, perhaps using a breakout box to determine the signals that are present. If the flow control mechanism isn't working (isn't configured properly) you are going to experience overrun errors. The sender isn't going to know when to stop sending and the receiver will be overrun. In the absence of a correct handshake it is possible to simply slow down the transmission rate (lower baud rate) to allow the receiver to keep up with the transmitted data stream. To solve RS-232 interconnect problems it is necessary to study the signals that are available and, if no "correct" connection can be made, then you provide the signals as needed by cross connecting pins. Not all RS-232 devices can be successfully connected -- there may simply be no way to make it work.

Previous Topic ] Next Topic ] 
Compendium Index ] Up ] Compendium Contents ] Search ]

OTHER TOPICS AT THIS OUTLINE LEVEL:
General Overview ] RS-232 Standard ] Bit Encoding ] Character Encoding ] Data Errors ] Physical Circuit ] DTE and DCE ] DB-25 Connection ] Control Signals ] Break-Out Box ] Directional Signals ] [ Connecting DTE's ] Async & Sync ] Other Signals ] Custom IC's ] RS-423 ] RS-422 ] Modems ]

{Revision F-1} All Content Created By Optimized Engineering Corporation is
Copyright © 1995 - 2000 by Optimized Engineering Corporation
All Rights Reserved

The contents of this web site may not be duplicated or distributed in any
manner without prior written consent of Optimized Engineering Corporation.