joey@teneron.UUCP (Joey Pruett) (06/24/85)
Hollow: 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). I placed the UARTs I am using (Signetics 2661) into remote loopback mode (the incoming data is immediately transferred from the reciever shift register into the transmitter holding register) and discovered the same problem. I think I have tracked the source to a baud rate clock that is slightly slow (about 0.006% off), but everybody indicates that asynchronous communications have tolerances around 0.5%. With continuous data coming into the device at 9600 baud, the output will drop one character approximately every 3.8 seconds. Does anybody out there have any ideas or suggestions for what I can do about this problem? Is it a problem at all, or does all async communication have this problem? Any and all comments appreciated, Joe Pruett Teneron Corporation 6700 SW 105th Suite 200 Beaverton, Oregon 97005 (503)646-1599
pph@charlie.OZ (peter horan) (06/28/85)
[] 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