(1)  Short note on the overloading of numeric response codes

If the AT+FTS=? command was issued on a modem that didn't support
it, and if numeric result codes were set, it would appear that the
modem could only delay for 40 ms intervals, since the numeric code
for ERROR is 4.

(2)  Short note on asymmetric capabilities

Models with other asymmetric fax capabilities, such as modems that
can transmit using V.17 but can't receive with that modulation are
also available, as in the following example, captured from an
industrial-quality rather than a personal computer modem :

AT+FRM=?                What speed can the modem use to receive T.4 data
3,24,48,96              V21, V.27 ter and V.29 modulation only
AT+FTM=?                What speed can the modem use to transmit T.4 data
3,24,48,72,73,74,96,97,98,121,122,145,146
                        V.21 V.27 ter V.29 and V.17 modulation

Note that the modem in this last example doesn't believe in final OK
result codes.  I haven't seen any modems which have more
comprehensive receive than transmit capabilities (but that doesn't
mean they don't exist). You should note that the restrictions here
don't imply an inability to handle a specific data rate, but do imply
an inability to handle a specific modulation scheme.  For instance,
the example above can certainly handle 9600 bps fax reception, but it
can only do so by using V.29 modulation.  This is the most common fax
speed, incidentally.  It should be remembered that when faxes
publicise their capability to send and receive at 9600 bps, they are
always referring to V.29 modulation.  Nobody boasts about support for
the V.17 version of 9600 bps, as boasting about 14400 bps is much
more impressive.

One other thing that is worth noticing is that fax modems are quite
capable of admitting to having either useless or impossible
capabilities.  An example of this is the modem above that claims to
be able to transmit T.4 at 300 bps.  This is something that is not a
recognised group 3 option.  Attempting to use it would result in a
fax taking 32 times longer to send that using 9600 bps, which would
give a worse performance than the obsolete group 1 fax machines.

(3)  Short note on half duplex modem responses

We've mentioned that half duplex communications are subtly
different to full duplex communication in earlier chapters.  It might
seem quite obvious that while two modems can transmit and receive at
the same time over a full duplex link, over a half duplex link one
end is the transmitter and the other end is the receiver.  Or to put
this a different way, a full duplex connection allows bidirectional
communications, while a half duplex link only allows communications
to take place in one direction at a time.  The subtlety arises from
the fact that when two modems communicate in half duplex mode, the
receiver is incapable of sending and the transmitter is incapable of
receiving.  This means that all transmissions are blind.  There is no
way a transmitter could even listen to any signal which might let it
know whether or not it was being received correctly, and there is no
way a receiver could send such a signal even if the transmitter were
capable of hearing it.  So while making a transmission over a full
duplex link when no carrier signal has been detected is clearly a
waste of time, it happens as a matter of course in half duplex
communications.  The transmitter cannot hear a carrier, and the
receiver cannot send one.  Response codes such as CONNECT and NO
CARRIER have a quite different meaning when used by fax modems.  A NO
CARRIER message, and the sight of the DCD light on a breakout display
or a modem panel going out is something that people brought up on
normal asynchronous data communications associate with dropped lines
and failed sessions, but in the context of half duplex fax sessions
all this is a quite normal part of line turnaround.

Furthermore, programmers used to dealing with full duplex
communications are also used to dealing with a modem in its command
mode only under a very restricted set of circumstances.  Setup and
dialling commands are one thing, but communicating with a modem in
command mode when it is on hook is generally done only when it is time
to disconnect.  The contrast with half duplex fax communications is
striking.  A fax session is marked by a continual sequence of on-hook
commands sent by application software in response to messages sent by
the modem.

The usual primary response to a command that has been accepted is the
CONNECT message.  It should follow all the class 1 fax data commands,
and means that data should be either transmitted or received.

An ERROR response at this stage means that the command was not sent
correctly.  Using a parameter that is out of range could provoke this
response, in which case the remedy is to check the range of possible
parameters with the =? form of the command, and then to try again. It
can also appear if a CONNECT response to a transmit data command
isn't followed by the sending of data.

An OK is not a normal primary response, and an inappropriate OK means
that either the hardware or the software must be behaving in an
irregular or unreliable manner.  This doesn't of course apply to the
AT+FRS=n and AT+FTS=n silence timing commands mentioned belowe.  An OK
is also the response to an aborted command. This use should be
familiar to anyone who has programmed a Hayes compatible modem, as OK
has always been the usual response issued when a dialling command is
cancelled.

The two silence commands AT+FTS=n and AT+FRS=n generate a simple
OK response after the required period of silence has been observed or
detected. An OK is not a normal primary response to a data command
however, and an inappropriate OK means that either the hardware or
the software must be behaving in an irregular or unreliable manner.
This doesn't of course apply to the AT+FRS=n and AT+FTS=n silence
timing commands mentioned above.  An OK is also the response to an
aborted command. This use should be familiar to anyone who has
programmed a Hayes compatible modem, as OK has always been the usual
response issued when a dialling command is cancelled.

(4)  Short note on modem training

The type of training when establishing a modulation is not to be
confused with the TCF training check frame required to evaluate the
quality of a phone line which we mentioned above.  The TCF is
generated and evaluated as part of the T.30 session protocol, whereas
a synchronous training sequence is a much lower level phenomenon.  In
terms of the ISO model presented briefly in our chapter on the
extensions to T.30, it is part of the data link layer.

(5)  Short note on flow control failures

These needn't be a result of faulty software or slow OS responses to
stop events; it could also occur with external modems when using
hardware flow control as a result of a dry joint in a connector plug
or some other cable fault. I've always found cable faults of this
type the most difficult problems to diagnose, as I tend look for
software reasons for unpredictable behaviour, which experiments with
various modems indicate is precisely what happens when flow control
fails. While some modems seem to switch off and ignore data that
overruns buffers until they get back to decent buffer level, others
get very confused and accept odd bytes when they have the room, and
can respond with ERROR or even NO CARRIER messages depending on what
they think is happening. There is no prescribed behaviour for this
situation and consequently it is difficult to work out what is going
on.

(6)  Short note on an ambiguity in the Class 1 TCF specification

The class 1 specification is slightly inaccurate when it talks of on
replicating nulls.  In normal AT+FTM transmission, a <dle><etx> pair
ending a TCF is not transmitted, since the data stream filtering
prescribed by the class 1 data rules ensure the sequence is
recognised as the end of data.  This means that the last byte
actually transmitted was the last NULL of the sequence.  The exact
wording of the class 1 document is that if

"the last transmitted character is ASCII NULL (0) the DCE shall
continue to transmit NULLs until the DTE sends more data or until 5
seconds elapse"

Were we to interpret this literally, we'd have to end the TCF with at
least one byte which was neither a NULL nor a <dle>.  In fact, the
universal interpretation of the specification is that the modem's
"last transmitted character" really means its last received
character, which is the computer's last transmitted character.

(7)  Short note on sending null frames

The +FTH command can also be used to send a null frame.  This is
used in situations where the transmitter wants to tell the modem to
return to command mode, but doesn't want to tell the remote fax that
it has finished transmitting.  There's actually only one situation
where a null frame is a normal occurrence.  It must be sent to the
modem after the RCP frames have been transmitted in error correcting
mode (ECM) in order that the modulation can be changed from
high-speed transmission to low-speed negotiation before the post-page
commands are sent.  We'll see this when we cover error correcting
mode in more detail later on in this chapter.

(8)  Short note on deliberate underrun

The TSB-43 note issued by the TR 29.2 committee to clarify the
workings of class 1 points out that the ending of a transmission with
a deliberate underrun has been interpreted by some software houses as
permitting the ending of a frame without a terminating <dle><etx> by
the simpler method of just stopping after the final data byte.  The
modem detects this and ends the frame itself.  This was clearly not
what was intended, as TSB-43 seeks to discourage this practice by
pointing out that it doesn't permit the modem to tell whether the
underrun occurred intentionally or by mistake.  The latest version of
EIA-578 explicitly states the ending the data stream with the
<dle><etx> is the preferred method.

Personally, I think this is rather a weak argument, as it makes
absolutely no difference at all to the modem what the reason for the
underrun might be ; it takes the same action and issues the same
response whether a frame ends with a buffer underrun or a
<dle><etx>.  It is even possible to argue that the buffer underrun
method is preferable because it requires less overhead on the computer
CPU, and can in theory results in faster response times by around a
millisecond.  The class 1 specification states that a fax modem
shouldn't add the FCS and the final flag until the buffer is empty in
any case.  However, there is one occasion where the <dle><etx> frame
terminating sequence has to be used, as buffer underrun isn't an
option.  This is when is when a null frame is sent to the fax modem. 
A null frame, being a frame with no contents, isn't retransmitted to
the remote fax, but is instead taken by the fax modem as an
indication that a sequence of transmitted frames has ended.

(9)  Short note on the T.30 preamble 

You may recall that T.30 specified 1 second of flags as a preamble to
sending any sequence of negotiating frames.  The Class 1
recommendation doesn't say that the modem automatically handles this
requirement, but as I've never seen a negotiation failure that
resulted from ignoring it, I think that it must do.

(10)  Short note on AT+FRH and the NO CARRIER report

There is some confusion in the EIA-578 class 1 recommendation
regarding this report.  Both section 8.3.4 describing +FRM, and the
sample calling sequence in section A2.1 seem to imply that the NO
CARRIER is spontaneously generated by the fax modem.  This is in fact
incorrect.  While the NO CARRIER is an acceptable response to an
AT+FRH command when a carrier is lost, it is always a response, and
is never a spontaneous report.  Note that it is not followed by a
final OK.  Issuing AT+FRH when the last frame had a P/F bit of 1 is
an example of this type of NO CARRIER.


(11)  Extended note on the need for a timeout with AT+FRM data

There is some ambiguity in the specification as to what
constitutes the end of the received data stream.  The T.4
recommendation is quite clear that end of the data is marked by an
RTC sequence ; RTC stands for Return to Control.  Following the RTC,
the transmitter switches back to the negotiating speed and sends its
post-page message.  However, the definition of service class 1 is
quite clear that

"CCITT T.30 session management and CCITT T.4 image data handling are
done by the DTE" (2.1/EIA-578)

and that consequently a class 1 modem is under no obligation to scan
the incoming data looking for an RTC sequence, and indeed, ought to
pass all data through transparently.  The EIA Class 1 specification
further states that after the +FRM command, the modem should mark the
end of data with the <dle><etx> sequence and then return to command
mode with the NO CARRIER message upon detecting a loss of carrier.
While this may be contrary to the T.30 recommendation, it is
acceptable behaviour for a class 1 modem.  However, a surprising
omission from EIA-578 is any guidance as to how a modem should decide
when a carrier has been lost.  Though it isn't part of the
specification, a reasonable deduction is that there has to be a
timeout that controls the reporting of loss of carrier in all class 1
modems.  As a matter of fact, the Rockwell class 1 documentation
specifically states that S10 is used for this purpose when both +FRH
and +FRM have been issued.

In the case of +FRH though, data reception is not transparent and the
fax modem is obliged to check all incoming HDLC data ; it returns to
command mode with either OK or ERROR after detecting a closing flag
once the frame check sequences have been compared.  No timeout is
needed ; in case of error the maximum frame length of around 3
seconds should provide sufficient indication of carrier loss.

This doesn't apply in the case of the +FRM ; the transparency of all
received data means that some sort of carrier timeout must be the
primary mechanism used to decide when to return to command mode after
phase C has finished.  The length of the timeout used is fairly
important, as one that is too long can easily disrupt receipt of
phase D post-page messages.  If the receiver doesn't move to phase D
quickly enough, then the result at best is inefficiency, and at worst
a complete loss of the session.  The T.30 specification is quite
clear as to the timings involved here.

There are four considerations :

1.  5.3.2/T.30 states that "transmission of the RTC signals the T.4
modulation to drop off the line and be replaced by the T.30 binary
coded modulation system.  The transmission of the RTC signal shall be
followed by a delay of 75  20 ms before the T.30 binary coded
modulation system commences to transmit."  Presumably this delay
occurs while the line is idling.  The worst case delay is 55 ms while
the best case delay is 95 ms.

2.  5.3.1/T.30 states that "the preamble for binary coded signalling
at 300 bit/s shall be a series of flag sequences for 1 s  15%."  The
worst case preamble is therefore 850 ms, with the best case preamble
being 1150 ms.

3.  A post-message command consists of address, control and FCF
octets, with a 16-bit frame check and a closing flag ; these 6 octets
take only 20 ms to transmit under all circumstances.

4.  5.4.2/T.30 states that "if the transmitting station does not
receive an appropriate valid response within 3 s  15% it will repeat
the command.  After three unsuccessful attempts the transmitting
station will send the disconnect (DCN) command and terminate the
call."  The worst case again is that the transmitter will wait only
2550 ms for a response ; in the best case the wait will be 3450 ms.


Adding these up, we can see that if the receiver delays moving to
phase D longer than 1.245 seconds then it is bound to lose the
transmitter's first attempt at sending a phase D command ; in order
to be sure of receiving it the receiver must move to phase D within
905 ms.  If the receiver takes longer than 4.4 seconds to begin phase
D it could also lose the second attempt to send the post-message
command, while if it waits longer than 7.9 seconds it might also lose
the third, and with it the whole session.

In fact, the situation is complicated by the fact that the fax modem
has to send a <dle><etx> and a NO CARRIER code to the computer, and
the application software controlling the modem has to see this
message, save its data to disk, and then send the AT+FRH command to
the modem before phase D can start.  There may also be some latency
in the modem itself which affects the issuing of responses and the
performance of commands.

It's often said that the timing requirements involved in handling the
T.30 session protocol using class 1 modems is one of their limiting
factors.  It must surely be even more of a limiting factor if a large
proportion of the 905 ms allowable between the end of phase C data
and the arrival of a phase D command is taken up with waiting for the
modem to detect a carrier loss.  I therefore decided to investigate
the actual timings involved empirically.

I was initially puzzled by Rockwell's assertion that S10 controlled
this timeout.  S10 is one of those parameters whose default varies
widely from modem to modem, though all agree that the units used are
1/10th second intervals.  The original Hayes Smartmodem 1200 default
was originally 7 (for 7/10th second) but some modems report defaults
as high as 50 (for 5 seconds).  My puzzlement arose because the most
common default these days is 14 (for 1.4 seconds), which is what
Rockwell claim to use.  Clearly, a 1.4 second delay before the
post-message command can be picked up is far too long, and if true,
guarantees that at least one error with one retransmitted phase D
frame will result.

I tested the behaviour of S10 on a popular Rockwell-based modem.
Issuing the ATS10?  command after +FCLASS=1 but before receiving fax
data indeed produced the response 14.  However, no errors were
forthcoming ; increasing the value of S10 from 14 to 200 failed to
generate any errors either.  Fortunately, it seems the S10 register
does not control the phase C carrier timeout at all.

In an attempt to find out what timeouts were used, I inspected the raw
data stream received.  This shows that class 1 fax modems do quite
happily carry on receiving data after 6 EOL codes have been received,
as intimated in the class 1 specification.  This data initially
appears as flag octets, with the hexadecimal value ffh, which is what
might be expected if the transmitter hadn't dropped the carrier
immediately.  These flags are followed by garbage bytes with random
values, which in turn are followed by the <dle><etx> sequence.  The
number of flags and the number of garbage bits is also unaffected by
register S10, but is affected by the connection speed of the fax. 
Whether a connection was made at 14400 bps or 4800 bps, the closing
flags after the RTC lasted about 40 ms and the garbage between the
flags and the <dle><etx> lasted about 12 ms.  I didn't time these ; I
counted the bits in the data received and worked backwards from the
reported connection speed.

My conclusion from that particular session was that the transmitter
was taking around 40 ms to drop the carrier after the RTC was sent ;
this is allowable, as up to 75 ms can elapse before phase D has to
begin.  Once the carrier had been dropped, the Rockwell fax modem
detected this and reported back with the <dle><etx> in around 12 ms.

The time lost from the modem overhead is therefore quite
insignificant.  The +FRM command becomes quite straightforward to
implement if timings aren't an issue.  All an application has to do
is to take in all the data that comes, handle the <dle> shielding and
trust the modem to detect when the transmit carrier has gone off.
Once the terminating <dle><etx> has been sent, the application can
save the data, and wait for the to modem sends the secondary result
code NO CARRIER before issuing another command.

(12)  Short note on breaking up octets into bits

Here's an analogy giving you some idea of what chaos can result when
breaking up an ordered sequence.  Image what would happen if a
solitary phoenix turned up at Noah's Ark and went in with a
half-blind rhinoceros. The successively ordered pairs of animals
would be disrupted in the same way. The other rhino would have to
pair off with the lion, the other lion would have to pair off with a
tortoise, the spare tortoise would end up with a giraffe, and so on.
If Noah came along a couple of hours later to check, there would be a
lot of work to do in sorting out the resulting mess.

(13)  Extended note on latest Class 1 AT+F enhancements

I have not seen a final draft of the T.class1 proposals.  The
information given here is therefore preliminary and its status may
change in the future.  I had thought that final approval of all new
EIA fax modem standards may well be delayed until they can
incorporate changes relating to the new 28800 bps half duplex
modulation scheme included in the V.34 proposals, but this may turn
out to be incorrect.  Recent reports reaching me that T.class1 has
been approved by the ITU as recommendation T.31 (with T.class2 being
approved as T.32) were denied (in writing) by the ITU when I asked
them.

Meanwhile, the latest revision of EIA-578 does include a number of
new commands. All the commands are optional and need not be
implemented by manufacturers.  While it is true that the proposal
incorporating these changes is not yet approved, the first five of
the new commands seem to be taken directly from the EIA-592 class 2.0
document, which definitely is approved.  This isn't just a
coincidence, though there doesn't seem to be a commitment to
introduce more commands common to all fax modem classes as a matter
of principle.  Nevertheless, it is most unlikely that descriptions of
the commands given here will change in any significant way, as they
also apply to the class 2.0 versions.

                        A. Modem interrogation

The first three commands all provide the same sort of modem
identification information that existing class 1 modem programmers
usually obtain from the various ATI commands in non-fax modem.  All
the commands return text strings ; apart from limit of 2048
characters and a prohibition on including the OK result code in any
details returned, the implementation is essentially free-format.

i. The +FMI? command causes the modem to return manufacturer
identification information as one or more lines of text.

ii. The +FMM? command causes the modem to return product
identification information as one or more lines of text.

iii. The +FMR?  command causes the modem to return version number or
revision level information as one or more lines of text.

                  B. Modem to computer configuration

The next two commands are specifically aimed at helping to solve the
problems of modem to computer links which are probably the most
common cause of failed fax sessions.

iv. The +FLO command takes one parameter :

AT+FLO=0 turns off all flow control.  The draft document states that
if +FLO=0 then "some other method shall be used which is beyond the
scope of this standard".

AT+FLO=1 turns on XON/XOFF flow control in either direction.  This is
the default.  The class 2.0 specification doesn't make clear that
this should be active in only one direction at a time ; flow control
is needed to control data output to the modem when transmitting
faxes, but is used to control data input from the modem when
receiving faxes.  In both cases, the bit stream may contain apparent
XON and XOFF characters which in reality are part of an image and
need to be left alone.

AT+FLO=2 sets CTS/RTS flow control.  The standard actually states
that this means we "use circuit 133 for flow control of the DCE by
the DTE" and that we "use circuit 106 for flow control of the DTE by
the DCE".  Hardware flow control is optional and does not have to be
implemented.

There is command to turn on both XON/XOFF and CTS/RTS flow control. 
It is a shame the parameter is not a bitmapped one, with bit 1
controlling XON/XOFF and bit 2 controlling CTS/RTS.  If this had been
adopted, then the AT+FLO=3 command would turn on both XON/XOFF and
CTS/RTS flow control.

v. AT+FPR

This command controls the speed at which the computer and the fax
modem communicate.  It takes a single parameter, which is the desired
bit rate divided by 2400.  The following table, taken from the latest
draft of TIA/EIA-578, shows that the parameter is given as a
hexadecimal digit, which is unusual given that all the other
parameters take decimal values.  It also seems to represent a
difference from the class 2.0 version of this +FPR.


Ŀ
0  autobaud      
1  fixed @ 2400  
2  fixed @ 4800  
3  fixed @ 7200  
4  fixed @ 9600  
6  fixed @ 14400 
8  fixed @ 19200 
C  fixed @ 28800 
10 fixed @ 38400 
18 fixed @ 57600 



There are two possible defaults for this command.

The first default is the special case AT+FPR=0, which causes the
modem to autobaud ; it detects the speed from the AT prefix of each
command it is sent, and uses the last speed it received a command at
for all its reports.

The second default is AT+FPR=8.  Since 2400 x 8 = 19200, this causes
the modem to communicate with the modem at a fixed rate of 19200 bps
while AT+FCLASS=0.  As we saw in chapter 6, modems which run at a
fixed speed of 19200 when in fax mode predate the class 2.0
specification by some years.

While autobauding is optional, values of 4 and 8 (9600 bps as well as
19200 bps) are mandatory.  As usual, the AT+FPT=? form of the command
will enable an application to determine the possible values.  

The speed specified by +FPR takes effect immediately after modem
finishes issuing the OK result code.  The class 1 recommendation
states that this command can be combined with +FCLASS, and gives the
example of 

AT+FCLASS=1;+FPR=8

as a method of setting a modem to class 1 and also setting the
interface speed at the same time.  I would recommend that users check
that this actually works before trying to use it.  I've generally
found that software which uses a separate line for each of the
commands in the AT+F command set tends to be more reliable when it
comes to coping with new modem models.


                          C. Fax data format

vi. AT+FDD

This optional command enables the use of the <dle><sub> embedded
control code to send two successive <dle> characters, where <sub> is
decimal 26 or hexadecimal 1ah.  The original class 1 specification
required that genuine <dle> pairs be sent as four characters in the
form <dle><dle><dle><dle>.

The default of +FDD=0 means that the <dle><sub> code will not be
used.  A modem has to explicitly enable the use of the shorter code
with the setting of +FDD=1.

