Path: utzoo!attcan!uunet!husc6!mailrus!tut.cis.ohio-state.edu!uwmcsd1!ig!agate!saturn!eshop
From: eshop@saturn.ucsc.edu (Jim Warner)
Newsgroups: comp.dcom.modems
Subject: Re: US Robotics / Micom incompatibility
Keywords: US Robotics, Micom
Message-ID: <3239@saturn.ucsc.edu>
Date: 11 May 88 01:17:31 GMT
References: <267@sagpd1.UUCP> <21560@oliveb.olivetti.com>
Reply-To: eshop@saturn.ucsc.edu (Jim Warner)
Distribution: na
Organization: University of California, Santa Cruz
Lines: 25


Subject: Re: US Robotics / Micom incompatibility

I have thought about the problems associated with Micom 600/6600's
a lot.  My understanding is that the quad cards operate in 
oversampling mode at all baud rates up to and including 2400 and
only switch to quasi-synchronous mode at 4800 and 9600 BAUD.  This
is for backwards compatibility with the old "low speed" quad cards.
In compatibility mode, the Micom samples the bit stream aprox
9600 times a second.  In every case I looked at, the Micom was
running its sampling SLIGHTLY faster than 9600 Hz.  About every
1 in 150 characters had 1/8 of at bit (at 1200 BAUD) sliced out of
it.  That makes the baud rate for that character come out to be
1215.  I actually still have oscilloscope photographs that show
the time displacement effect from an unsychronized sampling at a
less than infinite rate.  I think that this may explain why over-
speed mode may have worked on your modem.  Two stop bits, likewise,
gives the modem a chance to get caught up with the speed fluctuations
introduced by Micom's sampling.

Here at Santa Cruz where our RS-232 lines can get to be up to
several thousand feet long, the timing jitter introduced by sampling
set the limit on how far/fast we can send data. 

jim warner