The questions are at the bottom of the post.

I understand that there are a lot of sources of timing errors inherited in UART communications. The magnitude of these errors is what limits the difference between the receiver and the transmitter buade rate frequencies that the receiver can tolerate and still be able to receive the data correctly.

The only source of error that i couldn't (completely) grasp, was the START bit error or as it's sometimes called "send/receive jitter". Well, I was first introduced to this error when i was reading an application note published by Maxim, titled
"Determining Clock Accuracy Requirements for UART Communications"

this a a photo of the section that discusses the START bit error in Maxim App note: 06 From that app note, I can understand that the receiver clock is started when the UART is intialized. When the falling edge of a START bit is detected, the receiver clock could be at just any point in its cycle and doesn't have to be at exactly its rising edge when the start bit falling edge occurs. So why should we care? well, though I don't know why it has to be so, but the UART receiver will only start counting its clock cycles, on the next rising edge of its clock after detecting the falling edge of a START bit. That means that if the falling edge of a START bit occurred at any moment in the clock cycle rather at its rising edge, the receiver will wait until the next rising edge of its clock occurs, and then starts counting its clock cycles.

That will definitely introduce a phase error which will in effect shift the point at which the receiver takes sample(s) of the data by some unknown amount, provided that the falling edge of the START bit didn't occur at exactly the rising edge of the receiver clock.

Now if we want to know the limit of this delay between starting the count of the clock cycles and the detection of the falling edge of the START bit, we need to analyze two cases:

1- The falling edge of the START bit could occur just after a receiver clock rising edge. In that case, the point at which the receiver samples the data line (ideally, the center of each bit in the frame) will be delayed in time (i.e after the center) by an amount no longer than one receiver clock cycle period (i.e +1) as it's illustrated in the figure below. 01
So far so good, now here comes the part where things start making no sense for me.
2- The falling edge could, alternatively, occur just before the clock rising edge. In that case either the rising edge will have enough setup time to detect the low state of the start bit and then it will be related to the first case (i.e maximum delay of +1) so the receiver won't wait for the next rising edge and will start counting the clock cycles at this current rising edge, or, alternatively, the rising edge won't have enough setup time to detect the start bit low state and in that case the receiver will ignore this rising edge and start counting clock cycles at the next rising edge, so this will cause the receiver to sample the data line at a point off the center of each bit in the frame by a maximum amount of (one receiver clock cycle time + the clock setup time) , right? because that's how I undestand it. The figure below just explains every thing. #04.bmb#

Well in the above app note, it doesn't say so about case No.#2, where the falling edge occurs just before the clock rising edge but not with enough setup time to use it, Instead it says that the sampling point will occur (before) the center of each bit in the frame by a maximum amount of one receiver clock period (i.e -1)!!

To me, this doesn't make sense at all. because my understanding is that for the sampling point to occur (before) the center of each bit in the frame, the receiver will have to start counting its clock cycles (before) it detects the falling edge of the START bit, so that it will finish counting 4 clock cycles (if it's 8x) or 8 clock cycles(if it's 16x) before reaching the center of the START bit, which doesn't make any sense!
the figure below illustrates my point.

The -1 error in this app note created some confusion for me, so I started looking for other app notes that discuss anything related to the start bit error or the send/receive jitter hoping that i come across one that explains this error in a little more detail than Maxim's.

My research has came up with one paper and one application note from STMicroelectronics. Unfortunately, the two didn't help me much, they just mention that the delay in general ( they don't say anything about what will happen when the START bit falling edge will occur before or after a receiver clock rising edge) will be the interval time of two subsequent buade rate clock ticks for the transmitter, and two subsequent receiver clock ticks for the receiver.

this a photo of the section that discusses the START bit error in the paper: #13476032643_1_4_JISC.PNG#

and this one from STMicroelectronics app note (page 16): #CD00105092.PNG#

I guess what they mean by "the interval time of two subsequent clock ticks", is one clock period, right?

