AT commands reference guide

[RamShop55]

Hi again,

thank you very much for the help on the previous topic, now I have maybe another stupid question. I am trying to use the SIM900 GSM module with a PIC16F690. I see that normally various AT commands are sent in plain RS232 format when other microcontrollers are used like Arduino.

For example:
SIM900.print("AT+CMGF=1\r");

Is there a good reference book for AT commands? Also I see that a special RS232 function is used in Arduino, is that really necessary? What will happen if I use a PIC16 MCU and send a normal RS232 command?

For example:
printf("AT+CMGF=1\r");

[temtronic]

1st place to look would be the website of whatever 'SIM900' module you are using. Not ALL 'SIM900' modules will have ALL the features or command set.

2nd, yes you can send the 'commands' that way, but ,it's better to use fprintf(...) and 'streams'. That way different msgs can be sent to various 'RS232' devices or an LCD module.
Simply get the CCS C manual and search for 'printf'.

Jay

[RamShop55]

Thanks,

I already know how to use fprintf ().


Example:
#USE RS232(UART1,ERRORS,BAUD=9600,STREAM=COM_A)
fprintf(COM_A,"Online\n\r");

[Ttelmah]

OK. 'AT' commands, are actually originally 'Hayes' modem commands.
Basically nearly 40 years ago, Hayes launched a modem, and wanted to have
it's command 'language' reasonably flexible and extendable. They designed
a standard 'set' of commands for doing things like establishing the
connection, terminating the connection, changing phone numbers etc. etc..
This was the original 'Hayes command set'.
This became adopted over the next few years by more and more modems.
So chipsets implementing modems began to all be 'AT' based.
Now the 'language' has a few dozen pretty much 'standard' commands,
but everything beyond this depends on the features of the modem itself
and the extensions it implements.
'AT' was the 'attention' string that begins most Hayes commands.
Then the modem only responds to commands when it is in 'command mode'.
Once actually connected, it is instead in data mode. Sending everything it
receives to the other end of the connection. The sequence to go to command
mode from data mode, is defined as a pause, then the sequence "+++"
followed by another pause. This is designed to be unlikely to
ever happen by accident (after all, even if you were sending "+++", you
are hardly going to pause without sending anything else immediately
before and afterwards...).
Understand then that timing becomes important. Not just sending the
strings, but also timing this correctly. Waiting when required, and also
looking for particular replies and changing what you do based on these.

The standard Hayes set is described in Wikipedia at:
<https://en.wikipedia.org/wiki/Hayes_command_set>
Then look for:

ETSI GSM 07.07 (3GPP TS 27.007) which describes the standard
extended suite for GSM.

and

ETSI GSM 07.05 (3GPP TS 27.005) which describes the extended
commands for SMS.

Everything beyond this is 'modem specific'. The command manual for
your modem, is at:

<https://simcom.ee/documents/SIM900/SIM900_AT%20Command%20Manual_V1.11.pdf>
Then slightly 'puzzled'. You show an example sending "Online" to the
serial port. Why?. The port talking to the modem, is what will be telling
you it is online.

Then on the Arduino command, this is it's way of doing serial. Every
processor/language has it's own way of doing such things. CCS has kept
to the C standard using printf/putc, the Arduino uses these for it's screen
rather than serial.

Now, 'beware'. The SIM900, internally is a 3.3v device. If talking to a
5v PIC you need level translation. The Arduino, can 'get away' without
such translation on the RX pin (since it's input threshold is 2.4v), while
most PIC's will need a buffer here (since the input threshold on the
serial pins is normally 0.8*Vdd). Some boards do have transistor buffers,
so are OK. Others do not.....

[RamShop55]

Thank you very much for this detailed example, its very rare to see such a good answer. You should be a professor in the University, this is exactly the kind of explanations that I am looking for.

The PIC16F690 has a wide range voltage support, from 1.8V to 5.5V. It will work on 3.3V and 0.8*3.3V=2.64V, which should be ok.

For the timing, I think that is covered by the RS232 settings, for this module 19200 kb/s being used.

If I use CCS there should be no problem using fprintf (). I have to send fprintf (" +++ ") to enter command mode and then use the AT command "AT+CMGF=1\r" ? They don't use it in the example. Maybe the SIM900.begin(19200) function does it in the background.

[temtronic]

Comment. While the PIC has a wide voltage range, at 3 volts, the maximum clock speed is only 10 MHz. If you use the internal HF Osc (saves 2 pins !), you'll get 8 MHz max. Just something to understand.

Jay

[Ttelmah]

and the 'timing' I was referring to, is the need for you to have thing like
pauses when you want to send the +++. You need to actually stop
serial transmission for 0.5 second, then print +++, then stop again, or
the +++ won't be accepted.....

Also the reason they "don't use it in the example" is that the modem
wakes up in command mode. You need the +++, when later you have
already made a connection, and you then need to do something like
hang up the modem.

[RamShop55]

@temtronic
I did not know that the clock frequency changes with the voltage, I am using 4MHz, I hope the lower voltage has no impact on this.

@Ttelmah
About command mode, to summarize:

