Re: [hylafax-users] Receive error

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

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*