Tony Lawrence: RS232 (The Lights are On) (1991)
THE LIGHTS ARE ON, BUT...
The bane of my life is RS-232 communication. This one area has
caused more wringing of hands and tearing of hair than anything
else. And while just plain RS-232 to RS-232 hookups are bad enough,
the addition of modems makes things worse. If the modems are high
speed, data compressing models, I start quivering before the cables
are even hooked up.
There was a time when I thought that my problems could be
alleviated by an increase in knowledge. I felt that I really didn't
know enough about RS-232 in general and modems in particular, and
that this knowledge gap was contributing to my confusion and
despair. It seemed logical to assume that a liberal application of
books, tools and playing around could only bring good
results.
Well, I have the books, and have read all about MNP and V.42bis. I
have puzzled over Phase Shift Keying and Quadrature Amplitude
Modulation. I've bought Gender Changers and Null Modems and
Breakout Boxes, along with a horribly expensive crimper that
attaches modular plugs to phone wire cables. I have played with
cables and modems and software of all descriptions. In short, I
have given myself a short, intensive course in the theory and
practice of RS-232 communication.
Certainly these efforts have improved my understanding of what is
supposed to happen when two computers reach out and touch each
other with their DB-25's. Unfortunately, what is supposed to happen
is generally not applicable to life in the real world. I still find
myself typing AT commands into stubbornly unresponsive modems or
watching garbled and unreadable messages scroll up and down totally
confused screens.
One of the most frustrating situations is when two modems have been
carefully matched, lovingly configured and quite properly
introduced to each other. They have accomplished their ritual
handshaking, exchanged squeals of delight, and have settled down
with all the proper lights aglow, seemingly throbbing in
anticipation of the joyous exchange of data that is to come. They
then refuse to transmit or receive even one single character.
Frantic conversations with my counter-part at the other end ensue.
"Yeah, my 9600 light is on- is yours?" "My keyboard is dead- no, I
think the whole system is dead!". Breakout boxes with festive red
and green leds are applied to no avail. Port configurations are
checked and re-checked. Accusations of subscribing to sub-standard
long distance services are invariably bandied about, and when
things get truly desperate, the very integrity of the Operating
System is called into question.
In such situations, the modem happily retains the connection with
it's mute friend, while the two of them gobble up Message Units.
Guard signals (+++), which are supposed to summon the modem to
attend to commands, are blithely ignored. Nothing short of
unplugging the phone is likely to convince either modem that the
intended mating has not worked. The occasional blinking of a Data
light only adds to the mystery: if these two devices are talking,
what on earth are they saying?
I know exactly what they are saying: "It's that Lawrence guy again-
and we are REALLY driving him nuts this time!"
© 1991 Anthony Lawrence. All rights
reserved.
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page |
| Today | This Week | This Month | This Year | Overall |
| 2 | 2 | 35 | 396 | 3,583 |
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
UnixartRsNum232 :
Don't try to run any serial interface faster than 9600 bps with software handshaking. Above 9600, the time it takes for an XOFF character to reach the sending machine can be sufficient to cause a buffer overflow at the receiving end. Hardware handshaking is infinitely more reliable and will readily support speeds beyond 115.2 Kbps on most reasonable systems.
--BigDumbDinosaur
Depends. You can do it with terminals because most can't
really display above 1600 baud or so - they can draw a line faster, but not a whole screen.
With printers, maybe, maybe not. But I seldom set printers above 9600 baud anyway because few can actually print that fast.
--TonyLawrence
I run my two Wyse 60's at 38.4K, my Oki 395 at 19.2K and my Wyse 160 at 115.2K. One of my clients has a Tally 6100 printer that prints 900 lines/minute, which works out to around 1900 CPS on average (assuming 132 chars per line, which is the default). That unit is run at 38.4K. Anything slower and the printer would be waiting on the server for data.
A lot of it is dependent on the quality of the cable, the quality of the connectors and, most importantly, the quality of the EIA-232 hardware in the server. I've never had any trouble achieving reliable, high speed connections with Equinox hardware. Digi-Board's stuff is another matter.
--BigDumbDinosaur
Oh! Almost forgot. *** DO NOT *** connect frame ground on the printer to frame ground on the host computer if the two are powered by physically separate circuit breaker panels. You may accidentally set up ground plane potential imbalance current flow through the data cable, which will cause the link to generate random errors that will have you muttering to yourself.
As a general rule, you don't need frame ground bonding at both ends. If you are using shielded cable, bond the shield to frame ground at one end only (preferably the host computer) and insulate the shield and its drain wire (if present) at the other end. Never use the shield for signal ground.
If your EIA-232 wiring is through UTP cable the frame ground serves no purpose. Ironically, UTP is far more likely than the shielded stuff to produce reliable high speed operation. If you want the technical explanation as to why this is so, raise your hand. <Grin>
--BigDumbDinosaur
---July 23, 2004
I ALWAYS want the tech explanation :-)
--TonyLawrence
Add your comments