Start bits in asynchronous serial communications

Question

I understand synchronous serial communication conceptually but I'm having trouble with how asynchronous works. Specifically in this situation:

Let's say I want to send a byte: 0x03. We have a start and stop bit, which are low and high, respectively. How does the receiving device "know" that I'm sending a start bit followed by 6 0s? How does it know that that isn't just one long start bit?

Followup: what exactly is a UART? I'm asking what the common use is, as I've seen various places refer to it as a standard and others as a piece of hardware.

Answer 1

How does the receiving device "know" that I'm sending a start bit followed by 6 0s? How does it know that that isn't just one long start bit?

Because with this kind of communication, both the sender and receiver have to agree ahead of time on a few parameters. The two key parameters here are the baud rate and the number of data bits.

The line starts out in the idle level. The transmitter first sends the start bit, which is at the opposite level. It then sends the data bits, followed by the stop bit.

Unlike what others have said, the stop bit is not a checksum. It is required so that there is always a transition at the leading edge of the start bit. Otherwise, if the last data bit ov the previous character happened to be of the same polarity as a start bit, the receiver wouldn't be able to see the start bit if a new character was sent immediately. The stop bit is essentially enforced line idle time between characters. That time is also used to absorb some clock mismatch between the sender and receiver.

When idle, the receiver monitors the line looking for it to change to the non-idle state. When that happens, it starts a stopwatch. Since it is configured for the same bit rate as the transmitter, it knows when each data bit is sent, whether it differs from a previous bit or not. The middle of the first data bit is at 1½ bit times from the leading edge of the start bit. The second at 2½ bit times, etc.

After the last data bit is received, the receiver waits for the line to go back to the idle state, then waits for the next start bit again.

A UART is a device that does all this transmit and receive timing for you. You configure the UART for the baud rate you will use, the number of data bits, and a few other parameters. After that, you usually just give it full bytes and it takes care of chugging out the bits. For receiving, it detects the start bit, does the timing, grabs the bits, and gives you a byte on a silver platter, often with some additional optional status information.

Answer 2

Well it works like this. With Async communication, the receiving end usually must already know the baud rate, which is close enough to simply meaning "bits per second" for our discussion. So we have a "normal" or "at rest" state of the ground referenced communication line which will actually be the same state as the "stop" bit (this will make more sense in a minute).

Now if you, as a receiver, "know" what the speed (Baud or BPS) is expected to be, then you can arrange a circuit to be triggered when it senses a transition to a new state. Well, since this new state is the opposite of the "at rest" state, you now KNOW a byte is being transmitted. Next, since you "know" the speed, then you can calculate the time a bit should take to complete, right? So when the receiver detects this transition, it must wait 1-1/2 the time of a bit, and then look at the new state. The first "1" bit time to to wait until the "1" start bit completes, and the second "1/2" bit time is to ensure that when you look at the state of your first data bit, you are "sampling" right in the middle of that bit.

