Connect with us

Slightly unmatched UART frequencies

Discussion in 'Electronic Basics' started by valentin tihomirov, Nov 25, 2003.

Scroll to continue with content
  1. UART is used to transfer a byte in serial form bit-by-bit. I know that 10%
    deriviations in frequencies of transmitter and receiver are permissible. I
    was learnt that UARTs synchronyze at the falling edge (1to0) of start bit;
    hence, there should allow for transfer of a stream of bytes of arbitrary

    I have developed a simple UART. It's receiver and transimtter run at 9600
    bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer.
    To test the design I've created an echo device; it merely mirrors all the
    bytes sent to it back to the sender. It works fine with one of COM ports on
    my PC. Another COM port has its crystal running at a bit faster fundamental
    frequency. This causes a problem when it sends a long stream of bytes to my
    UART. In fact, sender and recepient cannot synchronize at falling edge of
    start bit because one of them is slower and is processing a previous byte
    wrile sender proceeds to next byte transmitting start bit. Despite of the
    fact, my receiver still works fine beacuse it is ready to receive next byte
    right after a first half of stop bit is received. Just to clarify, receiver
    acquares values from serial input at the middle of each data bit slice; it
    reports BYTE_READY in the middle of stop bit and from this moment is ready
    to accept next byte, i.e. ready fror synchronization. Therefore, if data is
    coming slightly faster and falling edge of start bit is located within stop
    bit (according to my UART's clock) receiver is still capable not to overlook
    the data.
    On the other hand, transmitter should transmit all 10 bits (start + 8 data +
    stop) @ 9600 bps. Consider for instance an UART forwarder or an echo device.
    If data is coming faster than I forward it I get a buffer overrun
    ultimately. That is, receiver is ready with a byte in its buffer to be
    copied into transmitter to forward but slow transmitter is still shifting
    data out and its buffer is blocked.
    I have a "fast" solution for my UART echo device; if transmitter has
    transmitted > half of stop bit and sences that there is a next byte received
    it stops sending current stop bit and starts transmitting a start bit for
    next byte. Untimely ceasing transmission is not good solution because
    transmitter may be connected to a good matched or slightly slower running
    UART. Design may be not a forwarder thus data provider may differ from 9600
    bps receiver. In this case, starting early transmission of next byte while
    remote peer is still receiving stop bit causes stop bit error.

    What is interesting in this situation is the fact I can build a good echo
    device from any industrial manufactured UART (I've used standalone 16c750
    and ones built into i8051). They never have a buffer overrun issue despite
    sending port is slightly faster than receiving (like sending data from my
    fast COM port to slow one). Note, no flow control is used, buffers are
    always 1-byte long. Which trick do they use? Again, 10% frequency
    dereviations between sender and receiver are considered permittable and no
    flow control is not required since sender and receiver both run at formal

    I feel this should be a well-known problem (solution) and just wonder why I
    did not encounter this consideration before.

  2. rickman

    rickman Guest

    When you say "your" UART, is this a design you did yourself in an FPGA?
    If so you may not have designed the logic correctly. In order for the
    receiver to synchronize to a continuous data stream, it has to sample
    the stop bit in what it thinks is the center and then *immediately*
    start looking for the next start bit. This will allow a mismatch in
    speed of almost a half bit minus whatever slack there is for the sample
    clock rate. BTW, you are sampling at at least 8x the bit rate, right?

    The max mismatch is not 10%, but a bit less that 5%. In the field I
    find that 2 to 3% mismatch is reliable, but any more and you can start
    getting errors. I guess the difference in theory and practice is
    perhaps skew caused by the drivers.

    Does this make sense?


    Rick "rickman" Collins

    Ignore the reply address. To email me use the above address with the XY

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
  3. When you say "your" UART, is this a design you did yourself in an FPGA?
    Yes, you're right I have my design runs on CPLD. However, the qestion is
    more in logic rather than implementation. The value 10% I have got from's forum where "Software Uart" is a hot topic.

    I use 16x oversampling and check input values at middle of a bit (SampleCnt
    = 7). You suggest exactly what I have done. I think receiver part will work
    under any condition. But I need to know what should I do with transmitter
    module. As I attempted to explain, this half-bit solution cannot be used to
    synchronize transmitters. It is a bad idea to start transmitting next byte
    at the middle of the stop bit. It may fail listening device with slow clock
    as it reaches center of stop bit when start bit of next byte is being
    transmitted. On the other hand, if data is coming slightly faster
    transmitter should do something, otherwise I face buffer overrun condition.
    I understand that I can ignore the problem with transmitter module, it is
    receiver that should synchronize with transmitter. However, I had got buffer
    overrun problem until I used a trick described in my message (early
    transmit). It is defenetely not the problem with receiver because I have
    solved it right before got problem with transmitter's buffer overrun. And I
    want to know how should function correct logic; there should be a solution
    as commertial UARTs work without any problems. My UART is the first one
    where I've realized that it is at all possible to get a problem with slowly
    transmitting uart.
    Is now the problem become clearer?
  4. Joel Kolstad

    Joel Kolstad Guest


    You bright up a good subject, and you're absolutely correct that if you
    continuously send data from one serial port at 9600.01bps to a receiver at
    9600, sooner or later there must be a buffer overflow. There's no way
    around this -- but keep in mind that RS-232 (or most any protocol, for that
    matter) isn't designed to send a truly continuous stream for days, months,
    or years at a time without a break! With a typical RS-232 device, there are
    MANY breaks, and keep in mind that something like a PC often has a pretty
    generous software buffer (many kilobytes) backing up the hardware so that it
    would take a 'long' time to create an overflow. I can't explain your
    observation that an, e.g., 8031-based data forwarder -- supposedly -- works
    other than to say I suspect that perhaps you didn't really do the type of
    torture test that could produce an overrun. (I.e., did you look with a
    scope or logic analyzer to make sure there was NEVER a idle bit time that
    might have allowed the receiver to 'catch up'?)

    One solution that you can use for protocols such as 8B/10B -- where you get
    a bazillion data bytes interspersed with an occasional 'comma' character --
    is to use a form of compression where you assign 9 bits to ever received
    byte and 'swallow' any comma you get by setting the high bit. You can then
    sit down and work out how often you need to insert a comma into your
    bitstream to avoid buffer overflow. We had a gigabit fiber interface that
    used this approach, and with a 16 byte FIFO for buffering and a +/-100PPM
    clock at 1.0625Gbps, the numbers worked out to many thousands of bytes
    before overflow would be a concern.

    To build a data repeater that never suffers from potential buffer overflow
    under any circumstances whatsoever, I don't think you have many options
    other than locking the re-transmit bit rate to that of the received data
    using, e.g., a PLL. You could try this in software as well, I suppose, if
    you have a bit rate generator that's 'finely tunable' -- most in
    microcontrollers aren't!

    A few other comments:
    'Permissible,' yeah, I suppose, although 10% wouldn't be anything to write
    home about!
    Nothing wrong with 16x oversampling (it will definitely help -- a little),
    but keep in mind that you _can_ get away with no oversampling at all and get
    quite reasonable results if you position the sample point at the middle of
    each bit interval.

    ---Joel Kolstad
  5. Hal Murray

    Hal Murray Guest

    You bright up a good subject, and you're absolutely correct that if you
    I think you are missing a key idea. The receiver has to make
    sure that it will tolerate early start bits. That is the receiver
    has to start looking for a new start-of-start-bit right after
    it has checked the middle of the stop bit rather than wait unitl
    the end of the stop bit to start looking.

    [Interesting thread. Thanks. I didn't know about that trick.]
  6. Correct. If you really must tolerate continuous streams, with no data loss,
    and only a single stop bit, then you must actually be able to 'pass on' data
    at whatever average rate it comes in at.
    Some UARTS have the idea of fractional TX stop bits to allow this, most just
    2 stop bits to give margin.
    Receive should ALWAYS start looking for START at the middle of STOP.
    ( but chips do not always get this right :)

    The OP's idea of a full half bit is a coarse example, that can force an
    error, as it
    jumps right to the limit

    Since this was using 16x BAUD clocking, you can quantize to 1/16 of bit
    or in appx 0.625% steps. 4 of these is 2.5%, or 1/4 bit, that tolerates to
    9840 Baud
    If you don't want to use up all the error budget at one end, that's about
    the limit.
    ( 1/4 bit at each end, or a tad less, if you use 3 slot vote sampling )

    This is why most uC with trimmed on-chip OSCs specify 2.5% or 2% precision.

    Since this a PLD device, you could watch for TX buffer phase, and nominally
    a full STOP bit, but if the phase indicates margin problems (incomming
    faster than outgoing)
    you can decrement the STOP bit in 1/16 fractions - or you could force 15/16
    wide STOP bit
    and use a crystal, and keep the logic simpler. (tolerates to 9660 Baud, 100%
    traffic )

    A purists design would also extend STOP bits fractionally, (17/16 at ip
    <9600Bd true)
    so a sudden whole bit jump did not occur. That could cause problems if a
    of these are in a chain, and a system with phase jitter, that averages 9600,
    but is
    sometimes faster, sometime slower might also exist.

    Makes the idea of a Continuous BAUD test pattern generator interesting -
    one that can
    generate controlled errors on both sides of true, and with dithering.

    Good student project :)

  7. GPG

    GPG Guest

    MAXIMUM error is .5 bit over one frame. In your case frame = 10 bits.
    ..5/10 = 5%
  8. Joel Kolstad

    Joel Kolstad Guest

    Unless your (slightly slower) transmitter also has the capability of
    producing shortened start (or stop) bits, how those this approach 'fix' the
    problem? If the date rates are, say, 9601 received BPS and 9600 transmitted
    BPS, detecting early start bits just buys you one extra bit interval before
    your overrun your buffers, doesn't it?

  9. ITU-T Recommendation V.110 (a.k.a. I.463) explains how to do
    synchronous to asynchronous conversion (to get async serial signals
    across ISDN). This includes things like stop bit shaving.

  10. rickman

    rickman Guest

    Well, this is not correct. Analyze the situation yourself and see at
    what point the receiver will not sample the data at the correct time.
    You will find the allowed slip is half a bit over the whole word which
    is about 5% give or take.

    That assumption is where you are wrong. There is nothing the
    transmitter can do to change the way it works unless you *always*
    transmit at a rate slower than your receiver.

    The transmitter can be either faster or slower than the receiver. If
    the transmitter is slower than the receiver, then the start bit
    detection will simply happen a few clocks after the end of the stop bit
    rather than right at the end. If the transmitter is faster than the
    receiver, then the start bit detection has to occur before the end of
    the timing of the stop bit. If the transmitter starts the start bit
    early you make the problem worse. If the transmitter delays the start
    bit, then this will prevent any issues. So you can eliminate the
    problem by sending two stop bits and only looking for one at the
    receiver, but clearly this is not how commercial units work.

    Commercial receivers start looking for a start bit leading edge as soon
    as the middle of the stop bit has been timed and checked. You need to
    do the same thing. You don't care when the end of the stop bit
    happens. You only care about the leading edge of the start bit which
    may be a bit earlier than the end of the stop bit as timed by the

    Others have posted in this thread by this point all the info you should
    need. If you still don't understand what is wrong with your
    understanding of the problem, let us know and we will try to make it
    more clear.

    To us, yes. Is it more clear to you as well?


    Rick "rickman" Collins

    Ignore the reply address. To email me use the above address with the XY

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
  11. rickman

    rickman Guest

    No, by looking for the start of next word before the last word is
    complete, the receiver can receive data faster than you would calculate
    given the clock speed and the bit count. The receiver can receive data
    in 9.5 bit times per byte rather than the 10 bit times per byte the
    transmitter takes to send them. That is where the 0.5 bit or about 5%
    rate mismatch numbers come from.


    Rick "rickman" Collins

    Ignore the reply address. To email me use the above address with the XY

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
  12. rickman

    rickman Guest

    I think I just understood what is wrong with my thinking. I was only
    looking at one direction. The problem the OP has is that he is looping
    back the received data and retransmitting it at the same slow(er) rate
    the receiver is using. Since the transmitter must use a full 10 bits,
    then the buffer between the receiver and transmitter will overflow at
    some point.

    This is a problem that is found in communications systems. All units
    must run at the same rate, but may use a different reference. So if
    they receive data at 8.0000 kHz and try to DAC it at 7.9999 kHz, about
    once per ten seconds there will be a byte too many and a sample will
    have to be dropped. This will cause a noticable click or other
    distortion of the voice.

    Some systems try to buffer this out, but that only postpones the
    problem. Most systems use a common reference that is very accurate and
    stable. Then the ADC and DAC clocks must be sync'd to the reference. I
    worked on a system that used a bendable VCXO to establish the 8 kHz
    rate. As the buffer data count varied from half full, the VCXO rate was
    increased or decreased by small amounts to keep the average rates

    In the case of the OP, the first channel can use two stop bits and the
    echo channel can use one stop bit. This may not be pretty, but it will


    Rick "rickman" Collins

    Ignore the reply address. To email me use the above address with the XY

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
  13. Joel Kolstad

    Joel Kolstad Guest

    Hi Rick et al.,

    I'm glad someone else agrees with me! I think we'd all agree now, then,
    that either you need an adjustable output clock or the part to transmit with
    a shortened stop (or start) bit, which is effectively the same thing as
    adjusting your output clock rate anyway.
    ....or they force the data to be encoded with its clock so that a PLL can
    extract the exact frequency reference and work with that.
    It certainly will but the price is a reduction of ~10% of the average
    throughput! Of course, that may be negligible depending on the system.

  14. Jean Nicolle

    Jean Nicolle Guest

    Hi all,

    I've posted some code to do a UART last week on the fpga4fun site...

    For the receiver, the bits are sampled in the middle - with the sampling
    point configurable.

    Also, the receiver starts checking for a "start" as soon as the "stop"
    mid-point bit is detected, so that should be consistent with the
    recommendations posted earlier.

  15. I finally found from another post that the OP was trying to build a loop
    back device that would send back everything it received. Since it is
    possible to receive a character in (about) 9.5 bit times, but it takes
    10 to send it, (8N1), an unbuffered device could quickly lose data.

    It seems that this is not one of the cases the protocol was designed to
    handle. As far as I know, the popular full duplex with remote echo
    would not have been considered when the protocols were defined.

    Also, as far as I know both the popular XON/XOFF and RTS/CTS flow
    control are relatively recent inventions. RTS/CTS is from the real half
    duplex days, where only one side could transmit at a time.

    Part of the asynchronous protocol is that both ends have their own clock.

    For T1 and related protocols, one end synchronizes its clock to the
    other, so that there is no speed matching problem.

    For ethernet, the receiver synchronizes to the transmitter from clock
    information in the data stream.

    It should be possible to build a device with a UART and PLL to
    synchronize the transmit clock to the incoming data rate. There should
    probably be some buffer to last until the PLL locks.

    -- glen
  16. UARTs are almost always crystal controlled, so the tolerance is less
    than 1 percent, and there shouldn't be a problem with this. When a
    serial data stream is run through a multiplexer, where the sampling
    rate is less than 10x per bit, then you might see such large
    deviations ("dereviations").

    @@[email protected]@[email protected]@@[email protected]@[email protected]@[email protected]@@[email protected]@[email protected]@[email protected]@,@@[email protected]@[email protected],@@[email protected]@[email protected]@[email protected]@
    ###Got a Question about ELECTRONICS? Check HERE First:###
    My email address is whitelisted. *All* email sent to it
    goes directly to the trash unless you add NOSPAM in the
    Subject: line with other stuff. alondra101 <at>
    Don't be ripped off by the big book dealers. Go to the URL
    that will give you a choice and save you money(up to half). You'll be glad you did!
    Just when you thought you had all this figured out, the gov't
    changed it:
    @@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@@[email protected]@[email protected]@@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@[email protected]@@
  17. Error accumulates. 1% means that receiver accepts 9.9bit long farmes while
    transmitter transmits 10.0 bit-long frames. After re-transmitting 100 bytes
    (frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not
    enaught. The longer the stream the lager the buffer required. Infinite
    buffer is required for continous stream. As masters stated, UART was not
    designed for this purpose.
  18. "valentin tihomirov"
    Some UARTs are designed for this purpose
    - look at the data for Philips 26C94 families, and esp. the
    area of Sending fractional stop bits.
  19. you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks
    .... ALL async UARTs MUST be capable of handling this.. that's why there's
    flow control.

    You will find that 99.9% of them start looking for the start bit 1/2 way
    thru the stop bit. If you want to build a repeater then you will need a
    fractional stop bit generator OR you can over spec the crystal by 1.5% (or
    the baud rate generator) OR you add RTS / CTS flow control like everybody

  20. Joel Kolstad

    Joel Kolstad Guest

    There are a lot of systems in the world that don't use flow control and
    simply rely on a 'mutual agreement' between the interconnected devices that
    large streams of unbroken serial data isn't produced. This is especially
    the case of, e.g., sensors that produce real-time RS-232 output data with no
    buffering of their own -- in such a case flow control would just throw data
    away, so it's often not implemented to begin with. (I have a motto
    something to the effect of... if detecting an error does no more good than
    just ignoring it, you might as well ignore it... Although unfortunately this
    idea is often perverted into, 'if detecting an error takes effort, even if
    ignoring it causes the machine to rip off someone's arm, you might as well
    ignore it because otherwise the customer will immediately be able to pin the
    blame on you rather than having to guess whose fault it is.' :-( )
    1 -- The fractional stop bit generator is a good idea, and is apparently
    implemented in -- some -- commercial devices. This was news to me, but it
    does seem to be a very good solution.
    2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
    is inherently non-scalable -- I can't connect together a dozen of these
    repeaters unless each one is progressively 1.5% faster, which isn't viable.
    3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
    just that the real world doesn't always play by those rules. :)

    ---Joel Kolstad
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day