Serial Communications
By Duncan Strand.
November 1998

Email me about this page

Web Notes

Some of the images in this web version of the report are either to big, or to small. This will be fixed as soon as possible.

Summary

This report looks at the impact that different communication settings can have on the transmission of data using a simulated RS232 serial link. What was found was that it is important to ensure that the device settings match otherwise the data may become corrupt when transmitted.

Various different types of devices have also been connected together to try and get them to send data to each other, with full flow control. This showed that different types of devices do not always have flow control, or that the flow control is implemented in a different way.

Table of contents.

Introduction

Conclusion

Acronyms

Introduction

The aims of this report are to investigate the effect that different communication settings can have on two devices that are trying to communicate over a simulated RS232 link, and to experiment connecting various different types of simulated machines via a simulated serial link.

Throughout this report I will make use of diagrams to show the transmission and reception of data. These diagrams use a high line to show logic 1, and a lower line to show logic 0. This is known as non-return to zero level.

Any acronyms that have been used are listed with their meanings at the back of this report.

Effects of changing the communication parameters settings

I set-up the RS232 simulator so that both the devices are machine 1. The baud rate is set to 9600, two stop bits are used, parity is set to even, and there are 8 data bits.

Pin 2 on the left hand device is connected to pin 3 on the right hand device two, pin 3 on the left hand device is connected to pin 2 on the right hand device. Pin 7 on the left hand device is connected to pin 7 on the right hand device.

Anything typed into the text area on either machine appears in the text area on the other machine.

Baud rate

Changing the baud rate on the left hand machine so that it is 600 baud will mean that the text received by the right hand machine will not be the same. Entering the text "This is a test" on the left hand device, resulted with "ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ" being displayed on the right hand device. This is because the characters are being transmitted at a slower rate than what the receiver is expecting.

Figure 1

The example in figure 1 (above) shows the character "g" being transmitted (only the data bits are shown). For this example the transmitter is transmitting at 300 baud (the signal is changing 300 times a second). As the receiver is expecting the transmission to be at 600 baud (the signal changes 600 times a second) it is expecting the signal to change twice as fast than the transmitter is capable of. As the baud rate is slower than the receiver's baud rate the receiver, receives twice as many bits in the same time period. The transmitter sends 01100111 as the data bits, but the receiver receives 0011110000111111 as the data bits.

Stop bits

Having set the baud rate so that they are now the same, I changed the number of stop bits to 1 on the left hand device and set it to 2 on the right hand device. This did not appear to have any effect on the text that was sent. Changing the stop bit settings to other values did not affect the text either. When more stop bits are being transmitted the receiver still displays the correct text because it ignores the extra stop bit and is waiting for the next start bit. When the transmitter is sending less stop bits than the receiver is expecting it may still receive the text because the stop bit has the same logic state as when the line is idle. If the more than one character is going to be sent (a text file) then the transmission will be corrupted because the receiver will wait until two stop bits are sent.

Data bits

After resetting both devices to use two stop bits, I changed the number of data bits to be sent by the left hand device to 5. The right hand device is still using 8 data bits. Typing "This is a test" resulted in "(33!3" being received.

Figure 2 (right) shows the data transmitted by the left hand device that is sending the letter "g". As characters are 7 bit, 2 bits of data bits are lost, corrupting the transmission.

As the receiver is expecting 8 data bits to be sent when the receiver decodes the bits, as shown in figure 3 (right), it reads the parity bit and the stop bits as part of the data. The transmitters idle time is received as the parity and stop bits.

Parity

To find what effect changing the parity will have on the transmission of characters, I set the left hand device to use 9600 baud, 2 stop bits, no parity and 8 data bits. The right hand device has the same settings except that the parity is set to even.

Using the RS232 simulator to send the character "g" resulted in the correct text being received on the right hand device.

Figure 4

Figure 5

Figure 6

Figure 7

Sending at 110 baud, receiving at 9600

Because the receiver is operating much faster than the transmitter, the receiver is receiving all the 12 bits of data in the time it takes for the transmitter to send the start bit. So all the data received should be 0 (see figure 8 (above right)). Once the 8 bits of data have been received the receiver waits until two stop bits are received, ignoring anything that is transmitted whilst it is waiting. The two stop bits are received when the transmitter sends the first data bit. The data received by the receiver (including control bits) is 11 00000000 0, however the RS232 simulator shows the data received to be all 1s. There are a few possible reasons (all incorrect) for this:

