Jump to content
Sign in to follow this  

UART Baudrate Error Budget

Recommended Posts

I was reviewing a Cypress data sheet for the CYW4390 and saw a line in the UART chapter saying that the total baud rate error budget for both ends had to be less than 2%.  With a large dependence upon internal oscillators these days, it seemed a good time to discuss these error budgets.  Is 2% reasonable or conservative?

First here is a quick back of the envelope calculation for link budget for UARTS.  I will assume "perfect" rise & fall times, and 8, none, 1(8n1) framing.

There are a total of 10 bits in a byte with 8n1 so each bit is 10% of the total byte time.  If your link budget is larger than 10%, you will miss a bit.  BUT WAIT... all UART implementations I am aware of try to sample in the center of the bit.  Generally, this is done by oversampling 16x and using the center 3 samples as a majority detect.  If you consider that slipping the byte time by 1/2 a bit time will cause a missed bit, our link budget is now 5%.  If you KNOW you are talking to a PERFECT receiver, then you can accept the entire 5% error.  (Of course, you can assume your design is perfect and pass the blame to the other side, but then you would not be reading this.). I am sure that perfect transmitters & receivers are not possible, so we shall reasonably accept 1/2 the responsibility for the link budget, making our baud rate error specification 2.5%.

Hmm.  Something still seems rotten.  The data sheet states that the TOTAL budget is 2%.  Our envelope scribblings say 5%.  What gives?

Here is a good writeup by Maxim Integrated (https://www.maximintegrated.com/en/app-notes/index.mvp/id/2141) that adds some more details.  Essentially, you have an uncertainty of ±1 sample-time detecting the START bit and a terrible link would have a 50% chance of detecting the midpoint of the stop bit.  The short of the story is a ±3 sample-time error budget out of a needed 152 sample-times (160 sample times less 1/2 a bit time) or ±2% error budget for the link.  That assumes you are over sampling 16x.  On a PICmicrocontroller, the UART has a high speed mode (BRGH = 1) which changes the sampling rate to x4 instead of x16.  This can have a profound effect on the error budget due to the ±1 bit sampling uncertainty.

So here are a few recommendations:

1) Always use the MAXIMUM sampling rate available in your UART.

2) Consider a crystal (20ppm) or a resonator (0.5%) or if you must use an internal oscillator, I hope your temperature & power supply is stable so your oscillator accuracy is good.

3) Consider using the auto baud features and internal oscillator tuning features if they are available in your controller.

Good Luck

Share this post

Link to post
Share on other sites

I lost you a bit at the end there, so you say +-2.5% is pretty close to correct but it does not take the sampling into account, if you do - that reduces to +-2% error budget which means that if the 2 devices drift apart more than 4% (the one goes up 2% and the other one goes down 2%) - you will start seeing errors?

That sounds about right for what I was expecting...

But how much does that change with BRGH to 4x? 

Does that mean the budget becomes close to 1% ?


Share this post

Link to post
Share on other sites

Those are great questions.  So here is the answer with the same procedure.

10 bit-times * 16 provided 160 total sample times in a byte.  The error threshold occurs 1/2 a bit time early so you subtract 8 sample for 152 total sample times as the baseline.

Then the article assumed additional errors of ±25% and ±37.5 for the two test cases.  .25 * 16 == 4 and .375 * 16 == 6 less 1 bit for sampling uncertainty and you get ±3 and ±5 sample times of allowable mismatch out of 152 sample times.

If we rework the numbers for x4 sampling and x8 sampling we get the following:

x4 Sampling (PIC BRGH = 1)

10 * 4 == 40 - 2 == 38 total sample times.

.25 * 4 == 1 and .375 == 1.5. less 1 for sampling uncertainty and you get ±0 and ±1 (rounded .5 up to 1 for a 'good" link)

So you just can't receive a bad link (50% chance of catching the last bit) and on a reasonable link (75% chance of catching the last bit) you have a 1/38 == ±1.3% link budget.  

If BRGH is set, you need a fantastic signal and you get a ±2% link budget.

x8 Sampling (AVR U2Xn bit set)

10 * 8 == 80 - 4 == 72 total sample times to the edge of acceptability.

.25 * 8 == 2 and .375 * 8 == 3 less 1 for sampling uncertainty and you get ±1 and ±2.

Total Link Baudrate Error is 2/72 == ±2.7% and 3/72 == ±4.2%.  Essentially, the lower oversampling means the middle is sampled more broadly which increases area where the edges can be caught.


Share this post

Link to post
Share on other sites

Ok I think I get it now. 

We can separate the quality of the link from the basic budget. We know on a perfect link the slew rate is instant. I will do a 10% bit time slew rate for the table calculation as that is typically what I like to have.

Sorry I was too lazy to do the 8x, but it is somewhere inbetween.

Samples from 
Start to centre 
of stop bit
Budget without
As % Sampling 
Error Budget
with Sampling 
Clock Error
Ideal slew
Clock Error
10% bit slew
4x 38 +-2 sample periods 5.26% 1 period +-1 sample period +-1.32% +-0.52%
16x 152 +-8 sample periods 5.26% 1 period +-7 sample periods +-2.3% +-2.03%


From the PIC16F18875 datasheet the clock accuracy is +-2%, which means that from 0 to 60C between 2.3V to 5.5V you can use the internal oscillator for 2 devices to communicate realiably only if both devices are oversampling at 16x, if you want to use 4x over sampling you will not get reliable communication as the clocks cannot remain within +-0.52%. 




  • Like 1

Share this post

Link to post
Share on other sites

Ok.  That looks more like what I suspected.  Thanks for checking the math.

That 1/2% error budget in x4 mode will be challenging for most systems.  You will need short cables and/or low baud rates.


Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  


  • Popular Contributors

    Nobody has received reputation this week.

  • Similar Content

    • By Marco
      I have a program in MPLAB that works correctly when sending messages through the LIN system at a baud rate of 9600, but when I change it to 19200 it does not come out. I am using the MPLAB Code configurator V4 tool and in the window for Eusart I put the 19200 which are the Baud Rates to which I want to transfer.
      It is expected to know the values in the eusart.c file of SP1BRGL and SP1BRGH for the Baud Rate corresponding to 19200.
      Tried with SP1BRGL values of 0x40,0X65,0xFE, 0x3B, 0x3D keeping SP1BRGH at 0x00.
      Also in the application in the Registers of the variables of Sp1BRGL and SP1BRGH so that they correspond to a Baud Rate of 19200.
      For the calculation, the table for pic16 was used, it is expected in high transfer speed with a 16 Mhz oscillator an SPBRG of 51 but it still did not work.
      I do not know what I am doing wrong, to read the data I am using a LIN analyzer tool and everything works at a Baud rate of 9600 but I take it to be 19600 for the application.

    • By dvvrao
      Does the simulator for PIC32MX470F512L support UART with DMA operation? 
      I wrote a program that transmits a character using UART with DMA, but does not work. 
      I used Dynamic USART driver with Buffer Que Data Transfer model using DMA.
      PFA the package file of the project.
      Please let me know if there is any thing wrong with the code or harmony configuration.
  • Create New...