UART BaudRate drift calculation on PC side?

[xpress_embedo]

Hello!! all, i am having a device, which sends data to PC using UART, is there any way to calculate the drift in the Baud Rate of the received data.

Lets say, i had written a program in a micro-controller to send some characters to PC using UART communication, but this micro-controller has to face different ranges of temperature and due to which the clock can change and due to this, the Baud Rate can also change.
Is there any software for this purpose or, any other way to to calculate the drift in Baud Rate as compared to actual Baud Rate.

[h0nk]

Hello xpress_embedo,

the change of baudrate is direct proportional to the change of oscillator frequency.
You should check the data sheet for You PIC it there are any figures about the depencancy to temperature.
Attached a figure for the internal oscillator of a PIC 12F675.
RS-232 works well if the error is below approx. 4%.
From the figure the error at 0 grad celsius should 2% compared to 25 grad celsius.
For testing send the character 'U' back-to-back in a loop and measure the frequency.
It should be equal to Your baudrate.

To avoid any trouble i would simply use a quartz.

Best Regards

[xpress_embedo]

Actually i am not using PIC micro-controller, one can use any micro-controller, i just want to make a simple Drift Rate Calculator or one can say Error Calculator.
It doesn't matter whether by using any type of crystal i get proper baud rate.
Sending 'U' means sending 0x55 and in Binary 0b01010101.
By Padding Start and Stop Bit the signal will look like the following (LSB is transmitted First)
0(Start) 1(LSB) 0 1 0 1 0 1 0(MSB) 1(Stop)
Suppose the device under test is continuously transmitted 'U' character, and then by measuring the frequency i can calculate the baud rate.
I will use PIC16F877A for frequency measurement.
Is that okay, or i have to do something else also.

[h0nk]

Hello xpress_embedo,

most controller derive the baudrate directly from their oscillators either with direct or sometimes fractional dividers.
So no extra calculation for the error should be necessary.

To get the error of Your RS-232 below 2%, the error of the oscillator has the same margins.

A 16F877A with a quartz would be fine to measure this. Also some multimeters and digital scopes offer frequency measurement.

I would recommend to check with a scope, that the frames are really send back-to-back.


Best Regards

[titi]

Hi xpress_embedo,

it should be more precise to measure the period or the duration of the pulse high by using the CCP/TIMER1.
Frequency=1/Period

This can helps you:
"PIC­ MCU CCP and ECCP Tips n Tricks" at http://ww1.microchip.com/downloads/en/DeviceDoc/41214a.pdf
Best regards.

[kreutz]

Also be aware that, due to the baud-rate being generated by means of main clock frequency division, some baud-rates will have less deviation than others at the same temperature. Use one of those and you will have less probability of communication problems. The optimum solution is to have a good quartz crystal/oscillator for the uController clock as per h0nk's suggestion.

[flo0319]

In general internal clocks of uC are RC calibrated oscillators and the frequency is 8,12,16 MHz. Unfortunately for UART Baudrate those freq. generate errors.
For example pic16f877 has only external clock and in datasheet can be found a table with different clock configuration and the error generated to each standard baudrate http://ww1.microchip.com/downloads/en/DeviceDoc/39582C.pdf page 114. To avoid this error, can be used the special quartz (designed for serial communication ) like :
    1,8432 MHz (das ist die klassische Frequenz des PC-Baudratengenerators)
    3,6864 MHz
    4,9152 MHz
    6,1440 MHz
    7,3728 MHz
    9,8304 MHz
    11,0592 MHz
    12,2880 MHz
    14,7456 MHz
    18,4320 MHz
    19,6608 MHz
    22,1184 MHz

but this will not solve your BR drift  during temperature variation

[solutions]

UARTs work by OVERSAMPLING, around 8x, 10X, or 16x, depending on device, if I remember it right...the second letter in the acronym is ASYNCHRONOUS. That means clock drift DOES NOT MATTER because each start of packet resets the sampling point.

So, unless you are using slang for a USART, which does require synchronization, in most UART protocols the clock errors on the send or receive side are irrelevant if the clocks are kept within a few percent of the ideal baud rate. It is left to the reader to do the math.

If you are sending a continuous data stream and not packets or single characters, over a UART you are abusing the protocol, particularly since there is no clock encoding or line balancing, just bit banging.

But you said you are sending characters. That implies a bracketing of start/stop bits and a minimalist set of bits between them. Should be NO PROBLEM.

[h0nk]

It should be equal to Your baudrate.

should be:
It should be half of Your baudrate.

Best Regards


PIC16F819 running on internal Oscillator at 4 MHz with a baudrate of approx 38400: