Handling @ character in gsm 7-bit mode | Telit Cinterion IoT Developer Community
October 11, 2018 - 2:53am, 3878 views
The application is programming the "Cinterion ELS31-V REVISION 22.214.171.124" modem. I am using the CSCS command to set the GSM 7-bit character set. On the other end a cellphone is sending a message also using the GSM 7-bit character set. The message itself contains, as part of the message, an e-mail address in the form of "firstname.lastname@example.org". In the GSM character set the '@' character is the nul ( value 0 ) byte, so I would expect "somebody" followed by the nul-byte followed by "somedomain.com" as part of the message. Instead what I am seeing, as part of the message, is the string of characters "somebody\00somedomain.com". Can anybody explain why "email@example.com" in the message would appear as "somebody\00somedomain.com" ? I have programmed around this anomaly I am getting, but I do not understand why it is happening.
If I understand you correctly the module receives the message sent by a cellphone and then displays @ character as \00. The configured character set is GSM. \00 is an escape sequence for @.
According to AT commands specification document the module uses escape sequences for its non-UCS2 output for all characters with a value below 32 (hexadecimal 0x20). And the input parser of the Customer Application ***** to be able to translate escape sequences back to the corresponding character of the currently used alphabet.
Please see more in chapter 'Supported character sets'.
Please point out to me where in the Gemalto manual it says that incoming gsm 7-bit characters below the value of 32 are represented by an \nn escape sequence.
Please read chapter 1.6 'Supported character sets' in 'Cinterion ELS31-V AT Command Set' document. Please pay special attention to the note in the end.
What "notes" at the end ? I have read chapter section 1.6 many ***** but I have yet to find a line that says that gsm 7-bit characters below the value of 32 are represented by /nn, where nn is hex equivalent for the character. It is not that I do not believe you that this is the case, since I saw it happening as reported in my OP. I just do not see anything in the documentation telling me so. I do not see why gsm 7-bit characters below 32 are just not sent as is, since any program reading what is sent is capable of handling any byte value between 0 and 127.
Could you please write the document version and ID printed on the first page? I'll compare with mine.
Here's the quote:
The UE also uses escape sequences for its non-UCS2 output: Quotation mark (") and the escape character itself (\, respectively Ö in GSM alphabet) are converted, as well as all characters with a value below 32 (hexadecimal 0x20).
Hence, the input parser of the Customer Application ***** to be able to translate escape sequences back to the corresponding character of the currently used alphabet.'
I don't know if this helps but I used the characters changing first AT+CSMP=17,167,0,8 (UCS2 ****).
I had characters 00E4 - ä, 00E5 - å and 00F6 - ö which I sent as 00E400E500F6 and ctl-z to send it.
It came to my mobile phone like: äåö. I also sent 6276476446272063562F64A64264A. Please test what you will get:)
Communication and Mechatronics
Enkom Active Oy – www.enkom-active.fi
Upseerinkatu 3 A, 02600 Espoo, Finland
Mobile: +358 400 411368
Office: +358 10 204 0000
Fax: +358 10 204 0010
The document version and ID are:
I see the same quote you mention starting with "Note:" above. But such a note does not mention the form of the escape sequence at all, which is evidently '\nn' where nn is the two character hex representation of the gsm 7-bit character. How someone is supposed th guess what the form of the escape sequence actually is from the text of the note I do not know. But you are correct that the note you are quoting is in the manual which I have. OK, so now I know that all characters below 32 and the '\' character and the '"' character are sent with '\nn' escape sequence. This answers my original post. Thanks !
Thank you for your feedback.
Actually there are example escape sequeces shown in the table below the note, but maybe it's still not clear enough for the reader.