<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 25-Jul-20 13:47, Paul Koning wrote:<br>
</div>
<blockquote type="cite"
cite="mid:30B36674-B0F7-4834-92CB-36583F20FAC8@comcast.net">
<blockquote type="cite" style="color: #000000;">
<pre class="moz-quote-pre" wrap=""> But by the mid to late 70s, i.e. with the glass TTY it started to fall from favor. I don't know why, but I would suspect this was because dedicated lines started to supplant telephone circuit-based connections and single-bit error detect was not useful. It did not happen that often.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It could be that glass TTYs were computer peripherals, and typically close to the computer or connected by a modem that was pretty clean. The older devices tended to be on current loops, possibly quite long ones with debatable signal quality.
</pre>
</blockquote>
<p>How often you got parity errors was a function of modem
generation and line quality - acoustic couplers from your house in
the country were good for frequent parity - and mult-bit - errors.<br>
</p>
<p>By the 80s modems got much smarter. While the 103 was pure
bit-by-bit FSK, in addition to coding improvements, later modem
protocols (e.g.USR HST in 186, then V.42) provide error correction
(including retransmission). In between, V.34 does a lot of work
in the initial handshake to adapt to line characteristics.</p>
<p> So the error rate became essentially zero (though latency could
be unbounded).</p>
<p>Except in some weird cases (I won't mention which computer rooms
had modems several hundred feet from the computer's
interfaces...), the modem - host and modem - TTY would be within
the RS232 limit of 25 ft.</p>
<p>OTOTH, parity in hardware was cheap - though software often
didn't handle parity errors very effectively. Software used (IBM)
or moved to 8-bit characters as I8n came along. So unless parity
was used in HW, or you had a non-byte architecture (e.g. the
PDP-10 which treats "bytes" between 1 and 36 bits equally), it was
inconvenient.</p>
<p>In any case, while the short modem - DTE interface was still a
vulnerability, once you have an error-corrected path, "parity was
for farmers."</p>
<p>Current loops - especially when optically coupled - were actually
quite good. Extending RS232 beyond the 25 ft spec could get
problematic. Yes, 3,000 ft was quite possible. But sensitive to
environment. I had a number of notable cases where customers
complained about long line (RS233) issues - and switching to
current loop modems (typically > 20ma) resolved them. Hint:
you don't want to run long RS232 lines around elevator machine
rooms, or industrial factory floors, or ...</p>
<p>Like anything, it helps to read, understand, and conform to the
specifications...</p>
<p><br>
</p>
<pre class="moz-quote-pre" wrap="">
</pre>
</body>
</html>