Re: [hylafax-users] modem evaluation

[Andrew <andrew@xxxxxxxx>]

Rance Hall wrote:
> I'm looking at the MultiModemZPX PCI modems from shop.ifax.com
> We have a low use environment so I dont see value in muti-line modems.
> Has anybody used this modem, can you tell me about your experiences with 
> it? [...]

We are a reseller/distributor of those modems in our country.
If you want, we can sell by mail order.

We use exactly this model (MT5634ZPX-PCI-V92) on our own 2 machines:
1 on PC Windows 2000,
and 1 on SUN Solaris 10 x86 (UNIX).

Windows has no problems with it.
Solaris 10 has no driver for PCI modems.

I filed a bug report for Solaris. And I wrote an article on configuring a PCI modem with the existing driver. Currently a new driver is being made by SUN.
I myself have patched the existing driver, so it now works with PCI. Now we can wait for an indefinite time for a proper driver to arrive.

Connection speed to internet boosted from 33-38kbps (winmodem) to 46-51kbps (Multitech Hardware modem).

Although, lately our Telecom has artificially lowered the speed (perhaps by installing some filters) lest I complain that the connection speed varies from day to night. Previously, when the speed did vary, Telecom was embarrassed not to know why. Now the speed is 45-46kbps most of the time.
Still I will complain. Because they lowered the speed by intent.

Connection speed is one thing. Data download speed is another.
Under Windows the rate is usually 4.2-5.0kB/s.
Under Solaris - 2.5-2.9kB/s (perhaps because my patch is not very good).

V92 standard does not live up to the claims of its makers.
Modem-modem negotiation time did not shorten. It actually increased from about 11 seconds (USR winmodem with V90) to 22 seconds (MultiTech hardware modem with V92).
The V92 command set gives an option to bypass some negotiation phases. But only a tiny portion is actually omitted (a few seconds).
The V92 modem doesn't recognize our Telecom's "call waiting" signal. Perhaps it needs reconfigurations for that. "Call waiting" is signalled by interfering on the line, when an incoming call arrives during an existing connection.

Technical support does respond to queries. But they seem to be a bit dumb. Though, compared to tech support of USRobotics, MultiTech is far better. USR tech support is completely dumb.

That's my experience with Internet configuration.

Now to Fax.

It is fairly easy to set up Solaris to send a Fax without using any Fax software. Perhaps it would work with any other UNIX/Linux too. The procedure is not a straightforward one, though, even if it worked. And below I explain that it doesn't work so far.
That's what I currently try to do. I don't want to get trapped in all the bugs of HylaFax or eFax, or any other complex thing.

For testing I use "AT" commands.
Class 2.1 Fax command set is the easiest to grasp.
I tried to use the same commands on Windows and SUN Solaris 10 x86.

Under Windows all goes well, and I can reach a point (CONNECT prompt) at which I can start sending the fax image.

Under Solaris the modem disconnects abruptly at random moments. Most frequently it disconnects after "AT+FDT". If it didn't not hang up earlier, it will do so after "AT+FDT". That's where the CONNECT prompt should appear afterwards.
I tried all other Fax classes (from 2.0, to 1). But the complexity of commands increases. While I spend time thinking about responses I see on screen, eventually the modem hangs up.
So I have not yet figured out a sequence of commands for other Fax classes.

But because the Fax-Modem does work under Windows, there should not be a reason for it not to work under Solaris.
I presume the problem is that the driver sets the modem to a wrong state, or perhaps it misinterprets the response coming from a remote fax after "AT+FDT".

It is completely possible that this modem works with other types of UNIX or Linux. Perhaps it is only a problem of the driver for Solaris. I will work on this bug and see if I can remedy it.
If I succeed, it would be possible that I create a simple generic Fax interface for UNIX - one for all types.
People with complex needs would of course have to use programs like HylaFax, eFax, or commercial ones.

Another, less important, problem with this modem is that its UART chips cannot perform a loopback test properly. Hence, some drivers would not figure out the size of its FIFO buffer, and would assume just 1 byte. I had to patch my driver.
Though, the recognition of the size of the FIFO buffer doesn't influence the download speed. It influences only the upload speed. Yet, I didn't measure the increase of speed after appkying my patch. (Download is measured easily. Upload - not.)
FIFO loopback test on this modem is still possible via "AT" commands. But drivers are not likely to be aware of that.

So much for now.

Andrew


____________________ 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@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*