Re: [hylafax-users] RECV FAX: Failed to properly detect high-speed data carrier.

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Hans Strickler wrote:

> Trying to make sure this is not a configuration error and/or where the 
> problem is in the connection.  Any input gladly accepted.
>
>  
>
> Suse 9.1
>
> HylaFAX (tm) Version 4.2.1
>
> Multi Tech MT5634ZPX-PCI-V.92 Internal Modem(s)
>
>
> Feb 25 14:07:40.75: [ 7153]: <-- [9:AT+FTH=3\r]
>
> Feb 25 14:07:41.71: [ 7153]: --> [7:CONNECT]
>
> Feb 25 14:07:41.71: [ 7153]: <-- HDLC<3:FF C8 23>
>
> Feb 25 14:07:42.10: [ 7153]: --> [2:OK]
>
> Feb 25 14:07:42.10: [ 7153]: RECV send CTR (confirm continue to correct)
>
> Feb 25 14:07:42.10: [ 7153]: MODEM input buffering enabled
>
> Feb 25 14:07:42.10: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:44.53: [ 7153]: --> [8:+FCERROR]
>
> Feb 25 14:07:44.53: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:44.74: [ 7153]: --> [8:+FCERROR]
>
> Feb 25 14:07:44.74: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:45.05: [ 7153]: --> [8:+FCERROR]
>
> Feb 25 14:07:45.05: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:48.58: [ 7153]: --> [8:+FCERROR]
>
> Feb 25 14:07:48.58: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:48.79: [ 7153]: --> [8:+FCERROR]
>
> Feb 25 14:07:48.79: [ 7153]: <-- [11:AT+FRM=121\r]
>
> Feb 25 14:07:49.00: [ 7153]: --> [8:+FCERROR]

Unfortunately, there's not a one-size-fits-all way to handle +FCERROR.

Getting +FCERROR after AT+FRM=121 means that we went looking for the 
V.17 12000 baud carrier and found some other carrier (probably V.21) 
present instead.  There is a possibility that this means that the sender 
is trying to communicate something with V.21, or it could mean that the 
sender's modulators made some noises that tricked our end into thinking 
that V.21 was heard, or it could mean that *our own* V.21 carrier has 
not turned off (as silly as that may sound), or it could mean other 
things, too.

In this situation we simply handle +FCERROR by repeating AT+FRM=121 for 
up to 20 times (as long as we keep getting +FCERROR).  Twenty times may 
be a bit excessive, but in my real-world testing looping like this 
actually proved to be the most advantageous approach because often 
(depending mostly on the modem type) I see +FCERROR happen a few times, 
but eventually we successfully connect with the expected carrier.

Now, we *could*, at least at some point after +FCERROR, issue AT+FRH=3 
(to receive the V.21 message).  However, chances are rather good that 
we'll have missed it.  Usually we have to issue AT+FRH=3 *before* the 
sender raises the carrier's training flags for things to work right.  
So, the only real advantage to doing AT+FRH=3 would be in expectation of 
the sender repeating the message after the first non-response.  In most 
cases I found that when doing this, the message that we'd end up 
receiving would be DCN (disconnect), and that doesn't help us out much 
anyway.

Perhaps a fair compromize would be to limit the +FCERROR loop to maybe 5 
times, and then go to the AT+FRH=3 approach.  I could probably code up a 
patch that would do this for you, if you wanted to play guinea-pig.

However, the fact that your log shows CTC/CTR indicates a rather 
significant communication problem between you and the sender, and I'd 
recommend fixing that first.  Do you see CTC happen very often?

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*