How to write a AT+CUSD ussd command to support maximum handsets

Syed Aqeel Ashiq picture Syed Aqeel Ashiq · May 8, 2015 · Viewed 11.7k times · Source

I am facing an issue related to AT+CUSD command. On some Gsm modems, this command expects three parameters while on the others, it expects just two parameters. Moreover, different values of those parameters.

I want to know that, how can I configure the Gsm modem so that this command can be executed in a uniform way on most Gsm modems.

Forexample: On Nokia c6-01, the cusd command is executed successfully only in this way:

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

Whereas on Sony Ericsson K750:

AT+CUSD=1,"*123#"

It gives an error if I give a third parameter.

Answer

hlovdal picture hlovdal · May 9, 2015

The command is defined in 27.007, and the syntax is given as

+CUSD=[<n>[,<str>[,<dcs>]]]

so actually all parameters are optional and it is valid to invoke the command with either 0, 1, 2 or 3 arguments.

Regarding the <dsc> value, its specified default value 0 maps to GSM 7 bit default alphabet with German language and value 15 is GSM 7 bit default alphabet without any specific language according to 23.038 as far as I can tell. It also says

Implementation of the GSM 7 bit default alphabet is mandatory. Support of other character sets is optional.

so if the Nokia device gives error with AT+CUSD=1,"*123#" I would interpret that as it not having any German language support and thus fails. As for the Sony Ericsson phone I cannot say why it fails if it fails given a <dcs> argument of any value (of course there will be several values it will fail for, but it ought to support 15). Try to iterate over the languages and see if you get any hit (is for instance English supported?).

You might try to specify GSM 7 bit in alternative ways e.g. 32 (or possibly by exploring Any reserved codings shall be assumed to be the GSM 7 bit default alphabet (the same as codepoint 00001111) by a receiving entity., although that might not work on all phones).

Since you are checking the final result codes for any AT command you issue in any case (you are, right?), it is not that much extra work to implement a fallback algorithm:

  1. first try to invoke with dcs = 15
  2. if that fails then invoke with dcs = 32
  3. finally if all above fails try without dcs.

This should be the most portable way to invoke AT+CUSD on a large set of handsets.


By the way, notice that the 0 value for <n> is underlined in the 27.007 specification. It is a bit subtle but it means that it is a default value, without saying so explicitly (like done for <dsc> for instance). So AT+CUSD= is the same as AT+CUSD=0 (and actually you could even invoke AT+CUSD=,"*123#" as the same as AT+CUSD=0,"*123#", although you might encounter phones that fail to parse this correctly. All phones/modems produced early by Sony Ericson, and almost all produced later, and all phones based on platforms from ST-Ericsson will parse this correctly).


If you want to automate testing you can do so using my atinout program, e.g.:

echo ATE1 | atinout - /dev/ttyACM0 -
for i in $(seq 0 15) 32; \
do \
        echo AT+CUSD=1,"xxxx",$i; \
done | atinout - /dev/ttyACM0 -

if your modem device is /dev/ttyASM0.


Update: Your selected character set for strings might quite possibly be the problem here like described in this answer. Try to run AT+CSCS="GSM" and see if that helps.