CODEWITHSUNDEEP
parsinggsmat-command
kmp
kmp

Reputation: 10865

How to deal with odd message from AT+CMGL command

I have a bit of code (incidentally in .net but I don't think that matters) that sends and receieves SMS messages via a GSM modem plugged into the USB port of a Windows 7 PC (using AT commands sent to a virtual serial port).

It works generally fine (in that I can understand most of the messages that come in) but every so often when I issue an AT+CMGL command I get a message that is not what I expect to see, or that I can work out what it is.

Here is an example (I have changed the values of address and body because I have no idea if this message contains any information that I would not want to become public but I have kept the length of the values the same and put in characters that are indicative of the message):

+CMGL: 0,"REC READ","7700000000000000000000",,"12/09/10,10:25:06+08"
0123456789ABCDEF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+CMGL: 1,"REC READ","7700000000000000000000",,"12/09/10,10:25:07+08"
000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000

OK

The first thing that struck me was that the address is quite long and does not contain a + (or start 00) so does not really look like a telephone number (at least within my limited understanding of telephone numbers). I wondered, therefore, if this could be a message from my telecom provider.

Secondly the body of the message looks to be hexadecimal values, so possibly it is a bit of binary data. So, my question is...

Is there any way that I can decode these messages to work out what they actually are?

(I tried just loading the body into a binary array and dumping it to disk with a .jpg extension to see if it was an image, but of course that didn't work).

This feels like it may be parameter settings perhaps - is there some sort of header that I could read off to find out if this is the case perhaps?

Upvotes: 3

Views: 2238

Answers (2)

hlovdal
hlovdal

Reputation: 28228

Yes it is possible to parse those, and your suspicion of this being hexadecimal data is also correct. This can happen due to character encoding.

I just wrote an answer with regards to UCS-2 character encoding and AT+CMGL where the hex encoding will be the case all the time. Start by reading that. Then read 27.005 for the details about the <data> format to see if you can figure out how to detect when it is hex encoded or not.

If you fail to figure out, or maybe in any case, you can set the character encoding to "HEX" to always get the data hex encoded, although that does not magically solve all your problems because just because you always will get the data hex encoded, you still need to know the exact character encoding on the data you receive, and if this can vary you must know when...

So maybe using UCS-2 is not a bad idea because then you know that all received data will be in the exact same format and encoding.

Upvotes: 2

Shiridish
Shiridish

Reputation: 4962

I am not sure how correctly I am addressing your problem but I guess its with the format that you are getting the messages are not supported with your modem settings. Which format is enabled for the messages? Text or PDU?

An AT+CMGF command will return the message formats supported. AT+CMGF=1 sets to text format.

Upvotes: 0

Related Questions