UART BAUD RATE TOLERANCE
Jim
tolerance? i.e if you select 38.4, what can sender ...send
you?
Thanks.
jok
Allan Herriman
This is a bit off topic for c.l.v. (perhaps you should try something
like comp.arch.embedded?)
Usually the frequency tolerance is about 5%. But this depends on the
particular format used (8,N,1, etc); how accurately the UART can
determine the centre of the start bit; and the size of the data
sampling window (usually just a single sample, but some use multiple
samples with majority logic decoding (eg, 8051)).
Uart input:
-------------------------------------------------------
|st-|bit|bit|bit|bit|bit|bit|bit|bit|st-|
|art| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |op |
-----------------------------------------
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ <- sample instants
s 0 1 2 3 4 5 6 7 s (0% frequency error)
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ <- sample instants
s 0 1 2 3 4 5 6 7 s (incoming is 5% slow)
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ <- sample instants
s 0 1 2 3 4 5 6 7 s (incoming is 5% fast)
(Sorry about the ascii art...)
You can see that errors will occur when the frequency difference is so
great that the stop bit sampling point occurs either at the end of bit
7 (when the incoming rate is too high), or the bit 7 sampling point
occurs at the beginning of the stop bit (when the incoming rate is too
low).
Does this answer your question?
Perhaps you wanted to know what tolerances are achieved in practice?
In the days of electromechanical ttys, the tolerance could get to
about 5%. (Which is why ITU-T V.4 recommends two stop bits for baud
rates < 200 bps.)
These days, everything comes from a crystal or a ceramic resonator
(perhaps +/-200ppm). However, dividers are used to generate the baud
rates, and sometimes the wanted baud rate doesn't map to an integer
divisor. In this case (which is fairly common) the tolerance will
still be better than +/-1% (& usually better than 0.2%). Look up an
8250 (16C450) data sheet for details.
Also, some motherboard clock generators use multiple PLLs to
synthesise all PC motherboard clocks (including the 18.432MHz for the
UART) from a single 14.31818MHz crystal. These also have the
"rational number" problem, but the accuracy is still better than 1%.
Regards,
Allan.
Zeki Basbuyuk
>Any folks know what one should design to regarding baud rate
>tolerance? i.e if you select 38.4, what can sender ...send
>you?
>
>jok
The way I look at the problem is as follows.
You have 10 bits to send(Start,8 bits,Stop, Technically it is 9 bits. 10th
is high anyway.). How much error would make you skip 1 bit? This is roughly
%11.1. Lets say you are using a UART which does 16X sampling. How much
inherent sampling error it will introduce ? <%1 percent in overall data
location(for a total of 10 bits). That makes you tolerance about %10.xx some
percent. It you assume that the receiver and the transmitter are using the
same technique for adjusting the clock (may not be exact etc.) then Divide
the number by 2 and that is the maximum tolerance you should be off.
Otherwise you'll be sampling previous or the next bit at the last sampling
time.
In short just %5 is the max.
Good luck.
Jonathan Bromley
>Any folks know what one should design to regarding baud rate
>tolerance? i.e if you select 38.4, what can sender ...send
>you?
Easy enough to calculate the tolerance.
Receiving UART is synch'd by the leading edge of the start bit.
It then samples halfway through each subsequent bit. This
sampling must stay comfortably in the middle of the bit,
right up until the first stop bit which occurs 9.5 bit times
later (10.5 bit times if you have parity). So your worst
possible drift is half a bit time in (nearly) ten bit times,
or 5%. In practice you need to be quite a bit better than
this because (a) synchronisation is usually only good to
1/16 of a bit time, (b) the receiver probably needs three
consecutive 16x-oversampled data points to get a result.
Say you fall back to 3% as a reasonable compromise.
Then you need to share this error budget between
transmitter and receiver, so neither of you should be
more than 1.5% wrong.
HTH
Jonathan Bromley