banderso@sagpd1.UUCP (Bruce Anderson) (05/07/88)
Recently, I had a requirement for an inexpensive 2400 bps modem so
I went out and purchased a US Robotics unit. This wasn't the Courier
model but the less expensive Sportster 2400.
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. I tried using a Prometheus
and an Anderson-Jacobson unit and they work perfectly under identical
circumstances.
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. It also
goes away if the connection through the Micom unit is started at 1200
and then upped to 2400. This causes the port selector to simply sample
each bit as it comes in rather than treating a byte as a single entity
as it does when you make the connection at 2400.
I've talked to both Micom and US Robotics and neither had any suggestions
or explanations to offer. (Actually the person I talked to at Micom
was not familiar with the port selector and gave me information which
I later found out was directly contradicted by the manual).
If anyone has an explanation for what might cause this I'd be interested
in hearing it. Otherwise, just be aware that there seems to be an
incompatibility between these two products.
Bruce Anderson - Scientific Atlanta, GPD
UUCP: ... ncr-sd!sagpd1!bandersojerry@oliveb.olivetti.com (Jerry Aguirre) (05/11/88)
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.
eshop@saturn.ucsc.edu (Jim Warner) (05/11/88)
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
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/11/88)
I think that if you look at the Micom you will find that the baud rate
is slightly off. We had a similar problem years ago, and that was it. By
using 2 stop bits you widen the window, since the problem occurs when a
start bit is detected where a stop bit should still be. This resets the
clocks on a character basis.
You can check this with a scope to be sure, and I hope you will. Most
UARTS can run "1-1/2 stop bits", (no I'm am NOT making it up) but I
doubt that the modem gives you a way to get to it. As I recall that is
the standard for either 110 or 134.5 baud.
---
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mebrian@cbw1.UUCP (Brian Cuthie) (05/12/88)
In article <21560@oliveb.olivetti.com> jerry@oliveb.UUCP (Jerry Aguirre) writes: > >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. Most high speed modems are actually Synchronous modems with Asynchronous converters. This conversion from Async to Sync, and back, is done (usually) at the bit level. The reason that there is an overspeed option is that Synchronous modems are within .01% of spec'd speed. Async tolerances, however, are much more liberal (-2.5% to as high as 3%). This obviates a need for more bandwidth on the Sync side of the channel. To put 3% overspeed Async data on a 0.01% tolerance line, stop bits are deleted in the Synchronous data stream. However, in order to have time to re-insert the stop bits on the receiver side, the clock for the Asynchronous transmitter of the Sync to Async converter (part of the receiver in the modem) must run 3% overspeed. This doesn't always make the DTE equipment happy. Note that the amount of overspeed tolerance need not be a full 3%. Most modems allow several selections since, in effect, you are choosing the speed at which you will throw data at the DTE on the receiving end and not all DTEs can survive too much overspeed. Also note that modems from different manufacturers may not behave as expected when selecting options such as overspeed. It is possible that, although the modem on the transmitting end is deleting stop bits to allow for the overspeed data, that the receiving modem does not know that it must run it's Async converter faster. Thus it is possible to overrun the receiving modem at the *synchronous* level. Hope this hasn't been too confusing... -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu