Re: [hylafax-users] MODEM Command Error

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*