Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!jerry From: jerry@oliveb.olivetti.com (Jerry Aguirre) Newsgroups: comp.dcom.modems Subject: Re: US Robotics / Micom incompatibility Message-ID: <21560@oliveb.olivetti.com> Date: 10 May 88 23:09:20 GMT References: <267@sagpd1.UUCP> Reply-To: jerry@oliveb.UUCP (Jerry Aguirre) Distribution: na Organization: Olivetti ATC; Cupertino, Ca Lines: 40 Keywords: US Robotics, Micom In article <267@sagpd1.UUCP> banderso@sagpd1.UUCP (Bruce Anderson) writes: >For a couple of days I just used it with a terminal to work on a >remote host and it worked without a flaw. When that job was done I >connected it to our Micom port selector (model Instanet 6000) as a >call out unit. In this configuration it worked fine at 1200 but at >2400 it couldn't receive more than about 10 characters in a row >without starting to garbage some of them. ... >Through trial and error, I discovered that if the remote host is set >to 2 stop bits rather than 1 stop bit, the problem goes away. I had the same problem a few years back. I connected some 1200 BPS modems for dialin to a Micom 600. In the case of continuous output, such as 'cat'ing a file or a long 'ls' the connection would garbage a character every few hundred characters. Setting two stop bits made the problem go away. Eventualy I found an option in the modem labled 'allow overspeed data' that basically allowed 1221 BPS instead of limiting it to 1205 BPS. This fixed the problem without requiring two stop bits to be set. I only tested this for output (from Micom to modem) as I had no need for continuous input in the other direction. My original assumption was that there was a baud rate mismatch in the Micom so that a continuous stream of data would gradually overload the buffer in the modem. (Faster modems don't deal on a bit by bit stream, they actually know about start and stop bits and such.) This explaination was never satisfying because if I connected the modem directly to the host there was no problem. How could the Micom send bytes out faster than it received them from the host? My understanding is that the Micom doesn't have enough buffering in a connection to accumulate a burst of data. Just now it struck me that perhaps the problem really was stop bits. Above a certain data rate the Micom switches from sampling bits to transfering a character at a time. I wonder if, in that mode, it is receiving 1 stop bit from the host and generating 2 stop bits on output to the modem. Definitly something strange going on inside the Micom.