Re: V.17 issue using Davicom modem

On 03/27/2017 01:15 AM, Christo Labuschagne wrote:
> Mar 27 09:34:44.46: [23191]: <-- [11:AT+FRM=146\r]
> Mar 27 09:34:45.05: [23191]: --> [7:CONNECT]
> Mar 27 09:34:45.08: [23191]: Bad HDLC terminating flag received.
> Mar 27 09:34:45.45: [23191]: RECV received frame number 1

So, notice that frame number 0 was missed.  So, we'll signal PPR in 
order to get the sender to retransmit it.

> Mar 27 09:34:50.67: [23191]: RECV send PPR (partial page request)
> Mar 27 09:34:50.67: [23191]: <-- [11:AT+FRM=146\r]
> Mar 27 09:34:51.25: [23191]: --> [7:CONNECT]
> Mar 27 09:34:51.25: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xf8
> Mar 27 09:34:51.28: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0x80
> Mar 27 09:34:51.30: [23191]: Bad HDLC terminating flag received.
> Mar 27 09:34:51.44: [23191]: Bad HDLC terminating flag received.
> Mar 27 09:34:51.50: [23191]: Bad HDLC terminating flag received.
> Mar 27 09:34:51.52: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xe0
> Mar 27 09:34:51.61: [23191]: RECV assumed RCP frame with block end
> Mar 27 09:34:51.62: [23191]: --> [10:NO CARRIER]

This time the sender only transmits frame number 0, but we miss it 
still.  We'll send PPR again...

> Mar 27 09:34:55.56: [23191]: RECV send PPR (partial page request)
> Mar 27 09:34:55.56: [23191]: <-- [11:AT+FRM=146\r]
> Mar 27 09:34:56.13: [23191]: --> [7:CONNECT]
> Mar 27 09:34:56.17: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xf8
> Mar 27 09:34:56.18: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xe0
> Mar 27 09:34:56.22: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0xf0
> Mar 27 09:34:56.35: [23191]: HDLC frame not byte-oriented.  Trailing 
> byte: 0x80
> Mar 27 09:34:56.39: [23191]: RECV received RCP frame
> Mar 27 09:34:56.50: [23191]: --> [10:NO CARRIER]

Missed it again.  Repeat...

> Mar 27 09:35:00.42: [23191]: RECV send PPR (partial page request)
> Mar 27 09:35:00.42: [23191]: <-- [11:AT+FRM=146\r]
> Mar 27 09:35:01.00: [23191]: --> [7:CONNECT]
> Mar 27 09:35:01.22: [23191]: RECV received frame number 0
> Mar 27 09:35:01.23: [23191]: RECV received RCP frame
> Mar 27 09:35:01.36: [23191]: --> [10:NO CARRIER]

Yay, we got it this time.  Based on the exchanges above I suspect that 
the Davicom's V.17 fast-train DSP is just a little slow at getting going 
(maybe it did not train extremely well in the TCF slow-train period).  
Fortunately, it worked eventually.

> Mar 27 09:35:01.36: [23191]: <-- [9:AT+FRH=3\r]
> Mar 27 09:35:04.44: [23191]: --> [5:ERROR]

Here's the killer.

ITU T.31 8.3.6 describes the Class 1 modem's handling of the +FRH 
command.  This section only describes an ERROR result if it is first 
preceded by a "CONNECT" response.  In such a case it would mean "the 
frame was received in error (FCS is not OK, or carrier lost, or data 
lost due to data overflow)".

ITU T.31 8.3.6 only provides for a CONNECT, +FCERROR, and NO CARRIER 
response to the +FRH command.  The CONNECT response is to be followed by 
data and ultimately either an ERROR or OK result.

So, the problem is that we have go guess at what the modem is trying to 
say by reporting ERROR 3 seconds after +FRH=3 without the CONNECT coming 
first.

We do see this with some other modems, and as best we can tell it always 
means that the +FRH command is not possible to execute because the modem 
is on-hook.  This may be plausible, it may not be.  It would depend on 
the modem's ability to detect hook status. I don't know that modem well 
enough to say if it's a plausible explanation or not.

However, my guess is that the modem is reporting ERROR erroneously 
instead of NO CARRIER or simply staying silent until V.21 HDLC is 
eventually heard (this would be the most-useful).  Unfortunately, there 
is presently no knob within HylaFAX to change how this is handled.

My advise would be to bring this matter up with the modem manufacturer 
to see how they believe it should be handled.  If some change is 
required in HylaFAX then that can be investigated, but in the past when 
we have tried to accommodate other out-of-spec behaviors like this we 
generally find that while we may be able to fail things more gracefully, 
the end result is still to fail.

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe [email protected] < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail [email protected].*