Re: [hylafax-users] wierd faxes..

[Shawn Henderson <shawn@xxxxxxxxxxxx>]

I dont have zttest ..can I use zttool?

Lee Howard wrote:
> 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*