Xref: utzoo comp.sys.pyramid:220 comp.dcom.modems:2361
Path: utzoo!utgpu!water!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.sys.pyramid,comp.dcom.modems
Subject: Re: Solution to Problems with UUCP/modems.
Message-ID: <16037@onfcanim.UUCP>
Date: 3 Sep 88 21:28:43 GMT
References: <14170@comp.vuw.ac.nz>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Followup-To: comp.dcom.modems
Organization: National Film Board / Office national du film, Montreal
Lines: 22

In article <14170@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>We were still puzzled by the fact that the modem did not behave like this every
>time.  It turns out that the Quattro determines both the terminal baud rate
>*and parity* from any "at" command.  When in data mode it converts all data
>from a remote modem to the parity determined this way.
>
>The (old) Quattro manual I have does not document this "feature", but I have
>spoken to one of the distributors engineers who says his manual does.
>But he also claims the Quattro is behaving perfectly reasonably.
>Is he right?  How many other modems behave like this?

I believe that a modem's job is to get bits from one place to another,
without changing them.  I have never used any modem where it was even
possible to ask it to do parity-bit stripping in data mode.  Any modem
that decides to throw away some data bits by default is, in my opinion,
a piece of junk.  Without some sort of explicit instructions to ignore
the 8th bit, the modem *must* assume that all bits are data.

Parity stripping in command mode may be quite reasonable, but not in
data mode.

	Dave Martindale