sung@mcnc.UUCP (09/02/87)
I have seen most all the nasties about RS232 that other people have been mentioning in this group. Still I have better success in getting serial devices to work than I have ever had with parallel devices, for example. Perhaps a methodical approach to the connection helps. Even in the case of a totally unknown connection, it can be deduced this way. For the path to work, first we need the send and receive leads and ground. In many cases ground and chassis are the same but even if not as long as it has a power transformer (or use an isolation transformer if not sure) a scope will read some waveform to chassis. Then see which leads are negative - control leads will usually be positive. Input leads will have either no voltage or a small amount. Having found the negative leads set up the unit and type some keys. The transmit lead will toggle (if you only have a meter use break). Next jumper from transmit to the suspected input leads (the ones with no voltage or a low one) and one of them will cause characters to be echoed. In many cases these are all that will have to be discovered. Granted it is not trivial but it also doesn't take all that long. Hardware pacing is a different story. I generally try to avoid any pacing if possible. That way the control leads can be used for device control and not transmission control. In more and more cases nowadays I have to attach "intelligent" devices back to back (say a small data switch to a larger one) and the lack of coordination in the way control leads are used causes a lot of trouble. In telephone work, two connected devices are generally controlled with two leads, one in each direction. The states possible are on, off and pulse. This last state is used to send the dialed number forward. In fact, this is what has developed into the "signalling channel". No such coordination (yet) exists for the data folks, and I have spent much time programming and making adapters so that in most cases the so-called intel- ligence is exactly what I have defeated. An example, since this is the modems group, has already been mentioned in the case of command-driven modems. They come set up for human keyboard control and need to be reset to work either into a dataswitch or a computer port. Many times a combination does not exist to allow the modem to work both in and out. Let's say the host port uses DTR to tell the modem it wants to go out and the modem uses DCD to tell the host it wants in. In an idle state then, DTR and DCD should both be negated. Some modems will not answer calls if DTR is negated. Well let's have the host drop DTR long enough to drop carrier and then bring DTR back up. That is not always possible. Some hosts have to see DCD go up first before raising DTR (some want RI even). Other combinations lead to the endless loop that has been discussed recently. What you wind up doing a lot of times is giving up on using the same modem both ways. Modems are cheap enough to do that with, but ports generally are not. A standard (I know, that's a nasty word) I would like to see is a method of "tandem" connections, that is to say how do we insure that given a chain of data communications device end-to-end signalling can be transmitted. This is purely to be sure that the session has ended and the devices are available for further use. Next step would be to define how destination infor- mation could be passed along the chain. If I dial a long distance number, I dial it once. All the switches in the chain tell each other where to send the call. In contrast, with dataswitches I have to connect to each device and tell it myself where to go next. Well, enough of everybody's time. Thanks all for reading.