First of all, I want to thank MultiTech Munich for their support (borrowing me two test modems w/o charge).
Second, I can only strongly recommend these modems, they are great
(but expensive). Got it, unpacked it, switched it on, set mgetty’s init
string (MODEM_INIT) to ATS0=0&S1 – and everything simply
worked. Flawlessly. (Warning: usually I recommend AT&S0 to force the
DSR line high – needed, because otherwise some O/Ses won’t do hardware
flow control – but that doesn’t seem to work on my model. AT&S1 means that
H/W flow control only works when a carrier is present, but then, who needs
flow control in command mode?)
The modems do very reliably distinguish incoming fax and data calls, and outgoing fax works also very good (unfortunately, it’s limited to 9600 bps fax rate, but that’s no big problem).
The only problem I’ve seen is that those modem do the fax bit order on
reception right (everybody else does it wrong, to be compatible
with Rockwell, who botched it in the first place). Thus, g32pbm
won’t be able to decode the data, unless you call it as g32pbm -r.
(You can see if the bit order is wrong if g32pbm complains in every single
line). I’ll work something out for one of the next releases to work around
this (modem-quirks 02).
BUT: There seems to be a way to tell the modem to behave like a Rockwell one and use the "wrong" byte order. Carlos Fonseca found the following text on ftp.multitech.com:
Function Command Description
PROCESS +FRBOR Maintaining compatibility with
DATA IN Rockwell Class 2 chip set for fax data
DIRECT OR reception .
REVERSE ORDER FRBOR=0 - Process received fax data in
direct order.
FRBOR=1 - Process received fax data in
reverse order.
so, with AT+FRBOR=1 added to the modem initialization string, it should be possible to get fax reception on the MultiTechs going without tricks.
Glenn Thobe suggested the following definitions for policy.h (which mostly are factory defaults anyway, but it wouldn’t harm to set them)
#define MODEM_INIT_STRING "ATS0=0Q0&D3&E1&E4&E13&E15" #define FAX_MODEM_HANDSHAKE "AT&E4"
My mgetty.config for those modems looks like this (everything not mentioned is set to the defaults I ship in policy.h).
# MultiTech MT1432BG port <whatever1> init-chat "" \d\d\d+++\d\d\dATE0E1V1H0 OK ATL0M0S0=0 OK modem-type cls2 # MultiTech MT2834BG port <whatever2> init-chat "" \d\d\d+++\d\d\dATH0&F OK ATX4&D3 OK ATQ0L0M0S0=0 OK modem-type cls2
Some of the newer 56k-capable MultiTech modems have voice functionality, but some firmware versions are very much broken. Others seem to work more or less. So make sure you can return your modem to the dealer if it doesn’t work - and if the dealer isn’t willing to do this, get a different modem. Russell King told me that the firmware version 0316D should be working ok, but I got some negative reports as well. Hmmm.
News The most recent series of MultiTech modems (MT5634ZBA-V92 external, or MT5634ZPX-PCI-V92 / ISI5634PCI internal), based on the Lucent/Agere Venus chipset, seem to be really good for fax, data and voice support. Older firmware releases had bugs in the voice area, but if you use the most recent firmware version, they should be fine. For vgetty, you might need to set "forceV253 true" and "rec_compression 6" in voice.conf (Contributed by Lee Howard, <faxguy@howardsilvan.com> – thanks).