Re: Uart baud rate matching

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
On Mon, 18 Aug 2003 17:21:56 +0200, "David Brown"

Quoted text here. Click to load it

A 1.36% error combined with a nominal 0% error from the other end
should present you with few problems.

If the other end was potentially 1.36% off in the opposite direction,
You're looking at a combined potential error > 2%, which would make me
nervous.

A 5% error would almost guarantee problems.  Consider that about 10
bits are sent to transmit a single byte.  Even though everything is
re-synched at the beginning of each byte, the error within a byte
accumulates so that the error at the end of the byte might be 50% or
more of a bit width.  Depending how the UART does its bit sampling,
you could end up with an erroneous value for the last bit as much as
50% of the time.  

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Uart baud rate matching
Quoted text here. Click to load it


Typical RS-232 asynchronous serial communications require that each
side's clock is accurate to within 2% of the nominal data rate.  The
receiver syncs up his clock at the leading edge of the start bit, but
never resyncs during the frame.  The receiver then tries to sample the
remainder of the frame in the center of each bit.  Assuming the sender
and receiver are both off 2%, but in different directions, the
receiver would be about 42% of a bit width off center by the time he
got to the first stop bit on an 8-bit+parity "frame."  IOW, just about
ready to fall off the bit entirely.

Re: Uart baud rate matching
Quoted text here. Click to load it

All of the replies so far have ignored the slew rate limiting in the
line
drivers.  The effect of these at 115200 bps is that an appreciable
amount
of each bit time will be consumed by a possible change of state, mark ->
space or space -> mark.  If the final bit time is off by 42%, there is a
very high probability that it will sample during a change of state.  
Behavior of the line driver is probably undefined during this time
period,
and is likely to produce erratic behavior.

To see what I'm talking about, hook a scope to the Tx line of a serial
port
transmitting at 115200 bps.  Send a continuous stream of 'u's, which
have
a transition between each pair of bits.  The tops and bottoms of the
bits
almost don't flatten out before the end of the bit time.  Compare that
to
the same data transmitted at a much lower data rate.  Peaks are
comparitively
flatter.

Just one of those darn real-world analog phenomena.
    ---   rod.

Re: Uart baud rate matching

Quoted text here. Click to load it
with
safe

That's pretty much what I thought, and what I have seen in practice.  Thanks
to all posters for confirming it.

David




Site Timeline