One last thing, I always thought that (all) UART tranceivers synchronize or align their receivers clock with the incoming data by waiting for the next rising edge after detecting the falling edge of the START bit( provided that the falling edge didn't occur at exactly a rising edge of the receiver clock), until I read this lecture from Silicon Labs, titled " Serial Communication". In that lecture, they mention a different method to align the receivers clock with the incoming data by resetting the receiver clock once the falling edge of the START bit is detected .
Here's a picture from Silicon Labs lecture (page 8) that illustrates this method of synchronization #Serial_Communications.PNG#
I quote:

"The example above shows (one way) for devices to align their internal clock with the incoming data. Once the start bit is received then the clock system restarts its count sequence allowing for the clock edges to line up according to the bit time specified"

I have Three questions here:

1- why in Maxim's method of synchronization, the receiver has to wait for the next rising edge if the falling edge didn't occur at exactly the moment of a rising edge in the receiver clock? I mean why does it have to be so? why not just start counting clock cycles at the moment the falling edge of the START bit occurs? does this have something to do with the way sequential logic works in general or it is just a design thing? I mean why wouldn't be there a circuit that starts a clock once a falling edge is detected and then counts its clock cycles?

2- If Silicon Labs method of synchronization seems like it doesn't introduce any START bit error, why it's not widely adopted by other companies that design UART modules?

3- I understand why there's a +1 start bit clock cycle error, but I just can't understand why there's -1 start bit clock cycle error, which is mentioned in an application note by Maxim.


6 Answers 6


Many (probably most) UART designs operate by dividing a system clock by some value to yield a rate which is some multiple of the desired baud rate (often 16x), and then only examining the state of the serial line once for each edge of that clock. For 9600 baud operation and 16x scaling, the clock period would be 6.5 microseconds. Since the system only looks at the receive line once every 6.5 microseconds, it can't tell when within the 6.5 microsecond window the falling edge occurred.

I would guess that the reason this design is so common is that it allows one programmable divider circuit to be used to set the baud rate for both transmission and reception; the transmitter and receiver will need separate divide-by-16 counters, but a fixed divide-by-16 circuit is a fair bit simpler than a programmable one. I would guess that 16 is the preferred divide ratio because power-of two ratios are a little easier to implement than other ratios in discrete silicon, and 1/16-bit timing uncertainty was "good enough" but 1/8-bit wasn't. Crystals were manufactured to drive UARTs that were built from discrete logic using power-of-two scaling factors, and later integrated UARTs wanted to keep using the stock crystal frequencies that had been used with the UARTs that had been constructed from discrete logic. In fact, an odd-number divide ratio like 1/13 would probably been better than 1/16, since the window of uncertainty will be centered about each bit (rather than off to one side). A 1MHz clock divided by two and then by 13 would yield a baud rates of 38461.5 (about 0.2% above 38400); inserting additional divide-by-two stages would allow for slower baud rates.

I don't know why more UARTs don't have a separate baud-rate generator for the receiver which starts counting when the start bit arrives. The extra silicon cost would be by today's standards negligible. My guess would be that a lot of chip designers don't give UARTs much thought, since many of them have many other annoying quirks or misfeatures and provide no means of finding out useful things (such as whether the UART is presently in the process of receiving a byte, or whether a byte is currently being transmitted or received).


The start bit servers two purposes, to indicate a new character is being sent and to provide a timing reference for that character.

To explain why the UART protocol is what it is, let's start with a simple scheme, see why that doesn't work, then see how to modify it to make it work. You can start out trying to send data using a single signal by simply sending a high for a 1 and a low for a 0. You can dictate that the bit rate is known ahead of time, so the receiver knows how long each bit is. However, there are some problems with this. This is just a endless stream of bits. How does the receiver know how they are supposed to be packed into bytes? What happens when the transmitter has nothing to send? You only have two states, so how do you tell the difference between nothing and a long string of 0s, for example? What if there really is a long string of 0s or 1s, how do you make sure the receiver stays synchronized with the transmitter? There will inevitably be some mismatch between the two clocks, so for some long enough string of 1s or 0s the receiver will get out of sync.

One way to get around several of these problems is to keep the line at a idle level you arbitrarily pick, then require a single bit to the opposite level before sending new data. To know when data is over and the line is at idle instead of a long string of 0s, for example, you always send a finite number of bits after this initial start bit. Since there is now a start bit preceeding each fixed chunk of bits, you can re-sync the receiver clock to the leading edge of the start bit. Now the receiver clock only needs to be matched to the transmitter close enough to still know where the bits are at the end of the chunk.

This scheme implies one more bit per chunk. Since there has to be a transition at the start of the start bit, the line has to be in the opposite state immediately before the start bit. We can't have a start bit immediately follow the last data bit of the last chunk because there is no guarantee what level it might be. The solution is therefore to add a stop bit after the chunk of data bits.

So now for each chunk of bits, we have a start bit, some known number of data bits, and a stop bit. This is exactly how UART communication works. Usually the chunk size is 8 bits so that each chunk transfers one byte. This means each 8 bit byte takes 10 bit times to send. The extra 25% overhead is part of the cost of knowing where the byte boundaries are, allowing for dead time, and allowing for some finite clock mismatch.

For 8 bits/chunk, the worst case timing is from the start of the start bit to the middle of the last data bit, which is 8.5 bit times. Let's say we don't want to be off by more than 1/4 bit time (1/2 bit time is the guaranteed to fail limit) when sampling the last bit, so that is 1/4 bit in 8.5 bits, which is 2.9%. That is the acceptable clock mismatch between the transmitter and receiver using this scheme.

In practise, the clocks need to be a little tighter than that. Most UART imlementations use synchronous logic with a internal clock running at 16x the baud rate. That means there is up to 1/16 bit-time error in determining the start of the start bit. So the real error budget is 1/4 - 1/16 bit time in 8.5 bit times, which is 2.2%. A good rule of thumb is 2% for the normal 1 start bit, 8 data bits, and 1 stop bit protocol.

  • \$\begingroup\$ Thanks Olin for your reply. The thing is I am aware of most of what you've just said and still it didn't answer any of my questions, mainly the first one which is ; I totally get the +1 start bit error but not the -1 start bit error because it doesn't make sense and still it's mentioned in Maxim app note (i.e +-1 start bit error), how this -1 start bit error happens? \$\endgroup\$
    – Idmond
    Commented Nov 21, 2013 at 20:46
  • 4
    \$\begingroup\$ @Idmond: I answered your first question "What exactly is the start bit error in UART?". The rest was way too long to read. If you want a more specific answer, please be more concise. In any case, even if my answer doesn't tell you what you wanted to know, I hope it will help others understand the UART protocol and give some justification for why it is what it is. \$\endgroup\$ Commented Nov 21, 2013 at 20:55

2 uses: Time reference to deal with jitter and false start detection.

I see the first aspect is well covered by OP and various answers.
The leading edge of the start bit provides the a time reference for subsequent bit samples which nominally occur 0.5, 1.5, 2.5, 3.5 ... bit times after the start bit. Typically about this midpoint, multiple samples are made and conclude with majority voting. As the sending and receiving clock phases are not synchronized, any variance (jitter) can be compensated with a N times faster receiving clock - all to accomplish that sample near the mid-point. (Other schemes possible.)

2nd use, I did not see so far: False Start detection
As a spike of noise may falsely be considered a start of a start bit, the start bit itself is re-sampled, like following bits, near its middle, or 0.5 bit time after the leading edge. Should the candidate start bit not conform to the expected state, a typical UART will quietly reject it and begin looking immediately for a new candidate start bit.


I think you're reading to much into what Silicon Labs have said. I've just read it and it seems to me that what they are saying does not contradict with expectations for a UART designs. Their drawing showing the "Internal async clock" does-not imply that there isn't a higher frequency clock "behind" async clock.

The first "short" pulse you see (on the left) could be "hiding" behind a much higher frequency digital counter that resets every start edge. It could have resetted at count 5 of 16 (hence a short pulse) or count 320 of 1024 - they are just not showing this higher speed counter and I don't think you can assume it isn't there in the background.

  • \$\begingroup\$ Ok. I get that and I didn't think this is the real clock they're showing, but what i was asking was even if it was a 16x, 32x or whatever clock in the receiver, they obviously reset it when the falling edge of the start bit occur, so the beginning of the receiver clock cycle will almost align with the start bit falling edge, and that will almost eliminate the start bit error. right? unlike the the Maxim's method where the receiver has to wait a maximum of one clock cycle, so when the receiver comes to the sampling point, there will be a considerable shift from the middle of the bit.right? \$\endgroup\$
    – Idmond
    Commented Nov 21, 2013 at 21:07
  • 2
    \$\begingroup\$ They both have to wait up to one cycle - one cycle of the "top" clock may be a fraction of one thousandth of the data rate in which case waiting one cycle is hardly an issue. It becomes an issue when the "top" clock period is a significant fraction of the data symbol time. \$\endgroup\$
    – Andy aka
    Commented Nov 21, 2013 at 21:15

IMHO, there is no problem here, unless you need to know the timing of the character to more precision than a single bit time, which is a very unusual requirement.

All the appnotes are really saying is that they are attempting to sample the incoming data stream near the center of each bit cell so they avoid any transition noise or ringing that might be happening between bit cells. The generally accepted tolerances for baud rate require that the center point start out well centered so that in the worst case clock mismatch the sampling point of the last bit hasn't crept too close to either edge of the bit cell.

Using a 16x sampling clock exceeds that requirement, an 8x clock would not, and non powers of two divisor cost more transistors without adding any real value.

(Note that the async serial standards we follow today were invented with mechanical transmitters and receivers. No logic, just synchronous motors that commutated the signal. The start bit caused the receiver's motor to start turning, and it had to go from stationary to stable rate during that bit time. The contacts were placed so that they sampled at bit centers, and the last position on the cam was the stop bit which had to give the motor time to coast into the stopped position. The commutator cam made a single revolution per character.)

In almost all async UART applications I've seen personally, it has rarely been necessary to know the timing of a character any more accurately than it came before the following character and after the preceeding character.

There have been some broadcast video applications where the start bit of the first character of a command packet had to have a specific timing relationship to the video it was controlling. With exactly 15.984 9600 baud character times per NTSC video field, you can see how that could arise. When it did arise, we occasionally had to build our one async serial transmitter (half a UART) just so that the start bit could be guaranteed to fall at the right spot.

I've also seen GPS systems where certain NMEA sentences emitted carry a timing guarantee for the start bit of the first character of the sentence compared to their 1Hz pulse per second output that is synchronized to internationally standardized time bases via the constellation of atomic clocks in orbit. If attempting to use that class of GPS receiver to synchronize time in your computer very precisely, then you might need to be able to detect the exact time of the start bit to better than 2 parts in 16x baud rate. There are open source hardware and software solutions to that problem, start reading about ntpd and you will find references.

  • 1
    \$\begingroup\$ In the mechanical implementations, the motors ran continuously, and the timing mechanics were driven through a clutch. This allowed the starting and stopping to occur instantly (well, "instantly" relative to mechanical things). \$\endgroup\$
    – gbarry
    Commented Apr 10, 2014 at 6:37

The Maxim appnote analyzes a bit in isolation, hence the +/-1 sample, which is correct given the possible clock skew between the transmitter and receiver.

When a bit is analyzed relative to the start-bit, samples can only be late if the send and receive clocks are exactly the same. If the send and receive clocks are not exactly the same, for example if the receive clock is slightly faster, a bit can be sampled before its mid-point.

Another exception being a false start-bit from line noise preceding the real start-bit. For one treatment of handling false start bits, see the 68HC11 reference manual; it is very detailed.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.