Re: [hylafax-users] seeing problems on panasonic faxmachine

[offman <offman@xxxxxxxxxxxxxxxx>]

On Sep 7, 2005, at 11:18 PM, Lee Howard wrote:

> offman wrote:
>
>
> > Sep 07 10:01:38.04: [17117]: SEND recv PPR (partial page request)
> > Sep 07 10:01:38.04: [17117]: <-- [9:AT+FRS=7\r]
> > Sep 07 10:01:38.16: [17117]: --> [2:OK]
> > Sep 07 10:01:38.16: [17117]: DELAY 200 ms
> > Sep 07 10:01:38.36: [17117]: <-- [11:AT+FTM=122\r]
> > Sep 07 10:01:38.40: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:38.98: [17117]: --> [2:OK]
>
>
> From this we can tell that the receiver sent us an empty PPR  
> signal... meaning that the PPR signal indicated that all of the  
> frames that we transmitted were received correctly.  So the  
> receiver should have sent MCF and not PPR; however, something that  
> happened (perhaps the duplicate sending of the single-frame 25 in  
> one block) has confused the receiver and makes it think that there  
> are still frames that it needs to get before sending MCF.
>
> So at this point our only choice is to send empty blocks until the  
> 4th PPR signal is received and then to send EOR (to end  
> retransmissions and move on).
>
> I continue below...
>
>
> > Sep 07 10:01:38.98: [17117]: <-- [9:AT+FTS=9\r]
> > Sep 07 10:01:39.08: [17117]: --> [2:OK]
> > Sep 07 10:01:39.08: [17117]: <-- [9:AT+FTH=3\r]
> > Sep 07 10:01:39.13: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:40.55: [17117]: --> [2:OK]
> > Sep 07 10:01:40.55: [17117]: SEND send PPS (partial page signal)
> > Sep 07 10:01:40.55: [17117]: SEND send EOM (more documents)
> > Sep 07 10:01:40.55: [17117]: <-- [9:AT+FRH=3\r]
> > Sep 07 10:01:41.31: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:43.12: [17117]: --> [2:OK]
> > Sep 07 10:01:43.12: [17117]: SEND recv PPR (partial page request)
> > Sep 07 10:01:43.12: [17117]: <-- [9:AT+FRS=7\r]
> > Sep 07 10:01:43.24: [17117]: --> [2:OK]
> > Sep 07 10:01:43.24: [17117]: <-- [9:AT+FTH=3\r]
> > Sep 07 10:01:43.29: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:44.63: [17117]: --> [2:OK]
> > Sep 07 10:01:44.63: [17117]: SEND send EOR (end of retransmission)
> > Sep 07 10:01:44.63: [17117]: SEND send EOM (more documents)
> > Sep 07 10:01:44.63: [17117]: <-- [9:AT+FRH=3\r]
> > Sep 07 10:01:45.39: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:46.32: [17117]: --> [2:OK]
> > Sep 07 10:01:46.32: [17117]: SEND recv ERR (confirm end of   
> > retransmission)
>
>
> According to T.30 the ERR signal is a confirmation to EOR and  
> indicates that the receiver is ready to continue without requiring  
> any further retransmissions of the previous block.  However, many  
> fax machines out there (and apparently this Panasonic) will abort  
> either after receiving EOR or after sending ERR.  They do this with  
> reason (good reason, from their point of view), and so for the most  
> part the best thing that can be done is to do all that we can to  
> avoid EOR.
>
> I continue below...
>
>
> > Sep 07 10:01:46.32: [17117]: SEND end page
> > Sep 07 10:01:46.33: [17117]: SEND FAX (000000485): FROM   
> > steve@xxxxxxxxxxxxxxxx,sluo@xxxxxxxxxxxxxxxx TO   
> > 0-17909-00-852---26669677 (page 1 of 1 sent in 1:03)
> > Sep 07 10:01:46.33: [17117]: SEND FAX (000000485): FROM   
> > steve@xxxxxxxxxxxxxxxx,sluo@xxxxxxxxxxxxxxxx TO   
> > 0-17909-00-852---26669677 (docq/doc200.ps;c1 sent in 1:03)
> > Sep 07 10:01:47.35: [17117]: SEND FAX: JOB 202 DEST   
> > 0-17909-00-852---26669677 COMMID 000000485 DEVICE '/dev/ttyS1'
> > Sep 07 10:01:47.35: [17117]: <-- [9:AT+FRH=3\r]
> > Sep 07 10:01:47.36: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:47.37: [17117]: --> [5:ERROR]
> > Sep 07 10:01:47.37: [17117]: MODEM Command error
> > Sep 07 10:01:47.37: [17117]: FCS error
> > Sep 07 10:01:47.37: [17117]: <-- [9:AT+FRS=7\r]
> > Sep 07 10:01:47.48: [17117]: --> [2:OK]
> > Sep 07 10:01:47.48: [17117]: <-- [9:AT+FTH=3\r]
> > Sep 07 10:01:47.53: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:48.84: [17117]: --> [2:OK]
> > Sep 07 10:01:48.84: [17117]: SEND send CRP (command repeat)
> > Sep 07 10:01:48.84: [17117]: <-- [9:AT+FRH=3\r]
> > Sep 07 10:01:49.60: [17117]: --> [7:CONNECT]
> > Sep 07 10:01:50.51: [17117]: --> [2:OK]
> > Sep 07 10:01:50.51: [17117]: COMREC error in transmit Phase B/got DCN
>
>
> Yes, see here the receiver triggered an abort.
>
> So what can be done to prevent EOR?  Well, the best thing to do is  
> to limit the risk of PPR.  Getting PPR means that the data was  
> corrupted somewhere after HylaFAX delivered it to the modem and  
> before the receiver got it.  So for the most part that means "line  
> noise", but it could also mean bad modulators on the modem or fax  
> machine, etc.  So you review your logs and see if PPR is frequent -  
> even to local fax machines, and if it is, then something's probably  
> wrong with your own telco connection.  If not, then you may want to  
> have the receiver check theirs.  And if they're also clean, then  
> you'd want to try a different modem to see if that helps.
>
> We could also try to figure out what it is that HylaFAX is doing  
> that triggers this problem (empty PPR) on the receiver.  To do that  
> I'd need to be able to send some test faxes to a problematic  
> destination from my development system.
>
> Lee.
this is an odd machine , sometimes it takes faxes with no problems.
on the retransmit , it took 3 faxes with no problems.
but some times it goes , silly, I suspect that it is just poor error  
handling by the  panasonics, if the fax is good , it all works fine,  
if you get transmission errors then it falls apart.

If you do decide to send some test faxes that is fine, just remember  
it is gonig to cost you IDD to Hong Kong.

if this sort of thing is useful for you to improve hylafax, I can  
start sending them to you.

Steve


____________________ 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*