# UART baud rate error tolerance

I have a question regarding the UART baud rate error tolerance, as the thread title indicates. First of all, I want to point to an excellent tutorial on clock accuracy: Maxim Integrated Tutorial

I understand that the baud rate error tolerance depends on many parameters, for instance, cable attenuation which is in direct correlation to the cable length, the baud rate itself etc. The UART baud rate on a dsPIC33E is determined by an $\text{UxBRG}$ register, which value is calculated as:

$$\text{UxBRG} = \frac{F_P}{16 \cdot \text{BR}^\star} - 1$$

where $\text{UxBRG}$ is a register of type unsigned int (16-bit), $F_P$ is the CPU clock frequency in Hz, and $\text{BR}^\star$ is the desired baud rate in bps.

For example, if we want a baud of rate of $\text{BR}^\star = 19200\,\text{bps}$, and the CPU clock frequency is $F_P=60\,\text{MHz}$, the corresponding register value would be 194.3125, which can be rounded to 194 or 195. The actual baud rate with respect to the $\text{UxBRG}$ register value can be calculated as:

$$\text{BR} = \frac{F_P}{16 \cdot (\text{UxBRG}+1)}$$

For the above example, the actual baud rate can be one of the following:

• $\text{BR}=19230.76923\,\text{bps}$ ($\text{UxBRG}=194$) -> the baud rate error is +0.160%
• $\text{BR}=19132.65306\,\text{bps}$ ($\text{UxBRG}=195$) -> the baud rate error is -0.351%

The baud rate error is calculated as:

$$\text{BR}_{\text{err}} = \frac{\text{BR}^\star - \text{BR}}{\text{BR}} \cdot 100\%$$

However, in the above example, although $\text{UxBRG}=194$ gives a lower absolute baud rate error (+0.160%), I would rather choose $\text{UxBRG}=195$ (-0.351%). The reason for this is that when a bit on the data bus toggles from 0 to 1 (or vice versa), the cable capacitance would "slow down" this transition, something like an RC circuit, which could even be 30% (or more) of the bit period. Of course, this depends on a cable length, the baud rate itself etc. Due to this reason, I would rather that the "baud rate clock" drifts from the center of the bit towards the end of the bit. Please let me know does this makes any sense at all.

P.S. Since in UART communication the clock resets itself on each frame, I know that everything under 3% baud rate error in "normal" operating conditions is considered to be acceptable.

Best, Marko.

I would rather that the "baud rate clock" drifts from the center of the bit towards the end of the bit.

That's fine when looking at the receiver, but keep in mind that UART communications is usually two-way. If you send with a slow clock, then you're putting the receiver at the other end at a greater disadvantage.

It's better to pick the smallest absolute error for the best performance in both directions.

• Dave, yes this makes sense. Since the "true baud rate error" is (approximately) the sum of baud rate errors from two devices that communicate. In other words, in communication between two devices, one of the clocks will always drift to the "left", and the other to the "right" on a time axis. Therefore, the safest scenario is to choose the baud rate that is closest to the "ideal baud rate". Thanks for the help! Jul 23 '16 at 19:48

I'm addressing a statement in the question that is incorrect and, because it underpins the whole basis of the question, makes the question invalid: -

The reason for this is that when a bit on the data bus toggles from 0 to 1 (or vice versa), the cable capacitance would "slow down" this transition, something like an RC circuit, which could even be 30% (or more) of the bit period.

When you look at any half decent transmission-line (like coax or properly designed copper tracks on a PCB) it has a characteristic impedance and this can be mathematically modelled as a bunch of short sections like these: -

At low frequencies, R and C dominate and you get capacitive problems. For instance, on telecom lines the impedance isn't 600 ohm across the speech spectrum but more like this at audio: -

At much higher frequencies this settles down to be 100 ohms in the above example but on many coax cables it is 50 ohms or 75 ohms. Note that in the above picture nominal impedance (600 ohm) is shown with the dotted line and roughly corresponds to the impedance at 1 kHz.

So, getting back to the point, the edge transitions in your signal are very fast and these will be transmitted at a part of the spectrum that is at least 1 MHz or above and therefore the characteristic impedance equation (shown above) boils down to $\sqrt{\dfrac{L}{C}}$ i.e. purely resistive.

This means, unless you have what might be descibed as really crappy cable (or badly designed connections on your PCB), the edges of your digital signal will not be low pass filtered as such.

Given also that if you don't treat cables and tracks as transmission lines you will see strange phenomena in your signal that may look like capacitive effects. I'm talking about signal reflections from a badly terminated transmission line. All of these are good methods in there own ways: -

If you don't make an attempt at terminating the line in one of the methods above you will likely get reflections bouncing back and forth and it may look like this is caused by too much t-line capacitance.

• Andy, in the tutorial that I have posted in my first post, they mention slow rise/fall times due to the "overly capacitive cable", and they estimate this to be 25% of the bit period. According to your post, this is not an issue, unless poor cabling is used. Please correct me if I'm wrong? Are there any other reasons besides poor cabling or badly designed PCB connections that might affect rise/fall time of a bit transition? Thanks for this intro in transmission and cabling! Can you please recommend any script/book in which I could read more about things like signal reflections etc.? Thanks! Jul 23 '16 at 19:58
• UART (e.g., RS-232) connections are rarely made with anything approaching a true transmission line across the frequency band of interest, especially considering that the fundamental frequency is half the baud rate. Capacitive loading of the deliberately-limited drive current is indeed the primary contributor to waveform distortion. Jul 23 '16 at 20:06
• The naivety of that last comment surprises me. The downvote however doesn't given who made the comment. Jul 23 '16 at 20:35
• @Marko I take issue with that Maxim article. I have looked for articles to substantiate it but cannot find anything so, if the down voters can offer some evidence I would appreciate it. Jul 24 '16 at 9:38
• Andy, no problem, thank you for your help! Regardless to my initial assumption, it is always better to choose a baud rate that gives the smallest absolute error, as I already explained in the comment to Dave's answer. Jul 24 '16 at 17:37