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