mbr@aoa.UUCP (Mark Rosenthal) (05/10/88)
I have installed two MultiTech 224EH 2400 baud modems on our VAX 8650 running
Ultrix 2.0. The processes which talk to the modems are either tip or uucico.
The modems are configured to talk at 4800 bps out the serial port, and use CTS
to tell the VAX to stop transmission temporarily when they are in danger of
overrunning the speed of the phone line. The VAX software respects CTS (as
verified by watching the led's on a breakout box). The modem is supposed to
negotiate speed (and possibly MNP level) with the remote modem.
Things seem to work fine in "normal" mode (i.e. with MNP turned off). This
gets me 300, 1200, and 2400 bps. The problem comes when I turn on "reliable"
mode (i.e. the modem does MNP level 4 error correction all the time) or
"auto-reliable" mode (i.e. the modem will do MNP level 4 error correction if
the remote modem can handle it). With error correction turned on however, the
modems freeze up.
Has anybody else run into similar problems? Any suggestions?
--
Mark of the Valley of Roses
...!{harvard,ima}!bbn!aoa!mbrmbr@aoa.UUCP (Mark Rosenthal) (05/11/88)
In article <221@aoa.UUCP> I wrote about problems I have encountered trying to
use MultiTech 224EH 2400 baud modems with error correction turned on. I
neglected to mention the firmware rev of the modems. Here are the responses
the modem gives to the "ATI" commands:
modem ID #
ATI0 244
firmware rev #
ATI1 606
firmware for error correction
ATI2 506
MultiTech tells me that these are the latest revisions.
--
Mark of the Valley of Roses
...!{harvard,ima}!bbn!aoa!mbrsteveg@ritcsh.UUCP (in stereo where available) (05/13/88)
I had a similar problem though I was running with XON/XOFF flow control
and was loosing data. My problem was that I was allowing XON XOFF codes to
pass thru and thus when I hit an XON if the other end modems buffer was
full, since my modem passed the XON through to the other end thus
hitting the computer, the computer would output data even though
it's modem may of XOFFED it and did not want any more data, thus the loss.
By doing much testing I found the correct settings are:
&E1 if you want auto reliable compressed mode
&E4 for hardware flow control
&E5 for XON/XOFF flow control
&E6 do not pass incomming flow control through phone line
only act upon it.
&E8 is default and I did not want to mess with this setting.
&E11 in normal mode modem will support flow control
&E13 support pacing / flow control
&E15 support data compression if remote modem supports it
In my setup I use XON XOFF I would suspect that if you wish hardware
flow control the only setting that need be changed is the one dealing
with the type of flow control being used.
If you are doing binary data transfer you do not want to use XON XOFF
flow control.
--
___ ___ ___ Steve Good ...uunet!ccicpg!cci632!ritcsh!steveg
|@/o o\@| @/- -\@ @/o o\@ Network Administrator BITNET%"SNGDCO@RITVAXD"
| \ o / | / o \ \/-\/ Rochester Institute of Technology (716)475-2702
\ --- / | --- | /---\ "I hear nothing, I see nothing, I say nothing" ShultzNU013809@NDSUVM1.BITNET (Greg Wettstein) (05/26/88)
I have just received a Multitech MT-224EH modem and am setting it for
reliable (MNP Class 5/compressed mode) communications with another MT-224EH.
I have read the manual thoroughly and have wired an RS-232 cable which
supports all nine lines (SEND, RECEIVE, GND, RTS, CTS, RI, DSR, DTR, CD).
I have written my own terminal emulator (MSC C 5.0 + assembler) which
supports interrupt driven asynchronous communications. I run the terminal
emulator on a Zenith Z-159 and use the MT-224EH to dial into an ITT
XTRA (with another MT-224EH) running SCO XENIX.
My desire is to run both modems at 4800 baud to take complete advantage
of the increased throughput provided by the MNP protocol as well as
data compression. Since one of my desires is binary file transfers using
the IMODEM protocol my interpretation is that hardware handshaking using
CTS/RTS control pairs is the only feasible method of flow control.
The problem that I am having with CTS/RTS control pairs is with the initial
state of the control signals. I have set the internal jumper so that
RTS is not forced high (functions normally) and have correctly set SWITCH 1
on the internal four pole switch so that CTS follows the RTS signal. Even
though my terminal emulator raises RTS in its initialization procedure the
modem refuses to acknowledge with CTS and of course this hangs an emulator
using CTS/RTS control pairs. It apprears that the Multitech modem will not
raise CTS (even in the presence of RTS) unless a valid carrier detect is
available. I have a copy of QMODEM 3.1 and it also complains that CTS is
not available when it attempts to initialize the serial port.
My question is whether or not I have missed some control switch setting or
perhaps some internal jumper is still mis-configured. The manual that
comes with the modem is pretty good but I do not think that the section
describing hardwire flow control does a good job of documenting exactly
what has to be done. I am in the middle of a catch-22 because I cannot
initiate a call without a valid CTS and I cannot seem to get a valid CTS
until a valid connection is achieved. The only thing I have been able
to think of is to write code into my terminal emulator which does not
attempt RTS/CTS flow control until a valid DSR signal is elicited by the
modem.
Any suggestions, comments or questions would be greatly appeciated. I have
a pretty fair background in PC's and asynchronous communications so responses
at any level of expertise would be gratefully accepted. I will summarize
all responses back to the net. Thanks in advance to all respondents.
As always,
G.W. Wettstein
NU013809@NDSUVM1mbr@aoa.UUCP (Mark Rosenthal) (06/01/88)
In article <1211NU013809@NDSUVM1> NU013809@NDSUVM1.BITNET (Greg Wettstein) writes: >The only thing I have been able >to think of is to write code into my terminal emulator which does not >attempt RTS/CTS flow control until a valid DSR signal is elicited by the >modem. I have gone over the modem settings in detail myself, and have not found any way to get the modem to assert CTS while dialing and then use that pin for flow control only after the connection has been established. I believe that 'tip' and 'uucp' work because they are written to ignore the state of CTS until a call has been established (i.e. DCD is asserted). -- Mark of the Valley of Roses ...!{harvard,ima}!bbn!aoa!mbr
NU013809@NDSUVM1.BITNET (Greg Wettstein) (06/02/88)
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.davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/06/88)
On many UNIX systems there are two (or more) names for every serial
device. These are just diferrent minor devices, and one uses CTS, the
other doesn't. For instance, on my Xenix/386 system, the line with CTS
is tty2A, and the one without is tty2a. The dialer used by cu and uucico
uses the second line to send dialing commands, then the line with CTS
enabled is used for data transmission.
Several other systems, such a Wicat have much the same scheme,
although the name are diferrent.
Obviously your system may not be setup this way.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me