(1)  Short note on different types of fax modem

The AT command set was originally developed by Hayes for their
Smartmodem and later adopted in one form or another by most modem
manufacturers.  As well as external and internal fax modems, PCMCIA
fax modems are also available.  These may appear to be external
modems, but they actually have more in common with internal modems,
as the PCMCIA system gives them direct access to the bus rather than
to a standard serial port.

There are three main types of fax modem which are not covered in this
book.  

i. The first are CAS modems, which are only programmable via a
software driver. The text of the CAS specification appears on this
disk in the file CAS.TXT for those who are interested.  To quote from
the introduction :

"The DCA/Intel Communicating Applications Specification (CAS) defines
a standard, high-level programming interface for data communications
applications.  It offers software developers a simple and
straightforward method for adding data communications functions to
their products. This interface is independent of the hardware and
software used to implement the underlying communications facilities.
This shields software developers from the details typically
associated with using communications hardware.  It also permits
developers to code their applications to the interface and to be
assured that their applications will work with new generations of
hardware products."

Unfortunately, CAS compliant modems were only ever used widely under
DOS, as the API was implemented via TSR utilities which were never
ported to other environments with any degree of success. The quality
of the driver is of course just as crucial for CAS based software as
is the quality of the modem, and by relieving programmers of
responsibility for fax implementation, CAS also denies them the
chance to fix anything that doesn't work properly.  The commitment of
Intel to the specification is now questionable, as they didn't
respond to my enquiries about their fax products, and they appear not
to be making CAS fax modems any longer (though CAS drivers for class
1 and class 2 modems are available).

ii. The second type of fax modem which we don't cover is the Sierra
Sendfax. As far as I am aware these are no longer manufactured.  They
were only capable of sending faxes, and their command set was an AT
type, similar to that of EIA Class 2.

iii.  The third type of fax modem which we don't cover are
intelligent fax boards such as those manufactured by Brooktrout and
Gammafax.  These contain their own memory and processor and should be
regarded not as mere peripherals which need to be controlled by their
host computer, but more like network fax servers, which can be told
what to do and then get on with it, requiring no more instruction or
resources.

(2)  Short note on DTE-DCE terminology

DTE=Data Terminal Equipment=consoles, printers and any other device
where data originates or ends up.  DCE=Data Communications
Equipment=modems and other devices which transport data.  I seem to be
unable to perform the necessary mental adjustment needed to enable me
to read paragraphs containing these terms without stopping to
remember which is which. This serves to break up the flow of the text
of the specifications (which are generally not written in a terribly
narrative style in any case).

(3)  Short note on recent standard specifications

While the ANSI/TIA/EIA-602 standard for the AT command set does now
provide a normative reference guide, it essentially represents
post-facto attempt to regularise what we basically a fairly chaotic
process of ad-hoc extensions to what is still largely a free-for-all
among modem manufacturers.  The ITU Study Group 14 is also joining in
with the attempt to bring out an internationally recognised standard
set of AT commands, but it remains to be seen whether this is going
to be either useful or successful.  Manufacturers are by now used to
adding whatever commands they feel like, and communications software
houses already have long lists of modems to choose from in their
installation routines.

The latest proposal for a standard set of AT commands for modems is
the draft V.at specification currently under consideration by the
ITU.  This groups a number of modem functions together, all of which
begin with the prefix AT+ followed by a single defined lead-in
character.  There are a number of these lead-in characters defined as
follows :

Ŀ
AT+A  Addressing       
AT+C  Cellular         
AT+D  Data compression 
AT+E  Error correction 
AT+F  Fax              
AT+G  Generic          
AT+I  Interface        
AT+M  Modulation       
AT+T  Test             
AT+V  Voice            
AT+W  Wireless         
 

It isn't at all clear whether this scheme will be widely adopted even
if it is approved.  I suspect that one of its inspirations is the
fact that fax modems have been successfully using AT+F since the late
1980s.

