From: wolfgang@wsrcc.com (Wolfgang S. Rupprecht)
Newsgroups: comp.sys.sun.apps
Subject: Re: SupraFaxmodem & NetFax
Keywords: fax, modem, netfax
Date: 27 Jul 92 18:06:56 GMT
Organization: W S Rupprecht Computer Consulting, Fremont CA

fitz@frc2.frc.ri.cmu.edu (Kerien Fitzpatrick) writes:
>Is anyone else trying to use one of the new SupraFaxmodem V.32bis modems
>with NetFax 2.1.  I am already using NetFax with an Everex EverFax modem
>and everything works fine.  When I try to use the Supra I get one strange
>result.  The output on the receiving end is two pages long (for each page).
>All the text is just stretched vertically.  I've checked the parameters sent
>to the remote fax and everything is the same as for the Everex.  The only
>thing I could think of is that the density ( #lpi) was wrong, but it is
>correct.  If anyone else has or is trying to get this combination working
>I would like to hear about their results.

Another Supra V.32/faxmodem victim.  Join the club.

 -*- mode: text -*- 
###############################################################################
##									     ##
##	File:     BUGS							     ##
##	Author:   Wolfgang S. Rupprecht <wolfgang@wsrcc.com>		     ##
##	Created:  Wed May 13 22:39:11 PDT 1992				     ##
##	Contents: Supra bugs
##									     ##
##	Copyright (c) 1992 Wolfgang S. Rupprecht.			     ##
##	All rights reserved.						     ##
##									     ##
##	$Header$							     ##
###############################################################################

Supra V.32bis modem
MODEM #14E-002800

1) During fax transmission DCD is low.  This makes using HW flow
	problematic.

	(Sunbug: Due to Sun OS bugs rcv is off if HW flow is enabled
	and CD is off.  HW flow needs to be on for page transmission.
	Technically this follows the RS-232 standard.  But why is it
	only followed if (outgoing) HW flow is active?)

2) FAX doesn't hang up if DTR is low.  &D2 or &D3 mode.

	fax will actually stay Off Hook with *NO* modem lines
	active either in or out.

3) Manual claims that you can't auto-reload params on DTR low *and*
   have hang-up on DTR low.  (feature clash problem &D2 &D3)

	Having both is really needed for a robust system.	

	This may just be a documentation bug.  The modem does appear
	to drop an active connection when DTR drops.  (Thanks to John
	Hood for pointing this out.)

4) Can't lock computer-modem baud rate to known value on incoming
   (dialin) phone connection.

	When the modem powers up the computer-modem buad rate is
	undefined.  The modem appears to track any computer to modem
	output or line noise and use that to "autobaud" to a new
	connection rate.  Incoming calls are subjected to whatever
	baud rate the modem last saw (or thought it saw) on the last
	outgoing connection.

	Perhaps after a DTR induced reset the baud rate is reset to
	the speed in use for the last &w command.  I must check
	this (but how????)

5) Carrier loss to CD delay is a constant ~ 20 seconds.  Register s10
   has no effect.  (ditto for s9)

	This is only in modem mode.  CD never appears in fax mode!

6) busy detection is buggy.  Often one gets voice answers that
   generate a "busy".  Other times a real busy isn't detected.

	I did a sleep and quick redail on BUSY, until I noticed that
	BUSY was being detected for an outgoing voicemail message.

7) sending +FET=2 doesn't generate an OK command reply.

	out: AT+FET=2
	in:  +FPTS: 1
	in:  +FHNG: 0
	AT+FET=2 failed - timeout

8) wait for carrier register s37 = 5 has no effect in fax mode, after 
	ATA command.  We will wait for quite a while.

9) The ATA command will not return OK or ERROR after +FCON.  Remote
	site eventually drops line.

	This means class 2 receive doesn't work appear to at all.

10) Supra appearently uses the FDCC VR values instead of the FDT VR
	value for each transfer.  This leads to double/half size pages
	of printout.

11) Supra answers phone even if DTR is low. (eg. when S0=1, &D3)
	DTR should inhibit any modem action, and hold the modem in a
	reset state.

12) If incoming call disconnects before the speed negotiation completes
	(as in a voice call) the Supra will then lock onto the
	following dialtone and claim "300" on the display.  The modem
	appears to eventually go back on hook.  But I wonder how long
	it might "talk" to the dialtone.

13) Modem often has trouble locking onto a trailblazer (at 2400 baud)
	located on a second phone line right next to it.

14) The ST scan Fax line scan time is negotiated up to max setting for
	no appearent reason. On a fax send send the other side can
	claim a scan time of 4.  I claim a scan time of 0 (or 4).  The
	Supra and Fax then negotiate a 7!  

15) If FAA=1 Supra doesn't answer adaptively as either FAX or Data
	modem.  If FCLASS=2 the modem will not answer data calls.

	    out: AT+FCLASS=2
	    in:  OK
	    out: AT+FAA=1
	    in:  OK
	    out: AT+FCR=1
	    in:  OK
	    in:  RING
	    out: ATA
	    in:  +FHNG: 1
	    in:  OK

16) AT+FBUG=1 doesn't turn on debuging.  Not technically a bug, but
	certainly not a feature either.

17) Writing to the Supra immediately after DTR goes high, after a
	DTR-low reset has taken place, will leave the modem in a
	confused state.  Eeprom parameters are not correctly reloaded.

---------
from the net:
---------

n1) Spkr volume setting L0-L3 don't have any effect.  Needs PC board
    fix. 

n2) The -,*,) LAPM/MNP commands don't work.  Will be a ROM fix.

n3) Supra never originates fallback/fallforward speed changes.  Two
    Supras talking on a bad line won't ever negotiate for a better
    connection.




-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
Xref: sparky comp.sys.sun.apps:1440 comp.windows.open-look:3189 comp.windows.news:425