FAQ: Asynchronus External Modems
- Q: How do I determine if my modem is causing the
problem?
- A: A very good way of troubleshooting a possible modem
problem is by
removing the
modem from the picture completely. Connect a terminal or
workstation running the
same application to a local port instead, and see if the problem
still exists. If the problem
still exists, then the modem isn't causing the problem, something
else is. If the problem
goes away, then perhaps you should check into the modem possibility
further by comparing
your problem with some of those listed below.
-
Q: Why can't I send commands to the modem?
- A: Check the cabling and make sure it is the correct type, i.e.
straight-through and not
a null-modem cable, unless it is specifically requested. Another
thing to note is that some
Unix operating systems require the DCD signal to be high in order to
talk to the modem
in command mode. This can normally be accomplished either by
forcing DCD high with
a DIP switch, or an AT command such as AT&C0. Check and make sure
the device is
owned by UUCP and has permission set at 666. Also, make sure the
power is on.
-
Q: Why am I seeing garbage on my screen?
- A: The majority of cases of garbage on the screen can be attributed
to either a parity or baud
rate mismatch. The parity mismatch can be fixed by ensuring that
the parity on the port
matches the parity of the terminal/remote application. Most of the
time parity will be set
for either 8N1 or 7E1, but they have to match on both sides. A
modem will normally be
transparent to this, so check the port and remote
terminal/application settings and make
sure they match. If they are both set correctly, then check the
modem for parity settings
and make sure they match as well. A baud rate mismatch occurs when
a modem’s DTE
rate is at a different speed than what the port is set to. This can
be fixed by changing either
or both of the settings so they match. The most desirable speed
setting is the highest DTE
rate which both modem and port have in common. This is necessary
because for modem
compression to occur, the DTE (port) speed has to be higher than the
DCE (connect) speed.
Some common DTE speeds are 2400, 9600, 19200, 38400, 57600 and
115200. Yet a third
possible cause of a garbage connection is that error correction is
not enabled. Enabling
error correction is a must if the desired connect speed is higher
than 9600 baud.
-
Q: Why won't UUCP work?
- A: It is not within the scope of this document to go into all
possibilities of why UUCP may not
be working, but from a purely modem standpoint there are a few things
to be aware of. UUCP
has a built-in protocol based on the "g" protocol. Because of this,
some changes must be made
to the modem parameters. For UUCP to work successfully, flow control
on the modem must
either be disabled or set for hardware (RTS/CTS) flow control.
Xon/Xoff flow control will
conflict with the characters used for the UUCP built-in protocol,
thus causing the transfer to fail.
Additionally, compression on the modem must be disabled because with
it enabled the UUCP
transfer will get out of sync and fail.
-
Q: Why does my application keep jerking/pausing?
- A: This problem can be caused by flow control or a retrain/rate
renegotiation of the modem
connection, depending on how long the pauses are. A quick pause,
which happens only
during heavy traffic over the modem, would indicate flow control.
Flow control can also
be responsible for what appears to be jerky operation. Although
flow control is a normal
function of modems, some do it better than others.
A possibility of improving undesirable
behavior is that most modems have transmit and receive buffer
parameters, which can be
modified. A smaller buffer size would be desirable in noisy line
conditions. The same is
true if there is a parameter called transmit block size. A longer
pause of data flow may
indicate another problem, retrain/rate renegotiation. This normally
occurs when modems
are connecting over dirty or poor telephone lines, or when a line
that was originally good
deteriorates and makes it necessary for the modems to renegotiate the
speed they were
communicating at. This problem can be remedied by connecting at a
lower baud rate,
such as 9600 or 14400. These low speeds are virtually immune to all
but the worst line
conditions, so the problem should go away.
Another possibility would be to disable retrain/rate renegotiation
entirely, although you should also switch to a lower connect
speed (DCE rate) in conjunction with this option to prevent excessive
retransmission of bad data packets.
-
Q: Why won't my modem answer?
- A: A common problem is that the port may not enabled for login (check
your system
administration guide for instructions). If the port is already
enabled, two remaining
possibilities are that either DTR (pin 20 of RS232) is not pinned
into the cable, or
auto-answer is not enabled on the modem. For correct cable pin-outs,
please refer to
the Digi Standard Cable spec and/or your modem manual. The cable
between an async
Digi board and a modem will always be a straight-through
cable.
-
Q: What is the command to do ______ ?
- A: Since every modem manufacturer uses a unique AT command set, we
can not include
all of their various commands. Digi equipment works with a wide
variety of external
modems. Here are some general guidelines for setting up an external
modem to work
best with our equipment:
- A locked serial (DTE) speed, which matches the speed the port is set to
(set this to the highest serial baud rate supported by both modem and port).
- Hardware or RTS/CTS flow control (Xon/Xoff flow control turned off).
- DCD follows carrier (typically &C1).
- DTR normal (typically &D2).
- Error Correction turned on.
- Disable escape character.
- Save the profile to non-volatile RAM (NVRAM).
It should be noted that in order to utilize hardware (RTS/CTS) flow
control, a serial cable with pins 2,3,4,5,6,7,8, and 20 is necessary.
For additional guidance, please check your modem manual or with the modem
manufacturer.
Revised 10/04/98: MT
|
|