I can't help feeling that perhaps I ought to apologise for mentioning
the 1.0 and 2.1 service class proposals. However, the point is surely
that developers ought to be aware of possible "gotchas" in the
future.  For instance,  if the software provided on the accompanying
disk sees a 1 in an AT+FCLASS=? response string it assumes class 1. 
It will therefore fail to work properly with a class 2.1 modem. 
Whether developers looked on this as a bad thing or a good thing
depends on whether software upgrading is thought of as a profit
centre or as drain on resources.

(4)  Short note on voice modem responses

We have already mentioned that the AT+FCLASS=? command includes as a
possible response the value 8. This indicates that the modem has
voice capability, with the various voice commands prefixed by AT+V. 
Though these commands are outside the scope of this book, it is worth
pointing out that proposal PN-2986 describes how a modem in voice
mode can play recorded voice messages and detect DTMF tones.  This
would permit the setting up of a fax-on-demand system with voice
prompts and document selection by means of tone pad responses.  A
number of competing proprietary methods of doing this also exist,
notably the various AT#V extensions to the Hayes command set
developed and marketed by companies such as Cirrus and Rockwell.

(5)  Short note on Class 4

Incidentally (mischievous mode on) it is possible that the digit
result code for an error, which is 4, will conflict with a valid
response for a modem when the Service Class 4 proposal emerges from
the TR 29.2 committee : it remains to be seen how the committee will
handle this (mischievous mode off).

(6)  Short notes on manufacturing quirks

i. It is worth pointing out that using chips from one source does not
commit a modem builder to using the same manufacturer's code to
control those chips.  On the one hand, a company producing a modem on
the cheap is more likely to use code that diverges from the industry
standard because the authors did it in a hurry, while on the other
hand, a modem company with a lot of resources which writes its own
code is more likely to feel that their interpretation is the correct
one.  In either case, the end product is yet another interpretation
of the specification.

When this happens, it isn't generally possible to rule on the
correctness of alternate responses, such as returning 001 instead of
a plain 1 to a query (which could occur whether numeric or verbal
result codes are being used). Whether they contravene the
specification is too difficult to say.  In the case illustrated, what
is probably happening is that the firmware in the modem is using the
same routine to dump the value of the service class as it uses to
dump the value of numeric S registers, where values such as 001 for 1
are accepted as normal responses.  A routine that ignored leading 0s
in responses would obviously be better at handling this modem than
one that just inspected the first digit that came in after the
parameter test.  But then, hindsight is a wonderful thing.  Prior
research is better.

ii. Michael Shiels of Delrina, who has compiled a list of the
behaviour exhibited by various models of class 2 modems, reported
that some modems return 0 or OK for commands which aren't implemented
at all. This led me to start investigating this area further. The
following command sequence was captured from a modem using the Sierra
chipset :

AT+FCLASS=?             ask the modem what its capabilities are
0,2                     the modem can handle data and class2 fax
OK                      the modem responds OK
AT+FCLASS=1             tell the modem to enter fax class 1
OK                      the modem responds OK
AT+FCLASS?              ask the modem what service class is in force
1                       the modem claims to be in class 1
AT+FCLASS=?             ask the modem what its capabilities are again
0,2                     the modem still claims no class 1 compatibility
OK                      the modem responds OK again
AT+FCLASS=9             tell the modem to enter fax class 9
OK                      the modem responds OK
AT+FCLASS?              ask the modem what service class is in force
9                       the modem claims to be in class 9

The above behaviour almost certainly contravenes the specification,
but as the circumstances under which OK and ERROR responses should be
issued are vague, even this isn't totally certain.  The EIA simply
states that the use of the ERROR response is mandatory where a
command is either not recognised or is terminated abnormally.
Arguably, the sequence above is legal as the commands terminated
normally and are recognised as garbage.  It may be stretching a
point, but computers and programmers can sometimes tend to be very
literal in their interpretations of standards documents. Irrespective
of whether it is legal or not, the fact is that reputable
manufacturers do produce modems incapable of class 1 operation which
nevertheless respond to an AT+FCLASS=1 command with an OK, and
respond to a follow-up AT+FCLASS?  enquiry with a 1.  The safe
practice is always to test a parameter before setting it.

