Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hayes!tnixon
From: tnixon@hayes.uucp
Newsgroups: comp.dcom.modems
Subject: Re: Intel 9600ex
Message-ID: <3779.27bbbc87@hayes.uucp>
Date: 15 Feb 91 10:48:39 GMT
References: <4028@gazette.bcm.tmc.edu> <3186@unocss.unomaha.edu>
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 97

In article <3186@unocss.unomaha.edu>, fg041@unocss.unomaha.edu
(fg041) writes: 

> For some reason, Intel has chosen only to present the Bell 103 answer tone
> for three seconds.  Many modems, including the Racal 3451 here at work, will
> not respond within that period.  Of course, most dumb 300 baud modems will
> not work either.  (Yes, some people actually use them.)  

The 2250/2850 Hz tone (unscrambled binary 1 signal for Bell 103, 
Bell 212, V.22, and V.22bis) is sent for three seconds because the 
CCITT studies indicated that this was more than long enough.  A 
_real_ (dumb) Bell 103J modem, as well as all of these others, will 
respond in 610 milliseconds (plus the round-trip delay of the 
circuit) from the start of the signal.  Extensive testing by all
other manufacturers who are members of the CCITT (including
Racal-Milgo US and UK!) uncovered no modems that wouldn't respond in
under 3 seconds.  This time limit is now part of the V.32 and
V.32bis standards, so you'll find it in virtually all newly-released
V.32 and V.32bis modems (including Hayes Ultra 96). 

> I did report it to Intel, and they admitted they knew of the problem but
> could not/would not say when a fix was due.  (Real Soon Now ;-)  

I sincerely hope that Intel uses extreme caution in "fixing" this 
problem.  It is important that if both the originating and answering 
modems are V.32/V.32bis AutoMode modems (support lower speeds, which 
most of them do), that both of them know in advance the duration of
this timer.  Otherwise, they may inadvertently and unnecessarily 
connect using V.22bis instead of V.32, if the originating modem is 
manually-dialed or otherwise connected to the line too far into the 
answer tone (or even after the answer tone).

> Right now I could care less about v.32bis for the thing.  I just want it to
> operate properly with the standard modems that have been around for the past
> several years.  (And no, I don't consider telling the affected users to get
> newer modems an appropriate solution.)

I think you should blame Racal, who were active participants in the 
development of the Automode Procedure, for not speaking up and 
saying that one or more of their older products would have a problem 
with this.  Perhaps they just didn't care, and considered other 
factors to be more important.  AT&T was also a very active
participant in the work, and surely would have indicated if they had
a problem with the original 103 modems.  Hayes tested the
three-second limit with the dozens of modems we have in our labs
(all of our previous products [all versions of them], plus dozens
from other manufacturers), and found 3 seconds to be more than
sufficient; in fact, no modem we tested required more than 1.7
seconds, but we supported the 3 second limit to allow for double
satellite hops and other contingencies. 

> It's too bad that when a product such as the 9600ex came out, it was so
> thoroughly tested against the Robotics and Telebit macho modems, when it
> is so glaringly obvious that they failed to verify the performance with
> the older ones.  I could possibly see one or two models having difficulty,
> but this is with several types of modems from several different vendors.

First of all, the Intel modem's "bit pump" was not designed by 
Intel.  I believe it is a Rockwell chipset, so you'd have to blame 
Rockwell for this.  Rockwell was ALSO an active participant in the 
CCITT Study Group XVII deliberations on this topic!  Personally, I 
think Intel has been quite responsible, by following the CCITT 
Recommendation to the letter.  It would be irresponsible of them to 
arbitrarily select a different value from that specified in the 
standard, thereby introducing possible interworking problems with 
other AutoMode modems.  It is unfortunate that you've found some 
obscure modems that fail to connect even though they're presented 
with FIVE TIMES the amount of USB1 signal required by the applicable 
standards!  I must say that the position of Study Group XVII on this 
was quite clear -- why should they take extraordinary steps to 
accomodate modems that do not comply with CCITT standards?

I should comment, by the way, on how Hayes has addressed your 
problem -- we DID take extraordinary steps, even though the CCITT 
didn't.  We implemented a new S-register, S97, which specifies the
duration of this USB1 signal sent from the answering modem.  The
factory default is 3 seconds, as required by the standard, but it
can be set in 1/10th second increments from 1.5 seconds to 7
seconds.  The documentation clearly warns that making it shorter 
than 3 seconds can cause problems with connecting with certain
older, low-speed modems (such as yours), and that making it longer
may introduce problems with late- and manually-connecting Automode
modems. Nevertheless, the option is there, so that you can extend
the USB1 transmission tome in case you're more concerned about
connecting with older non-compliant low-speed modems that your are
about manually-dialed V.32 modems. Perhaps you could suggest to
Intel that they implement a similar feature.  I'd be happy to
provide them with the documentation on Hayes' register if they ask
for it; it is public and not the subject of any patent. ;-)

	-- Toby

-- 
Toby Nixon, Principal Engineer    | Voice   +1-404-449-8791  Telex 151243420
Hayes Microcomputer Products Inc. | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                   | UUCP uunet!hayes!tnixon  AT&T    !tnixon
Atlanta, Georgia  30348  USA      | Internet       hayes!tnixon@uunet.uu.net