What is the serial protocol commonly used over RS-232 (among other links) and where did it come from?

Question

The RS-232 standard (and ITU V.24 and V.28, which as I understand it are basically the same thing) specifies connectors (DB-25), electrical characteristics (-15 to -5/-3 V for "mark," +3/+5 to +15 V for "space"), signal wires (ground, TX, RX, etc.) and "hardware" flow control (DTR/DSR, etc.), but does not specify any standard for the serial protocol used over the connection, beyond limiting the bit rate to 20 kbps.

There's a standard protocol we use over these connections that's asynchronous (thus not needing any of the lines that RS-232 provides for synchronous protocols), sends marks at idle, starts a data word ("byte") with a space, sends the data bits of the word (5-8, usually) from least significant to most significant bit, optionally adds a parity bit, and ends the word with 1, 1.5 or 2 spaces. Additionally it defines a "break" signal as a relatively long (longer than a "byte") sequences of spaces.

Where did this serial protocol originate (I suspect that it predates RS-232), and what is it called? On what transmission systems was it originally used, and when did it start being used on RS-232?

Answer 1

The bit-serial protocol that is most often used to transfer data frames over RS-232 interface is simply called the "asynchronous start-stop protocol", a method that was patented already in 1916, and these days the circuit to serialize and deserialize these data frames is commonly called an UART, Universal Asynchronous Receiver Transmitter.

The protocol is really simple, but as it defines how each bit is sent with NRZ line code, how a multi-bit symbol is sent (LSB first), and how the symbol is framed with a logic zero start bit and logic one stop bit, it really is a protocol how to send asynchronous bit serial data frames.

The protocol has it's roots in the way how morse code evolved to telegraph and teleprinters, and how the use of Baudot code evolved into more generic format of asynchronous start stop protocol. There are various electromechanical ways of implementing the bit reception, but it is believed that the first digital circuitry to use sampling to receive bits was the line card on a PDP-1, and most UARTs as integrated ICs (such as the early WD1402A, SCN2651 or 8250) or embedded into a MCU still work similarly.

Some manufacturers did not call it an UART, but SCI for Serial Communication Interface or CIA for Communication Interface Adapter.

In any case, equipment already used serial comms, and even if they were protocol-wise adaptive enough to interface with each other, there was no standard for electrical interface and connector so that the equipment could have been just connected together, so the RS-232 standard filled that part and intentionally did not define any specific protocol to allowed any protocol between equipment.

Before RS-232 different equipment may have used different voltage levels that were simply incompatible or could cause damage unless adapted with external components. In addition to using voltage, current loop interfaces existed as well.

Answer 2

The framing protocol of 'start bit, data bits, stop bits' predates RS-232 and other voltage-based physical encodings. It was used, for example, on 20 mA current loop Teletype interfaces.

It is described in this 1931 Teletype model 14 printer manual, though I'm not claiming that Teletype Corp invented it.

Wikipedia says the form was used in pre-1930 devices, and 'derived directly from the design of the teletypewriter' - by which I understand it to mean that the start bit established synchronization, and the stop bit(s) provided recovery time for the mechanical components (like the rotating commutator in some teletypes).

Answer 3

Where did this serial protocol originate, and what is it called?

What is described in the second paragraph is not a "serial protocol", but a description of the abilities to form a transmission word of most integrated asynchrones serial units, not any specific protocol.

A protocol would include at lowest level the definition of a specific word format and work up from there.

On what transmission systems was it originally used,

Most prominent on teleprinters (tty).

While serial signals were already in use since the late 1800s, all transmission formats had to keep sender and receiver synchronized for a longer period, which became the main problem (*1). There were several proposals for automated resynchronisation using start/stop codes, but it wasn't until the early 1920s that the Morkrum-Kleinschmidt Company brought the first teleprinter operating on a word based synchronisation, that is using a fixed word size encapsulated by a start state and a stop state or in modern technical terms:

• 1 start bit
• 5 data bits
• No parity
• 1 stop bit

In 1928 Morkrum-Kleinschmidt changed their name to "Teletype Corporation" .. and the rest is well known history.

and when did it start being used on RS-232?

Right from the beginning. The whole purpose of RS-232 is to standardize serial communication connections past a simple 4 wire TTY. It defines the basic electric and signal standards for such. So it's rater natural to connect those devices which already used such formats based on this standard.

---

Further Reading

RS 232 defines a

• connector with
• signal lines and their
• signal level and
• relation between signal lines as well as
• subsets (configurations) used for certain application cases.

Due the lack of dedicated clock signals it's only for self clocking (including asynchronous) specified. It does not define any specific asynchronous word format, families of word formats or protocols using them.

There's a standard protocol we use over these connections that's asynchronous (thus not needing any of the lines that RS-232 provides for synchronous protocols),

Nonetheless it does not supersede any of the RS-232 lines. CA/CB/CC/CD are required by RS-232 to be operated, otherwise it's not an RS-232, but a non standard connection (*2).

sends marks at idle, starts a data word ("byte") with a space, sends the data bits of the word (5-8, usually) from least significant to most significant bit, optionally adds a parity bit, and ends the word with 1, 1.5 or 2 spaces.

This describes the ability of most integrated asynchronous serial units, not any specific protocol. If at all it can be called a basic asynchronous word structure.

Additionally it defines a "break" signal as a relatively long (longer than a "byte") sequences of spaces.

Which is the basic definition of an inactive/broken line.

On serial lines are not bytes but words. Also it's not a 'sequence' of spaces, but a continuous space, as any division would mean having a mark inbetween.

The whole 'continuous space' is a carry over from Teletype times where a space is equal to no current, which is what happens when the line is inoperable (for various reasons). While RS-232 woudl allow to detect this independently, applications continued to interpret this as a bad line for compatibility with teletype sections.

---

*1 - Early ticker systems had to stop operation after a certain time and literally send boys running around the city to reset all devices before restarting operation.

*2 - See section "Required Interchange Circuits for Standard Interface Types" of the linked document

Answer 4

RS232 was designed to connect Data Terminal devices (like CRT terminals like ADM 3A, VT05, VT52 and VT100 and Teletypes, although most of those use 20/40/60ma current loop or computers) to Data Set devices (modems). This is why there is a Ring signal wire (the phone is ringing). The bytes could be sent asynchronously or synchronously (bits within the byte were synchronous).

Most of what was sent was human readable text. Digital Equipment Corporation (DEC) used DDCMP while the Un*x world used SLIP. IBM also had a protocol.

The standard was severely bastardized when PC came along. The DB25 connector got replaced by a DB9. Some PCs were wired as Data Terminals and some as Data Sets (meaning Rx and Tx were flipped). Many ignored DSR and DTR as well as RTS/CTS.

DEC used XON/XOFF as a software flow control. Again, many PC terminal emulation programs (except Kermit) ignored this.