So at this point, your receiver would sample the state, store the bit in a shift register, wait another full bit time, sample the state again. At that point it would shift the last recorded bit by one position, and store the new bit. This process continues until a previously agreed number of bits has completed. (Probably 8, but it doesn't have to be!) At that point you have recorded the entire incoming byte (or word).

There may or may not be an additional "parity" bit, again depending on agreed parameters between the transmitter and receiver. If there is a parity bit, the shift/ sample process continues one more time. A simple calculation is then done to count the number of "1" bits in the recorded word and see if the total is odd or even, and compare the result to the detected parity bit. (not surprisingly, the correct answer depends on whether "odd" or "even" parity is the agreed format).

Now the "stop" bit is less of an exact science, which is why you sometimes see options for "stop" bits ranging from "1" (at minimum) up to 2, sometimes including a 1-1/2 as an option. The stop bit (or bits) is simply the amount of time the receiver is hoping to have to move the last byte into the buffer of bytes it is receiving, and be reset and ready to receive another byte. So this is why the "stop" bit is simply a return to the "at rest" state.

Finally, a UART (Universal asynchronous receiver and transmitter) is a circuit, often provided as a either separate part or as a built in feature to a microprocessor. It will usually allow you to program all those "expected" parameters, baud rate, start and stop bits, parity options, and is capable of handling that whole sequence of state detection, sampling, and a shift register to receive or send a byte. It also will have interesting features to allow you to control the bit sampling rate. Typically, a UART will also provide an interrupt and a program "vector", so that when a byte is received, the controlling processor can immediately respond and store the byte.

Finally, though you didn't ask, there is also USART devices, which basically offer all the features of a UART, but additionally add the capabilities needed for SYNCHRONUS communication.

Answer 3

Asynchronous communication relies of the baud rate being correct. The start bit tells the receiver to check the bit level every BIT time defined by the baud rate.

So the receiver is basically interrupted by the start bit and begins polling the signal line every bit time thereafter to received the subsequent bits.

The stop bit is like a checksum and also ensures a gap between each byte of data. It will expect to see that or those bits in a defined state. If not then an error condition is generated.

A UART, Universal Asynchronous Receiver/Transmitter, is the state machine hardware that encompasses all that functionality.

If you select a different baud rate or format than the receiver is expecting, then the communication will fail.

Answer 4

You are correct that there are patterns that look like a lot of start bits or stop bits. The stop to start is a known transition (as Olin pointed it the reason for the stop bit) but if data is moving at line rate and a receiver comes in the middle somewhere it may take many symbols before the receiver can find a stop to start bit transition that the agreed number of bits later ends in another stop bit. It is easy to create patterns that if you send repeatedly at line rate the receiver could be locking on the wrong stop to start transition and be decoding the data wrong. Parity bits help with this, but are not foolproof, only really solved by having the data vary over time or forcing idle periods every now and again.

If you have too many start bits in a row it is a "break" which is a framing error but a specific framing error that is sometimes used intentionally.

It is considered asynchronous in that each side has its own clock, the messages are short enough that you can be off by quite a bit and still extract the 8-10 or so bits. Typical uarts will have a 8 or 16 times oversample, so that say they are 8x over sampled, so there are 8 clock periods per bit time, and if the start edge is on say count 2 of the oversample then for the next so many bits you sample on count 6 which would be bid bit cell, you only have to be good for 10 or so bit cells. You could even have your logic adjust if there are transitions if it not all ones or all zeros and you get halfway through and you see an edge on count 1 instead of count 2 on your oversampling logic, then you could sample the next few cells on count 5 instead of 6 to fine tune the middle of the bit cell. Very typical for continuous data to keep adjusting, for serial when we typically have say 10 or 11 bits per symbol/character you can the source and receiver clocks be quite a bit off and still work well enough.

Answer 5

Other answers well explain the bit level sampling, yet I wanted to explain deeper the sub-bit activities and details about clock skew and phase.

---

how asynchronous works.

The sender and retriever agree on format: a frame of 1 start-bit, N data bits, optional parity and 1, 1.5 or 2 stop bits.

They agree on an approximate common communication rate like 1/115,200 seconds per "bit" or baud. Each side runs its own clock. The result is that the clocks may be slightly different from each other. Segal's law. In theory, about 10% difference is allowed, in practice, it is more like 5%.

Yet an important element the do not share is phase of the their clocks. Even if both sender and receiver had identical clock frequencies the phase relationship between the sender/receiver clocks is not controlled. With nearly identical clocks, this phase slowly shifts.

---

To cope with this phase difference, the receiver samples at a higher rate than the baud. Let us assume 16x faster.

A receiver wakes up to look at its input, which it is sampling at 16x baud. If input is not idle, it waits until the line is idle for a while.

Once the input is in the idle state (no data being sent), the receiver looks for a sample transition to the active state. Once this is detected, a good receiver also looks 1/2 bit time (8x samples) later for a continuing active state. If this is detected then a state bit is found and the phase (within 1/16 of a bit) is detected of incoming data. If not, the spurious signal is usually quietly ignored and the receiver rejects this as noise and begins again as above.

The next N samples, done at full bit width from the start bit 1/2 bit offset, assumes the line is data and the LSbit to MSbit is read.

Sometimes a parity bit is included.

Lastly the next 1 (or rarely 2) bits are sampled (in their middle) and should be in the idle state. If not, the frame received is said to have a stop bit error or frame error. A long start bit is a special framing error called a break.

After the last stop bit is sampled, near its middle, the receiver is immediately ready for another start bit. This allows the sender and receiver's clocks to be up to about 5-10% off from each other and communication succeeds.

How does the receiving device "know" that I'm sending a start bit followed by 6 0s?

In OP's case, sending x03 or b0000-0011, after the line has been idle (1-1-1-1-... state) for a while and the receiver is ready, the sender outputs a start 0, 1-1-0-0-0-0-0-0, stop bit 1. The receiver detects the start bit, data and stop bit. Success!

---

Additional attributes, not covered, include over-sampling of data with a majority detect, break, parity details, higher level protocols, auto-baud detection, etc.