USB-TTL UART accuracy and tolerance tests

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm wondering if anyone has already done thorough UART accuracy and tolerance testing.  I've read a couple posts where people have tested the timing output of a UART module (and have done that myself in the past), but haven't found any tests on the input tolerance range.  I've read lots of documents that go over the theory for what kind of accuracy is required, but without any real-world tests.

What I mean by input tolerance is when I have an AVR running off the internal RC oscillator, my Pl2303HX modules (with an external 12Mhz xtal) will read the data error-free even when the AVR is 6-7% fast or slow.  When testing at 115.2kbps, my CH330 starts getting garbled characters when the AVR is only 1-2% fast, but it will receive error-free when the AVR is as much as 7-8% slow.  My CP2102 module seems to start getting errors when the timing is off by more than 4-5%.

In theory for 1 start bit + 8 data bits you need an accuracy of better than 9/8.5 = 5.88% for error-free reception without a sophisticated receiver that can re-clock on bit transitions.

 

I'm thinking of designing a project to automate testing of USB-TTL UARTs, but don't want to re-invent the wheel if someone else has already done all or some of the work.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

are there any clues in the chip datasheets ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The short answer: in general, the UART receiver samples each bit in the centre of its expected arrival time. If the clock at the transmitter and the clock at the receiver are not synchronised then they drift with respect to each other. Unless the clock is truly atrocious, over a short period they're unlikely to drift and can generally be considered constant.

 

The problem arises mostly when the transmit clock is slow with respect to the receive clock; the receiver will be looking for centre of each bit a little earlier with each successive bit and eventually it can sample the stop bit at the end of the last transmitted bit. Up to that point, the byte has been correctly received, but if the last bit is a logic low then because a logic high is expected for the stop bit then a framing error will be triggered. We can work out the differential error for this for each bit pattern, but with the most common 8-bit, one stop, no parity option, the maximum permissible error is when the transmit clock is is 5% slower than the receive clock. The receiver gets through 20 half-clock periods while the sender only does 19 of them.

 

Similarly if the transmit clock is fast, the start bit of the next byte might be received by the stop bit detector; this requires a significantly faster clock which is difficult to quantify because of a potential idle period between bytes. But again, it will be at least 5-6% faster.

 

Possibly of more significance is the way the clocks are generated at each end. If they are crystal locked at both ends, then each end can be expected to be within fifty parts per million; well within the error limits. But an internal RC clock can both be inherently inaccurate and significantly drifty over short and long time periods, perhaps mediated by temperature.

 

A final point to consider is the absolute baud rate. Pretty much every baud rate generator on a microcontroller (and external uart chips) calculates the final clock frequency - nominally eight or sixteen times the baud rate - by dividing the master clock by some integer. If the clock is not an integer multiple of the baud rate, there will be an immediate error. For low baud rates, the divisor will be large and the error therefore low; as you get to higher baud rates the divisor might be only two or three - obviously with a significant error.

 

End result? Unless you know the details of both ends of the transmission chain, you can't even begin to calculate the error. If both ends happen to be wrong in the same direction, things might work well... or not. Best practice is to get your end - with suitable choices of clocks and divisor rates - as close to the defined rate as possible. Ideally you would get the exact rate, but as I pointed out that's increasingly difficult at higher rates. At worst, your calculated rate should be within 2% of nominal. Most UART data sheets will have a table of divisor, clock, and error rates to help you choose.

 

Of course, of you control both ends, you can pick a rate to suit yourself... it doesn't have to be one of the 'official' ones.

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

are there any clues in the chip datasheets ?

 

I'm looking for real-world testing, not theoretical estimates based on datasheets.  I want to know which USB-ttl chips have the widest input tolerances and the tightest output tolerances.  In addition to satisfying my own curiosity, I want to be able to provide fact-based recommendations for people using my UART libraries.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
the UART receiver samples each bit in the centre of its expected arrival time.

some UARTs take multiple samples around the centre of the expected arrival time, and do a "majority vote" on them - to aid noise immunity.

 

I guess this will tend to reduce the timing error tolerance ... ?

 

I don't know if this applies to the UART function in any or many USB-to-UART converters.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ralphd wrote:
I'm looking for real-world testing, not theoretical estimates based on datasheets.  I want to know which USB-ttl chips have the widest input tolerances

