|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] Receive error
On 2004.05.10 04:46 Jörg Wiesenfeller wrote:
Hello all,
we have a hylafax-server (CVS) running on SuSe 8.1. We use 2 GVC 288
modem
for receiving and an AVM Isdn card for sending faxes.
While sending works very well, we have some problems with receiving
faxes.
About 10-20 times a day we got following error.
Failed to properly detect high-speed data carrier.
This means that HylaFAX (faxgetty) was unable to raise the high-speed
data carrier. The carriers are raised and dropped a lot with ECM.
Any clues on this ?
Here you are going fine, and then all of the sudden the data becomes
garbled...
May 10 12:58:17.56: [ 3657]: RECV received frame number 72
May 10 12:58:17.72: [ 3657]: RECV received frame number 73
May 10 12:58:17.87: [ 3657]: RECV received frame number 74
May 10 12:58:18.02: [ 3657]: RECV received frame number 75
May 10 12:58:18.09: [ 3657]: HDLC frame not byte-oriented. Trailing
byte:
0xc0
...
May 10 12:58:29.05: [ 3657]: HDLC frame too short (2 bytes)
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented. Trailing
byte:
0xc0
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented. Trailing
byte:
0xfc
May 10 12:58:29.20: [ 3657]: HDLC frame not byte-oriented. Trailing
byte: 0
May 10 12:58:29.33: [ 3657]: RECV assumed RCP frame with block end
May 10 12:58:29.33: [ 3657]: --> [10:NO CARRIER]
... it's so garbled that the RCP frames are missed, but the carrier
drop is detected. You're going to have to respond with PPR, re-raise
the reception carrier, and reattempt reception of the frames that you
missed.
May 10 12:58:29.33: [ 3657]: <-- [9:AT+FRH=3\r]
May 10 12:58:29.53: [ 3657]: --> [7:CONNECT]
May 10 12:58:30.61: [ 3657]: --> [2:OK]
May 10 12:58:30.61: [ 3657]: RECV recv PPS (partial page signal)
May 10 12:58:30.61: [ 3657]: RECV recv MPS (more pages, same document)
May 10 12:58:30.61: [ 3657]: RECV received 152 frames of block 1 of
page 2
So you only got about half the page properly. The low-speed carrier
seems to be unaffected by whatever happened.
May 10 12:58:30.61: [ 3657]: <-- [9:AT+FRS=7\r]
May 10 12:58:30.70: [ 3657]: --> [2:OK]
May 10 12:58:30.70: [ 3657]: <-- [9:AT+FTH=3\r]
May 10 12:58:30.72: [ 3657]: --> [7:CONNECT]
May 10 12:58:32.84: [ 3657]: --> [2:OK]
May 10 12:58:32.84: [ 3657]: RECV send PPR (partial page request)
May 10 12:58:32.84: [ 3657]: <-- [11:AT+FRM=146\r]
May 10 12:58:32.96: [ 3657]: --> [5:ERROR]
And, here's the problem. What does ERROR mean? The spec doesn't say
that ERROR is a valid response, and normally I'd guess that it means
that the modem is on-hook. We know that's not the case, though,
because the next command (sending DCN) doesn't result in ERROR.
There is a note in the Class 1 code (put there by a trustworthy
developer) that some modems respond to +FRM with ERROR instead of
+FCERROR when it encounters the wrong carrier, but doesn't return to
command mode. When this happens in non-ECM faxing the session is
aborted. In your ECM case, though, it looks like it did return to
command mode.
So, I guess the questions are: what does ERROR mean here, and what
should we do to recover? Can you possibly get these answers from the
modem documentation or from GVC support?
Assuming that, in this case, ERROR == +FCERROR, I can write you a code
patch to test this hypothesis. Do you want this?
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*
