Re: [hylafax-users] MODEM Command Error

["George H" <george.dma@xxxxxxxxx>]

Thanks for explaining most of this stuff to me. I also found those
hylafax pages the go knee deep on how the modem works.

This problem where we have to depend on the other modem to sync-up to
me is an issue. Is there a way for me to test this bug against my USR
modem? I have a fax machine but it never fails when I fax it to
hylafax. Do you know a set of modem command that would simulate
sending a fax and will repetadely show the failure of the AT+FRH=3 and
AT+FTRS=7 ?

Thanks for all your help

On 5/8/07, Lee Howard <faxguy@xxxxxxxxxxxxxxxx> wrote:
> 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.
> >>
> >
> >


--
"Nothing is impossible for the person that doesn't have to do it"
"The probability of anything happening is in inverse ratio to its desirability"
"If I were a roman statue, I'd be made alabastard"
--
George H
george.dma@xxxxxxxxx

____________________ 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*