dave@lsuc.uucp (David Sherman) (12/11/88)
Our dialins (four on a hunt group) are all Racal-Vadic 1200PA's, a good solid modem with no defects that I know of. We've never had problems with people calling in. A user has a Courier HST 9600-bps modem, and has not been able to connect to us at 1200 baud. He's been forced to work at 300, in fact. Calling at 1200, he gets carrier detect and then it's dropped instantly. Another person I know with an HST has been trying to poll us with uucp, and has the same problem. Our user tells me that the settings on the modem are: || USRobotics Courier 9600 HST NRAM Settings.... || || DIAL=HUNT M=1 X=4 F=1 B=1 || BAUD=19200 PARITY=N WORDLEN=8 || || &A1 &B0 &G0 &H0 &I0 &K1 || &M4 &N0 &P0 &R1 &S0 &Y1 || || S02=043 S03=013 S04=010 S05=008 || S06=002 S07=025 S08=002 S09=006 || S10=010 S11=044 S12=050 S13=000 || S15=000 S19=000 S21=010 S22=017 || S23=019 || || STORED PHONE #0: || #1: || #2: || #3: || || OK || || Dont worry about the reported baud rate - that is between the terminal || and the modem, the modem connects and transfers/receives with the remote modem || at the highest connection rate it can achieve (here being 1200 baud). Can anyone help? David Sherman The Law Society of Upper Canada Toronto (416) 947-3466 -- Moderator, mail.yiddish { uunet!attcan att pyramid!utai utzoo } !lsuc!dave
jbritain@pnet01.cts.com (Jim Britain) (12/13/88)
The Courier 9600HST, at times can be rather touchy connecting at lower speeds
if set to full "automatic" speed and protocol sensing, when calling other
modems.
The best solution, is to optimize the configuration for each call made,
although that is not always necessary.
The solution that works for connecting to lower speed modems that are fooled
by the request for ARQ correction, is simply to disable it, and also to
disable speeds higher than the system being called.
AT&m0 will disable the negotiation for ARQ correction
AT&n3 will set the top speed of the modem to 2400 baud (n2=1200, but not
necessary).
A complete string to relieve those disconnect errors:
AT&M0&N3
It is also wise, of course, when configuring for individual systems, to
enter the ATZ string first, so that you know that the modem is truly set to
the default NRAM values.
Or, upon disconnect issue the ATZ string to the modem, so that it is left in a
known state. (I just don't trust these things to stay in a "known" state, if
not in use).
It would also be wise for the user to lock his modem speed to his terminal
speed with the command AT&B1, and keep his speed negotiation totally within
the modem.
UUCP: {hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!jbritain
ARPA: crash!pnet01!jbritain@nosc.mil
INET: jbritain@pnet01.CTS.COMkarl@ddsw1.MCS.COM (Karl Denninger) (12/14/88)
In article <3630@crash.cts.com> jbritain@pnet01.cts.com (Jim Britain) writes: >The Courier 9600HST, at times can be rather touchy connecting at lower speeds >if set to full "automatic" speed and protocol sensing, when calling other >modems. This doesn't work in the following scenario: o Modem connected to Unix machine, which both dials out and receives calls inbound. Calls inbound come from all different speed classes. Now, with this scenario, you either have a (1) 9600-baud HST which can talk to a 2400 or 1200 baud MNP unit, and _SOME_ non-MNP modems, or (2) a 2400 baud modem which will NOT take a high-speed call! U.S. Robotics, this stinks! I agree that you should set parameters appropriately for outgoing connections, but this simply doesn't work for incoming callers. With the behavior I've seen, 3b1 systems CANNOT call us with the OBM at all, many other 1200-baud modems immediately disconnect (yikes!), and SOME others can connect through after 4-6 second delay. MNP units calling us work fine; this jives with the manual which claims that the /ARQ protocol is a MNP-type thing and is interoperable with MNP. Contrast this with our Telebit, which can connect with ANYTHING on an inbound call -- PEP _OR_ any and all 300-2400 baud modems. (It is true that you have to present PEP tones LAST to do this reliably, but at least you _CAN_ accomplish it!) The HST is a much poorer design for the real world given this problem. --- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
mikes@ncoast.UUCP (Mike Squires) (12/19/88)
In article <1988Dec11.125951.10539@lsuc.uucp> dave@lsuc.uucp (David Sherman) writes: >Our dialins (four on a hunt group) are all Racal-Vadic 1200PA's, >a good solid modem with no defects that I know of. We've never >had problems with people calling in. > >A user has a Courier HST 9600-bps modem, and has not been >able to connect to us at 1200 baud. He's been forced to work >at 300, in fact. Calling at 1200, he gets carrier detect and >then it's dropped instantly. Another person I know with an HST >has been trying to poll us with uucp, and has the same problem. > I have had similar problems with my HST that were eliminated by asking the HST to not check for MNP (AT &M0). I had problems with both an ARK 24K and AT&T modem of this type. Mike Squires Allegheny College Meadville, PA 16335 814 724 3360 uucp: ..!cwjcc!ncoast!{mikes,peng!sir-alan!mikes} or ..!pitt!sir-alan!mikes BITNET: mikes%sir-alan@pitt.UUCP (VAX) MIKES AT SIR-ALAN!PITT.UUCP (IBM) Internet: sir-alan!mikes@vax.cs.pittsburgh.edu
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (12/21/88)
In article <13271@ncoast.UUCP> mikes@ncoast.UUCP (Mike Squires) writes: | I have had similar problems with my HST that were eliminated by asking the | HST to not check for MNP (AT &M0). I had problems with both an ARK 24K | and AT&T modem of this type. This can be a problem with any MNP modem, particularly calling into a system which has good response. The problem only happens when the calling modem has MNP and the answering modem doesn't. What happens is that the modems exchange tones and whistles until they find a mutually satisfactory protocol and connect. The carrier detect goes true. At this point if the called system does login and/or autobaud, there may be a problem. The calling modem sends out a particular tone bust which means "would you like to do MNP?" If the called modem is not MNP, this burst gets passed on to the autobaud program, which may set speed to 134.5 or something. Then then end of the tone burst may get passed into the login sequence. Now the two systems are talking at a bad baudrate, neither able to understand the other. Needless to say, if the autobaud has already decided that the speed is set, nothing short of a start-over will make the connection work. Hope this clarifies the sequence. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me