UART timing

Hi all,


If a UART baud rate is out by 1.6% will this cause errors? i.e. if the  
baud rate is 9600 +- 1.6% will a receiver get any erroneous bytes? What  
about if the receiver has some kind of auto-baud... I would guess that if  
the transmitter baud rate is a little slow then the receiver might get an  
overrun errors and try for a slower rate?

Ross

Ross Marchant <acqua@spammytpg.com.au> wrote:

: If a UART baud rate is out by 1.6% will this cause errors? i.e. if the  
: baud rate is 9600 +- 1.6% will a receiver get any erroneous bytes? 

If you are running async then that sort of error will not cause problems.
The async start bit causes a resync, and after the usual 10 bits of async 
data the drift has not got far enough to cause problems. You can have 
more error than that and still work

: ......What  
: about if the receiver has some kind of auto-baud... I would guess that if  
: the transmitter baud rate is a little slow then the receiver might get an  
: overrun errors and try for a slower rate?

: Ross

Ross Marchant wrote:
> Hi all,
>
>
> If a UART baud rate is out by 1.6% will this cause errors? i.e. if the
> baud rate is 9600 +- 1.6% will a receiver get any erroneous bytes? What
> about if the receiver has some kind of auto-baud... I would guess that if
> the transmitter baud rate is a little slow then the receiver might get an
> overrun errors and try for a slower rate?


The limit for async is 2%.  If the sender and receiver are off 2% in
opposite directions, the sample point for the last bit is pushed to
near the edge of the useable limit.

If you know that one side or the other is bang on, you can have the
other side be 4% off.  In general so long as the two side are within
about 4% (or a smidge more) of each other you'll be OK, but you'll
obviously not be assured of reliable communications with other RS-232
devices in general.

<robertwessel2@yahoo.com> wrote in message
news:1126216754.028825.12900@o13g2000cwo.googlegroups.com...
>
> Ross Marchant wrote:
> > Hi all,
> >
> >
> > If a UART baud rate is out by 1.6% will this cause errors? i.e. if the
> > baud rate is 9600 +- 1.6% will a receiver get any erroneous bytes? What
> > about if the receiver has some kind of auto-baud... I would guess that
if
> > the transmitter baud rate is a little slow then the receiver might get
an
> > overrun errors and try for a slower rate?
>
>
> The limit for async is 2%.  If the sender and receiver are off 2% in
> opposite directions, the sample point for the last bit is pushed to
> near the edge of the useable limit.
>
> If you know that one side or the other is bang on, you can have the
> other side be 4% off.  In general so long as the two side are within
> about 4% (or a smidge more) of each other you'll be OK, but you'll
> obviously not be assured of reliable communications with other RS-232
> devices in general.
>

Thanks, I'm trying to solve a problem for someone remotely.
Symptoms:
* HyperTerminal connection to GPRS modem at 9600 baud works fine. Messages
come through fine at server.
* Embedded device connection to GPRS modem at 9600 baud doesn't work
properly. AT commands have to be sent one byte at a time slowly, and once
connected messages sent come out as garbage at server end.

Sounds to me like the embedded device's baud rate is way off, although I am
assured its only 1.6%. Maybe the modem is out by 3% and hence the error
occurs.

Ross

>
>Thanks, I'm trying to solve a problem for someone remotely.
>Symptoms:
>* HyperTerminal connection to GPRS modem at 9600 baud works fine. Messages
>come through fine at server.
>* Embedded device connection to GPRS modem at 9600 baud doesn't work
>properly. AT commands have to be sent one byte at a time slowly, and once
>connected messages sent come out as garbage at server end.
>
>Sounds to me like the embedded device's baud rate is way off, although I am
>assured its only 1.6%. Maybe the modem is out by 3% and hence the error
>occurs.

Did you check if the modem and embedded device use the same data
format (mostly 8N1) ? 
-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

On Fri, 9 Sep 2005 10:26:53 +1000, "Ross Marchant"
<rossm@NOexcelSPAMtech.com.auSTRALIA> wrote:

>* Embedded device 

Are you sure that the embedded device generates true RS-232 voltage
levels and not some "RS-232" compatible levels from a 5 V inverter ?

>connection to GPRS modem at 9600 baud doesn't work
>properly. AT commands 

Is autobauding enabled at the GPRS end ? Try disabling it. In
autobauding, the A and T characters are used to determine the speed of
the line and if the speed is too much away from the standard speed,
some erratic speed settings might occur.

>have to be sent one byte at a time slowly, and once
>connected messages sent come out as garbage at server end.

This would suggest that the transmit clock is more than 5 % higher
than the receiver clock. When the final stop bit is being received,
the receiver sample pulse should be in the middle of the stop bit.
After detecting the proper stop bit, the receiver would enable the
edge trigger (1->0) to wait for the next start bit. However, with a
too slow receiver clock, the stop bit sample pulse is at the end of
the stop bit or perhaps after the end of the character. 

When sending characters individually, the Mark state remains stable
long after the stop bit, so it will get a stable detection of the Mark
state (=equivalent to a stop bit) even if the sample pulse is long
after the end of the character.

When sending a string of characters, the next start bit is immediately
after the stop bit of the previous character. If the stop bit sample
point has been delayed into the next start bit, the Space state is
detected and the receiver would declare a framing error ("missing stop
bit")  and just the next 1->0 transition (now inside the next
character) is (incorrectly) interpreted as a start bit. Thus, a long
string of garbage is received, when the character synch is lost.

Try setting two stop bits when sending a string of characters. If this
works, this would be a clear indication of this kind of problem.

