Re: [hylafax-users] T.30 T2 / T1 timeouts and failure to properly detect high-speed data carrier

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2005.02.15 13:04 Hans Strickler wrote:

> System Specs:
>
>             SuSe 9.1
>
>             HylaFAX (tm) Version 4.2.1
>
>             2 MultiTech Modems (MT5634ZPX-PCI-V92) (both modems
> configured the same)

Feb 14 13:29:09.75: [ 6993]: RECV recv MPS (more pages, same document)
Feb 14 13:29:09.75: [ 6993]: <-- [9:AT+FRS=7\r]
Feb 14 13:29:09.93: [ 6993]: --> [2:OK]
Feb 14 13:29:09.93: [ 6993]: <-- [9:AT+FTH=3\r]
Feb 14 13:29:10.98: [ 6993]: --> [7:CONNECT]
Feb 14 13:29:10.98: [ 6993]: RECV send MCF (message confirmation)
Feb 14 13:29:10.98: [ 6993]: RECV FAX (000000275): from 919303****, 
page 5 in 0:54, INF, 3.85 line/mm, 1-D MH, 14400 bit/s
Feb 14 13:29:10.98: [ 6993]: <-- data [3]
Feb 14 13:29:10.98: [ 6993]: <-- data [2]
Feb 14 13:29:11.45: [ 6993]: --> [2:OK]
Feb 14 13:29:11.45: [ 6993]: <-- [11:AT+FRM=146\r]
Feb 14 13:29:12.96: [ 6993]: --> [7:CONNECT]
Feb 14 13:29:12.96: [ 6993]: RECV: begin page
Feb 14 13:29:30.16: [ 6993]: RECV: 30808 bytes of data, 422 total lines
Feb 14 13:29:30.16: [ 6993]: RECV: end page
Feb 14 13:29:30.16: [ 6993]: --> [10:NO CARRIER]
Feb 14 13:29:30.16: [ 6993]: <-- [9:AT+FRH=3\r]
Feb 14 13:29:30.54: [ 6993]: --> [7:CONNECT]
Feb 14 13:29:31.45: [ 6993]: --> [10:NO CARRIER]

422 lines is a rather short page compared to the other ones.  Maybe 
there was a disconnection.  Maybe the modem detected carrier loss when 
there wasn't one.  There isn't much that HylaFAX can do here, though.  
It would either be the modem manufacturer to fix this or an 
environmental fix with the lines, etc.

Feb 15 08:24:39.60: [ 6991]: RECV send PPR (partial page request)
Feb 15 08:24:39.60: [ 6991]: RECV sent fourth PPR
Feb 15 08:24:39.60: [ 6991]: <-- [9:AT+FRH=3\r]
Feb 15 08:24:39.84: [ 6991]: --> [7:CONNECT]
Feb 15 08:24:41.06: [ 6991]: --> [2:OK]
Feb 15 08:24:41.06: [ 6991]: RECV recv CTC (continue to correct)
Feb 15 08:24:41.06: [ 6991]: <-- [9:AT+FRS=7\r]
Feb 15 08:24:41.22: [ 6991]: --> [2:OK]
Feb 15 08:24:41.22: [ 6991]: <-- [9:AT+FTH=3\r]
Feb 15 08:24:42.17: [ 6991]: --> [7:CONNECT]
Feb 15 08:24:42.17: [ 6991]: <-- data [3]
Feb 15 08:24:42.17: [ 6991]: <-- data [2]
Feb 15 08:24:42.56: [ 6991]: --> [2:OK]
Feb 15 08:24:42.56: [ 6991]: RECV send CTR (confirm continue to correct)
Feb 15 08:24:42.56: [ 6991]: <-- [11:AT+FRM=121\r]
Feb 15 08:24:45.08: [ 6991]: --> [8:+FCERROR]
Feb 15 08:24:45.08: [ 6991]: <-- [11:AT+FRM=121\r]
Feb 15 08:24:45.29: [ 6991]: --> [8:+FCERROR]
Feb 15 08:24:45.29: [ 6991]: <-- [11:AT+FRM=121\r]
Feb 15 08:24:45.59: [ 6991]: --> [8:+FCERROR]

This kind of shortcoming could be largely avoided with AT+FAR=1... if 
only the modem supported it... and HylaFAX.  As it is, call this a 
problem with faxing.  Realize, though, that in order to get CTC you 
already know that there is a poor level of communication going on.  So, 
it's also possible that something happened beyond anyone's control.

If you see lots and lots of PPR in your logs, especially your receive 
logs, then you may have line quality problems.

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*