• Once the start bit is received, the receiver waits for a change in the voltage before receiving the data bits. This is not correct though, because a character that begins with a '0' would not be sent correctly.
• The receiver inverts the data bits if they are all 0. The problem with this is that sending the number 0 would change it to 255.

If the baud rate settings are not the same on both devices then any data transmitted will be corrupt. What is received depends on what the different baud rates are set to. This does not mean that two different devices cannot send data to each other, just that they must use the same communication settings. Even if they were the same device they should use the same baud rate.

Accurate Connection

To transmit data accurately it is necessary to ensure that both devices are using the same settings. This is because, as has been show above, certain combination of settings can produce correct transmission some of the time. In the real world (i.e. not using the simulator) having both devices set to different settings could slow the performance down as characters with incorrect parity would need to be resent.

It is possible to send data without loss if some settings are different. These are:

• Parity. Setting the transmitting device to any parity setting, and the receiver to no parity results in a successful transmission, but only if sending individual characters.
• Stop bits. You can send less than the required number of stop bits, if only sending one character at a time. If you were sending a string of characters then the receiver would be waiting for any remaining stop bits before receiving the next character. You can send more than required without problem, because a stop bit is the same as idle time.

7 and 8 data bits

If the left hand device is set to use 7 data bits, even parity, and 2 stop bits and the right hand device 8 data bits, even parity and 2 stop bits. Then the characters sent will only be corrupted some of the time.

A character will be corrupt if its bit pattern causes the parity bit to be set. For example, if the transmitter sends the letter "g" it will be corrupted by the receiver because it understands the parity bit to be part of the data, and the first stop bit to be the parity, as show in figure 9 (right).

Sending the letter "r" (1110010) results in a successful transmission (with the same parity setting) because the parity bit is not set. If the parity is set to odd then "r" would not be received correctly, but "g" would.

If the receiver is using 7 data bits and the transmitter using 8 then the transmission and reception is always successful. This is because the receiver (when using the simulator) does not report parity errors (which should occur when the transmitter sends a character that should have the parity set).

NULL modem

Because RS232 was designed to link computers to modems, and not computers to computers. To get around this limitation it is possible to wire the connections so that it appears to both computers that they are connected to a modem, and not another computer. The simplest method to do this is to connect pin 2 to pin 3 on the other computer, and pin 3 to pin 2 on the other computer.

Serial Links

There are many situations when a null modem link between two computers is useful. For example, if you need to transfer lots of files (or a large file) between two computers it is a lot easier to use a direct serial connection, rather than copying the files to disk and copying them back on the other computer.

