HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [hylafax-users] MODEM Command Error



The AT+FRS=n command is an extremely useful command which allows the Class 1 driver to "sync up" nearly on-demand, anytime it's used. There really is no substitute for it, either. Sometimes one can use AT+FRH=3 and, without getting a CONNECT, we can wait for a NO CARRIER ... but that's not consistent over modems, either, and it's really (in my opinion) a mis-use of the +FRH=3 command. The entire purpose of AT+FRS=n is to allow proper synchronization... and resynchronization.

The log you've provided below is a perfect example of why the +FRS=n command is so important. Without it, we depend on the other end to have the ability to sync-up with us (instead of us syncing up with them). If neither of us can sync up with the other then if we lose the initial synchronization (or never establish it in the first place) then what you see in the logs will happen.

USR modems, like yours, using the TI/USR/3Com chipset (some recent "winmodem" USRs use Conexant chipsets) seem to have problems sometimes after using +FRS=n. This is unfortunate. There are also many other modems that don't support +FRS=n at all.

You're welcome to try Class 2.0 and see if you fare any better, but you probably will have a different set of problems there.

If you have Caller*ID support then you could switch on-the-fly between Class 2.0 and Class 1 depending on the caller... but getting that all tuned right seems like a lot of work compared, maybe, to just buying a different modem.

Lee.


George H wrote:


I applied the work-around command to my config.ttySx files.

I do not get the MODEM Command error messages anymore but I get some
failed faxes in the logs like the below. I still get normal faxes most
of the times.

May 08 08:32:03.22: [20266]: --> [2:OK]
May 08 08:32:03.22: [20266]: <-- [9:AT+FRH=3\r]
May 08 08:32:10.23: [20266]: --> [0:]
May 08 08:32:10.23: [20266]: MODEM <Empty line>
May 08 08:32:10.23: [20266]: MODEM TIMEOUT: waiting for v.21 carrier
May 08 08:32:10.23: [20266]: <-- data [1]
May 08 08:32:10.28: [20266]: --> [2:OK]
May 08 08:32:10.28: [20266]: DELAY 70 ms
May 08 08:32:10.35: [20266]: <-- [9:AT+FTH=3\r]
May 08 08:32:10.43: [20266]: --> [7:CONNECT]
May 08 08:32:10.43: [20266]: <-- HDLC<32:FF C0 04 B5 00 AA 12 9E 36 86
62 82 1A 04 14 2E B6 94 04 6A A6 4E CE 96 F6 76 04 AC 74 8C 74 4C>
May 08 08:32:10.43: [20266]: <-- data [32]
May 08 08:32:10.43: [20266]: <-- data [2]
May 08 08:32:12.45: [20266]: --> [7:CONNECT]
May 08 08:32:12.45: [20266]: <-- HDLC<23:FF C0 02 4E A6 6E 4E A6 CA 04
1E 86 62 04 B2 F2 32 42 04 04 04 04 04>
May 08 08:32:12.45: [20266]: <-- data [23]
May 08 08:32:12.45: [20266]: <-- data [2]
May 08 08:32:13.28: [20266]: --> [7:CONNECT]
May 08 08:32:13.28: [20266]: <-- HDLC<13:FF C8 01 00 77 5F 23 01 FB C1 01 01 1E>
May 08 08:32:13.28: [20266]: <-- data [13]
May 08 08:32:13.28: [20266]: <-- data [2]
May 08 08:32:13.91: [20266]: --> [2:OK]
May 08 08:32:13.91: [20266]: <-- [9:AT+FRH=3\r]
May 08 08:32:20.92: [20266]: --> [0:]
May 08 08:32:20.92: [20266]: MODEM <Empty line>
May 08 08:32:20.92: [20266]: MODEM TIMEOUT: waiting for v.21 carrier
May 08 08:32:20.92: [20266]: <-- data [1]
May 08 08:32:20.97: [20266]: --> [2:OK]
May 08 08:32:20.97: [20266]: RECV FAX: No answer (T.30 T1 timeout)
May 08 08:32:20.97: [20266]: RECV FAX: end
May 08 08:32:20.97: [20266]: SESSION END



On 5/7/07, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:


George H wrote:

> May 07 12:34:41.21: [31707]: RECV training at v.29 9600 bit/s
> May 07 12:34:41.21: [31707]: MODEM set XON/XOFF/DRAIN: input ignored,
> output generated
> May 07 12:34:41.21: [31707]: <-- [10:AT+FRM=96\r]
> May 07 12:34:41.79: [31707]: --> [7:CONNECT]
> May 07 12:34:46.30: [31707]: MODEM TIMEOUT: receiving TCF
> May 07 12:34:46.30: [31707]: <-- data [1]
> May 07 12:34:46.37: [31707]: --> [2:]
> May 07 12:34:46.37: [31707]: --> [2:OK]
> May 07 12:34:46.37: [31707]: MODEM set XON/XOFF/DRAIN: input ignored,
> output disabled
> May 07 12:34:46.37: [31707]: <-- [9:AT+FRS=7\r]
> May 07 12:35:04.31: [31707]: --> [10:NO CARRIER]


Well, let me explain what that says.


It says that after receiving DCS (indicating an intent to use V.29 9600
bps) we then started listening for V.29 9600 bps carrier and heard it
and trained with it at 12:34:41.79.  If we are to trust the modem then
the sender did not drop the carrier for at least 4.5 seconds (TCF
training is only supposed to be 1.5 seconds long).  HylaFAX told the
modem to abort TCF reception and to then await the carrier drop
(AT+FRS=7).  That carrier drop was finally detected at 12:35:04.31, 22
seconds later, at which point the modem was then on-hook.

As it's an analogue modem I suspect that this represents an error with
the modem itself.  I would counsel you the same way as I've been
counselling USR users for a while now... avoid using +FRS entirely (your
session has it used twice).  Please make sure that you have this in your
modem config file:

#
# When using AT+FRS=n we see USR modems reset themselves in the middle
of sessions
# this is not good.  So, we seem to work-around that problem by not
using the
# command.  Unfortunately, this isn't an ideal thing.
#
Class1SwitchingCmd:     "<delay:7>"

Lee.





____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*




Project hosted by iFAX Solutions