[hylafax-devel] Re: Another Class1 question

[Dmitry Bely <dbely@mail.ru>]

"Harald Pollack" <Harald.Pollack@DATAnews.at> writes:

Hello Harald!

> >> Try a timeout of 2 (TWO) seconds (or maybe less) and cancel AT+FRH=3 state by sending AT\r ...
> >> modem should response with OK else modem is in undefined state!
> >
> >Hmm, I assumed (basing on our previous talks) that CONNECT (== HDLC flags
> >detection) timeout was specified by T.30 T4 timer (4.5 sec for manual
> >units). Wrong?
>
> :-) obviously, because we talked about RESPONSE-RECEIVED clause :-)
>
> Here it's the COMMAND-RECEIVED situation,

No. The receiver is sending CSI and DIS and waiting for the response. This is
"RESPONSE REC" node of Fig. 5.2B/T.30 -- I just have checked T.30.

> which is handled quite different. In consequence
> to T.30 you should NEVER wait,

Sure? IMHO T.30 specifies T2 for that purpose:

...
Time-out T2 makes use of the tight control between commands and responses
to detect the loss of command/response synchronization. T2 is 6 ¦ 1 seconds
and begins when initiating a command search (e.g. the first entrance into
the ?command received¦ subroutine, reference flow diagram in 5.2). T2 is
reset when an HDLC flag is received or when T2 times out.
...

i.e. T2 shows how long you should wait for command's HDLC flag, if I
understand this right.

>  but that's not as senseful as needed. I have found out, that
> a value between 1 und 2 seconds (for waiting for CONNECT) is practicable, but this is the
> ONLY remarkable limitation of class 1.

Then what T2 is for? My understanding is:

"RESPONSE REC"

|start responce search  |flag (CONNECT)         |whole frame received
|                       |                       |
|-----------------------|-----------------------|
 <--      timer1     --> <--      timer2     -->

timer1 = T4
timer2 = 3.1 sec because (from T.30)
...
b) any frame which is received and is detected as greater than 3.45 s shall
   be discarded (i.e. 3 s + 15%); 
c) a frame received which is between 2.55 and 3.45 s duration may be
   discarded.
...

"COMMAND REC"

|start command search   |flag (CONNECT)         |whole frame received
|                       |                       |
|-----------------------|-----------------------|
 <--      timer1     --> <--      timer2     -->

timer1 = T2
timer2 = 3.1 sec (same as above)

But if you say that timer1 = 2 sec, I will trust you :-)

> >> >still have no CONNECT after 4.5 seconds (T.30 T4 counter). Why?
> >>
> >> have wait too long!

Had I waited less, I would also have no 'CONNECT' after the first try :-)

> >> >Well, reset the modem, sending CAN character
> >>
> >> Use AT\r command instead to force OK response!
> >
> >OK. Is it portable way to reset any Class1 modem?
>
> I do not know, if it is 'portable', I only know, that it is working on ANY brand of modem
> (it is quite similar like the ATZ philosophy :-)
>
> >T.Class1 prefers sending single character:
> >...
> >If the DTE sends any character to the DCE other than DC1 or DC3 while the
> >DCE is in this mode, the DCE shall enter command state and send the OK
> >result code to the DTE.
>
> Yes, this 'should' also work, but I have use the "'" to emphasise, that there are some
> firmewares in some modems (I like very much :-) which will not react to any single
> character and in consequence will not react to CAN.

Oh, Zyxel again goes its own way :-) I've just found Sam Leffler's hack,
that worked around Zyxel Class2 "specifics". Unfourtinately this had made
some other modems unusable:

		/*
		 * (In some firmware revisions...) The ZyXEL modem
		 * appears to drop DCD when the remote side drops
		 * carrier, no matter whether DCD is configured to
		 * follow carrier or not.  This results in a stream
		 * of empty lines, sometimes* followed by the requisite
		 * trailing OK.  As a hack workaround to deal with
		 * the situation we accept the post page response if
		 * this is the last page that we're sending and the
		 * page is good (i.e. we would hang up immediately anyway).
		 */

> >> >Jun 08 17:17:41.57: [31768]: <-- data [1]
> >> >Jun 08 17:17:41.58: [31768]: --> [2:OK]
> >> >Jun 08 17:17:41.58: [31768]: DELAY 1500 ms
> >>
> >> Omitt this delay, because you have lost more than enough time with the former timeout of
> 4.5 sec.
> >
> >OK, I'll fix that.
>
> COMMAND-RECEIVE is much more sensitive to handle than RESPONSE-RECEIVED, because it is the
> only point to resynchronize well. If you do anything wrong here, you have lost the whole
> game ...
>
> Black magic :-)

:-)))

> >> :-) TCF check is best done, if you can count continous zero run for at least 1 second (of 1.5
> >> seconds TCF). This is not a standard value, but it is from my experiences from testing a lot of
> >> fax machines, how small a TCF could be (less than 1.5 sec) in worst case. Some machines need not
> >> more than 0.5 sec zero run, other need 1 second, but I have not seen any machine, which needs
> >> MORE than 1 sec zero run. this is only a hint.
> >
> >I'll change that according to your recommendations :-)
>
> Yes, but kepp in mind, that there will be a lot of people, who will not realize, what you
> are doing so far :-)

