[hylafax-users] Custom AT commands for setting fax speed

Lee Howard

2003-10-15 05:21:42 UTC

Post by a***@sola.com.au
Hi, I have an issue where I need to be able to use a custom AT command for
setting the fax transmission speed. Is this possible?
I am having problems with my Diamond 56k modems, they do not seem to fully
support V.29 faxing. I can tell it to use v.17 but only at each
transmission speed and not as a general setting.
+FTM=73 V.17, 7200bps
+FTM=74 V.17 (short train), 7200bps
+FTM=97 V.17, 9600bps
+FTM=98 V.17 (short train), 9600bps
+FTM=121 V.17, 12000bps
+FTM=122 V.17 (short train), 12000bps
+FTM=145 V.17, 14400bps
+FTM=146 V.17 (short train), 14400bps
So - What I want to be able to do is (when sending a fax) if the modem
negotiates 9600 speed issue the command at+ftm=97 etc. Is there
anyway/anywhere that this can be done?

When negotiating data signalling rates, both speed *and* protocol are
negotiated together. So if the receiver supports a maximum speed of
9600 baud, that indicates that it does not support V.17 or V.33, and
therefore V.17 cannot be used.

When a fax sender connects with a fax receiver the receiver initially
transmits its capabilities to the sender in the DIS signal. With
respect to the data signalling rates, the DIS signal contains
information about the protocol and *not* about the speed. Thus a
receiver may say it supports one of

V.27 ter
V.29
V.27 ter and V.29
V.27 ter, V.29, and V.33
V.27 ter, V.29, V.33, and V.17

So... if the remote supports V.17 then the system will attempt to train
at 14400 bps and it will only initially attempt to train at 9600 baud
when the remote does not support V.17 or V.33. So using V.17 in lieu
of V.29 is not an option.

If your modem reports V.29 support (AT+FTM=? response includes 72 and
96) but the support is faulty then you're in bad shape as a receiver,
because, as you can see from the list above, V.29 support is an implied
prerequisite to V.17 and V.33 support, therefore you'll be limited to
V.27 ter (4800 bps in theory but 2400 bps as tested - some bug is in
faxgetty somewhere, most certainly) for receiving. Fortunately, as a
sender, HylaFAX controls the negotiation in order to make "skipping"
V.29 negotiations possible while still utilizing V.17.

HylaFAX simplifies bitrates by "mapping" speeds against protocols.
Thus in sending V.29 is always used for 9600 bps and 7200 bps, but not
V.17, and V.33 is never used at all. In other words, you must disable
all 9600 bps (including V.17) and 7200 bps (including V.17). If
HylaFAX sees your modem supporting *any* 9600 or 7200 baud setting,
then it will assume that your modem supports V.29. (This is a safe
assumption if you don't consider broken modems.)

The attached patch implements the Class1TMQueryCmd and Class1RMQueryCmd
configuration options. By default they are "AT+FTM=?" and "AT+FRM=?"
respectively, but you can "force" the response (without querying the
modem) like this:

Class1TMQueryCmd: "!3,24,48,121,122,145,146"
Class1RMQueryCmd: "!3,24,48,121,122,145,146"

which would disable HylaFAX from using V.29 support in your modem (by
disabling every instance of 9600 and 7200 bps). This will allow
HylaFAX to send faxes at 14400 (V.17), 12000 (V.17), 4800 (V.27 ter),
and 2400 (V.27 ter) baud. I haven't tested this, but I believe that
fallbacks will go from 12000 to 4800 bps (which generally won't be a
very bad thing, anyway, since you'd likely reach V.27 ter later in the
same call).

Let me know how you fare.

Lee. (who apparently needed a distraction tonight)