UART Transmitter and Receiver Synchronize Timing

[EVblog1]

I am trying to understand how the sender and receiver react to each other in UART communication.

As I understand it, when we send data through UART, we follow a frame format. The first bit is the start bit, which is used to indicate the beginning of communication. After that come the data bits, whose number depends on the configured frame format. Next is the parity bit (optional), which can be used to detect a single-bit error, followed by the stop bit.

I believe that the UART line remains high when it is idle. When the sender wants to transmit data, it pulls the line low, creating the start bit. The receiver detects this transition and understands that communication has started.

What I do not fully understand is the timing relationship between the sender and receiver.  For example, if the baud rate is 9600, how do the transmitter and receiver stay synchronized? How does the receiver know when to sample each data bit after detecting the start bit?

At what exact time does the sender pull the line low, and at what time does the receiver sample or read the line? There must be some timing period that both sides follow.

[pqass]

What I do not fully understand is the timing relationship between the sender and receiver.  For example, if the baud rate is 9600, how do the transmitter and receiver stay synchronized? How does the receiver know when to sample each data bit after detecting the start bit?

At what exact time does the sender pull the line low, and at what time does the receiver sample or read the line? There must be some timing period that both sides follow.

Separate clocks in the sender and receiver run at a multiple of their baud; eg 16 times.
So the receiver just counts 8 clocks after a start bit is detected and then samples subsequent bits 16 clocks later.
If the two clocks are off by a couple of percent, the accumulated error (over 10 bits) is still within spec by the stop bit. 
Then the clocks are resynchronized on the next start bit.

The sender can pull the line low anytime after the last stop bit interval. There is no coordination between sender and receiver.

See here.

[Peabody]

The whole point of uArt communications is that it's Asynchronous.  There is no clock signal, but both sides have agreed what the baud rate is, which defines how long a bit period lasts.  So once the beginning of the start bit is detected, the receiver knows how long to wait to sample the line at the midpoint of the first data bit period.  It will wait 1.5 bit periods to read at the middle of the first bit, then one bit period later for the next bit, and so on until the end of the byte.  Then it will read again to make sure the stop bit is right and there is no framing error.  The next byte can start at any time, but once started, it has to follow the timing dictated by the baud rate.  And since each byte starts a new timing sequence, there are no cumulative errors beyond one byte, so the transmitter and receiver clocks can vary a bit and it will still work.

[langwadt]

receiver and transmitter both have to be told to run at 9600 baud so they know how long a bit period is.

The stop (and idle) bit is high so the startbit will always start with a high to low edge

When the receiver is waiting for a frame and see the line go from high to low it knows that is the beginning of the startbit, so one and a half bit period later is the middle of the first data bit, one bit period later the middle of the second bit, and so on until the stopbit where it can start to look for a startbit again 

[HwAoRrDk]

The asynchronous nature of clocking is also why, as baud rates increase, it's more important for each side to have an accurate clock. If one side's clock is, for example, 5% off compared to the other, then you may have problems.

So when you want your microcontroller UART to transmit and receive at 1Mbps, you probably won't be able to get away with using the internal RC oscillator, and instead need to use an external crystal.

[ledtester]

Here's a discrete implementation of a UART which might prove helpful:

https://shepherdingelectrons.blogspot.com/2020/07/uart-transceiver-for-breadboard-computer.html

[PCB.Wiz]

What I do not fully understand is the timing relationship between the sender and receiver.  For example, if the baud rate is 9600, how do the transmitter and receiver stay synchronized? How does the receiver know when to sample each data bit after detecting the start bit?
At what exact time does the sender pull the line low, and at what time does the receiver sample or read the line? There must be some timing period that both sides follow.

You are very close to answering your own question.
Get the data on any UART and read the description. Older model data sheets tend to be more verbose in the explanations.
Or, just use a pencil and paper to work out what happens.

Most common are higher clocks of 16x or 8x desired Baud, and a simple RX sampling counter is re-set/started by the start edge.