BTW, current algorithm is the following:

	/*
	 * Our criteria for accepting is that there must be
	 * no more than 10% non-zero (bad) data and the longest
	 * zero-run must be at least at least 2/3'rds of the
	 * expected TCF duration.  This is a hack, but seems
	 * to work well enough.  What would be better is to
	 * anaylze the bit error distribution and decide whether
	 * or not we would receive page data with <N% error,
	 * where N is probably ~5.  If we had access to the
	 * modem hardware, the best thing that we could probably
	 * do is read the Eye Quality register (or similar)
	 * and derive an indicator of the real S/N ratio.
	 */

It almost duplicates you criteria -- for 1.5 sec TCF zero-run should be at
least 1 sec long. 

> >> >... found RTC
> >>
> >> Are you sure ? I hope so.
> >
> >Sure that 6 consecutive EOLs has been found there? Absolutely.
>
> Well, than why you (or your code) will complain pixel count ? If you are quite sure it is
> EOL, well than stay to your decision :-)

This is not my code yet :-) It's still trying to decode everything between
RTC (ETX) and "NO CARRIER". Obviously the bug, but I am trying understand,
why this garbage happened there -- was it supplied by sender or it was our
side that appended it? Does Class1 allows such garbage?

> >> From this moment on, discard any received bit and wait for <DLE><ETX>
> >> A_N_D "NO CARRIER" sequence in parallel. Mainly USR brand modems in class 1 loose sometimes the
> >> DLE+ETX and they only send 'NO CARRIER' (but this can cost a lot of time
> >> for you).
> >
> >What should I do having found <DLE><ETX>? Immediately reset the modem
> >sending "AT" and do not wait for "NO CARRIER"?
>
> No, not reset, it is best, to wait for 'NO CARRIER'. You should treat RTC and/or DLE+ETX
> only as additional facts for page end. All which will (and must) count is the NO CARRIER
> response from modem.
>
> >
> >> >Jun 08 17:18:20.26: [31768]: RECV/CQ: Bad 1D pixel count, row 1147, got 425, expected 1728
> >> >Jun 08 17:18:20.26: [31768]: RECV/CQ: Bad 1D pixel count, row 1148, got 1867, expected 1728
> >> >Jun 08 17:18:20.49: [31768]: RECV/CQ: Bad 1D pixel count, row 1149, got 1853, expected 1728
> >> >Jun 08 17:18:20.79: [31768]: RECV/CQ: Invalid EOL code word, row 1150, x 255
> >> >Jun 08 17:18:20.79: [31768]: RECV/CQ: Bad 2D pixel count, row 1150, got 255, expected 1728
> >> >Jun 08 17:18:20.79: [31768]: RECV/CQ: Invalid WhiteTable code word, row 1151, x 29
> >> >Jun 08 17:18:20.79: [31768]: RECV/CQ: Bad 1D pixel count, row 1151, got 29, expected 1728
> >> >Jun 08 17:18:21.00: [31768]: RECV/CQ: Bad 2D pixel count, row 1152, got 1729, expected 1728
> >> >Jun 08 17:18:21.08: [31768]: RECV/CQ: Bad 1D pixel count, row 1153, got 2993, expected 1728
> >> >Jun 08 17:18:21.63: [31768]: RECV/CQ: Adjusting for trailing noise (12 run)
>
> All this above consumes CPU time, we should NOT waste!
>
> >> I miss the explicit detection of DLE+ETX.
> >
> >Yes, it seems always to wait for modem responce ("NO CARRIER") even after
> >RTC and DLE+ETX. Bug?
>
> No, absolutly no bug, but the time RTC is received is a good sign for that point, where
> sender starts its 75ms pause and changes to V.21 carrier. It is also a sign, that page will
> be complete.
>
> >> Watch the log time! You have found RTC at 17:18:20.19
> >> and you mark 'NO CARRIER' at 17:18:21.63 (which is 1.5 seconds). Seems that you have lost time
> >> while trying to decode waste bits instead of reading modem response. Can not happen, if program
> >> is multithreaded :-)
> >
> >I don't see how multiple threads could help here.
>
> Logging !!! The logfile is written, which will waste time and CPU ...

Do you think that 1.5 sec delay was caused by too slow logging? (decoding
could not eat so much CPU time). Perhaps it's possible in the worst case
(yes, I also prefer non-blocking logging :-)) But if the 1.5 sec between
RTC and "NO CARRIER" was really present, then we had no chances to win the
game?

> > DLE+ETX and "NO CARRIER"
> >are consecutive events, they cannot happen in the same time. And we cannot
> >miss either due to buffering and flow control.
>
> Sorry, I was complaining against the log itself. I use a log threat with the smallest
> priority value available ...
>
> >I'll check your theory by practice :-)
>
> Yes, PLEASE!

Hope to hear from you soon,
Dmitry

____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null