MCT Testing Methodology: Tips and Traps

You can avoid common MCT problems by using the following tips and avoiding traps listed below.

Avoiding Current MCT Limitations

• At the current time, some MCT menu items are inactive or awaiting further development to make them functional. Do not use ALL TESTS, SPEED ADJUST, ALL AUTOMATED, or ALL INTERACTIVE.
• Forced error control can sometimes produce erroneous results.
• The MCT is constantly evolving and being improved as Microsoft encounters modems with new features. Be sure you are always using the most current version of the MCT.

Avoiding Common MCT Setup Errors

• Do not forget to install a phone number for the MCT to dial.
• Make sure to have only one modem installed while running MCT. Use the Modem Control Panel to make sure only one modem is present.
• Make sure a network card or other device is not also using the same communication port as the modem. Check this using the Device Manager. Click the Start button, point to Settings, and click the Control Panel Option. In the Control Panel, double-click the System icon, select the Device Manager tab, and click the Properties button to display all the system devices and their current resource usage.

Using Alternate Configurations for Running the MCT

• If during MCT everything seems locked up, shut down and try again. If still failing, replace your test modem with a good modem and good INF and retest to reestablish that MCT is functional.
• Consider using several different remote slaves and running MCT connecting to each slave. As a minimum a V.34 slave modem will cause some connect responses to appear and a VFC slave modem will cause other responses. Thus with high end (V.34 and VFC) modems consider doing an MCT send file test with a VFC slave, note undocumented responses, then retest with a V.34 slave and note additional undocumented responses. Frequently high speed responses which are poorly documented in manufacturers manuals and this provides an extra level of security that an INF contains complete responses.

Avoiding Common INF Item Problems

• INF responses within an INF must be accurate and comprehensive for the modem. For example, an incomplete response such as "CONNECT 14400" instead of "CONNECT 14400" will cause a failure. If MCT fails to run to completion and you have not already enabled logging of modem events, then enable modem event logging and rerun the MCT. Study the log entries for bad or incomplete responses such as the example incomplete response shown above. Complete instructions for enabling logging of modem events is in Full Debugging of a Modem INF File Using Modem Event Logs.
• A common modem INF syntax mistake is to include \ (backslash) or other prohibited characters in a modem's name within the Strings section of the INF.
• A common INF mistake is an incorrect init string applied to all modems. For example one of your modems may require AT&F1 instead of AT&F. Perhaps one of your modems uses \Tn for inactivity timer instead of S30. Make sure you are using a fully robust init string. An example of a fully-robust init string is AT&FE0&C1&D2S95=47. An example of a non-robust init string is AT&FE0.
• If you suspect that your INF numeric response section is incorrect, consider switching to verbose responses.

Avoiding DTE and DCE Speed Problems

• Check the properties line of your INF for incorrect maximum DTE and DCE speed values. Values that are too high for the modem in use will cause MCT to fail. You can determine the maximum possible DTE speed by trial and error with any communications application and/or by examining the modem event log. See Full Debugging of a Modem INF File Using Modem Event Logs for instructions on how to enable modem event logging and interpreting the logs. To determine the maximum DTE speeds by trial and error, try to transmit init strings to the modem at various DTE speeds and learn by trial and error.
• Having DTE set wrong for a 2400 bps external modem can cause MCT failures. Care should be taken to encode correct maximum DCE and DTE settings into the properties line for your modem, especially if it is 2400 bps modem. For example, an external 2400 bps modem may have a maximum DTE of 2400 bps (modem probably has no compression). A similar 2400 bps modem may have a maximum DTE of 4800 bps (MNP5 compression) or a maximum DTE of 9600 bps (full V.42bis compression). Carefully refer to the manufacturer's documentation as your primary authority on maximum DTE settings. You can also experiment with the modem and use MODEMID.EXE to give you a fairly reliable measurement tool for DCE and DTE. If nothing seems to work with a 2400 bps external modem, try to lower the maximum DTE setting in the properties line to about 9600 or even 2400 (for modems lacking any compression).
• A 2400 bps internal modem may allow a maximum DCE of 2400 (as expected) and a maximum DTE of 115200 bps which is reasonable given inexpensive onboard high-speed UART technology. The manufacturer's documentation may state this and you may confirm this by testing and studying the modem event logs. However, having DTE set wrong for an internal 2400 bps modem sometimes causes MCT failures. Setting the properties line to 2400 maximum DCE and a high maximum DTE (for example, 115200 bps) sometimes causes handshake problems. If nothing seems to work with a 2400 bps internal modem, try lowering the maximum DTE setting in the properties line to about 9600 bps or even 2400 bps (for modems lacking any compression).