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?

  • 3
    I'm not sure it's even a "protocol", it's just all the logical possibilities, except that you could perhaps use only six bits. Actually you mention 5-8, but I have never seen 5 or 6 I think.
    – Tomas By
    May 29, 2023 at 22:46
  • 2
    Teletypes, such as ASR-33, used asynchronous protocols over current loop before RS232. May 29, 2023 at 22:47
  • 4
    @TomasBy It's clearly a protocol: there's a lot more to it than just how many bits you use for data. Note that I specify at least five different things that all must be done correctly for the communications to work. If you do something like leave out framing bits, add framing bits, reverse the order of bits in the word or idle at space instead of mark, you will fail to communicate with a counterparty following this protocol.
    – cjs
    May 29, 2023 at 22:48
  • 4
    @TomasBy Except it's not. It's perfectly reasonable, for example, to send bits MSb to LSb instead of LSb to MSb; both are equally useful. Yet only one of these is part of this protocol; the other would be a different protocol (and one not directly supported by typical UARTs).
    – cjs
    May 29, 2023 at 22:58
  • 4
    @TomasBy, it's beyond question a defined protocol and one of the longest-established communications protocols in common use in electronics engineering. It meets a de facto standard (not aware of a single written standard but that's just me) met by manufacturers and designers in a a huge number of places: IC manfs for microcontrollers/UARTs, software bit-banging implementations and HDL implementations for FPGA/CPLD/ASIC. Developers design against this long and reliably-established protocol to communicate: with no knowledge of the implementation in the other device, only its protocol settings.
    – TonyM
    May 30, 2023 at 11:27

4 Answers 4


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.

  • 1
    See this very interesting page - "History Of Teletype Development" - which points to this patent "ELECTRIC SELECTIVE SYSTEM" US 1,286,351. You'll look in vain for any "waveform diagram" of the type we're used to - and it's pretty hard to find the start/stop synchronization mechanism in the lengthy wall-of-text, but it's there. Also note the nice drawings of wire-wound bobbins for the relays and a single teletypwriter key itself - you don't see those symbols on too many patents these days ...
    – davidbak
    May 30, 2023 at 14:57
  • An interesting feature of early telegraphs is that they were powered from batteries that would degrade with time whether or not current was being drawn from them, and a telegraph line would have many stations wired in series, with each station having a key and a bypass switch. Whenever a station wasn't being used for transmission, the bypass switch would be closed, and when no stations were being used current would flow continuously in the line.
    – supercat
    May 30, 2023 at 19:43
  • 1
    Thus, the idea that the line idles while carrying current, and an entity that wants to transmit will break the current, then start sending information using a contact closure to signal activity, and then go back to having the idle line carry current again, goes back well before automated alphanumeric teleprinters.
    – supercat
    May 30, 2023 at 19:45

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).

  • 4
    Stop bit is also important for synchronization. Otherwise transmitting 0x00 would have no transitions and the clock phase would drift.
    – jpa
    May 30, 2023 at 8:51
  • 2
    @jpa "transmitting 0x00 would have no transitions" --> More like: the start bit itself is a transition. Stop bit (at least 0.5 of a stop bit) is important for synchronization to cope with a sending rate slightly above the receiving sample rate. Synchronization happens with the start bit edge. May 30, 2023 at 15:10
  • @chux-ReinstateMonica The start bit can't be a transition unless the stop bit is the opposite voltage polarity and is (required to be) present. It takes both the stop and start bits to guarantee a transition.
    – Sotto Voce
    May 30, 2023 at 18:36
  • 3
    @SottoVoce Yes a stop bit is needed when there is scant idle time between data "bytes" and data's MSbit is zero. Recall the idle condition is the same level as a stop bit. IAC, the stop bit does not time the synchronization. Sync is due to the start bit edge, which is ready to to be detected as soon as just after the 0.5 the stop bit. In essence a stop bit is simply a minimum idle time after the data. May 30, 2023 at 19:02
  • And that's how "one and half bits" is not a weird thing, it's just a length of time.
    – dave
    May 30, 2023 at 20:51

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

  • 2
    It describes the "ability of most" UARTs because they conform to that protocol. You could just as well (on RS-232 or many other interfaces) use an FM- or MFM-like scheme with a start sequence that determines the rate, as well as when the receiver should start its clock.
    – cjs
    May 29, 2023 at 23:07
  • 3
    "Which is the basic definition of an inactive/broken line. No. An inactive line on RS-232, for example, is neither marking nor spacing, and a broken line could be doing that, or just spacing, neither of which is a break signal.
    – cjs
    May 29, 2023 at 23:07
  • @cjs A protocol needs to define on format that can be understood by both sides, wouldn't it? different word sizes in the same protocol are simply not fulfilling that . Also, a to detect a broken line with other than space would require additional electronics. Traditionally (TTY) a broken line IS space. (also it's not a series of spaces, but a continuous one) P.S.: Would be helpful to keep your anger level down instead of flooding multiple comments within the same minute, wouldn't it.
    – Raffzahn
    May 29, 2023 at 23:10
  • 4
    Sorry about using two separate comments for two separate topics; I will try to keep in mind that you prefer me to mix topics in one comment (and one paragraph, since comments can have only one paragraph). A protocol offering options from a limited palette (such as seven or eight bit words) does not suddenly become "not a protocol" because it does that. You'll note that other things within the protocol are quite fixed with no choices, such as mark for idle, a single start bit and the order of bits.
    – cjs
    May 29, 2023 at 23:15
  • 1
    "Due the lack of dedicated clock signals" Not true. RS232 provides for both transmit and receive synchronous clocks, which are required for some protocols. Some modems worked with them, of the sort you'd need for X.25 for example. There is a VAST amount of serial connectivity out there via RS232, with all degrees of incompatibility possible. The miracle was ever getting two pieces of equipment to talk together reliably.
    – jimc
    May 30, 2023 at 17:52

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.

  • 3
    Most of what was sent was human readable text. Nothing in the RS232 spec would indicate that. Plenty of binary file transfers took place over RS232 connections. As far as XON/XOFF - most communications programs I worked with nominally supported both software (XON/XOFF) and hardware handshaking. The problem is that few did any handshaking very effectively compared to pure hardware solutions. May 30, 2023 at 14:11
  • 2
    I believe the negative votes are because this does not answer the question what protocol is commonly used to send data over RS-232 interface.
    – Justme
    May 30, 2023 at 16:38
  • 3
    There are too many errors in this answer to list.
    – Chenmunka
    May 31, 2023 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .