Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: Misc. ramblings about older USR modems
> RECV: 111 total lines, 0 bad lines, 0 consecutive bad lines
> --> [16:+FPS:1,112,0,0,0]
> --> [5:ERROR]
Timestamps would have been useful here.
> PercentGoodLines: 0
The example had 100% good lines, so lowering the good lines threshold would
have no effect.
> MaxConsecutiveBadLines: 0
The example had no consecutive bad lines, so again this is irrelevant.
The page was very short, only about 1 inch and unusually for this error,
the modem agreed on the scan line count.
To me this looks more like an overrun problem or a line problem.
> RECV: 2402 bytes of data, 156 total lines
> --> [16:+FPS:1,157,0,0,0]
> --> [7:+FHS:A1]
This looks like another short page problem.
> S7=3D90
> S36=3D0
Have you tried the first case with this as the only change.
>
> Solution. I had to set the S25 register to 200. This is probably way
> to high but it does work. This register tells the modem not to
> interpet a short drop in DTR as loss of communications. I guess it
> simply takes too long on a pentium 133 to transfer control over to getty.
I suspect you may find that getty is deliberately trying to drop any
previous connection as it starts - hylafax should hand over without
DTR dropping. If this is right, you may have problems with follow on
calls. faxgetty assumes that getty will not try to reset the line.
>
> Problem 5. This is my only unresolved problem and it relates to
> Problem 4. If I accept an incoming data connection and it=20
> disconnects normally some time later, the next attempt to fax in
> will not work. The same symptoms described in Problem 4 occur.
> However, if the sender tries again it will work.
Typical attacks on this problem are to use a rather more aggressive
modem re-initialisation sequence.
>
Note that none of these are the classic USR firmware bug syndrome and
I think your firmware pre-dates the firmware that started to cause
real problems.