Another use for a direct serial connection is for two player games. Although a serial link is relatively slow, the amount of data that needs to be sent between the two computers (the player's position, what the player is doing) is small.

Changing the device settings

There are four settings that can be changed that will effect the successfulness of the transmission:

• Baud rate. If the baud rate of the two devices is different then the transmission of characters will always be corrupt. This is because the timing that the two devices are working to is different. One device is expecting the data to be faster or slower (depending which device is has the higher baud rate) than the other.
• Parity. If the data is sent with parity it is important to ensure that the parity settings on both devices are the same. If the parity is on, with one device set to odd parity and the other set to even, then the parity will always be the opposite than what the receiver was expecting (see figures 6 and 7). If parity is set to none on the receiving machine then the parity will be ignored because the receiver is waiting for the stop bits.
• Stop bits. It is possible for the transmission of a character to be successful if the stop bit settings to not match. If the data is sent with 2 stop bits and the receiver is set to receive only 1 stop bit then the extra stop bit will be ignored by the receiver. If the data were sent with less stop bits than required the transmission would not be corrupt if the transmitter is sending only a single character.
• Data bits. If the data bit settings are different then the transmission of data will only be corrupt if the number of data bits causes part of the data to be lost. For example sending "0111 0010" with 5 data bits will cause the "011" to be lost. If the receiver is set to receive more data bits than are sent, then the receiver will understand the parity (if set) and stop bit(s) as part of the data.

Understanding the RS232

Machine 1 to machine 1

Machine 1 is a DTE because it transmits on pin 2. To connect these two devices pins 2 and 3 need to be cross connected, as shown in figure 10.

The left hand machine transmits data through pin 2 and received by the right hand machine through pin 3. The right hand machine transmits data through pin 2 and received by the left hand machine through pin 3.

Machine 1 does not have any hardware flow-control, and sends data (an XOFF message) to tell the other machine if its buffer is full. Once its buffer is no longer full it sends another message (XON).

If one of the machines were to go offline, as the other machine does not know this it will continue to send data.

Machine 2 to machine 2

Machine 2 is a DTE because it transmits on pin 2. To get these machines to communicate they need to be wired as show in figure 11. This is the minimum configuration to allow two-way communication between these machines, and have flow control.

Machine 2 uses software flow-control to tell the other machine that its buffer is full, it does this by sending XON and XOFF messages. The machine uses hardware flow control to detect if the other machine is offline. If the machine is off line it sets pin 4 to logic 1. As pin 4 (RTS) is connected to pin 6 (DSR) on the other machine this stops the other machine from sending data.

As this machine has full flow control there are no problems if either of their buffers are full. If either of the machines go offline the other machine will stop transmitting.

Machine 2 to machine 3

Machines 3 is a DTE because it transmits on pin 2. The pins need to be connected as shown in figure 12.

Machine 3 has limited hardware flow control, it can detect if the machine it is connected to is offline, but does not report its own on/offline status. Machine 3 knows if the other machine is offline when a logic 0 is set at pins 5 and 6.

Machine 3 has no software flow control. It ignores the XOFF message sent by machine 2 when its buffer is full. Machine 2 does not know if the buffer on machine 3 is full because machine 3 does not send an XOFF message or change the status of any pins. Machine 3 needs logic 0 to be set at pins 5 and 8 before it can send data. This lets machine 3 know that it is ok to send data and that there is a device connected.

Machine 4 to machine 3

Machine 2 is a DTE because it transmits on pin 2. Pins 4, 5, 6 and 8 on machine 4 all need logic 0 to allow machine 4 to transmit. Pins 5, 6, and 8 are connected to pin 4.

If machine 4 is offline it sets pin 4 to logic 1. This stops it sending data, because pins 5, 6 and 8 are also logic 1. As pin 8 (DCD) on machine 4 is connected to pin 8 on machine 3 this stops machine 3 from sending any data as well.

If machine 4's buffer is full then a pin 20 changes to logic 0, as this is connected to pin 5 (CTS) on machine 3 it stops machine 3 from sending data.

Machine 4 has full hardware flow-control (buffer full and on/offline). Machine 3 does not have hardware or software flow-control.

Machine 4 to machine 1

Because machine 1 uses software flow-control to show that its buffer is full, and machine 4 uses the hardware, it is not possible for machine 4 to know if the buffer of machine one is full.

Machine 4 cannot stop sending data when machine 1 is offline because machine 1 does not alter the status of any pins or send any data to show this.

Although machine 4 uses full hardware flow-control machine 1 does not check the status of any pin to see if its ok to transmit. There is no flow control with this configuration, this will cause problems if the buffer of either machine is full, or if either machine goes offline for some reason.

About the simulator

There are a number of ways in which the RS232 simulator can be improved:

• It only shows what data bits have been sent and received. It should show all the bits sent.
• You should be able to copy the text from the area showing what has been sent and received.
• Although not needed for this assignment, the "create new device" function should work.
• The LED colours should be the other way around, red to show logic 0 and green to show logic 1. If not then the red should be brighter than the green.
• It should report parity errors (unless this is typically the roll of software - in which case the help file should say this).
• The program needs to be able to save the configuration of the wires and what the two devices are.
• Context sensitive help (pressing F1 when the device setting's window is open displays help that is relevant to that window).

It does have some strengths:

• It's easier than trying to connect two machines. Without the simulator this assignment would have been much harder to complete because I would have been limited to only being able to experiment with the connections during lab time.
• No messing around with wires.
• It's easy to use.

Conclusion

It is clear from the test conducted using the RS232 simulator that it is important to ensure that the communication settings on two devices connected together are the same. If they are not then the result is either an incorrect transmission, or a transmission that works, depending upon the data that is being sent.

What has also been shown is that, although it is possible to get two different devices communicating with each other. It is harder to get them to send flow-control messages that the receiving device is capable of understanding. This shows that ideally two compatible devices should be used to get the best results, but it is not always necessary.

Acronyms

CTS Clear to send.
DCD Data carrier detect.
DCE Data circuit equipment.
DSR Data set ready.
DTE Data terminal equipment.
DTR Data terminal ready.
RTS Request to send.
XOFF Transmit on.
XON Transmit off