|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] FRH=3 -> timeout waiting for v.21 carrier
On 2003.12.10 01:48 Giulio Orsero wrote:
4.1.7, rh6x, courier v.34 in class1.
Sending to some destinations always result in training failed.
Before trying changing line/modem I'm sending log here.
I tried using -B 4800, Class1ResponseWaitCmd="AT+FRS=1" (2, 3, ),
using
hardware flow in place of soft to no avail.
Dec 10 09:54:03.92: [17213]: MODEM set XON/XOFF/FLUSH: input ignored,
output disabled
Dec 10 09:54:03.95: [17213]: DIAL 9,,000000000
Dec 10 09:54:03.95: [17213]: <-- [18:ATDT9,,000000000\r]
Dec 10 09:54:30.14: [17213]: --> [7:CONNECT]
Dec 10 09:54:30.14: [17213]: MODEM input buffering disabled
Dec 10 09:54:30.14: [17213]: --> HDLC<16:FF C0 04 00 00 6A AA AA 00 31
09 01 9D 60 5E 25>
Dec 10 09:54:30.14: [17213]: --> [2:OK]
Dec 10 09:54:30.14: [17213]: REMOTE NSF "00 00 56 55 55 00 8C 90 80 B9
06 7A"
Dec 10 09:54:30.14: [17213]: NSF remote fax equipment: Brother
Dec 10 09:54:30.14: [17213]: <-- [9:AT+FRH=3\r]
Dec 10 09:54:30.19: [17213]: --> [7:CONNECT]
Dec 10 09:54:30.74: [17213]: --> HDLC<25:FF C0 02 AC 0C AC CC 6C CC EC
AC 2C 0C 04 04 04 04 04 04 04 04 04 04 15 0C>
Dec 10 09:54:30.74: [17213]: --> [2:OK]
Dec 10 09:54:30.74: [17213]: REMOTE CSI "000000000"
Dec 10 09:54:30.74: [17213]: <-- [9:AT+FRH=3\r]
Dec 10 09:54:30.79: [17213]: --> [7:CONNECT]
Dec 10 09:54:31.07: [17213]: --> HDLC<11:FF C8 01 00 77 15 23 01 88 E7
CD>
Dec 10 09:54:31.07: [17213]: --> [2:OK]
After this point we don't hear from the remote again...
Dec 10 09:54:31.07: [17213]: REMOTE best rate 14400 bit/s
Dec 10 09:54:31.07: [17213]: REMOTE max page width 1728 pixels in 215
mm
Dec 10 09:54:31.07: [17213]: REMOTE max unlimited page length
Dec 10 09:54:31.07: [17213]: REMOTE best vres 7.7 line/mm
Dec 10 09:54:31.07: [17213]: REMOTE best format 2-D MMR
Dec 10 09:54:31.07: [17213]: REMOTE supports T.30 Annex A, ECM
Dec 10 09:54:31.07: [17213]: REMOTE best 10 ms/scanline
Dec 10 09:54:31.07: [17213]: USE 4800 bit/s
Dec 10 09:54:31.07: [17213]: USE 10 ms/scanline
Dec 10 09:54:31.07: [17213]: SEND file "docq/doc11343.ps;41"
Dec 10 09:54:31.10: [17213]: USE page width 1728 pixels in 215 mm
Dec 10 09:54:31.10: [17213]: USE unlimited page length
Dec 10 09:54:31.10: [17213]: USE 7.7 line/mm
Dec 10 09:54:31.10: [17213]: USE 2-D MR
Dec 10 09:54:31.10: [17213]: SEND training at v.27ter 4800 bit/s
Dec 10 09:54:31.10: [17213]: <-- [9:AT+FTH=3\r]
Dec 10 09:54:31.20: [17213]: --> [7:CONNECT]
Dec 10 09:54:31.20: [17213]: <-- HDLC<23:FF C0 C2 0C 1C EC CC 9C 2C CC
04 8C 8C 0C 04 9C CC D4 04 04 04 04 04>
Dec 10 09:54:31.20: [17213]: <-- data [23]
Dec 10 09:54:31.20: [17213]: <-- data [2]
Dec 10 09:54:32.94: [17213]: --> [7:CONNECT]
Dec 10 09:54:32.94: [17213]: <-- HDLC<6:FF C8 C1 00 53 14>
Dec 10 09:54:32.94: [17213]: <-- data [6]
Dec 10 09:54:32.94: [17213]: <-- data [2]
Dec 10 09:54:33.64: [17213]: --> [2:OK]
Dec 10 09:54:33.64: [17213]: <-- [9:AT+FTS=7\r]
Dec 10 09:54:33.77: [17213]: --> [2:OK]
Dec 10 09:54:33.77: [17213]: MODEM set XON/XOFF/FLUSH: input
interpreted, output disabled
Dec 10 09:54:33.77: [17213]: <-- [10:AT+FTM=48\r]
Dec 10 09:54:34.74: [17213]: --> [7:CONNECT]
Dec 10 09:54:34.74: [17213]: <-- data [900]
Dec 10 09:54:34.74: [17213]: <-- data [2]
Dec 10 09:54:36.31: [17213]: --> [2:OK]
Dec 10 09:54:36.31: [17213]: MODEM set XON/XOFF/DRAIN: input ignored,
output disabled
Dec 10 09:54:36.31: [17213]: <-- [9:AT+FRH=3\r]
Dec 10 09:54:39.41: [17213]: --> [0:]
Dec 10 09:54:39.41: [17213]: MODEM <Empty line>
Dec 10 09:54:39.41: [17213]: MODEM TIMEOUT: waiting for v.21 carrier
T.31 pretty much instructs the DCE to wait for the carrier forever in
the +FRH=n command. In theory if the carrier is lost, then the "NO
CARRIER" result would be given, but often a DCE will only do this if it
is lost after the command is sent. Thus if the loss occurred before
the command, we may never get a "NO CARRIER" signal no matter how long
we wait.
Given your log I think we could assume that the carrier is gone at this
point. Thus, something between the point of CSI and now could have
caused the remote to hang up without clearly disconnecting (sending
DCN).
The DCS signal looks proper. So at that point all you can do is vary
the parameters (speed, compression, etc.) until you get one that works,
and then figure out what the real difference is.
Do all of the receivers that have problems like this have the same
NSF? Does this happen with all modems on your end?
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@xxxxxxxxxxxx*
