Atmega128A Get the response string from sim900

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

I'm going to interface a SIM900 module to atmega 128a mcu via a UART0 port. I was successfully able to communicate with sim900 module using putty serial interface and got the responses. Now my target is to get response into a char array and process the response. General syntax of a AT command is as follows

 

AT\r\n                   //Command sent to modem

AT\r\nOK\r\n         //Response from modem with echo enabled

 

As this syntax doesn't have a termination character or a fixed length can you suggest me a method to get the full response. I have tried this code but it gives a partial response from the sim900 module.

// Code to receive one byte at a time 

uint8_t USART0ReceiveByte()
{
	// Wait for byte to be received
	while(!(UCSR0A&(1<<RXC0))){};
	// Return received data
	return UDR0;
}
// Code to receive the response string


void USART0ReceiveString()
{
	int i=0;
	while(1)
	{
		name[i]=USART0ReceiveByte();
		if (name[i]=='\n')
		break;
		else
		i++;
	}
	name[i++]='\0';
}

Sample responsees for the AT commands

 

  • AT{0D}{0A}{0D}{0A}OK{0D}{0A}
  • AT+CSQ{0D}{0A}{0D}{0A}+CSQ: 19,0{0D}{0A}{0D}{0A}OK{0D}{0A}
  • AT+CGATT?{0D}{0A}{0D}{0A}+CGATT: 1{0D}{0A}{0D}{0A}OK{0D}{0A}
  • AT+HTTPACTION=0{0D}{0A}{0D}{0A}OK{0D}{0A}{0D}{0A}+HTTPACTION:0,200,6{0D}{0A}
  • AT+HTTPREAD{0D}{0A}{0D}{0A}+HTTPREAD:6{0D}{0A}58E2A8{0D}{0A}OK{0D}{0A}

 

Please suggest me a method to get the full response from sim900 module.

 

Thank You!

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

Milprasad wrote:
but it gives a partial response
But those samples look "full" to me. In what sense do you think they are only "partial"?

 

BTW don't just do i++ without some check that i has gone beyond the length of name[]

 

A better approach is probably to setup an RXC interrupt and a ring buffer. Then just pull strings from it until '\n' (0x0A).

 

PS forgot to say that you are only going to be about the 10 gazillionth person trying to attach a SIM300 or SIM900 to a micro so there's tons of code out on the internet showing how to do this. As most of it is "above the hardware" it doesn't really matter whether such examples are for AVR or some other micro.

Last Edited: Wed. Jul 12, 2017 - 08:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If "partial" means that you miss the \n (perhaps later code relies on it being there), that's because you overwrite it with the string terminator.

 

Edit: Now I see what you mean perhaps. The responses contain multiple \n, so receiving until the first \n gives you of course only a partial response. You need to receive until the 3rd \n.

Stefan Ernst

Last Edited: Wed. Jul 12, 2017 - 09:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Milprasad wrote:
AT\r\n                   //Command sent to modem

Note that the AT Command Teminator is just CR - not CRLF.

 

As this syntax doesn't have a termination character 

Yes, it does - the CRLF marks the end of the response.

 

 

clawson wrote:
you are only going to be about the 10 gazillionth person trying to attach a SIM300 or SIM900 to a micro

Or, in fact, any other GSM modem.

 

Or, in fact, anything which uses AT Commands!

 

so there's tons of code out on the internet showing how to do this

Sadly, an awful lot of it makes the fundamental mistake of failing to properly handle responses - but the OP does seem to be onto that one!

 

smiley

 

As most of it is "above the hardware" it doesn't really matter whether such examples are for AVR or some other micro

Or, as noted, some other device using AT Commands.

 

 

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

Only a couple of days ago: http://www.avrfreaks.net/forum/interfacing-gsm-module-at32u3c3

 

EDIT

 

See also:

 

http://www.avrfreaks.net/comment... - note that V.250 is the ITU standard which formalises the so-call "AT Command" structure. It describes both the command termination & response formatting.

 

http://www.avrfreaks.net/comment... - on the all-too-common mistake of ignoring responses

 

And:

 

http://www.avrfreaks.net/forum/b...

 

 

EDIT 2

 

Mentioned in the above is use of a State Machine; see http://www.avrfreaks.net/comment... for a good tutorial.

 

 

#ATCommands

 

Last Edited: Wed. Jul 12, 2017 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Milprasad wrote:
AT\r\n                   //Command sent to modem

Note that the AT Command Teminator is just CR - not CRLF.

 

As this syntax doesn't have a termination character 

Yes, it does - the CRLF marks the end of the response.

Looking at the samples that seems not to be true. The echoed back AT command is terminated by CRLF, and the actual response not only has a CRLF at the end, but also at the front.

Stefan Ernst

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

sternst wrote:
The echoed back AT command is terminated by CRLF

Yes - because that's coming from the modem.

 

But the command you send to the modem should be terminated with just CR.

Generally, the extra LF doesn't actually hurt - it's just extra whitespace - but it is certainly not necessary.

 

 

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

sternst wrote:
The responses contain multiple \n, so receiving until the first \n gives you of course only a partial response. You need to receive until the 3rd \n.

Clearly, it's not always going to be the third.

 

This is where studying V.250 - and the module's AT Command manual - would help to understand the overall structure of the protocol.

 

In particular, note that there are Intermediate responses, and Terminal (or "Terminating" or "Final") responses.

 

