Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!osu-cis!tut.cis.ohio-state.edu!husc6!ukma!psuvm.bitnet!cunyvm!ndsuvm1.bitnet!nu013809 From: NU013809@NDSUVM1.BITNET (Greg Wettstein) Newsgroups: comp.dcom.modems Subject: Re: Problems with MNP on a MultiTech 224EH Message-ID: <1216NU013809@NDSUVM1> Date: 2 Jun 88 12:15:06 GMT Article-I.D.: NDSUVM1.1216NU013809 References: <221@aoa.UUCP> <2315@ritcsh.UUCP> <1211NU013809@NDSUVM1> <269@aoa.UUCP> Organization: North Dakota Higher Education Computer Network, Fargo, ND Lines: 64 DISCLAIMER: Author bears full responsibility for contents of this article. I received a reply from an individual who said he was using several (I assume MNP modems) in error-correcting (compressed?) mode using RTS/CTS pairs for flow control. This individual said that it was not intuitive but that CTS forcing was the method of getting these modems to work properly. I went back to the Multitech manual and re-read the documentation and I have the following obserations: The switch in concern if I interpret the commenter correctly is the four pole dip switch located inside the modem near the front leds. This switch selects asynchronous/synchronous communications, leased/dial-up lines, blind dialing/wait-for-dial-tone and normal/forced CTS. I read the description of this switch and the normal/forced mode is, I believe, somewhat misleading. It helps to refer to the section which describes the 8 pole dip switch which is externally accessible. The 8-pole DIPSW has a setting which allows DSR/CD to be forced on in command mode. The explanation of the DSR/CD forcing as well as the CTS forcing seem to suggest that this forcing takes effect only when the modem is in command mode. I assumed that if CTS flow control is selected (through the AT&E1-15 commands) the modem will properly assert CTS when the modem detects a valid carrier and connects. I opened up the MT-224E last night and selected CTS forcing using the internal 4-pole switch. In the process I powered down the modem and so it was reset to its default configurations (I have never set any control options in the firmware). After powering everything back up QMODEM and my own terminal emulator no longer complain that CTS is not asserted when the terminal emulators go through their initialization. Using the AT&E1-15 control switches I turned on CTS flow control, normal mode flow control and and pacing. I also turned off baud rate conversion (AT$BA0) and set the serial port speed to 9600 baud (AT&SB9600). I set my terminal emulator to run at 9600 baud and dialed into our IBM-3081 through a PACX/IBM-7171 front end and everything seemed to work just fine. I'm not sure that any significant pacing or flow-control would occur under these circumstances but at least everything functioned. I am in the process of enhancing the flow control in my own terminal emulator and as part of the enhancements I am adding an indicator on the status display which will indicatee the state of CTS. Hopefully with this enhancement I will be able to see when the modem asserts/de-asserts CTS flow control. The best test of course would have been to try an IMODEM file transfer but our one local bulletin board which supports MNP-based connections was busy. I will report back the results of these further tests when they are available. The next challenge will be to properly configure XENIX to do speed conversion and use CTS/RTS control pairs to pace the MT-224E which will be on that end. I was re-reading the XENIX documentation last night and I noticed in the addendum that the CTSFLOW and RTSFLOW keywords have been added as valid arguements to the getty command. I will experiment with this and report these results as well. To summarize it appears that the CTS forcing option only forces CTS when the modem is in command mode and normal CTS operation resumes when a valid connection occurs. If anyone has a different interpretation of the manual or has experienced different results I would be interested in hearing from them. I would like to thank everyone who has taken time to pass on their comments. As always, G.W. Wettstein NU013809@NDSUVM1 P.S.: Before I tried the CTS forcing I fixed the problem with my terminal emulator by teaching the interrupt handlers to only assert/acknowledge RTS/CTS control pairs when CD/DSR control signals were present.