best way to use UART for GSM modules

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

Hi!

I'm trying to find out the best way to configure the USART for interfacing with a GSM module.

I used to configure the USART with interrupt mode and fill a buffer, expecting an start character and end character in the received data.

Now I find that sometimes the GSM module send several data that doesn't work with my method. For example, if I send AT+CREG?, the module response is something like
+CREG: 0,1OK

I started to think that interrupt mode is not the best way to process received data.

According to your experience, what is the best way to receive and process ?

thanks!

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

I think you are mixing-up the low-level process of sending & receiving bytes with the higher-level process of interpreting those bytes as AT Commands & Responses.

AT Commands & Responses are not fixed-length, so your UART code needs to cope with that.

Probably the easiest way is to use a ring-buffer between the UART and the AT handler.

Probably a State Machine in the AT handling...

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

Quote:

if I send AT+CREG?, the module response is something like
+CREG: 0,1OK

Googling that it just means the module is registered on a home network - what's wrong with that? I'm not sure what you are suggesting the problem is?

For most system I'd usually choose to poll the Tx and interrupt on the Rx. That works as you tend to Tx synchronously but the responses may be asynchronous.

So to be honest I'm not entirely sure I understand where the "problem" is in all this?

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

jorge.ar wrote:
the module response is something like...

For a proper understanding of how the AT Commands & Responses are structured, study the ITU V.250 spec, and GSM AT Command specs:

https://www.avrfreaks.net/index.p...

https://www.avrfreaks.net/index.p...

and, of course, the specific AT Commands documentation for your oarticular module

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

awneil wrote:
I think you are mixing-up the low-level process of sending & receiving bytes with the higher-level process of interpreting those bytes as AT Commands & Responses.

AT Commands & Responses are not fixed-length, so your UART code needs to cope with that.

Probably the easiest way is to use a ring-buffer between the UART and the AT handler.

Probably a State Machine in the AT handling...

You're right, I'm mixing the low level and the sending&receiving.

I will read about ring buffers. Thanks!

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

clawson wrote:
Quote:

if I send AT+CREG?, the module response is something like
+CREG: 0,1OK

Googling that it just means the module is registered on a home network - what's wrong with that? I'm not sure what you are suggesting the problem is?

For most system I'd usually choose to poll the Tx and interrupt on the Rx. That works as you tend to Tx synchronously but the responses may be asynchronous.

So to be honest I'm not entirely sure I understand where the "problem" is in all this?

The problem isn't the result of the command but the best way of processing the information. Sorry if I was not clear!

I also poll TX and interrupt on RX.

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

Quote:

The problem isn't the result of the command but the best way of processing the information.

As awneil says - this is nothing to do with the low level processing of the individual characters - an interrupt ring buffer IS the best way (as long as the buffer is big enough). Then at a higher level you extract characters until a full response is seen - then act on it.

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

clawson wrote:
Quote:

The problem isn't the result of the command but the best way of processing the information.

As awneil says - this is nothing to do with the low level processing of the individual characters - an interrupt ring buffer IS the best way (as long as the buffer is big enough). Then at a higher level you extract characters until a full response is seen - then act on it.

I'm doing some test with the atmel's application notes AVR1307 - using XMEGA USART. It uses a ring-buffer as you suggested.

thanks for your help!!

Jorge.

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

I wish GSM modems would offer a better interface than the crusty old AT commands. I2C or something would be ideal, but no, we are stuck with a horrible and poorly defined terminal.

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

Quote:

I wish GSM modems would offer a better interface than the crusty old AT commands. I2C or something would be ideal,

You seem to be confusing concepts. I2C would simply replace UART. I don't see that would change the protocol.

Sure AT is too "human" and makes doing it with logic more complex than it ought to be but you could do a binary protocol over UART just as easily as I2C or SPI or whatever wire wiggling technique your heart desired.

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

I mean a proper register based I2C system, none of this AT command rubbish. If you want to know the state of the modem there would be no need to send an ASCII command and parse the result, just read a register over I2C and examine the status code.

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

mojo-chan wrote:
I wish GSM modems would offer a better interface than the crusty old AT commands. I2C or something would be ideal
clawson wrote:
You seem to be confusing concepts. I2C would simply replace UART. I don't see that would change the protocol.

Ha! Ha! We've had exactly that comment before, and that was exactly my reply:

https://www.avrfreaks.net/index.p...

8)

I disagree that the interface is "poorly defined" - it is well-defined and fomalised by the Standards bodies mentioned above (ITU, 3GPP).

IMO, The problem is not so much that the definition is "poor" (sic), but that people don't bother to take the time to properly study and understand it.

But I do agree that it is "human-focussed" at that does make it a lot of effort for machine use.

However, the trend is now away from AT Commands: QMI - the Qualcomm MSM Interface - is the way to go...

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

Free-form test responses that evolved over time with no particular guiding body and which can arrive at any time and not necessarily in response to the last command you issues are not any basis for a good standard.

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

mojo-chan wrote:
I mean a proper register based I2C [or SPI] system, none of this AT command rubbish. If you want to know the state of the modem there would be no need to send an ASCII command and parse the result, just read a register over I2C and examine the status code.
See also: https://www.avrfreaks.net/index.p...

Do you have an actual requirement for that?

If you do, drop me a PM...

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

mojo-chan wrote:
Free-form text responses

They aren't free-form - the structure is well-defined.

Quote:
that evolved over time with no particular guiding body

I suspect that the majority of standards actually evolved from something pre-existing.

The 'C' language itself is a case in point!

Quote:
which can arrive at any time and not necessarily in response to the last command you issues

A great many communications protocols work that way - with asynchronous or "unsolicited" events...

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

I wrote:
the trend is now away from AT Commands: QMI - the Qualcomm MSM Interface - is the way to go...

http://sigquit.wordpress.com/201...

http://blogs.gnome.org/dcbw/2010...

http://forum.xda-developers.com/...


http://www.google.com/patents/US...

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

We use a number of embedded modems in M2M apps at work. QMI looks interesting, but we have a lot of code written for AT command set modems from Telit and others. Qualcom don't want to talk to anyone who isn't going to order a few billion units so... We just have to deal with the crappy AT commands.