So you need to keep "collecting" responses until you reach the Terminal response - the OK or ERROR.

 

As noted in the links I posted earlier, a State Machine can help here ...

 

 

EDIT

 

Also beware of Unsolicited responses...

 

Last Edited: Wed. Jul 12, 2017 - 09:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Yes - because that's coming from the modem.
Yes, and the "what is coming from the modem" is the topic, not what is sent. How can CRLF be the terminator when there are two more CRLF inside of the "what is coming from the modem"?

Stefan Ernst

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

Yes - it was an aside.

 

But, as I said, it is the Command terminator - which is distinct from the Response Formatting sequence

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

clawson, sternst, awneil Thanks for the reply.

clawson wrote:
But those samples look "full" to me
sorry As I mentioned above "Sample responsees for the AT commands" are the responses I got by communicating using putty serial console.

When I use the coding as I mentioned in my first post, I got the response as "AT". "AT" is the echoed value. Response is enclosed like this  "{0D}{0A}OK{0D}{0A}". When I use this code

void USART0ReceiveString()
{
	int i=0;
	while(1)
	{
		name[i]=USART0ReceiveByte();
		if (name[i]=='\n')
		break;
		else
		i++;
	}
	name[i++]='\0';
}

I only get "AT" as the response as shown here  AT{0D}{0A}{0D}{0A}OK{0D}{0A} The reason is I am looking for the terminating character "\n" or {0D} and terminating the response. Instead of getting AT{0D}{0A}{0D}{0A}OK{0D}{0A} as the response I am getting "AT". In order to get the full response what should I need do?

Last Edited: Wed. Jul 12, 2017 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst, Thanks for the reply. "Now I see what you mean perhaps. The responses contain multiple \n, so receiving until the first \n gives you of course only a partial response. You need to receive until the 3rd \n" yes exactly.

 

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

Perhaps this will help:

https://github.com/cloudyourcar/...

 

Jim

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

awneil, Thanks for the reply. Response is enclosed like this  "{0D}{0A}OK{0D}{0A}" so if we looking for the termination character in this response it is terminated at the very beginning. So the resultant response is "" blank. so it is not working isn't it.

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

Milprasad wrote:
sternst, Thanks for the reply. "... You need to receive until the 3rd \n"

yes exactly.

No - not exactly.

 

In that particular case, it just happens to be the 3rd - it will not always be the 3rd.

 

In order to get the full response what should I need do?

Your parser needs to be more intelligent.

 

You can't simply look for any \n 

 

You need to be able to "collapse" sequences of multiple \n and/or \r into a single "terminator".

 

Or consider that some of them mark the beginning of output from the module, while others mark the end.

 

As already noted, a State Machine is a common way to do this kind of stuff ...

 

 

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

ki0bk wrote:
Perhaps this will help:

https://github.com/cloudyourcar/attentive

Well, the description certainly sounds like exactly what the OP needs:

 

cloudyourcar wrote:

Attentive: AT/GSM stack in pure C

 

Features

  • Full AT stack (command generation + response parsing).
  • Modular design.
  • Written in pure ANSI C99 with optional POSIX addons.
  • Compliant with ITU V.250 and 3GPP TS 27.007 for maximum interoperatibility.
  • Tolerant to even the most misbehaving modems out there (if instructed so).
  • Easily extendable to support new modems.

 

EDIT

 

And it does, indeed, seem to be using a State Machine

 

cool

Last Edited: Wed. Jul 12, 2017 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Milprasad wrote:
it is terminated at the very beginning. 

Actually, that is an introduction - not a termination.

 

It just so happens that the same sequence is used by both!

 

Which is where an awareness of State is important - hence the recommendation of a State Machine!

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

As I say all this stuff has been done before. The commands and the likely responses (can be multiple with different formats!) are well known. Most people employ some kind of "state machine". So, for example for the command:

AT+CGATT?{0D}{0A}{0D}{0A}+CGATT: 1{0D}{0A}{0D}{0A}OK{0D}{0A}

It may well be that it may respond "+GGATT:1" and then "OK" but suppose it might also say "ERROR" here. That is just one line of response not two. So for every command you really need to analyze all the potential responses and be ready for them. Of course if you don't see 'E' but '+' as the first character on the first line of response you can be pretty sure already it's not going to turn out to be ERROR. This is why you can handle this with a state machine.

 

On the whole "Hayes compatible" modems don't differ - a lot of this stuff is as old as the hills and folks have been capturing the responses for all the commands for years. That's why you should be able to find existing code that already knows all this stuff - no real point in reinventing the wheel.

 

The only problem as Andy alluded to is that you do not know the provenance of code you find on the internet. It may be a work of genius, it may be a steaming pile of dung. Usually it's pretty obvious from the initial "quality" of the code which you are looking at though.

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

clawson wrote:
it may be a steaming pile of dung.

Any sight of blind delays would indicate this case!

 

 

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

ki0bk wrote:
Perhaps this will help:

https://github.com/cloudyourcar/attentive

awneil wrote:
Well, the description certainly sounds like exactly what the OP needs

 

As this is such a frequently-recurring topic, I thought I'd add a note of these AT Command libraries I just spotted:

 

 

Disclaimer: I haven't tried them or reviewed the code, but have found other stuff from the author, Tilen MAJERLE, to be good.

 

#ATCommand