Re: [hylafax-users] Multi-Tech ZMA v.92 (1.28C firmware) sending is still not right.

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.10.14 22:12 An Intrepid HylaFax User wrote:

> Would lowering the modulation rate (speed) improve chances for
> success?

Sometimes.  Sometimes speeding it up improves reception, also.  But 
since we start at the fast and work our way to the slow, we've already 
covered that option.  As I mention in a paper-in-progress I've 
published at http://www.howardsilvan.com/HylaFAX/faxfacts.pdf, usually 
the benefit in "slowing down" is due to the change in protocol, not 
particularly the speed.  For example, I've found V.27 ter to be an 
extremely robust protocol, albeit slow.  So if there's some sort of 
line disturbance (i.e. a PBX or digital interference), then a protocol 
change is more likely the solution than is a change in transmission 
speed.

> Steve of Multi-tech (or anyone who knows), what do you suggest for
> OPTIMUM
> chances of successful deliveries to overseas machines?

(I'm including myself in the "anyone who knows" category... but I 
really only belong to the "anyone who may know" category.  I certainly 
don't put myself in the same "knowing" category as Steve.)

In overseas communications we generally assume a fair amount of line 
noise (this is not necessarily true, though).  In such situations, ECM 
is *highly* advantageous and EOR should be enabled (AT+FRY=4 in Class 
2.0).  Because you should enable EOR you probably shouldn't use Class 
2.1 (V.34 faxing/SuperG3) because you can't do EOR with V.34.  If ECM 
is not an option (because the receiver doesn't support it)... then 
sometimes starting out at a slower speed will help because you'll 
eventually "slow down" to V.27 ter sooner.

The HylaFAX documentation indicates that users may want to disable ECM 
on international calls.  I think that the reason this opinion is there 
is to help users avoid expensive tolls on ECM faxes which tend to take 
longer than non-ECM faxing.  But if cost isn't more important than is 
getting a perfect image through, then the documentation is off-base.

> Is there nothing to be done with "SEND recv RTN (retrain negative)"
> other
> than to hang up?

We don't hang up.  If the receiver responds to the post-page message 
with RTN then we are instructed to retrain and resend the same page 
because the receiver got an image of too-poor quality.

> What are the core issues/problems with getting faxes
> sent
> without so much hand-wringing?

It's almost always one of two things: incompatibility or interference.

> Is there any point to setting "outbound" copy-quality checking?

If you anticipate that HylaFAX will deliver corrupt TIFF to the modem 
and that the modem can correct it.

> So much of
> this
> fax stuff seems "kick and fail" when anything the least bit unexpected
> happens.

Honestly, that's the way that T.30 was written.  Basically if something 
unexpected happens (we get an unexpected signal, for example), we're 
required to disconnect.  So, the "kick and fail" appearance stems 
mostly from an adherance to T.30.

> The fax exchanges look like they drop and raise carrier repeatedly for
> each
> page - would it be better if carrier weren't dropped, if it could be
> driven
> this way?

Again, carrier drops are a core part of T.30 specification.  They are 
required to indicate specific points in the protocol.

> Are these call drops caused by unexpected events on the sender's side,
> receiver's side, or a timing issue of not responding quickly enough,
> or not
> waiting long enough?

Adherance to specification.

> At this stage, I'm ready to try CVS code if you think this would
> actually
> either improve things or help produce more logging data to feedback to
> the
> process of improvement.

CVS in Class 1 would give you a better picture of problems on ECM 
calls.  There are no significant protocol improvements otherwise.

> 03:50:04.53:  REMOTE best rate 14400 bit/s
> 03:50:04.53:  REMOTE max page width 1728 pixels in 215 mm
> 03:50:04.53:  REMOTE max unlimited page length
> 03:50:04.53:  REMOTE best vres 7.7 line/mm
> 03:50:04.53:  REMOTE best format 1-D MR
> 03:50:04.53:  REMOTE best 10 ms, 5 ms/scanline
> 03:50:04.53:  USE 14400 bit/s
> 03:50:04.53:  USE 10 ms, 5 ms/scanline
> 03:50:04.53:  SEND file "docq/doc163.cover;c0"
> 03:50:04.53:  USE page width 1728 pixels in 215 mm
> 03:50:04.53:  USE unlimited page length
> 03:50:04.53:  USE 3.85 line/mm
> 03:50:04.53:  USE 1-D MR
> 03:50:04.53:  <-- [23:AT+FIS=0,5,0,2,0,0,0,2\r]
> 03:50:04.64:  --> [2:OK]
> 03:50:04.64:  <-- [7:AT+FDT\r]
> 03:50:05.77:  --> [74:+FHT:FF 03 43 20 20 20 20 20 20 20 20 20 20 6E
> 69 61
> 6D 6F 44 74 62 65 44 ]
> 03:50:05.77:  --> [32:+FHT:FF 13 83 00 22 A8 80 80 00 ]
> 03:50:13.84:  --> [62:+FHR:FF 03 20 AD 00 51 5A 00 00 00 00 00 00 00
> 00 00
> 00 00 00 ]
> 03:50:13.84:  --> [52:+FNF:AD 00 51 5A 00 00 00 00 00 00 00 00 00 00
> 00 00]
> 03:50:14.42:  --> [65:+FHR:FF 03 20 AD 00 51 5A 00 00 00 00 00 00 00
> 00 00
> 00 00 00 00 ]
> 03:50:14.42:  --> [55:+FNF:AD 00 51 5A 00 00 00 00 00 00 00 00 00 00
> 00 00 00]
> 03:50:15.26:  --> [74:+FHR:FF 03 40 3x 3x 3x 3x 20 3x 3x 3x 3x 20 32
> 35 38
> 20 2B 20 20 20 20 20 ]

The repeated +FNF and +FHR reports indicate that there are a few TCF 
retrainings going on here, indication of a poor connection.  
Unfortunately, the modem firmware doesn't seem to "slow down" the 
communication rate during the retraining... possibly because HylaFAX 
sent AT+FIS and is trying to control the negotiations that way rather 
than relinquishing the control to the modem (HylaFAX Class 2 design).

> 03:50:15.26:  --> [27:+FCI:"     + 852 xxxx xxxx"]
> 03:50:15.62:  --> [35:+FHR:FF 13 80 00 6E E8 80 80 10 10 ]
> 03:50:15.62:  --> [22:+FIS:1,5,0,2,0,0,0,2,0]
> 03:50:16.66:  --> [74:+FHT:FF 03 43 20 20 20 20 20 20 20 20 20 20 6E
> 69 61
> 6D 6F 44 74 62 65 44 ]
> 03:50:16.66:  --> [32:+FHT:FF 13 83 00 22 A8 80 80 00 ]
> 03:50:25.04:  --> [14:+FHR:FF 13 84 ]
> 03:50:25.04:  --> [22:+FCS:0,5,0,2,0,0,0,2,0]
> 03:50:25.04:  --> [7:CONNECT]

But, finally we're able to successfully train at 14400 bps.

> 03:50:25.04:  Enable Real-Time Fax Compression Conversion
> 03:50:25.04:  Reading MMR-compressed image file
> 03:50:25.04:  <-- data [2]
> 03:50:25.04:  SEND begin page
> 03:50:25.04:  MODEM set XON/XOFF/FLUSH: input interpreted, output
> disabled
> 03:50:25.05:  <-- data [1038]
> 03:50:25.05:  <-- data [1039]
> 03:50:25.05:  <-- data [1041]
> 03:50:25.05:  <-- data [511]
> 03:50:25.05:  SENT 3576 bytes of data
> 03:50:25.05:  SEND 1D RTC
> 03:50:25.05:  <-- data [9]

This is a bit of protocol that has been fixed with CVS.  RTC signals 
don't belong on the end of MMR images.  The MultiTech modems seem to 
clean this up, anyway, and it is doing RTFCC, so it's explicitly 
instructed to do it.  So, it's not likely the problem, but I'm just 
pointing this out to be verbose.

> 03:50:25.05:  MODEM set XON/XOFF/DRAIN: input interpreted, output
> generated
> 03:50:29.53:  SEND end page
> 03:50:29.53:  SEND send MPS (more pages, same document)
> 03:50:29.53:  <-- data [2]
> 03:50:39.33:  --> [14:+FHT:FF 13 4F ]
> 03:50:43.37:  --> [14:+FHR:FF 13 4C ]
> 03:50:43.37:  --> [5:ERROR]
> 03:50:43.37:  <-- [8:AT+FPS?\r]
> 03:50:43.48:  --> [2:02]
> 03:50:43.48:  --> [2:OK]
> 03:50:43.48:  SEND recv RTN (retrain negative)

Not surprisingly (given the number of initial retrainings), the 
receiver has rejected our image, so now we'll send another AT+FIS 
command to slow things down...

> 03:50:43.48:  <-- [23:AT+FIS=0,4,0,2,0,0,0,2\r]
> 03:50:43.59:  --> [2:OK]
> 03:50:43.59:  <-- [7:AT+FDT\r]
> 03:50:44.72:  --> [74:+FHT:FF 03 43 20 20 20 20 20 20 20 20 20 20 6E
> 69 61
> 6D 6F 44 74 62 65 44 ]
> 03:50:44.72:  --> [32:+FHT:FF 13 83 00 2A A8 80 80 00 ]
> 03:50:53.06:  --> [74:+FHT:FF 03 43 20 20 20 20 20 20 20 20 20 20 6E
> 69 61
> 6D 6F 44 74 62 65 44 ]
> 03:50:53.06:  --> [32:+FHT:FF 13 83 00 2A A8 80 80 00 ]
> 03:51:01.41:  --> [74:+FHT:FF 03 43 20 20 20 20 20 20 20 20 20 20 6E
> 69 61
> 6D 6F 44 74 62 65 44 ]
> 03:51:01.41:  --> [32:+FHT:FF 13 83 00 2A A8 80 80 00 ]
> 03:51:09.70:  --> [14:+FHT:FF 13 FB ]
> 03:51:10.10:  --> [7:+FHS:25]
> 03:51:10.10:  REMOTE HANGUP: DCS sent 3 times without response (code
> 25)

But, unfortunately, the receiver seems to have disconnected immediately 
after sending RTN.

> 03:51:10.10:  --> [2:OK]
> 03:54:10.12:  MODEM TIMEOUT: reading line from modem
> 03:54:10.12:  MODEM <Timeout>

This timeout message is a HylaFAX bug, but didn't influence the 
problems earlier.  It occurs because HylaFAX doesn't know that the "OK" 
indicates that "CONNECT" will not be coming, so it keeps waiting for 
"CONNECT" until the timeout occurs.  The attached patch (untested) 
should fix this.

> 03:54:10.12:  <-- [5:ATH0\r]
> 03:54:10.25:  --> [2:OK]
> 03:54:10.25:  MODEM set DTR OFF
> 03:54:10.25:  sched policy=0, priority=0
> 03:54:10.25:  SESSION END

Lee.

Attachment: hylafax-waitforfix.patch
Description: Binary data