HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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




Project hosted by iFAX Solutions