Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ritcv.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rochester!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: net.dcom
Subject: Re: Noisy {{~r lines affecting 212A { modems
Message-ID: <1482@ritcv.UUCP>
Date: Thu, 17-Jan-85 23:57:50 EST
Article-I.D.: ritcv.1482
Posted: Thu Jan 17 23:57:50 1985
Date-Received: Sat, 19-Jan-85 01:37:57 EST
References: <145@pttesac.UUCP> <418@down.FUN>
Distribution: net
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 22

In 418@down.FUN :

> i sometimes get noisy lines, so i share your frustration.  i have tried
> changing my interrupt character, to no avail.  i conclude that DEL is
> not actually being seen, but that the uart is getting a framing error,
> which turns into a break, which turns into your interrupt character.

Hmm.  On the noisy line that I sometimes have to use, I almost always
see a DEL/{ pair sent to the remote system.  I set the terminal in 8-bit
no parity mode and ran 'cat' to pick up some of these alpha particles.
Sure enough, the DEL was a real DEL with all 1 bits -- apparently noise
forced a 0 (start bit) and recovered immediately to the default 1 state.

This could be fixed by setting the terminal to odd parity, 7 bits, but
then you only cut out the DEL - unfortunately, the pattern we see for
the { would pass an odd parity test.  We've thought about implementing
a SPACE parity option (parity always 0), as our junk characters almost
always have the parity bit set to '1'.  Anyone want to hack on this?
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA