I have found in the datasheets of microcontrollers that there is term called baud error rate. In order to reduce the error percentage one has to run the microcontroller at higher frequency. This error which depend on the oscillator frequency is called baud error rate in UART. Is this caused by the bit error rate (BER) ? The baud is composed of some bits. There are some number of bits per baud. So if there is a baud rate in data transfer then can we also called or relate to bit error rate (BER) ?

 

No! UART communication is bit synchronous, but byte asynchronous. This means that bytes on the communication channel have no fixed time relationship to each other. The bits are fixed in format and must be the same length in time, but the clock in the transmitter and the clock in the receiver may not have exactly the same frequency. This would be a problem over a long string of bits, but over the 10 or 11 bits of a single frame it is not a problem if the transmit clock and the receive clock are within a couple of percentage points of each other.

When reliable asynchronous communication is desired the microprocessor clock frequency will often be chosen to be an integer multiple of the bit rate, even if that would compromise the overall performance. For example, on an 8 MHz. ATmega part I would often choose a clock frequency of 7.3728 MHz. which is 64 times the baud rate for the UART channel of 115,200 bits per second. Using an 8 MHz. crystal there was no way to do reliable communication at that speed.

 

@Papabravo Thanks for your reply. I am trying to understand but from your reply it look like that there is no bit error rate in UART communication because of bit synchronization. Is that correct ? Please confirm.

How do we calculate baud error rate. For example if the baud rate is 115200 and the clock frequency is 16 MHz or 64 MHz then how do we calculate baud error rate assuming each baud is 1 bit.

 

Using an 8 MHz. crystal there was no way to do reliable communication at that speed.

And yet, I do exactly that with no problems at all. I am using a PIC24. The 8 MHz is multiplied by a PLL to 32MHz, then divided down to 115300 by dividing by 278 giving a baud rate of 115108.

So the actual baud rate, as a percentage of the ideal, is:

115107 / 115200 = 0.99992

or an error of 0.08%

TS: Watch, here is the calculation.

Even without the PLL, let’s do the calculation:

The divider should be

8000000 / 115200 = 69.4

So we choose 69

And the actual baud rate is:

8000000 / 69 = 115942

And the ratio is:

115942 / 115200 = 1.006 which is 0.6% too high. I am willing to bet this would also work reliably.

 

@BobTPH I understand the example without PLL. Thanks for the example.

Regarding the example with PLL. I don't get how you get 115300 and 115108. Please explain.

How about selecting a baud having no or almost no baud error for a particular frequency ? I know that there are standard baud rate already defined but can we set strange baud rate at both end to minimize the error ?

Second question is why we have baud in UART ? If we have 8 bits per character that become 10 bit by adding start bit and stop bit then we have 10 bit per character or 10 bit per baud.
If there is no bit error than there should also no error in sending 10 bits or multiple of 10 bits ? so why we have baud error then ?

 

When a character is transmitted from and external device, people "assume" the clock is spot on.
Not always the case, but it will be close.
If you ever create a software serial port, you will need to catch the first falling edge and count exactly 1/2 a bit rate.

At 11500 baud that will be 8.67uS per bit and 4.33uS for a half bit. The trick is to get all 10bits in before you either exceed 10bits time space or miss the 10th bit..

The middle of the tenth bit will be 86.7uS to ensure its read correctly.

If your processor speed can only get 1% then the timing will be 8.68uS or 8.66us ergo 86.8uS and 86.6uS for 10 bits
86.7uS - 4.33uS = 82.4uS and 86.7uS + 4.33uS = 91.0uS.. So 1% is NOTHING in the 10 bits.

I have seen 2% working fine... So as long as your error is >1.5% you'll be well in.

 

I think I am getting it now. What about if we have a Baud rate of 80000 (80 kBaud) ? If we have a microcontroller clock running at 8 MHz or 16 MHz then we don't have baud error ? Am I right ?

If yes then why do we work with those bauds which does not match with the clock tick ? Why not to use only those baud rates that inline with clock tick ?

 

If you are creating both devices.. Do any speed you like, but RS232 standards are there so you can reliably read "set" baud rates.

 

As usual there is a bit of history on 'why' for X baud rate.

The original UART was an electro-mechanical device (selector) on a teletype driven (geared for lower baud rates 45.45, 50, 75, 100, 150) by a synchronous (usually) motor (with higher baud rates usually multiples of the utility (US) frequency 300,1200,9600, etc...).

5:50 mechanical UART

>5% transmitting and receiving mechanical UART device baud rate differences were handled just fine as synchronization was only needed for less than 10 line mark/space transitions when connected back to back. When the signals were sent by radio you wanted almost perfect rate speeds on both ends because multi-path distortion and ionospheric propagation caused excessive error rates due to bit pattern shifting in transmission, causing data-bit and framing errors (does not see a "stop" bit at the expected "stop" bit time).
With longer asynchronous data sequences the odds of UART errors increases with transmission speed, as the detection time for a bit decreased to the point where noise and RF transmission artifacts eliminated the smaller timing error margins for one frame.

 

How about if we don't use RS232. We just use USB2UART bridge and aet the same baud rate in virtual COM appear in Windows PC same as Microcontroller. Can we use realiably baud rate with No baud rate error. In this case the baud will finish or terminate with clock tick.

 

And yet, I do exactly that with no problems at all. I am using a PIC24. The 8 MHz is multiplied by a PLL to 32MHz, then divided down to 115300 by dividing by 278 giving a baud rate of 115108.

So the actual baud rate, as a percentage of the ideal, is:

115107 / 115200 = 0.99992

or an error of 0.08%

TS: Watch, here is the calculation.

Even without the PLL, let’s do the calculation:

The divider should be

8000000 / 115200 = 69.4

So we choose 69

And the actual baud rate is:

8000000 / 69 = 115942

And the ratio is:

115942 / 115200 = 1.006 which is 0.6% too high. I am willing to bet this would also work reliably.

It would have been nice if the ATmega128 had a PLL, but it didn't. Nothing I could do about that, and for sure the UART @ 115,200 was NOT reliable. Drop the crystal slightly to 7.3728 MHz. and smooth sailing. Your mileage may vary and this was 16 years ago.

 

@Papabravo Thanks for your reply. I am trying to understand but from your reply it look like that there is no bit error rate in UART communication because of bit synchronization. Is that correct ? Please confirm.

How do we calculate baud error rate. For example if the baud rate is 115200 and the clock frequency is 16 MHz or 64 MHz then how do we calculate baud error rate assuming each baud is 1 bit.

Many, but not all UART devices require a clock that is 16 times the bit rate, so each bit cell consist of 16 clock periods. A device will sample three bits around the middle of the bit cell to determine the bit value. In order to lose bit synchronization over a 10 or 11 bit frame, you need for the transmit clock and the receive clock to be different enough so that the sample point on the receiver moves into the previous or the next bit cell in that frame. Remember, bit synchronization is established by the falling edge of the START bit following a period of one STOP bit or longer.

So for a clock rate of 16 MHz you would have 115200 x 16 = 1.8432 MHz is minimum x16 UART clock frequency.
The 16 MHz/1.8432 MHz = 8.6806, making the closest integer a 9
Assuming you can only specify integer divisors. If you choose a divisor of 9, then 16 MHz. / 9 = 1.7778 MHz, and
1.7778 MHz /16 = 111,111.1 bits per second. I can almost guarantee that this is not close enough to work correctly.
The closest useable frequency to 16 MHz would be 14.7456 MHz, since 14.7456/115200 = 128

That is a pretty small sacrifice in performance to guarantee reliable UART operation.

 

It would have been nice if the ATmega128 had a PLL, but it didn't. Nothing I could do about that, and for sure the UART @ 115,200 was NOT reliable. Drop the crystal slightly to 7.3728 MHz. and smooth sailing. Your mileage may vary and this was 16 years ago.

But even without the PLL, the speed would be off by less than 1%, and it take an error of more 6% before reading in the middle of a bit time would give you an incorrect bit in 8 bit data. So I am skeptical.

Is it possible the Arduino has pre-divided the clock before its baud generator? The PICs can either use the raw clock (for high baud rates) and a pre-divided click for lower baud rates. Is Arduino the same? Did you possibly select the wrong clock rate for it?

 

But even without the PLL, the speed would be off by less than 1%, and it take an error of more 6% before reading in the middle of a bit time would give you an incorrect bit in 8 bit data. So I am skeptical.

Is it possible the Arduino has pre-divided the clock before its baud generator? The PICs can either use the raw clock (for high baud rates) and a pre-divided click for lower baud rates. Is Arduino the same? Did you possibly select the wrong clock rate for it?

It was the limitation of integer divisors. The closest I could get was 111,111.1 bits per second, a 3.5% error. Maybe I was working with cranky devices on the other end, but it for sure did not work. I don't know what to tell you. Consult a datasheet for the ATmega128.

 

It was the limitation of integer divisors. The closest I could get was 111,111.1 bits per second, a 3.5% error. Maybe I was working with cranky devices on the other end, but it for sure did not work. I don't know what to tell you. Consult a datasheet for the ATmega128.

Okay, I will look. Seems that the PICs do this better.

The PIC samples 3 times in each period, and that would cause a wrong bit at a 3.5% error, though I thought they used a voting circuit, and that would still work right theoretically. This is from memory, so I might have it wrong.

 

This is how modern PIC USART bit detection works.

 

Yep, you are exactly right Papa, the ATMEGA divides the clock by either 8 or 16 before clocking the baud rate generator. With the divisor of 8, and 8MHz, it is clocked at 1MHz, so the calculation is:

divisor = 1000000 / 115200 = 8.69.

Choosing the closest integer, 9, we get the actual baud rate of:

1000000 / 9 = 1111111

I looked at my PIC code, and running at 16MHz, the clock rate is is 32 MHz, and it divides this by 4 before going to the baud rate generator. So it is starting with 8 MHz, which gives the 0.6% error I calculated above.

Edited to add: So a PIC running an 8MHz clock would base the divisor on 2,000,000, and the error would be 2%. And at that speed, it samples at half the period, which should never produce and error for 8 bit data.

 

How about baud rate 100,000 instead of 115,200 ? If UART clock running at 10 MHz would there be any baud error ?

Or 80,000 instead of 115,000 ? If UART clock running at 8 MHz would there be any baud error ?

 

How about baud rate 100,000 instead of 115,200 ? If UART clock running at 10 MHz would there be any baud error ?

Or 80,000 instead of 115,000 ? If UART clock running at 8 MHz would there be any baud error ?

Either will work fine, but you are unlikely to find any commercial devices that run at your peculiar baud-rate.
It would be perfectly OK if you are sending data to something else that you have made.

 

As usual there is a bit of history on 'why' for X baud rate.
(with higher baud rates usually multiples of the utility (US) frequency 300,1200,9600, etc...).

I never realised that! Probably because the list normally starts 75,110 before it gets on to multiples of 60Hz.