Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hayes!tnixon
From: tnixon@hayes.uucp
Newsgroups: comp.dcom.modems
Subject: Re: What is special about "AT" (was Re: Hayes Microcomputer lawsuit???)
Message-ID: <3768.27ad9916@hayes.uucp>
Date: 4 Feb 91 17:25:42 GMT
References: <143271@pyramid.pyramid.com> <3763.27aaed7c@hayes.uucp> <424@paralogics.UUCP>
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 76

In article <424@paralogics.UUCP>, shaw@paralogics.UUCP (Guy Shaw) writes:

> I am curious - is there some property of the prefix "AT" that makes it
> more suitable for the automatic detection of settings than other prefixes?
> By settings, I mean such things as speed, parity, character size,
> start/stop bits, etc.

Actually, there are any number of character pairs that would work 
equally well.  The key characteristics are (a) the low-order bit of 
the first character must be "1", so that it is possible measure the 
duration of the start bit; and, (b) the second character must have a 
different parity from the first character, so that the parity bits 
of the two characters can be examined in order to determine the 
parity being used by the DTE (even [if both characters are even 
parity], odd [if both characters are odd parity], zero [if both 
parity bits are zero], or mark/none [if both parity bits are 1]).  
Note that the "A/" sequence to repeat a command also has these 
characteristics, as does the lower case "at" sequence that is also 
acceptable.  Mixed-case "aT" or "At" is not acceptable, because the 
number of 1 bits in the two characters are the same, making it 
impossible to accurately determine the parity in use.

> I suppose that the completely naive approach is to keep cycling through
> settings until you see a proper 'A'.  

Most modem implementations do not cycle through speeds, but use a 
one-shot timer to actually measure the duration of the start bit 
of the "A" to determine the data rate.  The remaining bits are then 
clocked in, and checked to see if they are an "A" or "a"; if not, 
the character is ignored.  If so, what is often done today is to se 
up a UART with 8/N/1 format at the detected speed, in order to read 
in the remainder of the command line (i.e., the processor-intensive 
mechanism of clocking in individual bits is avoided as much as 
possible, especially when in online command state and trying to keep 
the carrier and error control protocol active in the background).

> Why did tips on the Arpanet use "@"?

I really don't know why, but I imagine it is because among graphical 
7-bit characters which can be produced on a standard terminal 
keyboard, only "@" has all zero bits in the lower-order positions.  
This may be easier to use to detect the rate when you DO have to 
cycle through data rates to try to get a valid character.

> Why did Hayes (or whoever it might have been before them) choose "AT"?

My understanding is that it was chosen from among the multitude of 
other possibilities because it could be considered an abbreviation 
for "attention".

> Is there any literature on this subject?  Or, is this really just one
> of those black arts that gets passed down informally from mentor to
> acolyte, or, even worse, gets inherited in the form of code and tables
> in ancient source code that works but no one dares tamper with?
> If the answer is RTFM, please do tell me which FM.  I have a few books
> on communications, but this does not seem to be one of the hot topics.
> I have not seen it discussed in this newsgroup, but then, I have been
> reading this newsgroup for only about a year.

You probably wouldn't find a discussion like this in a general book 
on communications.  You MIGHT find it in a book on modem design, 
such as John Bingham's book (but I can't remember the name, 
something like "Theory and Practice of Modem Design".) -- but even 
then I think his book dwells more on modulation than controller 
firmware design.  At Hayes, this technology is preserved and 
protected by the Systems Engineering department (where I work) and 
promulgated through internal standards documents and training 
courses for engineers.

	-- Toby

-- 
Toby Nixon, Principal Engineer    | Voice   +1-404-449-8791  Telex 151243420
Hayes Microcomputer Products Inc. | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                   | UUCP uunet!hayes!tnixon  AT&T    !tnixon
Atlanta, Georgia  30348  USA      | Internet       hayes!tnixon@uunet.uu.net