Re: [hylafax-users] USR 56k internal

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Jeff Schulze wrote:

> Mar 01 11:21:08.38: [ 2650]: RECV received frame number 13
> Mar 01 11:21:08.45: [ 2650]: Bad HDLC terminating flag received.
> Mar 01 11:21:08.45: [ 2650]: RECV assumed RCP frame with block end
> Mar 01 11:21:08.55: [ 2650]: --> [10:NO CARRIER]
> Mar 01 11:21:08.55: [ 2650]: <-- [9:AT+FRH=3\r]
> Mar 01 11:21:12.68: [ 2650]: --> [7:CONNECT]
> Mar 01 11:21:17.68: [ 2650]: --> [2:OK]


The version of HylaFAX and the level of logging that you have prevents 
us from knowing for certain what the signal received here was, but I'd 
guess at DCN.  Which would usually mean that the sender was aborting the 
fax at that point for some reason.  (Cancel button?  Paper jam?)

> Mar 01 09:31:13.14: [ 2568]: <-- [11:AT+FRM=146\r]
> Mar 01 09:31:20.25: [ 2568]: --> [2:OK] 


This is a USR thing here.  The only appropriate results for AT+FRM=146 
are NO CARRIER and ERROR.  Normally you'll see this sequence occur:

 <-- AT+FRM=146
 --> CONNECT
 --> data
 --> NO CARRIER

The OK response is undefined, and it probably means that the modem reset 
itself.  This kind of USR behavior started appearing when HylaFAX 
started using +FRS/+FTS instead of software delays.  And reports back 
seem to indicate that disabling the usage of +FTS/+FRS alleviates these 
kinds of problems.  Please see the end of the USR config here:

 
http://cvs.sourceforge.net/viewcvs.py/hylafax/hylafax/config/usr-xon?rev=1.2&view=markup

Although you seem to have indicated that you added this config item.  
This log you show us still uses AT+FRS=7, though.

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*