1. Wake up on power on(3.3V) in command mode.
2. Establish a connection with this code and enter data transmission mode:
fprintf(COM_A, "AT + CMGS = \"+CodeNumber""); /* This is weird. */
3. Enter command mode again by:
delay_ms (500);
fprintf (COM_A, "+++");
delay_ms (500);

How is the SMS sent, in command mode or data transmission?

The idea is when a pin on the PIC16F690 is high, an SMS is sent to the number. I was expecting this to be done by a simple set of 2 commands:

1. fprintf(COM_A, "AT + CMGS = \"+CodeNumber"")
2. fprintf(COM_A, "Message example from PIC16F690.")

but in case the first command is in command mode and the second in data transmission mode, i have to do the following:

1. Command mode on power on(3.3V).
2. Send fprintf(COM_A, "AT + CMGS = \"+CodeNumber"")
3. If the pin on PIC16F690 is high, send data transmission mode command.
4. Send fprintf(COM_A, "Message example from PIC16F690.").
5. Enter command mode again and standby:
delay_ms (500);
fprintf (COM_A, "+++");
delay_ms (500);

There is no need to initialize the modem as this is done on power on(3.3V)? In case I stay in data transmission mode, the SMS will be sent over and over again over some period of time(every second or so)?

Is this understanding correct?

[Ttelmah]

You need to send "AT+CMGF=1\r" before trying to send the message.
Otherwise it sends in PDU mode.
Then you need the telephone number you are going to send the SMS to
in full form. So:

+ddnnnnnnnnnn

Normally a 10digit number plus 2 digit country code.

Now your comment about weird, is wrong, as is the string!...

Point is the number has to be sent with " round it. Now the format
string uses " to end the string. So you have to escape these. But you
need to do the " at both ends of the number. You are currently only
escaping the one at the start. So:

fprintf(COM_A, "AT + CMGS = \"+CodeNumber\"\r");

Note how it also needs the '\r' at the end.

Now you need to actually send the SMS:

fprintf(COM_A,"This is the text for the SMS'\x1A");

Note the '\1A' at the end. You can send several lines, it is the
'\1A' that says 'this is the end of the SMS'.

Now, after the CMGF, the modem should respond with 'OK\r'. Then
after the CMGS and the SMS itself, it will respond with

+CMGD:rrrrr\r
OK\r

where 'rrrrr' is the message reference number.

Your code needs to be reading the replies and checking they say what
they should and not 'ERROR\r' which is what will be replied if something
is wrong, and have a timeout if a command is not responded to in
a specific time.

For just SMS, you can remain in command mode permanently.

Really you should check the connection status before trying to send.

[benoitstjean]

Hello,

[EDIT] Sorry TTelmah, I read quickly through and didn't realize you explained the CTRL+Z! Since I took some time to write this, I figured I'd leave it here rather than deleting it, it's just extra info! Cheers!


If I may comment, I started-off 7 years ago with the SIM900 only to realize that the cellular data rate was too slow for what I wanted but also it was going to eventually be phased-out because I believe it's an old 2G modem. Then I moved up to the 3G SIM5320 and now using the LTE SIM7600.

For the price, I'd go straight with the SIM7600, it's LTE and it's SIMCOM's flagship. But if the SIM900 is the only thing you have access to or can afford, then it is what it is.

In my SIM7600 code, this is how I send an SMS:

sprintf( sSMSMessage, "AT+CMGSO=\"%s\",\"%s\"", sToNumber, sMessage );

which would translate to AT+CMGSO="6135551212","Hello world".

The command accepts both the number AND the message.

With the SIM900, this is what I used:

sprintf( sString, "AT+CMGS=\"%s\"", sToNumber );

You issue the number first, then the modem will return a '>' prompt at which point you send your actual message data. Therefore, once you issue the AT command, you must have a loop that waits for '>', then you send your message then you have to send CTRL+Z.

So if you send "Hello world", it would be look this in plain english on your screen:

> Hello world CTRL+Z

but you would send it like this in code AFTER the '>' prompt has been received:

sprintf( sString, "Hello world\x1A" );

You could also load a bunch of pre-defined SMS messages in the modem's memory then simply load the message from memory.

I saw that you talked about DATA and COMMAND modes. In COMMAND mode, it's when you issue all the AT commands and responses. In DATA mode, that's when your UART and CELL channels 'bridge' to become a TCP channel out to the cell network. All data sent-out the MCUs modem will go out onto the cellular network on whichever port you specify and vice-versa, all data arriving on the cell channel on the specified TCP port will get routed to the MCU's serial port.

The SIM7600 has one physical UART but using the UART multiplexer protocol, one physical UART becomes multiple virtual UARTS therefore while I send commands to the modem, I can also simultaneously communicate over a TCP channel with a remote application.

You can get all documentation from SIMCOM's website here:

http://www.simcom.com/member/login.php?lang=en

Register yourself then you can download the docs there.

-or-

I can send them to you by email. My email is benoitstjean00_at_gmail_dot_com (replace _at_ and _dot_ with the correct symbols).

I have reference guides, AT command guides, evaluation board schematics, hardware design guides, application notes etc. I have like 30 files.

So if you email me, I can send them to you. Or just register on their website and get them there.

My original design with the SIM900 was with a PIC18F4620 running at 40MHz. But now I use a PIC24EP with a 29.4912 MHz clock overclocked at 129.024 MHZ. This lets me do a lot of things simultaneously. These modems a really kick-[spam].

What is the ultimate goal you are trying to achieve? Can you provide more details on what it is you're trying to do?

Ben
Ottawa, Canada

[RamShop55]

Thanks to everyone for the replies, It will take me some time to go through this, also I have to work.

My purpose is to build a first stage SIM MCU system which only sends SMSs and then to upgrade this to MMS (with pictures) and phone calls.

[benoitstjean]

I don't think you will be able to send MMS with SIMCOM modems. I wanted to do the same thing. I have a direct contact with a few SIMCOM Field Application Engineers in Shanghai and I've already confirmed that with them. Hopefully they change that.... anyhow, it is not possible with the SIM5320 and SIM7600. Not sure about the SIM900.

Good luck!

Ben

[temtronic]

The really sad thing is I just found an original Hayes 300 baud modem today while looking for my UV eraser...sigh, I also found a couple Intel 8008 CPUs !

[benoitstjean]

haha. Yes, sad indeed when you have to look for a UV eraser... gives your age away, especially when you find a 300 baud modem!