1

I am trying to execute USSD command using GSM modem.

AT+CUSD=1,"*200#",15

and the result I get is not readable

"+CUSD: 0,"Æ·ÜNÓu9XŽt�¤å1:,?—u0Œt�ši7è,Óëizy®ƒ5ÓnÔL»Ai7½,w‡éé·;Ì.ÏAòòœvÓËs�ÖL»",15"

when I try the same ussd code on the mobile phone using the same sim I get a correct result which is

"Forfait: 909DA. Recharchege:0.0DA Min gratuites: 0Min. Min internationales restantes :0Min"

changing the character set AT+CSCS from GSM to IRA or PCCP, PCDN, 8859-1 doesnt change the response it is the same response exactly

and changing AT+CSCS to hex gives me an error :

AT+CSCS="HEX"
AT+CUSD=1,"*200#",15 

OK
+CUSD: 2,"Unexpected Data Value",15
+CUSD: 2,"Unexpected Data Value",15
ERROR

and changing it to UCS2 and calling the USSD make my modem reboot

AT+CSCS="UCS2"
AT+CUSD=1,"*200#",15
Ayoub M.
  • 4,690
  • 10
  • 42
  • 52
  • 1
    The two Unexpected Data Value errors are for the `* ` and `#` characters because they are not hexadecimal characters. When changing character encoding with AT+CSCS it applies to **all** strings following as I mentioned in my answer. See [this answer](http://stackoverflow.com/a/18672278/23118) for an example setting UTF-8 with UCS2 encoding active. The same error applies in the second case with UCS2, although the behaviour of rebooting is not as nice as printing a helpful "Unexpected Data Value" error message. – hlovdal Jul 27 '15 at 14:33

2 Answers2

3

The AT+CUSD command is specified in 27.007 and the format of the unsolicited result code is defined as +CUSD: <m>[,<str>,<dcs>].

From your received response you can see that <m> is 0 and <dcs> is 15 in addition to the gibberish for <str> which by the way does not simply map directly to the AT+CSCS character encoding; there is a whole section devoted to explaining its presentation that you must look further into.

Looking up the 23.038 standard referenced in 27.007 the <dcs> value 15 maps to Language unspecified but reading the text above it also seems to be identical with GSM 7 bit default alphabet.

So yes, your suspicion about encoding problems is correct and unfortunately the standards are not very intuitive for this, you have to dive in deeply.

For debugging this I would start by setting AT+CSCS="HEX" and verify that the received data makes sense when decoded, and then work on either getting it presented in a usable format or possibly decoding it explicitly from hex in software yourself (but be aware that changing AT+CSCS then applies to all strings from then on, including the <chset> parameter of AT+CSCS when you want to change encoding to something else later on...)

hlovdal
  • 26,565
  • 10
  • 94
  • 165
  • First, thanks for the a very helpful response. I start to think that the , is encrypted can that be possible ? because I tried feeding the gibberish I got in response into a GSM 7bit decoder but with no luck. nothing resembling a clear message was found. – Ayoub M. Jul 27 '15 at 13:30
0

AT+CMGF=0

AT+CSCS=HEX

AT+CUSD=1,"*123#", 15

get the result and convert the ussd pdu to text

python lib : https://pypi.org/project/PDUUSSDConverter/

straight answer . good luck

imsahabi
  • 1