Are you sure that the embedded transmitter is actually transmitting a
decent stop bit. For instance in the QUICC coprocessor (in Motorola
MC68360/MPC860 etc.) there is an option of cutting the stop bit
shorter or even eliminate it. Make sure that this option has not been
selected.

Paul

>
> Thanks, I'm trying to solve a problem for someone remotely.
> Symptoms:
> * HyperTerminal connection to GPRS modem at 9600 baud works fine. Messages
> come through fine at server.
> * Embedded device connection to GPRS modem at 9600 baud doesn't work
> properly. AT commands have to be sent one byte at a time slowly, and once
> connected messages sent come out as garbage at server end.

Which GPRS modem are you using? - I have used some GSM/GPRS modems that
are *very* picky about getting the baud rate spot on. Which embedded
processor are you using and what's the clock source?

Iain Tebbutt
www.claritech.co.uk

Ross Marchant schrieb:
> 
> Thanks, I'm trying to solve a problem for someone remotely.
> Symptoms:
> * HyperTerminal connection to GPRS modem at 9600 baud works fine. Messages
> come through fine at server.
> * Embedded device connection to GPRS modem at 9600 baud doesn't work
> properly. AT commands have to be sent one byte at a time slowly, and once
> connected messages sent come out as garbage at server end.
> 
> Sounds to me like the embedded device's baud rate is way off, although I am
> assured its only 1.6%. Maybe the modem is out by 3% and hence the error
> occurs.
> 
Hello,

there are some microprocessors with built in UART which generate the 
baudrate clock from a 20 MHz clock. For 9600 Baud, there is an error of 
+ 1 % or - 1,4 %, but this error does not affect the communication.
What about messuring the signals with a scope? Some care is necessary to 
measure UART signals with a precision better than 1 %.

Bye

On Fri, 09 Sep 2005 18:05:35 +1000, <tebbutt@hotmail.com> wrote:

>>
>> Thanks, I'm trying to solve a problem for someone remotely.
>> Symptoms:
>> * HyperTerminal connection to GPRS modem at 9600 baud works fine.  
>> Messages
>> come through fine at server.
>> * Embedded device connection to GPRS modem at 9600 baud doesn't work
>> properly. AT commands have to be sent one byte at a time slowly, and  
>> once
>> connected messages sent come out as garbage at server end.
>
> Which GPRS modem are you using? - I have used some GSM/GPRS modems that
> are *very* picky about getting the baud rate spot on. Which embedded
> processor are you using and what's the clock source?
>
> Iain Tebbutt
> www.claritech.co.uk
>

The modem is the Audiotel industrial plus, the processor is the Atmel  
ATMEGA8L using internal clock source. There is an RS232 driver with -10V  
on TX.

I have used the Alphamicro GPRS modem successfully with my own embedded  
stuff. I think it *must* be the baud rate in this particular instance.

Thanks
Ross

On Fri, 09 Sep 2005 15:34:03 +1000, Paul Keinanen <keinanen@sci.fi> wrote:

> On Fri, 9 Sep 2005 10:26:53 +1000, "Ross Marchant"
> <rossm@NOexcelSPAMtech.com.auSTRALIA> wrote:
>
>> * Embedded device
>
> Are you sure that the embedded device generates true RS-232 voltage
> levels and not some "RS-232" compatible levels from a 5 V inverter ?
>
>> connection to GPRS modem at 9600 baud doesn't work
>> properly. AT commands
>
> Is autobauding enabled at the GPRS end ? Try disabling it. In
> autobauding, the A and T characters are used to determine the speed of
> the line and if the speed is too much away from the standard speed,
> some erratic speed settings might occur.
>
>> have to be sent one byte at a time slowly, and once
>> connected messages sent come out as garbage at server end.
>
> This would suggest that the transmit clock is more than 5 % higher
> than the receiver clock. When the final stop bit is being received,
> the receiver sample pulse should be in the middle of the stop bit.
> After detecting the proper stop bit, the receiver would enable the
> edge trigger (1->0) to wait for the next start bit. However, with a
> too slow receiver clock, the stop bit sample pulse is at the end of
> the stop bit or perhaps after the end of the character.
>
> When sending characters individually, the Mark state remains stable
> long after the stop bit, so it will get a stable detection of the Mark
> state (=equivalent to a stop bit) even if the sample pulse is long
> after the end of the character.
>
> When sending a string of characters, the next start bit is immediately
> after the stop bit of the previous character. If the stop bit sample
> point has been delayed into the next start bit, the Space state is
> detected and the receiver would declare a framing error ("missing stop
> bit")  and just the next 1->0 transition (now inside the next
> character) is (incorrectly) interpreted as a start bit. Thus, a long
> string of garbage is received, when the character synch is lost.
>
> Try setting two stop bits when sending a string of characters. If this
> works, this would be a clear indication of this kind of problem.
>
> Are you sure that the embedded transmitter is actually transmitting a
> decent stop bit. For instance in the QUICC coprocessor (in Motorola
> MC68360/MPC860 etc.) there is an option of cutting the stop bit
> shorter or even eliminate it. Make sure that this option has not been
> selected.
>
> Paul
>

Thanks for your detailed reply Paul, I'm convinced that it is a baud rate  
issue too, especially since I have been told that the device uses the  
internal clock to generate the UART clock! The RS232 TX voltage is -10V so  
its not the driver. The modem has an autobaud feature. I can't do any  
repgramming as I have only been given a product to test, but I will pass  
on the comments. Thanks heaps.

Ross