SIM900 Dial-up Connection Setup
SIMCOM’s SIM900 is the most common GSM/GPRS module in the maker/hobbyist community. It is of course not the best and the experience people have had with it varies. Most people use this for simple tasks like SMS sending and receiving making the experience people have had largely positive. The module is also cheap and readily available. Compared to building your own baseband module, you get some advantages:
- Certification of by regulatory institutions like FCC, CE, etc. is already done.
- The software stack is already done. The only thing you have to worry about is the command protocol otherwise known as AT command set. The software stack is very deep and complicated and there are very few resources you will find online for this kind of work.
The list goes on… Worth noting is that these benefits apply to almost all GSM modules and so does most of the post below.
This module comes with an inbuilt stack for TCP/IP with support for SMTP, HTTP, and more protocols. Unfortunately, support for Secure Sockets Layer (SSL)
is not present. Some reports in SO say that it is provided with a software update. For the uninitiated, SSL enables us to use HTTPS. Using HTTPS secures the traffic to a website. It requires encryption and this must be on both the client and the server. What if you need SSL support where you cannot do a firmware upgrade on the SIM900 module (FYI: a firmware upgrade requires access to DBG-RX
and DBG-TX
pins on the module). One way would be to completely ignore the presence of the TCP/IP stack on the module and implement it within the application that runs on your micro-controller. This way you can handle the raw TCP/IP traffic. More on this will come in a later post.
There are a number of already written TCP/IP stacks that you can use to avoid writing the stack yourself (quite tedious). They include KEIL RL-TCP
, lwIP
, Orynx TCP Middle-ware
and possibly others that I do not know yet. The first step is deciding how to connect the TCP/IP stack so that it can then handle the communication for you. Most stacks allow for Ethernet, PPP, and SLIP. Again for the uninitiated, PPP is Point to Point Protocol
initially developed by Microsoft. SLIP is Serial Line Internet Protocol
, not commonly used today. More information about them is available here and here.
To connect SIM900 to the TCP/IP stack I chose PPP and thus I need to do a dial-up connection which is the point of this post. Below I will explain the AT commands used and in the sequence that worked. IMPORTANT! Some steps are critical and if missed the whole connection will not work.
The commands sequence (5 separate commands)
I assume anyone reading this understands the basics of AT commands including the CR (Carrier Return) and the LF (Line Feed). Also the escape commands for the C language i.e. use of \\
\"
\r
\n
Command 1 (AT\r\n
)
The SIM900 module requires this command to be sent after boot up. Sometimes the module will not have had a cold start thus it is just good practice to do so. The expected response is AT\r\n\r\nOK\r\n
.
Command 2 (ATE0\r\n
)
This command helps reduce the length of the response of the module by disabling the command echo. The expected response is ATE0\r\n\r\nOK\r\n
.
Command 3 (ATZ\r\n
)
This command resets the communication setup. At this point, the response has been reduced and thus the expected response is \r\nOK\r\n
.
Command 4 (AT+CGDCONT=1,\"IP\",\"internet\"\r\n
)
This command sets the APN for use in the connection we will establish. In this case, the APN for the network I am using (639–03) is ‘internet’. Remember to change to the one that applies to the network you are using. The expected response if \r\nOK\r\n
.
Command 5 (ATD*99#\r\n
)
This command now makes the dialup connection. If it works you should see the change in the NETSTAT
pin. It pulses faster. If connected to an LED, it should blink faster. The expected response is \r\nCONNECT\r\n
. If you get an ERROR response, most likely the previous command was not executed properly.
Command 6 (ATH\r\n
)
This command will terminate the dial-up connection. Only call this once you have finished your transfer. The expected response is \r\nNO CARRIER\r\n
. Do note that it may take up to 5 seconds to respond. As such it is good to try twice, expecting the result above and the seconds time expecting \r\nOK\r\n
.
This post is not meant to and should not take away the need to confirm responses from the datasheet. In another post, I will focus on modifying the PPP connector for the TCP/IP stack provided by KEIL MDK RL-TCP.