Re: flexfax: New problems with 3com/USR Voice Faxmodem

[Okke Timm <okke@asta.uni-hamburg.de>]

David Woolley wrote:
> > Jan 02 23:01:43.09: [ 5807]: <-- data [2]
> > Jan 02 23:02:00.24: [ 5807]: --> [5:ERROR]
> > Jan 02 23:02:00.24: [ 5807]: SEND recv RTN (retrain negative)
> 
> I think RTN is guesswork here as it doesn't seem to have received a
> very informative error status.  However real RTNs should be generated if
> the receiver thinks that the transmission was of too poor quality for
> an acceptable image.  The intention was that this should be used when the
> telephone line properties had changed during the transmission and therefore
> the modems needed to train their equalisers for the new properties.
> 
> However, a systematic coding error might be interpreted the same way by a
> receiver that didn't actually monitor the analogue quality of the signal.
> 
> There is a known bug in the tag line processing in Hylafax that causes 
> systematic errors which are sufficient to make some receivers issue RTN.
> There is a patch for this, certainly at www.elgro.demon.co.uk and probably
> at the new hylafax site.
> 
> Coding errors may also be introduced by overruns at the transmitting end,
> due to inadequate flow control.
> 
> In a real retrain, the system should find a speed that produces acceptable
> quality.  Hylafax doesn't force this by default, although the modem shouldn't
> train faster than the line will tolerate.  If the problem is not the line
> quality, the modem will always retrain to the same speed.  People have
> reported that another patch, which causes the speed to be backed off
> explicitly, does improve matters.

Thank you for your response, I think it should be added to the HylaFAQ, it's
more precise and current than Sam's response to the same problem (Q160). 

This is weired: I played a bit with the source, added 1 (one) debug message
to Class20Modem::pageDone and the problem vanished. I'll see, if I
can find a reason for this strange behaviour...

Regards
Okke.