[SOLVED] What AT Command should I send to SIM800H to get response like SIM900 ?

Status
Not open for further replies.
M

milan.rajik

Banned
Joined
Apr 1, 2013
Messages
2,524
Helped
540
Reputation
1,078
Reaction score
524
Trophy points
1,393
Visit site
Activity points
0
What AT Command should I send to SIM800H to get response like SIM900 ?

I am doing a GSM project using PIC18F45K22 and GSM3 Click from mikroElektronika. The GSM3 Click example given by mikroE works fine but my code doesn't work. In mikroE example code they are checking for "OK\r\n" responses. In my code I am checking for "\r\nOK\r\n".

In SIM800 AT Command manual it just shows OK for the responses but doesn't mention whether it will be OK\r\n or \r\nOK\r\n. How to make SIM800H give responses similar to SIM900 ? I am having difficulty porting my SIM900 code to SIM800.

I am attaching the project which works fine. I have another code which works with SIM900 but that is not working with SIM800H.
 

Attachments

  • 1425051405_gsm3_click_mikroc_pic.rar
    68.3 KB · Views: 76
Last edited:

The SIM800 is compatible with the SIM900, except SIM800 uses USB and SIM900 uses RxD, TxD for debug port, in addition to other interface differences, Vcc range etc.

are you reading SIM800_ATC_V1.01 AT manual?
 
I am reading

sim800_series_at_command_manual_v101.pdf

http://www.amescon.com/media/13865/sim800_series_at_command_manual_v101.pdf

Now, I modified my code a little and except AT+CMGR command everything is working. The AT+CMGR command is not working because the SMS index is not being extracted properly.

I am attaching my project. Please have a look at it. It is written using mikroC PRO PIC compiler. It is device control by SMS. The same code works fine with SIM900. Don't know why SMS index extraction is giving incorrect value. I am testing in hardware.

Here it is failing.

Code: 
Get_SMS_Index(uartBuffer, smsIndex);


It is failing here.

Code: 
Get_SMS_Index(uartBuffer, smsIndex);
                               asm clrwdt
                               GSM_Send_Const_Cmd(uartBuffer, buff, resp1, cmd1, &index, &attempt, 1);
                               GSM_Send_Const_Cmd(uartBuffer, buff, resp1, cmd5, &index, &attempt, 1);
                               GSM_Get_SMS(uartBuffer, buff, resp1, cmd8, smsIndex, &index, &attempt, sms, 1);
                               Get_Code(sms, deviceCode);


The same code works fine with LinkSprite SIM900 modem.
 

Attachments

  • Testing.rar
    95.2 KB · Views: 100
Last edited:

Not satisfied. I said my code works fine with SIM900 but not with SIM800. I told you where it is failing.
 

Apologies for missing part 2 of your Q.

Does AT+CMGF=1 result in OK ..?
Are all messages same plain text & on same phone?
Anything useful from AT+CMEE=1 for extended errors?
 
What is AT+CMEE=1 ? where should I send it ?

I also tested SMS sending in my code.

Code: 
Send_SMS(uartBuffer, buff, resp1, resp4, cmd1, cmd5, cmd9, msg, &index, &attempt, 1);

Even it is working. Only SMS Index extraction and SMS reading is failing but they work fine with SIM900.

broken link removed
 

Attachments

  • sim800 problem.png
    44.5 KB · Views: 121
Last edited by a moderator:

I did one more test. The +CMTI response given by SIM800 is same as SIM900. So, the code which works for SIM900 should work with SIM800 but it is not working.

This is not working
Code: 
Get_SMS_Index(uartBuffer, smsIndex);

and hence these two are not working.
Code: 
GSM_Get_SMS(uartBuffer, buff, resp1, cmd8, smsIndex, &index, &attempt, sms, 1);
Get_Code(sms, deviceCode);

This is what is happening. See it shows 1 as SMS index in +CMTI response. 1 has to be extracted and AT+CMGR=1 command has to be formed and issued to read the SMS but it is sending AT+CMGR=4.

broken link removed

I think this is causing the problem.

There is a

AT+CMGD=1,4

OK

before +CMTI response and even though uartBuffer is cleared it is not getting cleared. So, Get_SMS_Index() is reading the 4 which is after the comma. Hence always it is AT+CMGR=4.

How to fix this ?

- - - Updated - - -

I modified the function like this but still it is sending AT+CMGR=4 when index is 1.

Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

void Get_SMS_Index(char *s1, char *s2) {
 
      while(*s1 != 'C') {
             *s1++;
             asm clrwdt
      }
      
      while(*s1 != 'M') {
             *s1++;
             asm clrwdt
      }
      
      while(*s1 != 'T') {
             *s1++;
             asm clrwdt
      }
      
      while(*s1 != 'I') {
             *s1++;
             asm clrwdt
      }
      
      while(*s1 != ',') {
             *s1++;
             asm clrwdt
      }
      
      *s1++;
      while(*s1 != '\r') {
          *s2++ = *s1++;
          asm clrwdt
      }
 
      *s2 = '\0';
      asm clrwdt
}


- - - Updated - - -

There is some problem. Earlier I connected SIM900 to PC and simulated using Proteus and it was working fine. I had not tested it in hardware. Now I am testing in hardware and both SIM900 and SIM800 gives the same result that SMS index is not being extracted properly. Don't know the problem. I have more than 1000 bytes free RAM.

What might be the problem ?

- - - Updated - - -

Problem solved. I had to add a 1 or 2 second delay like this.

Code: 
if(strstr(uartBuffer, CopyConst2Ram(buff, resp3))) {
           Delay_ms(2000);
           Get_SMS_Index(uartBuffer, smsIndex);

And

Code: 
void Extract_SMS(char *s1, char *s2) {
      unsigned int i = 0;
      asm clrwdt
      while(*s1) {
          if(*s1 == '\n')
              ++i;
          asm clrwdt
          *s1++;

          if(i == 2)break;
      }
      asm clrwdt
      while((*s1) && (*s1 != '\r')) {
              *s2++ = *s1++;
              asm clrwdt
      }

      *s2 = '\0';
      asm clrwdt
}

Now it is working fine in hardware both SIM900 and SIM800H.
 

Attachments

  • problem.png
    16.9 KB · Views: 108
Last edited by a moderator:

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…