NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/sun/apps/1493

Internet Message Format | 1992-07-28 | 7.0 KB

Path: sparky!uunet!usc!cs.utexas.edu!uwm.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!news
From: [e-mail] (Kerien Fitzpatrick)
Newsgroups: comp.sys.sun.apps
Subject: Re: SupraFaxmodem & NetFax
Keywords: fax, Supra
Message-ID: <[e-mail]>
Date: 28 Jul 92 15:27:27 GMT
References: <[e-mail]>
Reply-To: [e-mail]
Organization: Field Robotics Center, Carnegie Mellon University
Lines: 176
Nntp-Posting-Host: dirt.frc.ri.cmu.edu

In article [e-mail], [e-mail] (Wolfgang S. Rupprecht) writes:
> [e-mail] (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.
>
Well, after significant perusal of poor documentation on almost all fronts
(maybe there is no such thing as "good" documentation) we did find our
problems.  It seems that the Supra does not know by default its maximum
fax capabilities.  It did indeed have low resolution set.  It now works
much better with NetFax than the suggested Everex faxmodem.

At this time we do have a modified version of NetFax running with the Supra.
Hopefully in the near future we will complete our effort of fixing up
NetFax and release our changes.  Please do not send email requesting the
changes at this time.  Once completed I will make all the diff files available
for others that wish to use this.

> Another Supra V.32/faxmodem victim.  Join the club.
>
>  -*- mode: text -*-
> ###############################################################################
> ##                                         ##
> ##    File:     BUGS                                 ##
> ##    Author:   Wolfgang S. Rupprecht <[e-mail]>             ##
> ##    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    [e-mail] (or) wsrcc!wolfgang
> Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511




---
Kerien Fitzpatrick            Pittsburgh, PA 15213
Field Robotics Center            [phone]
The Robotics Institute            Internet: [e-mail]
Carnegie Mellon University