For a deeper dive, you can lookup low power UARTS that take extra effort to manage 9600 baud from 32.768kHz sub clocks.  (3.41333'x)

[EVblog1]

I am a bit confused because some member say that a clock signal is involved, while others say that UART does not share a clock. What actually happens?

How do the sender and receiver know that it is the correct time to transmit or sample a bit if there is no shared clock line between them?

From my understanding, the baud rate defines how many bits can be transmitted per second. For example, a baud rate of 9600 means that the transmitter can send 9600 bits per second.

What I am trying to understand is how the transmitter and receiver stay synchronized. If UART does not use a shared clock signal, how does the receiver know when to read each bit after detecting the start bit?

[ledtester]

The sender and receiver maintain their own counters that run at 16 times the baud rate. Of course, they are probably not in sync with each other.

When the receiver sees the start bit it resets its counter so that it is now in phase more or less with the sender's counter.

Running the clock at 16 times the baud rate allows the receiver to sample each bit near the middle of the sent bit -- i.e. when the receiver's counter mod 16 equals 8.

In short, when the receiver sees the start bit it knows exactly when each of the data bits will arrive and it samples the RX line at those times.

For instance, at 9600 baud each bit takes up 104 microseconds.

Here is some pseudo-Arduino code which receives a byte:

Code: [Select]

byte bits[8];

while (!digitalRead(UART_RX));   // wait for the start bit
delayMicroseconds(156);           // skip the start bit and half of one bit period
bit[0] = digitalRead(UART_RX); // read bit 0
delayMicroseconds(104);
bit[1] = digitalRead(UART_RX); // read bit 1
delayMicroseconds(104);
bit[2] = digitalRead(UART_RX); // read bit 2
...
delayMicroseconds(104);
bit[7] = digitalRead(UART_RX); // read bit 7
...

(This code assumes we are reading TTL level serial signals.)

[David Hess]

What I do not fully understand is the timing relationship between the sender and receiver.  For example, if the baud rate is 9600, how do the transmitter and receiver stay synchronized? How does the receiver know when to sample each data bit after detecting the start bit?

The baud rate is only the rate of signalling.  Internally the UART receiver samples at multiple times the baud rate so that it properly aligns on the start bit, and then it knows the timing of the remaining bits.  The receiver aligns on each start bit as they come in.

More advanced receivers sample each data bit multiple times so that they can better reject noise.

At what exact time does the sender pull the line low, and at what time does the receiver sample or read the line? There must be some timing period that both sides follow.

Both sides have an asynchronous clock which only has to be accurate enough for one entire character.  The transmitter can start a character at any time, and the receiver uses the start bit to synchronize for the duration of the character.

Some UART implementations allow for an external strobe to determine the first edge of the start bit which allows for exact timing to be transferred across the link, but this does not interfere with the accuracy of the character transmitted across the link because it only tweaks the timing of the start bit by an insignificant amount.

[amyk]

More advanced receivers sample each data bit multiple times so that they can better reject noise.

Some also use the bit transitions to fine-adjust their receive clock.

[PCB.Wiz]

If UART does not use a shared clock signal, how does the receiver know when to read each bit after detecting the start bit?

They do not need to share a common clock, but they do share the same baud rate.
The RX side is a simple state machine, that flips after the stop bit centre, to wait for a falling edge.
That falling edge typically preloads a /16 counter to 8, which then overflows in the middle of every following bit. ( at Baud*16 ticks of 8,24,40... )
A check at 8 ticks can verify the start bit is not a noise glitch, but has a significant width.
Some designs sample multiple times, very close to the centre bit time, and take a vote

[EVblog1]

I think I understand it now. When the sender transmits a bit (0 or 1), it holds the line at that logic level for approximately 104 µs at a baud rate of 9600.

When the receiver detects the falling edge of the start bit, it does not immediately read the data. Instead, it waits for about half of a bit period (approximately 52 µs) and samples the start bit near its center to confirm that it is valid.

After that, the receiver samples the line every 104 µs to read the data bits, typically near the center of each bit period where the signal is most stable.

[David Hess]

I am a bit confused because some member say that a clock signal is involved, while others say that UART does not share a clock. What actually happens?

Each UART has a clock, which could be shared, but is usually independent.  This means that each UART runs at a slightly different frequency unless they share a clock.

How do the sender and receiver know that it is the correct time to transmit or sample a bit if there is no shared clock line between them?

The sender can start transmitting at any time.  The receiver uses the start bit to start timing for reception of the data bits using its local clock.  Since the data is short, only one character, timing error from the two clock frequencies does not have enough time to accumulate to the point where it would cause errors.

What I am trying to understand is how the transmitter and receiver stay synchronized. If UART does not use a shared clock signal, how does the receiver know when to read each bit after detecting the start bit?

Timing starts with the reception of the start bit.  Since the character is only like 10 bits long, there is not enough time for the difference in the clock frequencies to cause errors.

[EVblog1]

My understanding is that when even parity is configured on both the sender and receiver, the sender counts the number of 1s in the 8 data bits. If the count is even, it sends a parity bit of 0. If the count is odd, it sends a parity bit of 1 so that the total number of 1s becomes even.

The receiver receives the 8 data bits and the parity bit, then performs the same parity check. If the total number of 1s in the received data and parity bit is not even, it sets the parity error flag.

[SteveThackery]

So just to add: the receiving UART synchronises itself to the sending UART by counting the time from the leading edge of the start bit. They then free-run as the rest of the character is transmitted/received.

[SiliconWizard]

When the receiver detects the falling edge of the start bit, it does not immediately read the data. Instead, it waits for about half of a bit period (approximately 52 µs) and samples the start bit near its center to confirm that it is valid.

After that, the receiver samples the line every 104 µs to read the data bits, typically near the center of each bit period where the signal is most stable.

Many actual implementations take several samples around the center rather than just one (and then just use some kind of majority voting), which is why an oversampling of 8 or 16 are common.

[SteveThackery]

Many actual implementations take several samples around the center rather than just one (and then just use some kind of majority voting), which is why an oversampling of 8 or 16 are common.

Yes, absolutely. To be fair, I think the previous replies were attempting to explain the basic principle of asynchronous communication. The "oversampling" is an implementation method. I don't think the early UARTs used it.

[ejeffrey]

All this is why UART is limited to ~10 bits per frame.  UART is a fairly old standard and designed to have modest hardware requirements.  It doesn't require super accurate clocks, only within a couple percent so it can be implemented with a cheap oscillator.  You need to make sure that during 1 byte the receiver clock won't skew more than 0.5 bit or you can get errors.  If the signal has more transitions you can lock onto them, but the worst case is determining the difference between 0xFF and 0xFE or 0xFF and a framing error with an invalid stop bit.

Limiting the byte size forces a start transition often enough to keep the receivers state machine in sync.  This is a generic problem in any asynchronous communication but there are many different solutions to it.  Most other asynchronous protocols allow longer messages, usually by forcing a minimum density of transitions so that the receiver can continuously re-synchronize.

[mikerj]

The asynchronous nature of clocking is also why, as baud rates increase, it's more important for each side to have an accurate clock. If one side's clock is, for example, 5% off compared to the other, then you may have problems.

So when you want your microcontroller UART to transmit and receive at 1Mbps, you probably won't be able to get away with using the internal RC oscillator, and instead need to use an external crystal.

This isn't quite true; the baud rate doesn't determine how well matched the TX and RX clocks need to be, rather the number of bits in a frame (error accumulation) and the slew rate on bit transitions and/or ringing (narrows the period where data can be sampled) are the primary contributors. For a standard 10 bit frame 3.75% is the maximum before errors will definitely occur with an otherwise perfect link, but the target should be under 2% for reliable comms, and if RC oscillators are used for clocks temperature effects can eat into this quite quickly.

[ejeffrey]

There is a separate problem at high baud rate where the linited divider choices may prevent you from hitting the target baud rate exactly.  For instance with a 40 MHz device clock and 16x oversampling you can't hit 115200 bps exactly.  It will have to use a clock divider of 22 to get 113,636 which is already 1.5% off. 

[langwadt]

There is a separate problem at high baud rate where the linited divider choices may prevent you from hitting the target baud rate exactly.  For instance with a 40 MHz device clock and 16x oversampling you can't hit 115200 bps exactly.  It will have to use a clock divider of 22 to get 113,636 which is already 1.5% off.

a few percent off should still be ok. The limited divider choice must be a left over from back when the size of an accumulator vs. a counter made a difference

[westfw]

For a standard 10 bit frame 3.75% is the maximum

How do you figure?  To drift from "the center of a bit" to "the next bit" would take an error of 0.5 bit time, or 5% clock difference over 10 bits...  (assumes infinite slew rate, but ... we're not including that in out "theoretical max", right?)

Also, it'd be slight more than that, since most implementations don't care much about the length of the stop bit...
(Of course, the real danger is when your transmitted and receiver are "off" in opposite directions, reducing your allowable error to ~2.5% on each side. (it's also worth remembering that at least one side is likely to be very accurate, with crystal or USB-synced clock in 0.1% range.) (and finally, you can run into situations where there transmitter and receiver have similar implementations and similar "inherent" errors in the same direction.  (Check out the hacks that Arduino uses to achieve "57600bps"))

[Andy Chee]

As a thought experiment to test your understanding of asynchronous reception, it might help to exaggerate and work through a hypothetical 256,N,1 format as opposed to the common 8,N,1 format. 

Have a think about how much difference is tolerable between the transmitter clock and receiver clock in order to receive all 256 bits correctly.  Think about the temperature effects and component tolerances.

Even if the receiver sampled exactly in the middle of the bit at the beginning, by the time the 256th bit needs to be sampled, the receiver clock may well have drifted out of sync.