das@cirl.UUCP (Dave Steffens) (08/16/86)
This is an excerpt from a note I published in net.unix-wizards.
Since this info is applicable to systems other than unix, I have taken
the liberty of posting it here as well. A fix for unix systems is included
in the posting to net.unix-wizards, q.v. Apologies in advance to anyone
who might deem this form of multiple posting inappropriate.
The problem under consideration is that it is sometimes difficult to get
a 2400/1200/300 baud modem on our uVAX running unix to settle into the
correct speed. For those who don't know, speed selection on unix is handled
by a program called /etc/getty which makes use of the BREAK key to force
a change of speeds. Each push of the BREAK key is supposed to cause
/etc/getty to switch to the next speed in its table. In our case, this
is defined as 1200/2400/300 round-robin. What the user sees is that more
than one speed is skipped for each push of the BREAK key. In particular,
it proved near impossible to select 2400 baud.
----------
All switches "bounce" for several tens of mSec after opening or closing.
On most keyboard keys this causes no problem because it is supressed
by the terminal logic that transforms key pushes into EIA signal levels.
When you do get multiple chars from a single key push, it is usually because
the key switch has gotten so noisy that it bounces longer than the dead time
built into the logic -- it begins to look as if the key was pushed twice.
While EIA specs say that a **true** BREAK should be exactly 1/4 Sec of space,
I have found that many inexpensive terminals do NOT adhere to this standard.
There is NO timing of the BREAK character -- the terminal causes the line to
space as long as you hold down the BREAK key. When the BREAK key is released,
it "bounces" just like all the other keys. But because there is no logic
on the BREAK key to suppress these bounces, they appear on the line as a series
of 2-10 mSec spaces separated by 2-10 mSec marks. Typically there will be
5-10 of these space/mark "glitches", with the first ones having longer space
than mark times and the later ones having longer mark than space times.
Now most computer interfaces detect BREAK as a framing error, i.e. a space
where the stop bit should be. Since a character at 2400 baud is about 4 mSec,
ANY glitch longer than 4 mSec will generate a framing error, i.e. will appear
to the software just like a REAL 1/4 Sec "BREAK". Similarly, ANY glitch
shorter than 4 mSec will appear to the software as a REAL character.
Since the first few space/mark pairs usually have the longest space times,
what the software ultimately sees is something like:
BREAK BREAK BREAK garbage-char garbage-char
These terminals work the same way at all baud rates. But since the character
time is 8 mSec at 1200 baud and most of the glitches are shorter than this,
most will appear as garbage chars at 1200 baud and few, if any, as BREAK.
Most modem speed-switching software, e.g. /etc/getty on unix, seems better
equipped to handle garbage chars than multiple BREAKs so this may be why
there is more of a problem at 2400 baud than at 1200 baud.
Note that this problem was seen frequently on a uVAX with DEC DHU boards
but only rarely on a VAX750 with DEC DZ and Able VMZ32 boards. It was never
seen on an 11/34 with MDB DZ boards. So there still may be some unexplained
differences in how each type of terminal interface handles framing errors.
--
{harvard,mit-eddie,think}!eplunix!earvax!das David Allan Steffens
243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory
(617) 523-7900 x2748 Mass. Eye & Ear Infirmary