hayes.txt

使用efax的fax工具程序

results rather than numeric results are preferred. Numeric result codes 
were originally intended to make it easier for software to control the 
modem, but there are two primary reasons they should not be used:

Software can be confused by a command echo. For example, if the 
following command were sent with echo on (E1) and numeric results (V0) 
on:

                       AT ... S9=20 <CR>

The resulting data, echoed by the modem, would be followed by the 
numeric result code zero, meaning OK:

                      AT ... S9=20<CR>0 <CR>

Software may become confused by seeing a 0<CR> result which is actually 
part of the command echo, then another 0<CR> which is the numeric 
result. A program can become unsynchronized with the command processor 
in the modem.

Turning off echo mode (E0) in the initial setup string would solve this 
problem; however, do not end that command with any digits (simply E).

Another shortcoming of numeric results is that the software must 
anticipate all possible responses. This requires updating controller 
software whenever new result codes are added. For example, suppose a 
CONNECT 115200 result were added with a numeric value of 31. If verbose 
results were used instead, and the controller directed to interpret the 
number after the CONNECT result as simply the connection speed in bits 
per second, no changes to the driver are necessitated by the new result 
code. If, however, numeric result codes were used, the result code 31 
must be added to the table, and the controller modified to interpret it 
appropriately.

As characters are received, they should be processed through a state 
machine providing the functionality of the following one. This state 
machine recognizes strings surrounded by <CR><LF> characters and stores 
the string in a character array. <CR><LF> are defined by S3 and S4.

Sample State Machine
Initialize with: state = 1 ;

ch = <next character from the input>
switch( state )
{
     case 1:     /*-- Scanning for leading CR --*/
               if( ch == CR ) state = 2 ;
               i = 0 ;
               break ;
     case 2:     /*-- Scanning for leading LF --*/
               if( ch == LF ) state = 3 ;
               else if( ch == CR ) state = 2 ;
               else state = 1 ;
               break ;
     case 3:     /*-- Buffer result, watch for trailing CR --*/
               if( ch == CR ) state = 4 ;
               else buf[ i++ ] = ch ;
               if( i > LIMIT ) state = 1 ;
               break ;
     case 4:     /*-- Scanning for trailing LF --*/
               if( ch == LF ) state = 5 ;
               else if( ch == CR ) state = 2 ;
               else state = 1 ;
               break ;
}
if( state == 5 )
{
     buf[ i ] = 0 ; /* Null terminate buffer */
     <process result in 'buf'>
     state = 1 ;
}

This state machine can be imbedded within a loop that reads all received 
data one character at a time, checks for a timeout, and also checks for 
user abort. Once a result is recognized, that loop can be exited or 
continued if additional results are expected.

Once a result code string is returned, it can be compared against the 
known result code strings. Some strings may incorporate wild-card 
suffixes. For example CONNECT followed by any numeric value indicates a 
successful connection at the indicated transmission rate. Even if a 
result such as CONNECT 38400 is not anticipated, if the controller has 
been coded for wild-card recognition, the controller will be capable of 
interpreting such responses correctly. This practice also facilitates 
interpretation of connection failed messages that are preceded by NO 
followed by any other character string such as DIALTONE, CARRIER, or 
ANSWER.

************************************************************************
D.3  Modem Preparation

Once the modem has been identified, the controller can continue to 
program any registers or user-defined values into the modem necessary 
prior to initiating the connection process. Typically, the setup 
operation is separated from the connection processing because it is 
performed independently of whether the call establishment will be in the 
originating or answering mode.

Setup commands can be issued at the highest transmission rate the modem 
supports as determined from the identification process or it may be 
fixed at a certain value if the modem is not identified.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
D.3.1  Reset

Before issuing any other commands to the modem, it is advisable to issue 
a Z or &F command to the modem before the identification or setup 
process. No specific response should be anticipated. The modem may be 
set up to return numeric, or no result codes. If a reset will be used, 
the following points should be considered:

*  Even if a recognizable result within 2.6 seconds, the program should 
continue. (Some modems do a lengthy reset process before responding with 
a result; others may be in Q1 or V0 mode.)

*  Following an OK result, an additional 600ms delay should be imposed. 
Some modems will respond with an OK then do lengthy reset processing, in 
which case they are unable to accept additional commands.

After the modem is reset, the first setup string (e.g., verbose rather 
than numeric result codes) should be issued, then the identification 
command.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
D.3.2  Setup

Software should generally provide some modem setup. However, the 
software can be written to rely on modem configuration via a stored 
profile recalled on reset, or  by DIP switches set depending on the 
product. In this case, any unique settings must have been set up prior 
to running the software, and all the program does is send the Z command 
to recall the desired profile. Even more basically, software can assume 
the modem is in the power-up state. However, unless the software will be 
used within a very predictable environment, these assumptions may result 
in failures with the controller software.

Some commands will always be overridden by the controller in order to 
ensure its proper functioning. Other command options should either 
default to the factory setting, or simply act as the "transfer agent" 
for the commands specified by the user. Menus and dialogs can be 
provided to prompt the user for specific activities; the program can 
then interpret these requests and configure the modem accordingly, as 
Hayes Smartcom products do, or provide the user opportunity to enter AT 
command strings.

Commands frequently set by a modem controller:

E0         Turn off echo mode to avoid having command echoes pass 
           through the result code scanner.

&F         Recall the factory profile.

Q1         Enable result codes to ensure that commands are being 
           processed, and to synchronize with the modem command 
           processor (except for synchronous communications where result 
           codes may cause the DTE confusion).

