Re: [hylafax-users] Partial page received problem

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.11.13 03:01 Andrea Nicolini wrote:

> I have another question for you, look at this log:
>
> Nov 13 11:46:46.94: [ 9707]: --> [7:CONNECT]
> Nov 13 11:46:46.94: [ 9707]: RECV: begin page
> Nov 13 11:46:46.94: [ 9707]: RECV: send trigger 022
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 2D pixel count, row 69, got
> 140, expected 1728
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 1D pixel count, row 70, got
> 0,
> expected 1728
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 1D pixel count, row 71, got
> 0,
> expected 1728
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 1D pixel count, row 72, got
> 0,
> expected 1728
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 1D pixel count, row 73, got
> 0,
> expected 1728
> Nov 13 11:47:09.45: [ 9707]: RECV/CQ: Bad 1D pixel count, row 74, got
> 0,
> expected 1728
>
> Are the previous 6 lines considered errors? What do they mean exactly?

I can't say anything about the error on line 69, but the other lines 
(70-74) are not lines of data, but are consecutive EOL codes which make 
up the RTC.  So it goes like this: 
000000000001000000000001000000000001000000000001000000000001000000000001.  
A single EOL code also terminates a scanline.  So the decoder sees an 
EOL with no image data before it, and thus reports "got 0, expected 
___".  It does that enough times consecutively until it determines that 
it has instead encountered an RTC rather than a mere end-of-scanline.  
So no, the "errors" on lines 70-74 are not errors but are just an 
anomoly of the MH/MR decoder.  Those lines should not (will not) be 
counted as "bad".  Unfortunately they must just be ignored.

> Nov 13 11:47:10.13: [ 9707]: RECV/CQ: Adjusting for RTC found at row
> 69
> Nov 13 11:47:10.13: [ 9707]: RECV: 69 total lines, 0 bad lines, 0
> consecutive bad lines
> Nov 13 11:47:10.13: [ 9707]: --> [17:+FPS:2,69,63,19,0]
> Nov 13 11:47:15.10: [ 9707]: --> [6:+FET:0]
> Nov 13 11:47:15.10: [ 9707]: RECV recv MPS (more pages, same document)
> Nov 13 11:47:15.10: [ 9707]: --> [2:OK]
>
> Here it seems that Multitech's QC is thinking that the page is full of
> errors, while Hylafax's says it's ok.
> What does this mean? Which one wins in this case? Is the page good or
> not?

If the MultiTech modem is performing copy-quality checking 
*_and_correction_*, then it is entirely possible that the DCE (modem) 
corrected the image data *before* it delivered it to the DTE 
(HylaFAX).  In cases where the modem performs CQ and correction, I 
would recommend either disabling modem CQ or to disable HylaFAX CQ so 
as to prevent anything like this from causing a corrupt image from 
being accepted and confirmed.

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@xxxxxxxxxxxx*