UART timing

Started by Ross Marchant September 8, 2005
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