Electronic – UART baud rate error tolerance

baudratemicrocontrolleruart

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.

Thank you in advance!

Best, Marko.

Best Answer

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.

Related Solutions

Electronic – UART receiver clock speed

Transmitter and receiver clocks are independent of each other, in the way that they're generated independently, but they should be matched well to ensure proper transmission.

The start bit, which is low, and the stop bit, which is high, guarantee that between two bytes there's always a high-to-low transition the receiver can synchronize on, but after that it's on its own: there are no further time cues it can use to tell successive bits apart. All it has is its own clock. So the most simple thing to do is starting from the start bit sample each bit at the middle of its time. For example, at 9600 bps a bit time is 104 µs, then it would sample the start bit at \$T_0\$ + 52 µs, the first data bit at \$T_0\$ + 52 µs + 104 µs, the second data bit at \$T_0\$ + 52 µs + 2 \$\times\$ 104 µs, and so on. \$T_0\$ is the falling edge of the start bit. While sampling the start bit isn't really necessary (you know it's low) it's useful to ascertain that the start edge wasn't a spike.

enter image description here

For a 52 µs timing you need twice the 9600 bps clock frequency, or 19200 Hz. But this is only a basic detecting method. More advanced (read: more accurate) methods will take several samples in a row, to avoid hitting just that one spike. Then you may indeed need a 16 \$\times\$ 9600 Hz clock to get 16 ticks per bit, of which you may use, say, 5 or so in what should be the middle of a bit. And the use a voting system to see whether it should be read as high or low.

If I recall correctly the 68HC11 took a few samples at the beginning, in the middle and at the end of a bit, the first and last presumably to resync if there would be a level change (which isn't guaranteed).

The sampling clock is not derived from the bit rate, it's the other way around. For 9600 bps you'll have to set the sampling clock to 153 600 Hz, which you'll derive through a prescaler from the microcontroller's clock frequency. Then the bit clock is derived from that by another division by 16.

unmatched clocks
This is what will happen if the receiver's clock isn't synchronous with the transmitter's:

enter image description here

The receiver's clock is 6.25 % slow, and you can see that sampling for every next bit will be later and later. A typical UART transmission consists of 10 bits: 1 start bit, a payload of 8 data bits, and 1 stop bit. Then if you sample in the middle of a bit you can afford to be half a bit off at the last bit, the stop bit. Half a bit on ten bits is 5 %, so with our 6.25 % deviation we'll run into problems. That shows clearly in the picture: already at the third data bit we're sampling near the edge.

Electronic – UART on the atmega328. Dataregister on the USART (UCSR0A) status never set on

I don't see where you put the correct F_CPU definition, which is mandatory for setbaud.h.

You also have to define the BAUD macro to use UBRR(L|H)_VALUE, like this:

#define F_CPU 1e6       // 1Mhz clock
#include <avr/io.h>
#include <util/delay.h>

void initUSART(void) {
 #define BAUD 9600
 #include <util/setbaud.h> 
 UBRR0H = UBRRH_VALUE;
 UBRR0L = UBRRL_VALUE;
// ...
}

You can also calculate the UBRRnx values with this site. The values depend on your clock speed and the prescaler setting. At the default configuration it is simply one, so it is not used.

And don't forget the pull-up resistors (about 10K ohm) at the TX/RX lines.

I hope this helps.

Best Answer

Related Solutions

Electronic – UART receiver clock speed

Electronic – UART on the atmega328. Dataregister on the USART (UCSR0A) status never set on

Related Topic