At work we have a lot of devices, routers, switches etc., that still have and need a console port for their initial configuration and for recovery in case of a crash. This technology from the 60's is still around today and I recently got interested in it after we needed a console server to manage all of these devices remotely.
What are we talking about in the first place, you may ask. RS232 is a serial protocol developed in the 60's primarily to allow communication between computers and modems. This is extremely evident in some of his control signals (I'm talking about you, ring indicator) but we are getting ahead of ourselves. While old ...very old... it is still widely used in the industrial and telco markets for its simplicity and reliability. Many routers, switches or industrial machinery lack any kind of video output and, considering they only have to send textual information, this is still a good solution.
The spec
As one can imagine considering the age, the protocol and spec are pretty simple but due to the fact that some parts are essentially abandoned and others were seldom used even back in the day, it can be a bit confusing.
While the spec mandated for a DB25 connector, by the 80's it was almost always replaced with a DB9 reducing the number of lines and signals. Modern day RS232 uses RJ45 connectors but the carried signals are the same as it's DB9 counterpart.
Electrical Characteristics
All signals are in the range of -15V to -3V for high level and +3V to +15V for low level (Yes, negative voltage too. Yes, the signals and the logic are inverted). The closer the signal is to ±15 the better for reliability, especially at longer distances. Between -3V and +3V we are in a transition region and no signal is valid.
All data transfers are serial (one bit after the other) and they are sent one byte at a time least significant bit first.
Here is an example transmission:
As no clock line is used to synchronize sender and receiver, between every packet there is a moment of silence and a fixed start bit used to mark the beginning of the transmission to avoid drifting.
Next comes the data bits LSB first followed by an optional parity bit. This is a very crude error correction technique.
At the end of every packet there is a final mandatory end bit to signal the end of the transmission and another moment of silence.
While some parts are fixed like the start and end bits others are configurable. The parity can be omitted or calculated in different ways and the pause can be longer or shorter.
Signals
While strictly speaking only 3 lines are mandatory (in what is known as a null-modem configuration) the full 9 lines are the following:
| Symbol | Name | Use |
|---|---|---|
| DTR | Data Terminal Ready | DTE is ready to receive, initiate, or continue a call |
| DCD | Data Carrier Detect | DCE is receiving a carrier from a remote DCE |
| DSR | Data Set Ready | DCE is ready to receive and send data |
| RI | Ring Indicator | DCE has detected an incoming ring signal on the telephone line |
| RTS | Request To Send | DTE requests the DCE prepare to transmit data |
| RTR | Ready To Receive | DTE is ready to receive data from DCE. If in use, RTS is assumed to be always asserted |
| CTS | Clear To Send | DCE is ready to accept data from the DTE |
| TxD | Transmitted Data | Carries data from DTE to DCE |
| RxD | Received Data | Carries data from DCE to DTE |
| GND | Common Ground | Zero voltage reference for all of the above |
| PG | Protective Ground | Connected to chassis ground |
RI and DCD are extremely specific to modems and are never used nowadays.
DTR, DSR, RTS, RTR and CTS are optional and only used when hardware flow control il required.
Flow Control
Today it's very hard to overwhelm a device via RS232 but back when it was introduced this was a very common occurrence. To avoid the sender from overflowing the receiver's buffer there was the need for the receiver to pause the communication before losing data. This procedure is known as flow control and is common in many different protocols even the most modern ones.
The specification allows two ways of doing it. The first and the older uses specialized signal lines. It's more robust but it requires many more cables. The second one sends special commands over the existing Tx and Rx lines.
Hardware Flow Control RTS/CTS
This is the oldest version of flow control and has been part of the standard since the beginning. While it requires more cables, it is very robust and still supported even by the Linux kernel.
It was introduced in its original form to be used with devices that could not receive and transmit at the same time and needed a sort of handshake to resynchronize each other before every transmission. By the 1980's all devices were bidirectional and the signals were redefined and simplified transforming them in what is known as RTS/CTS Flow Control.
In this scenario the DTE asserts the RTS line whenever it is ready to receive data from the DCE and the DCE asserts CTS whenever it is ready to receive data from the DTE. The two signals are independent to each other and only the corresponding side of the channel is affected. While the RTS was kept for historical reason, thinking it as RTR or Read To Receive makes everything clearer.
Software Flow Control XON/XOFF
This kind of flow control removed the extra signaling wires in favor of an in-band solution. When a receiver wants to pause the transmission it can send the ASCII character XOFF on his Tx line just like any other one. Subsequently the XON character instructs the sender to restart the transmission.
This solution has the benefits of removing two of the electrical conductors but is not without its flaws. The signal can easily be delays as it generally is processed in the same queue as the other data adding unwanted delay while hardware signals are normally enacted immediately.
While this techniques are very useful and were once widely used, many modern devices especially in the telco sector ignore both kind of controls. Cisco, Juniper, Arista, Brocade all ignore it.
Speed
Because RS232 does not feature a clock signal must agree on the transmission speed beforehand. The specification does not mandate any precise speed and thus it's generally limited but the hardware at both sides, the noise in the environment and the length of the transmission line.
That said there are some common and industry accepted "standard" speeds that most devices support. The most common are 9600 and 115200. Faster speeds are possible with modern hardware but they are rarer and support is hit or miss especially with cheap adapters.
The speed is generally measured in bauds representing the number of times the signal changes state per second. Considering that the RS232 signal has only two states, its equivalent to one bit per second.