Start Bit vs Start Byte

Question

I know in a lot of asynchronous communication, the packet begins starts with a start bit.

But a start bit is just a 1 or 0. How do you differentiate a start bit from the end bit from the last packet?

Ex. If I choose my start bit to be 0 and my end bit to be 1. and I receive 0 (data stream A) 1 0 (data stream B) 1, what's there to stop me from assuming there is a data stream C which contains the same contents of "(data stream A) 1 0 (data stream B)" ?

Isn't it more convenient to have a start BYTE and then check the data stream for that combination of bits? That will reduce the possibility of a confusing between the start/end bit.

Solution 1

Great question! Most asynchronous communication also specifies a stop bit, which is the complement of the start bit, ensuring each new symbol begins with a stop-to-start transition.

Example: let's transmit the characters ABC, which are ASCII 65, 66, and 67:

A = 65 = 0x41 = 0100 0001
B = 66 = 0x42 = 0100 0010
C = 67 = 0x43 = 0100 0011

Let's also assume (arbitrarily) that the start bit is 0 and the stop bit is 1, and the data is transmitted from MSB to LSB. The transmitter will be in the stop (1) state when no data is transmitted. So the receiver might see this:

Data:   ....1111 0010000011 111 0010000101 0010000111 11111....
         (quiet) ^   A    $     ^    B   $ ^    C   $ (quiet)

With apologies for the ASCII graphics, the data consists of a series of stop (1) bits while the channel is idle. When the transmitter is ready to send a character, it sends a start (0) bit (marked with ^), followed by the character code, and ending with a stop (1) bit (marked with $). It continues to send stop bits until the next character is transmitted, beginning with another start bit.

The reason we use start bits instead of bytes is efficiency. The scheme above requires 10 bits (1_start + 8_data + 1_stop) to transmit 8 bits of data, resulting in an overhead of (10 - 8) / 8 = 1/4 = 25%. If we used start and stop bytes, we'd need to transmit 3 bytes for each byte of data, which would be an overhead of (3 - 1)/1 = 2 = 200%. If the start, data, and stop bytes were each 8 bits, we'd have to transmit 24 bits instead of 10 for each character, so it would take almost 2 1/2 times as long to send the data!

Solution 2

One can always define a start byte as an indication that a message is beginning (and the ASCII SOH, STX, and ETX codes were intended for such purposes). However, the standard hardware and protocols for connection to data-transmission equipment (RS232C and later) operate at a lower level, and it is generally neither possible nor desirable to alter that arrangement (especially via software).

High performance synchronous data transmission schemes, such as those used on local-area networks and wide-area transmission systems do use elaborate frame markers. The frame marker is a distinct pattern of bits that never occurs in the stream for message data. There is typically a special rewriting rule that essentially "escapes" any in-data occurrence of a similar bit pattern so that transmission equipment will not see it as a frame marker. These escaped patterns are reconstructed by the recipient so the sender and receiver never have to pay attention to this. These arrangements make specialized hardware even more important, such as in the typical Network Interface Card (these days, motherboard chip) on personal computers.

BACKGROUND ON ASYNCHRONOUS SERIAL COMMUNICATION

It is useful to think of asynchronous serial transmissions as asynchronous between character/data frames and synchronous within the span of the character frame (including the start bits and initial stop/fill).

With this scheme, there is a constant fill signal between the frames and it is usually at least one data-bit wide, although some arrangements require a 1.5-bit or two-bit stop/fill. The stop "bit" uses the same signal level and can be considered the minimum fill period before another start bit will arrive.

When a frame is arriving, it is necessary to synchronize with the predetermined number of bits it is expected to carry. The transition from the fill to an opposite level signal is accomplished by the start bit which is always opposite to the stop/fill level. The sampling of the bits can be timed to happen in the middle of subsequent bit-arrival periods.

Technically, if frames were being sent at the maximum rate, it would not be necessary to send any stop/fill, proceeding to the start bit of the next frame immediately. However, counting on at least one bit worth of fill before the start-bit transition helps to keep the sender and receiver synchronized.

If you think of the asynchronous streams as being encoded from key depressions using a keyboard, you can see the importance of allowing arbitrary fill between character frames. Once it is known what frame to send next, it can be inserted immediately, with its start bit, at the agreed bit rate, after there has been at least one bit worth of preceding stop/fill.

It is also useful to notice that, in typical low-speed asynchronous transmissions, there are only two kinds of bits/levels, so the only way the presence of data as opposed to fill can be distinguished is by a marker scheme like this where the start of the frame is uniquelly detectable and the end of frame is predetermined (unless there is a more-sophisticated variable-length frame structure generally not used in asynchronous serial communication). It is actually rather difficult for a receiver to discover the bit rate of a transmitter without some additional agreement, such as looking for a recognizable data sequence from which one can estimate the bit rate which would have it arrive correctly when it arrives in incorrect form.

Even though high-speed modems now transmit complex analog signals that aren't described in terms of two simple signal levels, the RS232C (and later-mode) digital communication between a computer UART and the data coupling on the modem is pretty much as described.

High-speed modems also have additional capabilities for synchronizing with a distant end-point, as you can tell by listening to the signal audio while a connection starts up. In addition, There are separate signal lines in the serial cable to the computer that are used for pacing between the computer and the modem so that the sending party does not transmit new data frames faster than the receiving party (either computer or modem) can accept them. But a frame, once started, is always started at the agreed synchronous speed.

Wikipedia has a good description of asynchronous serial communication, what computer serial ports use.

There is a common over-simplification that suggests the stop bit determines the length of the data. That's not the case. The stop bit looks just like a level for another data bit. The way the stop bit and the period until the next start bit, are recognized is by knowing the bit rate at which in-frame data and start/stop bits are being transmitted and knowing how many bits a frame contains. Otherwise, there is no way to distinguish a stop bit from just another bit of that polarity as part of the data frame.

Comments

[Adam Liss]

You may be confusing start and stop bits with pacing characters, which are designed to delay transmission until the hardware "catches up" to it. Start and stop bits are strictly to synchronize the receiver with the transmitter, so it "looks" for each bit at the right time.

[Steve]

It seems like in your example that there is a "quiet"/idle phase. In a program, would I check for this with a timeout?

[user2522201]

I have never seen an implementation behave the way you describe, continually sending stop bits while the line is idle, that doesn't make any sense.

[Adam Liss]

I'm a hardware guy. If you check the voltage on the receive line of your PC's serial port, it will always be either at the 0 or 1 level (or rapidly transitioning between them). The point of the start bit is to force a transition from "stop" -- which is the same as "idle."

[Adam Liss]

@Steve: The hardware generally takes care of this for you. It sits idle until it detects a stop-to-start transition, then it clocks in the data, optionally performs some error-checking, sets a flag or generates an interrupt to indicate that data is available, and waits for the next start bit...

[Adam Liss]

... As a high-level programmer, you simply read the data when you get a signal that it's available, often in a loop until the HW tells you the data is exhausted, then do something else until the next data-ready signal.

[EvilTeach]

And I am leaving it as a warning to others.