Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (MU) 9/23/84; site charlie.OZ
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!munnari!mulga!aragorn!charlie!pph
From: pph@charlie.OZ (peter horan)
Newsgroups: net.dcom
Subject: Re: Asynchronous data slippage
Message-ID: <5187@charlie.OZ>
Date: Fri, 28-Jun-85 10:46:21 EDT
Article-I.D.: charlie.5187
Posted: Fri Jun 28 10:46:21 1985
Date-Received: Sun, 30-Jun-85 00:15:16 EDT
References: <183@teneron.UUCP>
Reply-To: pph@charlie.OZ (peter horan)
Organization: Computer Centre, Deakin Uni, Australia
Lines: 47

[]
In article <183@teneron.UUCP> joey@teneron.UUCP (Joey Pruett) writes:
>	I am currently working on a device that sits between a modem
>(DCE) and a terminal/computer (DTE) and processes the data going in
>both directions.  The problem I am experiencing is characters being
>dropped from the data stream when sending continuous data (at any baud
>rate). 

What is described here happens because the received data rate is slightly
faster than the rate determined by the receiving system's clock.
When the stop bit is sampled, the received character is transferred
into the receive buffer, where it is meant to be held until read.
Now, software takes the character and places it into the transmitter
buffer. It is next placed into the shift register to be sent to line.
However, the time to transmit a character to line is determined by
the system clock which we used for the receiver. So, characters are
transmitted at a slower rate than they are received. Eventually,
a character is received when all the buffers are full, and overrun
occurs and a character in the receive buffer is lost.

Solutions:
1. If the source is under control of the designer:
	Transmit with two stop bits (standard only at 110 & 300 bps, however)
	Receive and re-transmit with one stop bit.
	This works, because the speed of retransmission is controlled
	by the original transmitter. In effect, the retransmitted
	data has more than one stop bit, but less than two.

2. Re-transmit at a higher bit rate than received. E.g. receive at
	1200 bps, transmit at 2400 bps. This works well when there is a
	terminal and user involved because the user cannot generate
	data continuously.

3. Use a slightly faster clock so that the UART can send data on its way
	without filling its buffers.

4. Use a means of flow control such as echoplex, Xon/Xoff or CTS
	to stop the source. A buffer or fifo is needed in the path
	unless echoplex is chosen.

It would be nice, also, if UARTs could be programmed to generate
zero (0) stop bits as well as one or two. Then, timing can be
controlled by the source as in solution 1 above.

Peter Horan 
ACSNET: pph@charlie (Domains are nice!)
UUCP: mulga!charlie.OZ!pph