Success with Netcomm SmartModem M34F

[David Dawes <dawes@rf900.physics.usyd.edu.au>]

I've finally had some success in getting a NetComm SmartModem M34F (an
Australian made modem) working with HylaFAX 4.0pl1.  Since I couldn't
find some of the things I had to do to get it working mentioned in the
docs or FAQ, I thought I'd post some details here.

I've updated the firmware to the latest available from NetComm's web
site (http://www.netcomm.com.au), and it identifies itself as:

MODEM NETCOMM LTD. Series 5  V.34 28800 Modem DFS256K(A4)-Z7/V2.61L Fri Jul 28 11:51:10 1995

That's not very recent, but the modem is a few years old, and is not a
current model.

I'm running HylaFAX 4.0pl1 (built from source) on a Pentium box running
FreeBSD 2.2.

Starting with the standard "class2" config file, with the following changes
that seem to be required for a lot of Rockwell-based modems:

ModemDialCmd:		ATDT%s
ModemRecvFillOrder:	MSB2LSB
Class2DDISCmd:		AT+FDIS
Class2RecvDataTrigger:	"\022"

I had problems both sending and receiving faxes most of the time.
Occasionally a send or receive would be successful.

I found that by disabling Class2RELCmd:

Class2RELCmd:		""

I could get receives working reliably.  Without this (and with
PercentGoodLines set to 0), received faxes were garbage over 90% of the
time, with fax2ps reporting lots of:

Fax3Decode1D: fax00043.tif: Bad code word at scanline 1 (x 1624).

messages.


The problem sending faxes appears in the session logs as:

Apr 09 13:20:39.94: [  203]: SEND send EOP (no more pages or documents)
Apr 09 13:20:39.94: [  203]: <-- [9:AT+FET=2\r]
Apr 09 13:20:40.36: [  203]: --> [15:+FHT: FF 13 2F ]
Apr 09 13:20:43.07: [  203]: --> [15:+FHR: FF C8 31 ] 
Apr 09 13:20:43.07: [  203]: --> [7:+FPTS:1]
Apr 09 13:20:43.07: [  203]: SEND recv MCF (message confirmation)
Apr 09 13:20:43.08: [  203]: SEND FAX (00000112): FROM dawes@rf900 TO 1300368999 (page 1 of 1 sent in 0:20)
Apr 09 13:20:43.08: [  203]: SEND FAX (00000112): FROM dawes@rf900 TO 1300368999 (docq/doc75.ps;00 sent in 0:20)
Apr 09 13:20:43.20: [  203]: <-- [5:ATH0\r]
Apr 09 13:20:43.32: [  203]: --> [15:+FHT: FF 13 FB ]
Apr 09 13:20:43.32: [  203]: --> [7:+FHNG:2]
Apr 09 13:20:43.32: [  203]: REMOTE HANGUP: Call aborted,  from +FK or <CAN> (code 2)
Apr 09 13:20:43.32: [  203]: --> [2:OK]


On occasions where a send succeeded, the final three lines were:

Apr 10 16:53:27.32: [ 6832]: --> [7:+FHNG:0]
Apr 10 16:53:27.32: [ 6832]: REMOTE HANGUP: Normal and proper end of connection (code 0)
Apr 10 16:53:27.32: [ 6832]: --> [2:OK]


After reading a message someone posted here a few months ago about a similar
problem with a similar modem, and looking though the Supra/Rockwell Class 2
docs on the HylaFAX web site it seemed that the explicit hangup (ATH0)
was causing the problem.  The above Class 2 docs (which I know are not the
real spec) don't show an explicit hangup command being sent to the modem,
but rather that the hangup and FHNG reply should happen as a consequence
of the AT+FET=2 command.  This does indeed seem to be the problem, and I've
found that doing the following:

ModemOnHookCmd:		<waitfor:OK>

solves this problem.  An alternative might be to simply delay the ATH0 to
make sure that both ends have finished the events set in train by the
AT+FET=2 before forcing a hangup.

With this change, the session logs look like:

Apr 10 17:05:43.53: [ 6937]: SEND send EOP (no more pages or documents)
Apr 10 17:05:43.53: [ 6937]: <-- [9:AT+FET=2\r]
Apr 10 17:05:43.86: [ 6937]: --> [15:+FHT: FF 13 2F ]
Apr 10 17:05:46.58: [ 6937]: --> [15:+FHR: FF C8 31 ]
Apr 10 17:05:46.59: [ 6937]: --> [7:+FPTS:1]
Apr 10 17:05:46.59: [ 6937]: SEND recv MCF (message confirmation)
Apr 10 17:05:46.59: [ 6937]: SEND FAX (00000119): FROM dawes@rf900 TO 1300368999 (page 1 of 1 sent in 0:20)
Apr 10 17:05:46.60: [ 6937]: SEND FAX (00000119): FROM dawes@rf900 TO 1300368999 (docq/doc78.ps;00 sent in 0:20)
Apr 10 17:05:46.81: [ 6937]: --> [15:+FHT: FF 13 FB ]
Apr 10 17:05:48.17: [ 6937]: --> [7:+FHNG:0]
Apr 10 17:05:48.17: [ 6937]: REMOTE HANGUP: Normal and proper end of connection
(code 0)
Apr 10 17:05:48.17: [ 6937]: --> [2:OK]


Later, when looking through the server tracings, I found that receives
were typically ending with an abnormal FHNG status too, and making this
change also fixed that (which was causing some senders to sometimes not
get the MCF and thus assume that the transmission had failed).


David