On Sat, 10 Sep 2005 15:34:42 +0200, in msg
<1126359097.38a04f151dbeec5d386d9018010aead9@teranews>, Anton Erasmus
<nobody@spam.prevent.net> wrote:

>On Sat, 10 Sep 2005 09:12:27 +1000, "Ross Marchant"
><acqua@spammytpg.com.au> wrote:
>
>>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 use the same processor, and RS-232, in many of our products.

When using the internal clock source, and RS-232 on the Atmel parts you *must*
use the clock calibration byte to properly calibrate the internal clock or your
baudrate can be off enough to cause problems.

-Zonn
-- 
Zonn Moore            Remove the ".AOL" from the
Zektor, LLC           email address to reply.
www.zektor.com

On Sat, 10 Sep 2005 09:12:27 +1000, "Ross Marchant"
<acqua@spammytpg.com.au> wrote:

>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.
>

The internal clock is voltage and temperature dependant. As a test you
can try changing one or the other. As a long term solution, a more
accurate and stable clock is a must.

Regards
  Anton Erasmus

On Sat, 10 Sep 2005 09:40:58 +1000, "Ross Marchant"
<acqua@spammytpg.com.au> wrote:

> 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.

Check the AT command set for the GPRS modem, it might contain a
command to set a fixed baud rate, thus disabling the autobauding.

Paul

Ross,

did you have a look at the ATMEGA specification for the IRC? It is
horrible, there is a temperature drift from -40 / 85 C of almost 10%.
If you voltage changes e.g. battery driven the difference between a 5V
supply and 2.7V is more than 10% (without the temperature drift).
Companies that are serious about using the Internal RC with a UART
specify the max. drift over temp e.g. Philips LPC938 which is similar
to the ATMEGA but a 2-clock core has less than 2.5% across the
temperature range and is trimmed to better than 1% at room temp.

We used this one without any problems running a UART.

An Schwob


Ross Marchant wrote:
> 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

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

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


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

>
> 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

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