Re: [hylafax-users] Why would Class 1 work but not class 2.0? How would I troubleshoot class 2.0?

[Lee Howard <faxguy@deanox.com>]

On 2002.03.28 11:58 "Jeff Wiegley, Ph.D." wrote:
> I installed a Multitech MT5634ZPX-PCI-V92 Internal Data/Fax/Voice Modem
> and
> I
> used faxaddmodem to add this modem. Its currently the only modem in my
> machine
> and I configured it for class 2.0 fax service.
> 
> It didn't work. The modem would complete the handshake when answering. I
> also
> noticed other problems but couldn't really identify them.
> 
> I removed the config.ttyS4 file and reran faxaddmodem again but this time
> I
> configured it as a class 1 fax. Everything I've tried works now.
> 
> What would cause 2.0 to not work?

In your case (unsuccessful handshaking), I can't think of any reason other 
than firmware bugs in the modem's Class 2.0 protocol.

> Why would I want to use 2.0? what advantages does it give me?
> what can class 2.0 do that class 1 cannot?

You wouldn't want to use Class 2.0, generally.  The normal reason that you 
would use Class 2.0 is if the software you're using doesn't have a good 
Class 1 implementation.  Because in Class 2.0 the firmware handles more of 
the work, some people have thought that using Class 2.0 would reduce CPU 
load, but I think that this is simply untrue in any likely application.  
However, with HylaFAX the only time you'll ever see me use Class 2/2.0 is 
with DestControls to avoid a Class 1 bug in HylaFAX code for a particular 
destination.  But since there are no Class 1 sending bugs that I 
experience and know of...

> Class 1 seems to be more ubiquitous than class 2 or 2.0 does that
> mean that I should class 1 if my main priority is to be compatible with
> as many other fax devices as possible? What wouldn't class 1 be
> compatible with?

Bugs aside, Class 2/2.0 should be as compatible as Class 1.  In other 
words, the remote system sees us as a fax machine, and it cannot 
distinguish between our use of Class 1 or Class 2/2.0 because the use of 
Class is totally something handled between the software and the hardware 
and the hardware itself.

However, there are bugs, and generally speaking, you're going to encounter 
more bugs in Class 2/2.0 firmware and HylaFAX Class 2/2.0 code than you 
will with Class 1 firmware and HylaFAX Class 1 code.

> I also tried a USRobotics 5610B modem but it also didn't work very well
> as a Class 2.0 fax. But class 1 seems to work ok.  It just seems to me
> that Class 2.0 is just crap.

USR Class 2.0 firmware is bad and people have been saying for a long time 
now that they should only be used in Class 1.  However, I tend to believe 
that everyone should use Class 1 with HylaFAX 4.1+ unless they have a 
particular need to use Class 2/2.0 and they're confident in its 
functionality.

> What would it take to get a verified, correct /etc/config file for each
> of
> these
> modems?

etc/config.<devid> ?

There are prototypes already for both of them.  I believe that the USR 
5610B prototype made 4.1.1.  The MultiTech PCI V92 modem uses the same 
prototype as the V90 version which is in 4.1.1 also.  The prototype file 
and faxaddmodem will change a bit and should pick up the V92 properly in 
4.1.2.  See:
http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=247

Send the output of probemodem on them and I can verify this.

> I don't know enough about fax AT commands or fax protocol
> to troubleshoot the commands or make the right decisions. These are
> well-known brand modems I think it would be really handy to have
> dedicated config files for these models.

For the most part we can't create a config file for a modem which no one 
has tested and which has not had probmodem output posted to this list.  If 
someone has a modem that didn't assigned a prototype config during 
faxaddmodem (i.e., it asked you the AT commands one-by-one), then they 
should post the probemodem output.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null