Re: [hylafax-users] wierd faxes..

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Shawn Henderson wrote:

> Oct 30 09:20:42.92: [28960]: RECV recv DCS (command signal)
> Oct 30 09:20:42.92: [28960]: REMOTE wants 9600 bit/s
> Oct 30 09:20:42.92: [28960]: REMOTE wants A4 page width (215 mm)
> Oct 30 09:20:42.92: [28960]: REMOTE wants unlimited page length
> Oct 30 09:20:42.92: [28960]: REMOTE wants 7.7 line/mm
> Oct 30 09:20:42.92: [28960]: REMOTE wants 1-D MH
> Oct 30 09:20:42.92: [28960]: RECV training at v.17 9600 bit/s


Notice that this one is not using ECM.  Therefore you'll possibly get 
image corruption as evidenced here:

> Oct 30 09:20:52.58: [28960]: RECV/CQ: Bad 1D pixel count, row 192, got 
> 3320, expected 1728
> Oct 30 09:20:54.23: [28960]: RECV/CQ: Bad 1D pixel count, row 227, got 
> 2825, expected 1728
> Oct 30 09:20:55.06: [28960]: RECV/CQ: Bad 1D pixel count, row 228, got 
> 3468, expected 1728
> Oct 30 09:20:56.94: [28960]: RECV/CQ: Bad 1D pixel count, row 229, got 
> 2208, expected 1728


And if the sender does not retransmit the page in response to an RTN 
signal (which in this case was sent and the sender did not retransmit 
the page), then there is nothing to do.

> Oct 30 10:26:03.76: [20377]: RECV recv DCS (command signal)
> Oct 30 10:26:03.76: [20377]: REMOTE wants 14400 bit/s
> Oct 30 10:26:03.76: [20377]: REMOTE wants A4 page width (215 mm)
> Oct 30 10:26:03.76: [20377]: REMOTE wants unlimited page length
> Oct 30 10:26:03.76: [20377]: REMOTE wants 3.85 line/mm
> Oct 30 10:26:03.76: [20377]: REMOTE wants 2-D MMR
> Oct 30 10:26:03.76: [20377]: REMOTE wants T.30 Annex A, 256-byte ECM
> Oct 30 10:26:03.76: [20377]: RECV training at v.17 14400 bit/s


Notice that in this case ECM *is* used.  Thus, when image data 
corruption occurs (due to line noise or whatever) as seen here:

> Oct 30 10:26:12.71: [20377]: RECV received frame number 20
> Oct 30 10:26:12.71: [20377]: RECV frame FCS check failed
> Oct 30 10:26:12.71: [20377]: Bad HDLC terminating flag received.
> Oct 30 10:26:12.71: [20377]: Bad HDLC terminating flag received.
> Oct 30 10:26:12.71: [20377]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xf8
> Oct 30 10:26:12.71: [20377]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xfc
> Oct 30 10:26:12.83: [20377]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xf0
> Oct 30 10:26:12.83: [20377]: HDLC frame not byte-oriented.  Trailing 
> byte: 0
> Oct 30 10:26:13.11: [20377]: RECV received frame number 23


Then the ECM protocol essentially requires the sender to retransmit the 
portions that we report are bad.  Thus you'll see the retransmission of 
frames 20-22 here:

> Oct 30 10:26:25.63: [20377]: RECV received frame number 20
> Oct 30 10:26:25.77: [20377]: RECV received frame number 21
> Oct 30 10:26:25.89: [20377]: RECV received frame number 22 


This second fax should have been "perfect".  The first one would have 
had some problems.

From the generally-okay ECM session it doesn't look like there are line 
problems on your end, but... if there are then getting rid of those 
would help reduce the likelihood that a non-ECM session would result in 
corrupted images.  However, what result does zttest show on your 
system?  It should never be less than 99.98%.

Thanks,

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*