grr@cbmvax.UUCP (George Robbins) (02/24/88)
Today, while trying to discover why my Trailblazer was absolutly
refusing to connect to another site that I used to be able to contact
but had been getting "NO CARRIER" for days, I found some intersting
facts...
Recently, I patched our uucp so that it would set S50=n, where n
was appropriate to the kind of call I was making. This was needed
so that I could contact sites in "fast" mode that had S92=1 or
that I wanted to call at 1200 baud, despite there actually having
a 1200/2400 baud modem.
I've previously mentioned that Telebit needs an S50 mode that works
somewhat like S50=0, but that gives priority to the transmission
mode appropriate to the interface rate, so that connections can be
made at the rate the user/dial program expects without having to
modify S50 on a dynamic basis.
Anyhow, after changing uucp to explicitly set S50, I noticed that I
hadn't been able to get through to osu-cis for 3 days, and the
success rate calling some other sites was pretty dismal. Well,
maybe they were down? I called the number on the phone, and ring,
ring, 2400 baud answer tone! Hmmm. I fire up kermit and pound
in the ATDT stuff...RRING, RRING, CONNECT 2400. Can't get through
for 3 days??? Wait a minute, something fishy. I set S50=3, and
redial...NO CARRIER, try 5 times always NO CARRIER, change back
to S50=0, works good every time!
After some serious headscratching, manual contemplation and dicking
around with random (S90/S91) S registers, I still get the same
results. Taking a modem into the office so I can hear the speaker,
I find that the remote modem does answer, you get the two-step
answer tone, and the PSK static sounds, and the the modem says
NO CARRIER. After some more headscratching, idea: S7=60... Magic!
Now works every time, whether S50=0 or S50=3.
Problem(s):
The interpretation of S7 varies depending on what mode you select
with S50. When you set S50 to 3 or 2 (and perhaps 1), you may need
to set S7 to a longer carrier detect timeout to make connections
than what you needed with S50=0.
When S50 is set to 3 or 2 (and probably 1) you don't get the same
call progress detection as with S50 set to 0 or 255, e.g. you don't
get the RRING messages. The manual is silent about this.
What Appears to Happen:
In the S50=0 and S50=255 modes, the DSP chip is being used for
call progress detection. This gives you the remote ring detection
capability and the S7 time is being interpreted as the time from
call initiation until the detection of an answer tone.
When S50=1,2,3 the AMD "World Chip" is probably being used for
carrier detection. This chip doesn't do much in the way of call
progress interpretation, and only signals carrier detect at the
end of the answer sequence, perhaps with some additional delay.
This would pretty much explain why a longer time needs to be
specified when you explicitly select one of the low speed modes.
Solution:
Users should increment their S7 settings. Telebit should either
make the timeouts more consistent, or at least document the
difference to prevent severe mental distress on the part of modem
users who are under the illusion they understand what's going on.
--
George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)wtm@neoucom.UUCP (Bill Mayhew) (02/27/88)
The telebit manual does suggest changing the time limit to for detecting the carrier to 60 seconds, if you set the modem to try 1200 and 2400 before trying out FAST. I had the same problems that George did, but found I got consistent connections after changing to 60 sec timeout. I discovered the problem since our dial-in has to support calls coming in from non Trailblazers too. --Bill
grr@cbmvax.UUCP (George Robbins) (03/01/88)
In article <1024@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > > The telebit manual does suggest changing the time limit to for > detecting the carrier to 60 seconds, if you set the modem to try > 1200 and 2400 before trying out FAST. I had the same problems that > George did, but found I got consistent connections after changing > to 60 sec timeout. I discovered the problem since our dial-in has > to support calls coming in from non Trailblazers too. Yes, but that's in reference to a modem calling into a trailblazer with S92=1, where it's fairly obvious that you might need to allow a longer time to sniff the PEP answer sequence. In my case, I was calling a "dumb" modem and saying, use 2400 baud and don't search. It is counter-intuitive for this condition to require a longer carrier detect delay than one that has to wait through the entire 2400 baud answer sequence and then perhaps listen for PEP stuff. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
edm@nexus.UUCP (Ed Morin) (03/04/88)
I've noticed a lot of talk about switching the carrier detect sequence around on the 'Blazers (i.e. setting S92=1). Have people experienced a lot of prob- lems with non-Blazer modems not connecting when it puts out the "Moose call" first rather than last? I have tried several different 1200/2400 baud modems out and have never had a problem detecting carrier (eventually). What about the rest of you folks out there? Ed Morin Northwest Nexus Inc. - Public Access Unix for the Masses
grr@cbmvax.UUCP (George Robbins) (03/10/88)
In article <589@nexus.UUCP> edm@nexus.UUCP (Ed Morin) writes: > I've noticed a lot of talk about switching the carrier detect sequence around > on the 'Blazers (i.e. setting S92=1). Have people experienced a lot of prob- > lems with non-Blazer modems not connecting when it puts out the "Moose call" > first rather than last? I have tried several different 1200/2400 baud modems > out and have never had a problem detecting carrier (eventually). What about > the rest of you folks out there? In my case, it did confuse incoming calls from another site. The key seems to be whether the calling modem has "call progress detection" smarts. If all it listens for is the normal answer tone sequence, no problem. If it is trying to discriminate between ring / busy / voice responses to the call, then the "moose call" or recognition / training sequence can cause the smart modem to abort the call and return a "voice" or other response. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)