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