Get APLawrence.com by RSSTony 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.
More:
- Lighter
Unix/Linux Consultants
SCO, OpenServer, UnixWare, software, servers, security, networks, installation, administration, troubleshooting, maintenance, Watchguard, firewalls, VPNs, e-mail. Visit us at http://opensystemscomputing.com and www.go2unix.com.
http://www.m3ipinc.com Security, firewalls, ids, audits, vulnerability assesments, BS7799, HIPAA, GLB, incident handling
http://echo3.net/ Unix/Linux Custom Applications, Web Hosting, C/C++ Programming Courses
- Nov 23 08:34
So many sites tell me what I MUST do: focus on a niche, have an elevator pitch, all that.. naaaw - I LIKE being scatter brained. - Nov 23 07:35
Bailing out GM et al. is like bailing out SCO. It makes me angry that they even TALK about it.
Related Posts
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