Fax Failures - Having problems with false V.21 detections while receiving faxes

This problem can cause many different +FHNG (if class 2) or +FHS (if class 2.x) errors when receiving faxes depending on when the false V.21 detection occurs. To see if this is occurring, you would need to get a log of a failed receive fax with +FDB debug enabled. This can be done on a FaxFinder product by enabling Fax Debugging in the Modem Configuration web page. On other fax servers this may not be possible.

Once you have a log of a failed fax, look for the consecutive +V21 lines in the log. If this is occurring over and over it may be that V.21 false detections are occurring. It helps however to know the T.30 protocol to know when such detections are legitimate or not.

Sometimes non-V.34 receive faxes can fail because a high speed signal (V.17, V.29, V.27) is erroneously detected as a low speed signal (V.21 -- 300 baud). This can be identified in modem logs when the modem has three +V21 debug lines in a row in a case where a high speed signal is expected and the timing is right (eg. shortly after sending an MCF or CFR). The solution is to make the detection algorithm tighter so that false V.21 detects don't occur.

There are two fax s-registers that control this behavior in the modems. The modem's algorithm to detect V.21 signals while waiting for a high speed signal involves using a tone detector that looks for signals that are either 1650Hz or 1850Hz. It checks for these tones periodically (how often is controlled by AT+FS1) and they must trigger so many times (how many times is controlled by AT+FS2) for it to be considered a legitimate V.21 signal.

AT+FS1 - this controls how often V.21 tones are checked for (in milliseconds, default 30)
AT+FS2 - this controls how many detections in a row are considered a valid V.21 signal (default: 3)

If you are having trouble with this, you can change this to:

AT+FS1=32;+FS2=7

NOTE: The values for these S-registers are given in hex so 0x32 is really 50 decimal.