V0 or V1   Use either numeric result codes or verbose (recommended) 
           result codes.

S0=0       Disable auto-answer during the setup process to avoid 
           inadvertent disruption by an incoming call.

H0         Ensure modem is on hook before continuing to the answer or 
           originate process.

S12=10     Set the escape sequence guard time to 200ms to hasten the 
           escape for hang-up process. Also reduces the probability of 
           inadvertent user escapes.

S2=*       Change the escape sequence character for two reasons: To 
           avoid inadvertent user escapes, and to provide different 
           escape sequence characters for answer and originate ends. 
           This prevents inadvertent escaping when data is echoed.

S4=*       Modify the linefeed character to make the <CR><LF>NO 
           CARRIER<CR><LF> result code more unique if you scan for it
           to detect carrier loss.

S95=60     Enables the result codes which will provide the maximum 
           amount of information about the connection when it is 
           established.

Two typical setup sequences using these recommendations are shown below:

Recommendation for software design based on using pre-existing user 
settings:
              AT E Q V S0=0 H S12=10 S2=28 S4=31 S95=60 <CR>

Recommendation for software design based on starting from a known 
factory setting: 
              AT &F S2=28 S4=31 S12=10 S95=60

Note: Where the zero suffix is used, it may be omitted from a command. 
Spaces are shown above for readability, but the use of spaces between 
commands is not recommended. 

Once this setup command has been sent, and the OK response returned, the 
controller can continue to the originate or answer processing.

If user-programmed settings are included in additional setup strings, or 
the user is permitted to enter AT setup strings, the software should 
anticipate ERROR result codes. If an ERROR is returned in response to 
such a command, the result does not have to be reported to the user, but 
the controller should not be prevented from continuing in either case. 
Many times a connection can be made even though some setting is in error 
or is inappropriate for the class of modem being addressed.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
D.3.3  Establishing the Desired Connection and Fallback Strategy 
       (S36 Developers' Tips)

S36 determines which fallback action will occur if the protocols and 
procedures set by S46 and S48 do not produce a LAP-based (LAPB) error-
controlled connection.

The optimum fallback control strategy depends on which Hayes error-
control modem you have. The fallback behavior is determined by S36, S46, 
S48, and &Q5.

There have been two improvements in the V-series, OPTIMA and ACCURA EC 
modems that affect S36: The first added &Q6 Asynchronous Speed Buffering
(ASB); ASB provides the same fixed speed DTE interface and local flow control 
as in the error control mode but without the error control or remote 
flow control. The second improvement added V.42 with its Alternate 
Protocol (MNP).

Previously, S36 only consisted of one bit, Bit 0, 
which permitted the user to decide whether the modem would hang up or 
not if it did not succeed in negotiating an error-controlled connection. 
The factory default for S36 was 1, which meant fall back to direct async 
rather than hang up if an error control protocol is not established in 
&Q5 mode.

When &Q6 (ASB) was added, a fall back option for &Q5 mode, which can be 
controlled with S36, was also added. If S36 Bit 1 is set, and bit 0 is 
also set, the modem will fall back to ASB instead of direct async if no 
error control protocol is established in &Q5 mode. The factory default 
for S36 remained 1.

When V.42 was added, it added another fall back option, MNP, to S36. If 
S36 Bit 2 is set, then MNP will be attempted if the primary protocol 
selected in S48 is not established. Bit 2 is evaluated before Bits 0, 
then Bit 1. If MNP is established as the protocol, then Bits 0 and 1 are 
ignored. The factory default became 5 and later was changed to 7 to take 
more advantage of ASB.

Now that we know that there are three versions of S36, we may need a way 
to tell which version our software is controlling. First, verify that it 
is a Hayes error-control modem. This is done by issuing an I4 command 
and looking for the existence of a "b-string". A b-string begins with a 
lower case letter "b" and is followed by several upper case letters or 
numbers forming a hex value.

The easiest way for software to identify whether a Hayes modem 
supports Asynchronous Speed Buffering (also known as ASB, Buffered 
Async, or Normal) is to issue the following AT command,  AT &Q6 &Q5 
<CR>. If the result code is OK then &Q6 is supported, and ASB is also 
supported as a fall back. If the result code is ERROR, then &Q6 is not 
supported. If this is the case, then software should be prepared to fall 
back to a direct async connection.

The easiest way for software to identify whether a Hayes modem 
supports V.42 (and MNP) is to decode the first character after the 
leading "b" in the b-string of the I4 ID command response. The 
characters following the "b" in that line are "ASCII-hex" (0-9, A-F), 
which decode into 4 bits of ID code (3-0).  If Bit 3 is set, then MNP is 
supported; Bit 2 is V.42.

Armed with the knowledge of which S36 bits are supported, the software 
may now safely configure the modem and properly anticipate the fall-back 
action.

It should be safe to set S36 bit 2 to enable V.42 (and MNP) even if 
those protocols are not supported in the modem.

If the modem does not support ASB, then software should be prepared to 
follow the CONNECT XXXXX speed result code and change the DTE port speed 
to match the indicated line speed of the direct connection when no error 
controlled connection was negotiated.

If software will not change port speeds in response to the CONNECT 
message, then when software has identified a 'pre-ASB' modem, 
it should set S36 to 0 or 4 so that if no protocol is negotiated, the 
modem will hang up.

The following table shows the order in which the bits of S36 are 
evaluated: (Remember, these steps only occur after the S46/S48 
selections have failed to make a LAPBased error controlled connection in 
&Q5 mode.)