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

["Donald, Adam" <adam.donald@xxxxxxxxxxx>]

I am also using MT5634ZPX-PCI-V.92 Internal Modem(s), and getting similar
errors.

Hans, are you using firmware v 1.32i?

Lee, I see that you mention a problem with v.17 in this thread.
You may recall from a previous thread, "Re: [hylafax-users] Is DID required
for this application?", that I was having trouble with v.17 with the MT5634
as the sender.  While this issue that Hans has brought up deals with
receiving, do you think that it is related to the v.17 issue that you
mentioned in that previous thread?

FC 3
Hylafax 4.2.1
LT V.92 1.0 MT5634ZPX-PCI-U Internal Data/Fax/Voice Modem Version 1.32i
...
Mar 03 15:51:28.27: [16747]: RECV send PPR (partial page request)
Mar 03 15:51:28.27: [16747]: RECV sent fourth PPR
Mar 03 15:51:28.27: [16747]: <-- [9:AT+FRH=3\r]
Mar 03 15:51:28.36: [16747]: --> [7:CONNECT]
Mar 03 15:51:29.54: [16747]: --> [2:OK]
Mar 03 15:51:29.54: [16747]: RECV recv CTC (continue to correct)
Mar 03 15:51:29.54: [16747]: <-- [9:AT+FRS=7\r]
Mar 03 15:51:29.71: [16747]: --> [2:OK]
Mar 03 15:51:29.71: [16747]: <-- [9:AT+FTH=3\r]
Mar 03 15:51:30.68: [16747]: --> [7:CONNECT]
Mar 03 15:51:30.68: [16747]: <-- data [3]
Mar 03 15:51:30.68: [16747]: <-- data [2]
Mar 03 15:51:31.07: [16747]: --> [2:OK]
Mar 03 15:51:31.07: [16747]: RECV send CTR (confirm continue to correct)
Mar 03 15:51:31.07: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:33.41: [16747]: --> [8:+FCERROR]
Mar 03 15:51:33.41: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:33.63: [16747]: --> [8:+FCERROR]
Mar 03 15:51:33.63: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:37.39: [16747]: --> [8:+FCERROR]
Mar 03 15:51:37.39: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:37.62: [16747]: --> [8:+FCERROR]
Mar 03 15:51:37.62: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:37.84: [16747]: --> [8:+FCERROR]
Mar 03 15:51:37.84: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:38.07: [16747]: --> [8:+FCERROR]
Mar 03 15:51:38.07: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:38.29: [16747]: --> [8:+FCERROR]
Mar 03 15:51:38.29: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:38.66: [16747]: --> [8:+FCERROR]
Mar 03 15:51:38.66: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:42.22: [16747]: --> [8:+FCERROR]
Mar 03 15:51:42.23: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:42.45: [16747]: --> [8:+FCERROR]
Mar 03 15:51:42.45: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:42.67: [16747]: --> [8:+FCERROR]
Mar 03 15:51:42.67: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:42.90: [16747]: --> [8:+FCERROR]
Mar 03 15:51:42.90: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:43.12: [16747]: --> [8:+FCERROR]
Mar 03 15:51:43.12: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:47.02: [16747]: --> [8:+FCERROR]
Mar 03 15:51:47.02: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:47.25: [16747]: --> [8:+FCERROR]
Mar 03 15:51:47.25: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:47.47: [16747]: --> [8:+FCERROR]
Mar 03 15:51:47.47: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:47.70: [16747]: --> [8:+FCERROR]
Mar 03 15:51:47.70: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:47.92: [16747]: --> [8:+FCERROR]
Mar 03 15:51:47.92: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:48.15: [16747]: --> [8:+FCERROR]
Mar 03 15:51:48.15: [16747]: <-- [11:AT+FRM=121\r]
Mar 03 15:51:55.15: [16747]: RECV keeping unconfirmed page
...

-----Original Message-----
From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx] On Behalf Of Lee Howard
Sent: Tuesday, March 01, 2005 1:55 PM
To: Hans Strickler
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] RECV FAX: Failed to properly detect high-speed
data carrier.

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*

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