Sure. But examining the datasheets could help you narrow down the potential best candidates ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, I would expect absolutely no consequence to being a TTL uart vs RS232. The only difference is the line driver/receiver which is separate from the USB interface chip. The line interface should have no effect on baud rate timing; that will all be in the USB chip because that is where the UART is implemented.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

ralphd wrote:
I'm looking for real-world testing, not theoretical estimates based on datasheets.  I want to know which USB-ttl chips have the widest input tolerances

Sure. But examining the datasheets could help you narrow down the potential best candidates ?

 

I'm sticking to what's cheap and common, most of which I already have on hand.  My short list is CP2102, PL2303HX, CH330, CH340G, and maybe HT42B564.

 

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So you want to do BER (bit error rate) testing over the full temperature and voltage ranges of a number of chips? How do you propose to simulate real world noise? 

Sounds like a lot of work and I'll expect you'll learn something along the way. I'm not sure if you'll advance the state of the art though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are at least two things in play:

  1. How accurate is the BRG on the USB/Serial chip at the particular bitrate it's configured for.  Does it have a fractional BRG?  How many bits of fraction?  What's it's internal clock rate; a lot of chips have a 12MHz Crystal, but don't they multiply that to get at least 48MHz for USB clocking?  Which is used for the BRG?  Are you using a magic bitrate that is especially good or bad?  (The 16u2 on Official Arduino Unos is famously programmed to have a less accurate 57600bps, as long as it's less accurate in the same direction as the Arduino Core.)
  2. What is the sampling strategy, and does the help or hurt with less matching bitrates?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ralphd wrote:
I'm wondering if anyone has already done thorough UART accuracy and tolerance testing.

Well I suppose most devs are like me; satisfied once they get UART comms working, then never look at it again.

 

I did get bitten once though - we had a UART interface that been working well for years; then we added a command with a much longer payload than previously. We now got errors towards the back end of the payload. Our board used a 4MHz ceramic resonator and couldn't do 9600 exactly and the error accumulated disastrously over about 40 continuous characters.

 

I had to split the payload into 16 character chunks and send them with a delay between to allow the receiver to re-synch.

 

How is ralphd going to introduce the affect of message length into his testing ? No one Very few folks send just one character do they.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

I did get bitten once though - we had a UART interface... 

 

Odd. I *thought* that the USART re-synchronised at the start of every byte, by starting its internal state machine on the falling edge of every start bit. That *should* make the length of any message immaterial.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sending an extra stop bit on each character will usually allow the receiver to resynchronise on each character (i.e. send at 8-n-2 and receive at 8-n-1).

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

some UARTs take multiple samples around the centre of the expected arrival time, and do a "majority vote" on them - to aid noise immunity.

I think I read in at least one Atmel data sheet or app note long go that they do (or did) that.

Would certainly be interesting to see which of these interface chips is the most tolerant (a side-by-side comparison)

Another thing to look at is when do the various error flags start becoming activated.

 

...For now, I just stick with a nice solid crystal & prob would continue to do so, since it's a good 10cent investment. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. May 13, 2020 - 07:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many UARTs do majority vote. They have a lower tolerance to timing errors but only slightly; not really enough to worry about... if you're that far off, you've already got a broken comms system; a majority vote may have a better chance of telling you that the received byte is correct.

 

As I said earlier: keep your local baud rate less than two percent out and you'll be fine. Best bet: use a crystal.

 

Neil

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Best bet: use a crystal.

 The number of new chips with no high-speed crystal oscillator (and no multiplier scheme) is getting worrisome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 The number of new chips with no high-speed crystal oscillator (and no multiplier scheme) is getting worrisome.

They should enforce one of those "hard to get to" write sequences to enable/unlock the UARTS when RC fuse setting is in effect....kind of a "are you sure you want to do this" check.  Of course that would prob result in further mayhem.  

Too many never heard of a crystal &  fall into deep do-do when tolerances knock them down (after the 2000 board order has shipped).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What "RC Oscillator"?  It's a "Calibrated internal oscillator" with "Stored Frequency Error Compensation" - I'm sure it's "fine"!

 

(well, I also suspect that bad communications is the result of picking a bad crystal frequency nearly as often as it is using an out-of-spec internal oscillator.  115.2kbps most common bit rate on a m328 with 16MHz crystal - "what were they thinking?")

 

 

Last Edited: Thu. May 14, 2020 - 09:18 AM