Incidentally, the text points out the reliability of a modem is in no
way linked to how conservatively it interprets the standard.  I have
used a modem with the Sierra chipset utterly reliably in practice. It
remained plugged in and on line for over three months, collecting and
sending faxes without falling over once.  I soon forgave its attempt
to kid me into thinking it offered Class 9 support.

iii. All the TIA/EIA service class specifications contain a virtually
identical section numbered 8.2.2 , which states that the response to
an AT+FCLASS=? command is a list of values separated by commas.  Both
the original class 1 and class 2 specifications go on to give as an
example a response such 0,1,2.  It is quite possible to claim that
this example is simply one example from a number of equally valid
possible response formats.  For instance, we find in section 6.1.5.4
of the draft class 2 specification that

"in response to command testing the DCE shall present a <range of
values> to the DTE as ordered list, separated by spaces or commas or
as two values separated by a hyphen to represent a continuous range
of values."

This seems to indicate that both 0 1 2 and 0-2 would also be just as
valid as a 0,1,2 response.  These are not even the only
possibilities, as we can find in section 6.1.4.5 a statement that in
response to any test, either a range of values or a compound range of
values may be returned.  A little further on, section 6.1.5.6 of the
same document states that for compound ranges of values,

"individual subparameter ranges of values are presented as a range of
values bracketed by parentheses"

This, presumably, is where the (0,1,2) incarnation comes from.  The
moral of this tale is that while the specification may not actually
be ambiguous, it is sufficiently vague in parts to make it fairly
easy to see how different programmers could draw different
conclusions.  At least four different formats seem to be possible for
the AT+FCLASS=? response.

Considerations such as these may have been one of the reasons why the
draft class 2 specification PN-2388 was never approved.  The approved
version attempts to shut some of these stable doors, for we find that
section 8.2.2 in the approved version of class 2.0 states baldly that
the response to the +FCLASS=? command

" is a string of values separated by commas followed by a result code
; neither bracketing parentheses nor hyphens are permitted".

However, the ambiguities inherent in the other sections of class 2
which we quoted still remain.  The safe practice here is to try and
cater for all possibilities when a parameter is being checked.

(7)  Short note on the delay before the sending of AT commands

This peculiarity of modems generally is recognised in the draft
class 2 specification, which states that :

"the DCE may fail to recognise a command line if the start element of
the first character of the command line begins within one millisecond
of one half-bit time into the stop element of the terminating
character of the final result code character issued in response to
the preceding command line".

At least, that's what I think it is saying, though I think on purely
grammatical grounds that the final "character" in the sentence is a
typing error.  Presumably the TR 29.2 committee couldn't understand
it after a while either, as the sentence never made it to the 2.0
document, which simply states that

"the DTE shall not issue a new command line until the DCE has finished
delivering the complete final result code to the previous command
line, including any following <cr> and <lf> characters"

A case could be made for maintaining that modems which need overlong
delays before an AT are not up to specification.  The EIA standards do
say that all characters on a line which precede the AT characters
should be ignored ; but perhaps it would be a little harsh to expect
the rejection of these leading characters to be instantaneous.

Regarding the suggestion of a two-character delay, I can't be sure
what the reason for needing to tie the length of the delay to the bit
rate in this way might be, but I think it may be purely coincidental.
Modems that can interface to computers at faster speeds are quite
possibly the ones that need shorter delays.  On the other hand, it
might be that some modems really do need longer delays at slower
speeds.  I confess that once I'd found a formula that worked on every
modem I tried, I didn't worry too much about the reason why it
worked.  While there are some modems that can handle a shorter delay,
the two-character gap does no harm, and I'd rather use a pragmatic
hack that seems to works every time than a theoretical justifiable
algorithm that doesn't.  Basically, we can assume that if a modem has
sent nothing in that period of time, then it isn't going to.  Note
that the "one millisecond of one half-bit time" timing from that last
character of the final result string isn't much use to us when we
can't be sure what the final result string might be.  Programmers
must also be aware that certain conventional AT commands, notably
those such as ATZ which cause the modem to reset, need a longer delay
than this.  However, delays needed when a modem is off-line (or
on-hook, if you prefer) are not critical in the same way that on-line
delays are.

