Re: [hylafax-users] faxgetty flailing and failing.

[Jean-Pierre Radley <jpr@xxxxxxx>]

Lee Howard typed (on Tue, Jan 11, 2005 at 10:08:46AM -0800):
| On 2005.01.11 09:31 Jean-Pierre Radley wrote:
| 
| >Jan 11 12:20:35.46: [11449]: RECV training at v.17 14400 bit/s
| >Jan 11 12:20:35.49: [11449]: <-- [11:AT+FRM=145\r]
| >Jan 11 12:20:37.04: [11449]: --> [7:CONNECT]
| >Jan 11 12:20:38.10: [11449]: RECV: TCF 1804 bytes, 5% non-zero, 1699
| >zero-run
| >Jan 11 12:20:38.10: [11449]: RECV: reject TCF (zero run too short, min
| >1800)
| 
| At 14400 baud you need 1800 bytes to produce 1 sec, which if the 
| "minimum" duration that HylaFAX is expecting a good TCF signal to 
| last.  That's not happening, so it looks like the modem is slow to 
| detect the data carrier and that the line is noisy.
| 
| >Jan 11 12:20:44.19: [11449]: RECV training at v.29 9600 bit/s
| >Jan 11 12:20:44.22: [11449]: <-- [10:AT+FRM=96\r]
| >Jan 11 12:20:44.64: [11449]: --> [7:CONNECT]
| >Jan 11 12:20:46.27: [11449]: RECV: TCF 1890 bytes, 4% non-zero, 1801
| >zero-run
| 
| 1801 bytes at 9600 baud is 1.5 seconds, which indicates that you got a 
| perfectly clear connection with V.29.  This may suggest that there is 
| some problem with V.17 over this connection.
| 
| >Jan 11 12:20:46.27: [11449]: --> [10:NO CARRIER]
| >Jan 11 12:20:46.27: [11449]: DELAY 75 ms
| >Jan 11 12:20:46.35: [11449]: TRAINING succeeded
| >Jan 11 12:20:46.35: [11449]: ACCEPT TSI "SSC Consolidation"
| >Jan 11 12:20:46.35: [11449]: <-- [9:AT+FTH=3\r]
| >Jan 11 12:20:46.40: [11449]: --> [7:CONNECT]
| >Jan 11 12:20:47.70: [11449]: --> [2:OK]
| 
| The CFR signal is transmitted.  Now we are going to wait for the 
| high-speed data carrier to receive the fax image...
| 
| >Jan 11 12:20:47.73: [11449]: <-- [10:AT+FRM=96\r]
| >Jan 11 12:20:50.67: [11449]: --> [8:+FCERROR]
| >Jan 11 12:20:50.67: [11449]: <-- [10:AT+FRM=96\r]
| >Jan 11 12:20:51.06: [11449]: --> [8:+FCERROR]
| >Jan 11 12:20:51.06: [11449]: <-- [10:AT+FRM=96\r]
| >Jan 11 12:20:51.45: [11449]: --> [8:+FCERROR]
| >Jan 11 12:20:51.45: [11449]: <-- [10:AT+FRM=96\r]
| >Jan 11 12:20:58.60: [11449]: --> [2:OK]
| 
| What this indicates is that when the modem went to look for the V.29 
| 9600 baud carrier it found some other carrier there, probably V.21 (the 
| carrier used to send the slow-speed messages).  There are a few 
| different things that we could do at this point: 1) if the modem 
| supported it and if HylaFAX supported it we could use the +FAR command 
| to automatically adjust to receive whatever data the sender is 
| transmitting at that point, unfortunately, most modems don't support 
| +FAR, and currently HylaFAX doesn't, either; 2) we can just repeat 
| AT+FRM=n until we get bored or until we get something other than 
| +FCERROR; 3) we can assume that V.21 is being used and try listening 
| for V.21 to see what it is that the sender is trying to tell us.
| 
| In my tests I found that #2 was usually a better approach than #3 
| because usually the reason for +FCERROR is due to "mishaps" between the 
| sender's and the receiver's modulators - such as "clicks" or "noise" in 
| the raising and lowering of carriers.  However, in cases where the 
| sender doesn't receive the CFR signal properly, it will likely transmit 
| CRP, and this would also cause the same problem, and #3 would be a 
| better choice.  However, in my tests I found that the likelihood of 
| this proving to be beneficial was much less than when using #2.
| 
| If your modem supported +FAR (#1) then it may be a really nice thing to 
| get it supported in HylaFAX.  I have some modems that do support +FAR, 
| but this kind of scenario (where +FAR would be useful) plays out so 
| infrequently for me that I haven't been able to justify the development 
| cost to myself.
| 
| All of that said... the period after TCF is especially problematic for 
| various reasons.  For this purpose we have the Class1MsgRecvHackCmd, 
| paralleling Class1TCFRecvHack in some ways, which allows you to 
| interject a command or a pause before raising the high-speed data 
| reception carrier.  If this kind of error happens with all incoming 
| faxes, then you may want to play with settings like: 
| "Class1MsgRecvHackCmd: AT+FRS=1".

Since my last test, two things have changed.  The HylaFax binaries went
from 4.2.0 to 4.2.1, and the Hayes modem was moved from the COM2 port of
the server to a port on a Digi RealPort server.   Faxes are flowing now.

-- 
JP

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