[hylafax-devel] Re: Another Class1 question

[Harald Pollack <Harald.Pollack@DATAnews.at>]

On 09 Jun 2000 14:36:34 +0400, Dmitry Bely wrote:

Hello Dmitry!

>> 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, which is handled quite different. In consequence 
to T.30 you should NEVER wait, 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.


>> >still have no CONNECT after 4.5 seconds (T.30 T4 counter). Why?
>> 
>> have wait too long!
>> 
>> >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.

>
>> >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 :-)

>> >... 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 :-)

>> 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 ...

> 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!



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