|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] seeing problems on panasonic faxmachine
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.
____________________ 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*
