Baud rate errors

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

Anyone know how much error in baud rate is viable, for a UART that uses the typical 16x (sampling?) formula?

My problem:
microprocessor #1 has a 16MHz clock. ( can't change it).
microprocessor #2 has a 147456MHz clock. (yea!)
Neither is new enough to have a fractional baud rate divider.

At 115200, the difference is about 3.5%.
1/16 is about 6%.
If common UARTS oversamples with 16x, it would seem the tolerable error is then driven by ??? I recall that every start bit in common UARTs is 1.5 bit-times. Perhaps the sampling starts after the nth sample in the start bit - then for a stream of bytes, the error is cumulative... or does the UART re-sync to the byte-frame at the stop bit?

From here I get lost.

I'm fishing for why microprocessor #2 seems to lose bytes - about one in 500 data frame bursts, where a burst is about 40 bytes. Bursts have a lot of idle (marking) time in between them.

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

Mutual difference should better be held within +-1% which yields to individual tolerance of <= 0.5%.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Well you actually can get away with 2% at either end so 4% in total.

As to the problem - I know it's only papering over the cracks but could you not packetise the data with checksum/CRC and an ACK/NAK strategy to get corrupt ones resent?

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

stevech wrote:
Anyone know how much error in baud rate is viable, for a UART that uses the typical 16x (sampling?) formula?

Maxim has appnotes about this, and AVR datasheets have too. For 1 start bit, 8 data bits and stop bits using 16x sampling, you have 10 bits total meaning 160 sample clocks.

Depending on microcontroller/uart/whatever, they may use majority logic features to sample three middlemost bits and use the value it sees at least 2 times, or they might just sample once in the middle.

In the middle is then 8 clocks from start or end of the bit because a bit is 16 clocks wide. So deviation of 8 clocks per 160 clocks would be the absolute theoretical maximum allowed error to sample the starting or trailing edge of stop bit. It 8/160 is 5%. In practice the sampling phases will differ and all kinds of tranceivers and transmission lines cause skew so the maximum error should be anyway around 4%.

That means either end can deviate up to about 2% of the nominal and it should still work. This is what AVR datasheets say as well.

stevech wrote:

My problem:
microprocessor #1 has a 16MHz clock. ( can't change it).
microprocessor #2 has a 147456MHz clock. (yea!)
Neither is new enough to have a fractional baud rate divider.

At 115200, the difference is about 3.5%.
1/16 is about 6%.
If common UARTS oversamples with 16x, it would seem the tolerable error is then driven by ??? I recall that every start bit in common UARTs is 1.5 bit-times. Perhaps the sampling starts after the nth sample in the start bit - then for a stream of bytes, the error is cumulative... or does the UART re-sync to the byte-frame at the stop bit?

From here I get lost.

I'm fishing for why microprocessor #2 seems to lose bytes - about one in 500 data frame bursts, where a burst is about 40 bytes. Bursts have a lot of idle (marking) time in between them.

Start bit is exactly 1 bit or it would not work. Stop bit can be as long as forever. The re-sync starts from the leading edge of start bit, and many microcontrollers have some kind of noise detection logic there as well, so the point where resync happens it is not so black and white. Then all bits are clocked in in the middle, the stop bit being the last. Stop bit needs to be sampled high, but in theory, after the receiver has sampled it, another start bit can be transmitted, so 8 clocks early is the maximum.

You don't say if you need the devices only to talk together or with other equipment like PC as well, but you must select a baud rate that has below 2% error, preferably less. If you use 1 start, 8 data, 1 stop, no parity. All this will be different if you use more or less bits.

Sounds to me if those are the frequencies and standard baud rates must be used and 16x sampling, then all you can do is 38400. 57600 might work if 8x sampling were available.

If non-standard baud rates are acceptable and the devices only talk to each other, you could use 76800 very reliably.

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

16MHz and 115200 is ok if you use 2X mode. Tried that?

Imagecraft compiler user

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

Quote:
I'm fishing for why microprocessor #2 seems to lose bytes
Maybe it has nothing to do with the uart. Maybe cpu2 is too busy sometimes to get data out of uart buffer fast enough. I would assume you are checking for overrun and framing errors, though. I don't think you are going to get 'screwed up' data (timing) without a framing error. No buffer overrun or no framing error on cpu2 = cpu1 probably not sending the missing bytes for some reason. You could also try using 2 stop bits for kicks.

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

Are you limited to standard baud rates, or is this a private connection between just the two devices? In the latter case you should be able to find a non-standard rate that produces a lower baud error.

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

Also check: caps on the max232s correct? Some buffers cant keep up with 115200?

Imagecraft compiler user

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

thanks for the comments...

