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.