The following code uses the ANSI C clock structures (in time.h)to
introduce a delay on almost any machine which is accurate to the
millisecond. The function is called once at the start of the program
to calibrate the timer. It waits for the clock to tick, then counts
the number of calls to clock() in one second. On modern CPUs, this
number is always to be measured in the thousands (hence the long). We
then divide by 1000 and the result is the number of calls we need to
introduce a delay of 1 millisecond.

void delay (int milliseconds)
{
 unsigned long int x ;
 static unsigned long int calls=0L ;
 clock_t t ;

 if (calls==0L)
  {
  t=clock()+1 ;
  while (t>clock()) ;
  t=clock()+(CLK_TCK) ;
  while (t>clock()) calls++ ;
  calls/=1000 ;
  calls++ ;
 }
 else
 {
  for (x=0 ; x<(calls*milliseconds) ; x++)
  clock() ;
 }
}

Once calibrated, all subsequent calls to delay() will call clock()
however many times are needed for a millisecond. Note that the
calibration loop and the delay loop all involve one call, one
comparison and one increment; this makes the algorithm reasonably
accurate. Like all timing delays of this magnitude, it isn't going to
be exact, but it should be well within any tolerance required. Unless
you want to run with interrupts off, exact timings are always going
to be impossible.

(8)  Short note on modem-computer bit rates

An option to match the computer-modem speed to match the fax speed is
something that I've never seen it on a fax modem, and it isn't
immediately apparent how such an option would be implemented even if
it were available. It would be a highly unusual occurrence for the
fax negotiations to take place at the same speed as the eventual data
transfer speed, so presumably the speed would need to be changed at
least once in a session. In any event, it would require an eccentric
interpretation of the various progress messages included in the
various class 1 and 2 command sets to implement such speed changing,
and I can't say that I'm unhappy that nobody has thought of it.

On the other hand, I think it is unnecessarily restrictive to insist,
as some modems do, on a minimum asynchronous speed of 19200 bps where
a fax modem has the capability of sending and receiving faxes at 4800
bps or 2400 bps as well as 9600 bps.  Some hardware may be reliable
at 9600 bps but not at higher speeds, and some fax applications may
need to use systems software for setting asynchronous interface
speeds which frowns on the use of 19200.  In these circumstances,
restricting the speed at which faxes may be sent and received to 4800
bps and 2400 bps (using V.27 ter modulation) is surely better than
not allowing them to use a fax modem at all.   I belive that Rockwell,
Sierra and Exar have all at some stage manufactured chips, with the
capability for 2400 bps data and 9600 bps fax, which insisted on
separately fixed data and fax speeds

(9)  Short note on troubleshooting modems

In general, it is wise to check the modem manuals first. The
suggestions made in the text are based very much on my own experience
in programming fax modems, and I do not claim to have used every
model that has ever been made. Even if I did, there is no way of
guaranteeing that future modems will conform to my past experience. 
For instance, while I have never seen an EIA compliant fax modem that
doesn't also have data capability, there's no reason to suppose that
they will never be made.  You should refer to note 3 above for
reasons why a scan for a 1 in a response to AT+FCLASS=? is a test for
a class 1 fax modem which will almost cetainly not work for ever.

(10)  Short note on XON/XOFF protocol

Actually, the EIA seem to prefer the use of the somewhat less
intuitive ASCII terms DC1/DC3, but that's standards bodies for you.

(11)  Short note on AT+FBUF

Note that there is no command to find out the buffer size for class 1
modems, and the corresponding command for 2.0 modems is AT+FBS?;
however, the information returned is not identical and the flow
control thresholds are not given. Finding out the restart threshold
on a class 2.0 modem isn't a practical proposition; this matter is
discussed further in chapter 11.

(12)  Short note on the import character code fragment

If a carriage return (0x0d) is the last character and commands are
being terminated with a carriage return/line feed pair, then the
additional line if (k==0x0d) while (k!=0x0a) k=rxchar() ; just before
the end of the function may help to stop subsequent commands going
out while the modem is still sending its final line feed.