I'm checking for, seeing no receiver errors like framing and FIFO overflow (16 deep FIFO on receiving end w/interrupt at 8 bytes or char timeout- this is like the 16550 UARTs do).

I slowed the baud rate to 57600 but the errors persist - so the 3.5% mismatch seems not to be the culprit. Now, to prove that this is on the receiving end (transmit side not at fault) I'll wire up a data flow eaves-dropper PC serial port in a bridge fashion. No FIFO overflow errors (receiving micro has that sort of UART), no framing errors, and if the interrupt latency was horrible (like many tens of microseconds), I'd see framing errors, I think. All I see is missing bytes.

I have a 'scope but don't have a serial data analyzer.

Once if find/cure the error, I will look at non-standard baud rates. With UARTs that don't have fractional dividers (as do many today), and 16MHz against 14.745600MHz, the best seems to be two different divisors and a < 1% error at a bout 80Kbaud. I'd like to find dividers that would go to say, 160Kbps.

Re RS232.. not using it; this is logic level and the connection is a few inches of PC board traces.

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

OK, but I'm tellin ya that 2x mode on one or both might work. Try it already!

Imagecraft compiler user

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

I suspect you either have Kevin's AVRCalc, or something similar to make it easy to see the baud rate error for different baudrates and Xtals.

JC

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

Quote:
All I see is missing bytes
A little mind-bender :)

I don't know how you would get a 'baud mismatch' where the rx end didn't end up with framing errors. Since the rx end is not getting errors, the rx must be happy with the rate its seeing. It would be quite odd to have a baud mismatch that mattered without also seeing a framing error (at least with multiple bytes incoming, anyway).

On the original question-
I suppose it depends on when the rx starts checking for a start bit on back-to-back bytes- either at the end of the stop bit, or when it 'checked' the stop bit 'halfway' into the stop bit. If it needs to clock through the whole stop bit (8/16 baud clocks) before it starts checking for the next start bit, then baud rate errors would accumulate on back-to-back bytes (if tx faster than rx). Now, if you use 2 stop bits on the tx, I think the rx ignores the second stop bit (there is really nothing to see) and will then have some time to re-sync up to the next start bit, leaving any baud errors contained inside a single byte.

I think.

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

you can go for
83333.33333 @16MHz
83781.81818 @14.7456

and you can make 2x of that speed with both

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

I fail to see what the problem is.

16MHz AVR can do 115200 baud with U2X bit.
14.756MHz AVR can do any baud rate you like even with its hands tied.

Simply choose your baud rate. Set UBRR correctly for each AVR and away you go.

You will probably benefit from a proper interrupt service routine. There are many good library examples.

There are also many appalling examples (judging by what we see here)

David.

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

as this is placed in "General Electronics" I will assume that it's not AVR's we are talking about!

but
83333.33333 @16MHz
83781.81818 @14.7456
still holds, but perhaps 2x of that don't

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

I am still confused. All the 8-bit microcontrollers that I have ever come across tend to have F_CPU/16 somewhere in the calculation. Albeit with an extra div4 or div12 to account for cycles per operation.

Yes, I suppose that you can choose some non-standard baud rate that satisfies both F_CPU/16 values. Life is generally simpler if you stick to conventions.

I suspect this problem really comes down to using sensible ISR(RXC), rx_avail() and getchar() functions.

With a 14MHz AVR and a respected compiler, full-speed 115200 baud should work just fine. (unless you have serious ISR() loading from higher priority vectors)

Bear in mind that 115200 baud with U2X is reliable with a hard-wired connection. 57600 baud with 16x sampling would be safer for a 'noisier' link.

David.

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

My crystal ball is picking up on an external uart with a fifo as described in a previous message. Would it help us to know its part number perhaps? Gee, maybe it drops every 8th charcter when the fifo fills up?!?

Imagecraft compiler user

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

Quote:
My crystal ball is picking up on an external uart with a fifo
Your crystal ball needs a tuneup. :)

My crystal ball has just been serviced, it says 'Arm7'.

Thousands and thousands of bytes coming in, and not a single framing error. Nothing wrong with getting the baud rates matched as close as possible, but in this case 'these aren't the droids you're looking for, move along'.

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

Yes, I did a lot of testing, 'scope work, and wired up a PC's real serial port RX-only for eavesdropping. Reduced the baud rate so the error is small. I'm on the trail of some other infrequent I/O event causing a huge increase in interrupt latency.

I thing I've been shunned by curtvm so I'll go into radio silence.

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

Quote:
I thing I've been shunned by curtvm
Obi-Wan spoke the words, I just quoted them. (Also remember, that those WERE the droids they were looking for.)

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

Problem solved. typo in code for code other than the serial ISR... caused occasional long interrupt latency.

So the 3.5% baud rate mismatch at 115200 is tolerated.