Re: [hylafax-users] Partial page received problem

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2003.11.12 03:30 Andrea Nicolini wrote:
> Hi,
>
> I'm having troubles with some incoming faxes.
> It seems that sometimes I receive only a few lines of the fax but
> the sender's machine notify a successful transmission.
> Here's a sample log:
>
> Nov 10 15:52:57.93: [18933]: SESSION BEGIN 00048030 390434610760
> Nov 10 15:52:57.93: [18933]: HylaFAX (tm) Version 4.1.7
> Nov 10 15:52:57.93: [18933]: <-- [21:AT+FCC=,,,,1,0,,,0;A\r]
> Nov 10 15:53:11.90: [18933]: --> [4:+FCO]
> Nov 10 15:53:11.90: [18933]: ANSWER: FAX CONNECTION  DEVICE
> '/dev/ttyM1b'
> Nov 10 15:53:11.90: [18933]: STATE CHANGE: ANSWERING -> RECEIVING
> Nov 10 15:53:11.90: [18933]: MODEM input buffering enabled
> Nov 10 15:53:11.90: [18933]: RECV FAX: begin
> Nov 10 15:53:11.90: [18933]: --> [20:+FCS:0,3,0,2,0,0,0,3]
> Nov 10 15:53:11.90: [18933]: REMOTE wants 9600 bit/s
> Nov 10 15:53:11.90: [18933]: REMOTE wants page width 1728 pixels in
> 215 mm
> Nov 10 15:53:11.90: [18933]: REMOTE wants unlimited page length
> Nov 10 15:53:11.90: [18933]: REMOTE wants 3.85 line/mm
> Nov 10 15:53:11.90: [18933]: REMOTE wants 1-D MR
> Nov 10 15:53:11.90: [18933]: --> [2:OK]
> Nov 10 15:53:11.90: [18933]: <-- [7:AT+FDR\r]
> Nov 10 15:53:16.54: [18933]: --> [7:CONNECT]
> Nov 10 15:53:16.54: [18933]: RECV: begin page
> Nov 10 15:53:16.54: [18933]: RECV: send trigger 022
> Nov 10 15:53:16.54: [18933]: <-- data [1]
> Nov 10 15:53:17.68: [18933]: RECV/CQ: Bad 1D pixel count, row 58, got
> 0, expected 1728
> Nov 10 15:53:17.68: [18933]: RECV/CQ: Bad 1D pixel count, row 59, got
> 0, expected 1728
> Nov 10 15:53:17.68: [18933]: RECV/CQ: Bad 1D pixel count, row 60, got
> 0, expected 1728
> Nov 10 15:53:17.68: [18933]: RECV/CQ: Bad 1D pixel count, row 61, got
> 0, expected 1728
> Nov 10 15:53:17.68: [18933]: RECV/CQ: Bad 1D pixel count, row 62, got
> 0, expected 1728
> Nov 10 15:53:17.68: [18933]: RECV: 696 bytes of data, 63 total lines
> Nov 10 15:53:17.68: [18933]: --> [15:+FPS:1,58,0,0,0]
> Nov 10 15:53:41.22: [18933]: --> [6:+FET:2]
>
> Here it seems that the the modom received 58 lines w/o any error,
> and then it thinks that the page is over.

Notice the long delay between +FPS and +FET.  That indicates a carrier 
loss occurred prematurely.

This could conceivably happen for a number of reasons.  My first 
suspicion would be of the copy quality checking decoders.  In this case 
it looks like the DTE-based decoder (HylaFAX's) agrees with the 
DCE-based decoder (MultiTech's), however, so I would tend to look at 
other problems that caused the true loss (versus corruption) of data.

For example, if the sender's V.29 modulator or the receiver's V.29 
demodulator "crashed" and simply stopped transmitting/receiving data 
then this could conceivably happen.  I've seen first-hand this kind of 
thing happen before, too; the session would train successfully with 
V.17, but mid-way through the first page the data stream became quite 
corrupt or lost entirely, and the next signal properly detected was the 
V.21 carrier with the post-page message (PPM).  Because I was using ECM 
(this modem's behavior is one of the primary things that pushed me to 
code Class 1 ECM in the first place), the PPM indicated that I was 
missing data, and so it would eventually all come in, but usually only 
after "slowing" down to V.27ter (4800 bps).  That was mostly *my* 
modem's fault.  Eventually it died altogether and was replaced (and the 
problem went away almost entirely - now I blame similar sessions on the 
sender).

I can also conceive of line conditions causing the same kind of 
problem.  Line conditions could certainly cause a premature carrier 
loss.

You could probably test to see if it is your modem by trying another 
modem model on a different machine.

> I think that the problem is here.
> How can the modem know how many lines should it expect from the
> sending machine?

In non-ECM mode it really can't.  This is theoretical, but it could 
possibly analyze the expected page length based on session parameters, 
and then deduce whether or not it got enough lines to compose a page.  
That would be meaningless for unlimited page length sessions (like this 
one), however, and that approach would really benefit from an 
unimplemented ECM-like behavior where the received data from multiple 
retransmissions was compared to determine if "all" of the data was 
received and then all transmissions would be consolidated to build-up a 
single page (HylaFAX doesn't do this, and it would be extremely 
resource-heavy in usage).

> It seems that the modem is receiving an EOP before the actual
> completation of the page,
> how can this be possible? And, shouldn't the sender machine realize
> that the page was not
> fully received?

I hope my comments above illustrated how it can be possible.  The 
sender only knows the condition of the receiver based on the post page 
response.  So if we send MCF the sender has no way of knowing otherwise 
- AND, even if it did, it must proceed as T.30 requires it behave 
following our MCF signal.

> Nov 10 15:53:41.22: [18933]: RECV recv EOP (no more pages or
> documents)
> Nov 10 15:53:41.22: [18933]: --> [2:OK]
> Nov 10 15:53:41.22: [18933]: RECV send MCF (message confirmation)
> Nov 10 15:53:41.22: [18933]: RECV FAX (00048030): from , page 1 in
> 0:30, INF, 3.85 line/mm, 1-D MR, 9600 bit/s
> Nov 10 15:53:41.22: [18933]: RECV FAX (00048030): recvq/fax24974.tif
> from , route to <unspecified>, 1 pages in 0:30
> Nov 10 15:53:41.22: [18933]: <-- [7:AT+FDR\r]
> Nov 10 15:53:44.05: [18933]: --> [6:+FHS:0]
> Nov 10 15:53:44.05: [18933]: REMOTE HANGUP: Normal and proper end of
> connection (code 0)
> Nov 10 15:53:44.05: [18933]: RECV FAX: bin/faxrcvd
> "recvq/fax24974.tif" "ttyM1b" "00048030" "" "" ""
> Nov 10 15:53:47.09: [18933]: RECV FAX: end
> Nov 10 15:53:47.09: [18933]: SESSION END
>
>
> Any ideas?

Honestly, I'm not sure why you're not using ECM.  I can't really think 
of a receiving situation where ECM would be a bad thing... unless the 
line conditions frequently "drop" the connection.  You may certainly 
want to disable MMR, however, and disabling MR may even be a good idea 
(to minimize the consequences of receiving EOR signals).

You may want to try changing your ModemAnswerCmd to 
"AT+FCC=1,,,,1,1,,,0;A" if you see receiving work well at 14400 bps.  
If 14400 bps doesn't work well, then maybe "AT+FCC=1,3,,,1,1,,,0;A".  
Of course if you run into a lot of problems still, then it will be 
difficult to analyze the problem as accurately as if you were using 
Class 1 ECM.

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*