AT+CMGR: could the text contain \r\n?

Answers of AT commands are parsed using "\r\n" delimiter. In other 
words, the GSM modem transmits messages starting with "\r\n" and ending 
with "\r\n".

AT+CMGR answer (read SMS) is strange. It is composed by:

 
\r\n+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n
   <sms_text>\r\n
   \r\nOK\r\n

As usual, I parse this answer receiving blocks of characters from modem, 
ending with delimiter "\r\n".

- The first block (\r\n) is empty.
- The second block 
(+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n) 
is parsed splitting fields using comma delimiter.
- The third block (<sms_text>\r\n) is the SMS text, except last two 
characters.
- The fourth block (\r\n) is empty.
- The fifth block (OK\r\n) is the last block that ends the AT+CMGR answer.

This approach is good in most situations. But what happens if <sms_text> 
field contains \r\n? I tried to send an SMS with newline from my mobile 
phone and I noticed it is received as a single \n character. So the 
parsing above works well.

Yesterday my GSM modem received a SMS with true 2-characters \r\n 
newlines in <sms_text>! It was a SMS send by the mobile operator and not 
by a user. Anyway, it's possible to have the <sms_text> with embedded \r\n.

Have you noticed this before on your tests? How do you parse the AT+CMGR 
answer?

Op Wed, 29 Apr 2015 11:00:34 +0200 schreef pozz <pozzugno@gmail.com>:
> Answers of AT commands are parsed using "\r\n" delimiter. In other  
> words, the GSM modem transmits messages starting with "\r\n" and ending  
> with "\r\n".
>
> AT+CMGR answer (read SMS) is strange. It is composed by:
>
>   
> \r\n+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n
>    <sms_text>\r\n
>    \r\nOK\r\n
>
> As usual, I parse this answer receiving blocks of characters from modem,  
> ending with delimiter "\r\n".
>
> - The first block (\r\n) is empty.
> - The second block  
> (+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n)  
> is parsed splitting fields using comma delimiter.
> - The third block (<sms_text>\r\n) is the SMS text, except last two  
> characters.
> - The fourth block (\r\n) is empty.
> - The fifth block (OK\r\n) is the last block that ends the AT+CMGR  
> answer.
>
> This approach is good in most situations. But what happens if <sms_text>  
> field contains \r\n? I tried to send an SMS with newline from my mobile  
> phone and I noticed it is received as a single \n character. So the  
> parsing above works well.
>
> Yesterday my GSM modem received a SMS with true 2-characters \r\n  
> newlines in <sms_text>! It was a SMS send by the mobile operator and not  
> by a user. Anyway, it's possible to have the <sms_text> with embedded  
> \r\n.
>
> Have you noticed this before on your tests? How do you parse the AT+CMGR  
> answer?

Is the <length> field not indicative of the length of the sms_text?



-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Il 29/04/2015 13:11, Boudewijn Dijkstra ha scritto:
> Op Wed, 29 Apr 2015 11:00:34 +0200 schreef pozz <pozzugno@gmail.com>:
>>
>> AT+CMGR answer (read SMS) is strange. It is composed by:
>>
>>  \r\n+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n
>>
>>    <sms_text>\r\n
>>    \r\nOK\r\n
[...]

> Is the <length> field not indicative of the length of the sms_text?

Oh, yes. Indeed I'm changing my parser routine to take into account the 
<length> field.  It's one of optional fields that must be enabled with 
another command (AT+CSDH).

My question is: is it possible to send a SMS text with embedded "\r\n" 
sequence of characters? I can't with my mobile phone.

Op Wed, 29 Apr 2015 14:18:28 +0200 schreef pozz <pozzugno@gmail.com>:
> Il 29/04/2015 13:11, Boudewijn Dijkstra ha scritto:
>> Op Wed, 29 Apr 2015 11:00:34 +0200 schreef pozz <pozzugno@gmail.com>:
>>>
>>> AT+CMGR answer (read SMS) is strange. It is composed by:
>>>
>>>  \r\n+CMGR=<stat>,<oa>,[<alpha>,]<scts>[,<tooa>,<fo>,<pid>,<dcs>,<sca>,<tosca>,<length>]\r\n
>>>
>>>    <sms_text>\r\n
>>>    \r\nOK\r\n
> [...]
>
>> Is the <length> field not indicative of the length of the sms_text?
>
> Oh, yes. Indeed I'm changing my parser routine to take into account the  
> <length> field.  It's one of optional fields that must be enabled with  
> another command (AT+CSDH).
>
> My question is: is it possible to send a SMS text with embedded "\r\n"  
> sequence of characters? I can't with my mobile phone.

I think it is possible.  With my mobile phone I can paste text into the  
SMS body which was copied from arbitrary apps.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Il 29/04/2015 11:00, pozz ha scritto:
 > [...]
> Yesterday my GSM modem received a SMS with true 2-characters \r\n
> newlines in <sms_text>! It was a SMS send by the mobile operator and not
> by a user. Anyway, it's possible to have the <sms_text> with embedded \r\n.
 > [...]

And there is another more obscure situation, when one of the SMS text 
character is the null '\0' character!

I didn't think it was possible, but I really received a similar SMS (it 
was a configuring SMS, I don't know what is the technical name of this 
service).

I have two software layers: the low-level layers reads bytes from modem 
and put them in a buffer. When I receive the sequence "\r\n", the 
message is passed to the upper layer.

The high-level layer parses the message supposing it is a good C string, 
by using functions such as strlen(), strstr() and so on. As you can 
understand, the result isn't good if the message contains '\0' characters.

Just to let you know.

>Il 29/04/2015 13:11, Boudewijn Dijkstra ha scritto:
>> Op Wed, 29 Apr 2015 11:00:34 +0200 schreef pozz <pozzugno@gmail.com>:
>
>My question is: is it possible to send a SMS text with embedded "n" 
>sequence of characters? I can't with my mobile phone.

Did you try "\r\n"?


---------------------------------------
Posted through http://www.EmbeddedRelated.com