The best way to troubleshoot any SMS command issues would be via log, either remote logs or USB logs via Terminal can be collected. Please note that remote logging will be stopped if any changes to the connection will occur (econnect SMS, reset SMS, general network issues etc).
Once logging is started simply send the SMS commands to the device and all SMS processes will be recorded in the log. To ensure that the result is reproduced reliably it would be best to send the SMS command at least 3 times with about 2-3 min delays in-between.
After the log is collected open it with any plain text editor (Notepad++ recommended). You will find entries related to the SMS process of the device by searching for “sms.proc”:
If you’re using Notepad++ the “Find All in Current Document” or “Find All in All Opened Documents" function will be very useful and show all results in a separate section at the bottom:
Checking received SMS commands
If you simply want to check the received SMS text you can search for “[sms.proc]->sms:”, you will see the text of the received SMS in the same line:
The line “[sms.proc]->Psw” will also indicate if the password check was successful or not:
To check additional information about the received SMS (sender phone number, timestamp, encoding details etc) simply go up from the SMS text and you can find the PDU of the message between “[sms.proc]->SMS_idx” and “decode SMS” (also nested together with the modem AT command “AT+CMGR”):
In this example, the PDU is:
0791534850020220040C9153481002374700003270410125422108A0F3BC9D769BDF
PDU stands for “Protocol Data Unit” and is a way to represent the SMS message as binary strings encoded in hexadecimal characters. To decode the string, you can use an online SMS PDU decoder:
After decoding the PDU we get the following info:
NOTE: If you’re trying to troubleshoot SMS via GPRS commands then you will not see any entries such as “[sms.proc]->SMS_idx” or “AT+CMGR” because this process is only related to SMS PDU indexing in the modem. Instead, you should search for “rx id: 108” which will show any instances where the device received the command 108 (SMS via GPRS) from the server, but there is no way to check the exact data the server is sending (client’s server logs or TCP traces would help in that case).
Checking responses to SMS commands
To check the sent SMS command text, you can:
Find the answer below the entry “[sms.proc]->cmd:”:
Decode the PDU for more info (recipient phone number, encoding etc) by finding the entry “bytesToSend:” below the SMS command process entries:
In this example the PDU is: 0011000C915348100237470000FF8B53AA4E0693CD5CB09B2B4603C1683A194E37BBED404F284846A3C5642CB69D0DBAB198C121481683C958A06192A803C572309B8C053A4E9B3B50539704C958202928C6024DA13A106C073A42A553504CF704D958A02188C6021541B01D88B9D43D41381C0B5404C158206AF309BAED40D2A90E041BEE4050500C
Here is the result from the decoder:
NOTE: If you’re trying to troubleshoot SMS via GPRS commands then you will not see the entry “bytesToSend:” because this process is only related to SMS PDU indexing in the modem. Instead, you should search for “tx id: 007” which will show any instances where the device sent the command 7 (SMS via GPRS) from the server, but there is no way to check the exact data the device is sending (client’s server logs or TCP traces would help in that case).