Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!purdue!decwrl!eda!jim
From: jim@eda.com (Jim Budler)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit result codes
Message-ID: <446@eda.com>
Date: 15 Jan 89 20:42:11 GMT
References: <275@ssbn.WLK.COM> <85@sopwith.UUCP>
Reply-To: jim@eda.com (Jim Budler)
Distribution: na
Organization: EDA Systems,Inc. Santa Clara, CA
Lines: 57

In article <85@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes:
# In article <275@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes:
# | I have X3 set but I don't get any of the extended result codes
# | unless I have S50 set to 255 for PEP.  Also, the modem doesn't
[...]
# 
# I get extended result codes with or without s50=255.  Sometimes my telebit
Me, too. My uucico doesn't recognize anything newer than Hayes 1200, so

I can't use them, but I remember very clearly all those "unknown modem
error" message uucico used to log for a connect fast/comp.

# doesn't recognise a busy, other times it does.  Sometimes the busy switches

Me, too. But most frequently it does recognize it. By listening with the
speaker on, I got the impression that the weaker sounding BUSY signals
were the ones it didn't recognize.

# from a normal busy to a fast 'trunk' busy, (!?) and then the telebit
# recognises it.
# 
# However, I never ever get NO ANSWER.  It returns NO CARRIER instead.
# Has anyone else noticed this?  Not a big deal, but something isn't
# quite right.

Same here.

# 
# One site I dial into has a TB+ setup to present PEP last.  Many times
# it will hang up the connection before getting through all the various
# carriers.  My TB+ waits around a bit and then returns NO CARRIER.  If
# I manually have my system call again right away, the remote TB+ gets
# a little further through the sequence of carriers each time, and after
# 3-5 tries finally stays on the line long enough to connect.

My manual, under the S92 instructions says that the originating modem
must have S50=255 to call a site answering PEP last (and connect at
PEP), AND have S7 >= 60. 

# 
# Has anyone else seen this?  It seems that if it were a timer going off, it
# would be the same amount of time each time.  Again, this isn't a serious
# problem, uucp just keeps trying until it gets through.  

The length of time to successfully connect is a function of the line
quality. I have my S7=100. I talk to UUNET who answers PEP last. In the
dim reaches of my memory I recall having trouble such as you describe, and
it was before I found the passage under S92 about S7.

# tektronix!tekecs!sopwith!snoopy
# sun!nosun!illian!sopwith!snoopy

jim

-- 
Jim Budler   address = uucp: ...!{decwrl,uunet}!eda!jim
					 domain: jim@eda.com