-2

I am developing an application for GSM Modems using AT commands. I have a problem reading Unicode messages or ussd example: that dcs=17 not 7 or 15 or 72

Two years ago, and I'm looking for a solution to no availI was able to find a partial solution through the use of Chinese phone where the phone can read Chinese codingBut all Nokia phones do not support the codec Arabic or ChineseAnd service responses appear incomprehensible symbols Example:

+CUSD: 0,"ar??c 
?J <10???@d@??? @0@??@D? ?Z?xb 
@   $@?@?@Z@@?? @-@H?@???@b@@$? @3@h?P???@??(??",17

But when you use the phone shows the Chinese response service correctly 100% How do I address coding through Nokia phones or other

abolamar
  • 1
  • 1
  • 2

1 Answers1

2

The character set used for strings in AT commands is controlled by AT+CSCS. The default value is "GSM" which is not capable of displaying anything outside a relative limited set of characters.

In your case, to read Arabic or Chinese "UTF-8" is probably the best choice, although "UCS-2" also can be used (will require a little post processing though).

Below you can see how the selected character set affects strings. I have kept the phone number to my Chinese teacher from when I lived in Taiwan, stored as "teacher" in Chinese (lǎo shī). The actual phone number is stripped out here, but otherwise the following is a verbatim copy of the responses from my phone:

$ echo at+cscs? | atinout - /dev/ttyACM0 -

+CSCS: "GSM"

OK
$ echo at+cpbr=403 | atinout - /dev/ttyACM0 -

+CPBR: 403,"",145,"??/M"

OK
$ echo at+cscs=? | atinout - /dev/ttyACM0 -

+CSCS: ("GSM","IRA","8859-1","UTF-8","UCS2")

OK
$ echo 'at+cscs="UTF-8"' | atinout - /dev/ttyACM0 -

OK
$ echo at+cscs? | atinout - /dev/ttyACM0 -

+CSCS: "UTF-8"

OK
$ echo at+cpbr=403 | atinout - /dev/ttyACM0 -

+CPBR: 403,"",145,"老師/M"

OK
$ echo 'at+cscs="UCS2"; +cpbr=403' | atinout - /dev/ttyACM0 -

+CPBR: 403,"",145,"80015E2B002F004D"

OK
$ echo 'at+cscs=?' | atinout - /dev/ttyACM0 -

+CSCS: ("00470053004D","004900520041","0038003800350039002D0031","005500540046002D0038","0055004300530032")

OK
$ echo 'at+cscs="005500540046002D0038"' | atinout - /dev/ttyACM0 -

OK
$ echo 'at+cscs=?' | atinout - /dev/ttyACM0 -

+CSCS: ("GSM","IRA","8859-1","UTF-8","UCS2")

OK

Update, upon checking 27.007, the string for the +CUSD: <m>[,<str>,<dcs>] unsolicited result code is not a regular string, but has its own encoding:

<str>: string type USSD-string (when <str> parameter is not given,
       network is not interrogated):
  - if <dcs> indicates that 3GPP TS 23.038 [25] 7 bit default alphabet is used:
      - if TE character set other than "HEX" (refer command Select TE Character
        Set +CSCS): MT/TA converts GSM alphabet into current TE character set
        according to rules of 3GPP TS 27.005 [24] Annex A 
      - if TE character set is "HEX": MT/TA converts each 7-bit character of GSM
        alphabet into two IRA character long hexadecimal number (e.g. character
        Π (GSM 23) is presented as 17 (IRA 49 and 55))

  - if <dcs> indicates that 8-bit data coding scheme is used: MT/TA converts each
    8-bit octet into two IRA character long hexadecimal number (e.g. octet with
    integer value 42 is presented to TE as two characters 2A (IRA 50 and 65))

<dcs>: 3GPP TS 23.038 [25] Cell Broadcast Data Coding Scheme in integer format
(default 0)

You therefore have to first determine if dcs is 7 or 8 bit, and then decode according to the above.

PS, the "USC2 0x81" format is described here. although it should not behave differently from plain UCS2 in this particular case.

hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • Thank you You experience all the coding There is no encoding is capable of decoding service only response in the Chinese Phone Nokia Phones: at + cscs =? + CSCS: ("UCS2", "GSM", "PCCP437", "PCDN", "IRA", "8859-1", "HEX") OK Chinese Phone at + cscs =? + CSCS: "IRA", "GSM", "HEX", "PCCP437", "8859-1", "UCS2", "UCS2_0X81" Note coding this UCS2_0X81 is only when it is used Callback Service shows true As for the rest The same problem Why is this only in mobile encoding is how the Chinese can be admitted for Nokia phones??? – abolamar May 03 '13 at 15:51
  • Thank youI feel that the link that you added on 80.80.82 is very useful, but I could not analyzed and understood so farI can convert all replies service under coding DCS 72 or 15, but when only 17 here problem solved by Chinese phoneIf DCS = 17 problems 17 - USC2 Language Indicator. (The first character in a USC2 Lang IND has the language ID in it.This situation is not defined by the GSM 7.07 or the 3GPP 27.007Is a software solution or manufacturers?I use vb.net and therefore did not understand the Java code on that page – abolamar May 04 '13 at 00:33
  • 002E004000BF00A3004000EC0040039400F9039403980068006200BF00D800A5002900400040003100A100F20040039800400066004000680024004000F8004000310040003400A3002000F9004003A300400062004000F200A5004000F2004000320040004C00A3002000EC00A1039E004000720040004000620020005F0040002E exam!!!! – abolamar May 04 '13 at 13:17