I’m using the AT+CUSD command to send USSD codes, and I’ve got two questions about the usage. Question 1:
Some USSD commands don’t give back an indication. When can I be sure that there is no indication coming back. Is there some timeout or are there other means?
Question 2:
I’m getting +CUSD indications which have a format, that does not seem to be documentented in my AT Commands Reference guide. This is an indication coming as reply to AT+CUSD=1,*#21#,0 (querying call forwarding)
I get four columns instead of the documented 3 (m,str,dcs), these indications don’t want any user interaction, though they start with a ‘1’. How to interpret those indications, and might there be even other, differently formatted +CUSD indications? Interestingly, sometimes I get +CCFC indications instead which have the exact format like those CUSD indications:
Or could it be that +CCFC indications are wrongly presented as +CUSD indications?
FIRMWARE is 10.00.003
Thank you very much for helping.
Hi Christian,
it is because the call forwarding service is controlled by AT+CCFC command therefore the syntax of the response is the same.
Infact in case you use the ATD method to send USSD string the response is the following:
atd*#67#
+CCFC:1,1,"+39333xxxxxxx",145
OK
but I do not expect to see +CCFC using AT+CUSD=1,"string"
Hi Andrea,
> but I do not expect to see +CCFC using AT+CUSD=1,”string”
that was my question, I didn’t expect it either and I think it’s a bug.
I am using AT+CUSD, because I’m not sure which USSD calls are valid and which ones can establish a call (e.g. #31#030xxx).
But I have another question regarding USSD:
When I’m sending following command: AT+CUSD=1,*100#,0r
I’ll get following indication: +CUSD: 1,”Kontostand: 0.18 EURnBitte w{hlen Sie:n1 Konto aufladenn2 CallNow Transfern3 Mein CallYan4 Tarifoptionenn5 Guthaben Details”,0r
If I continue the menu selection with AT+CUSD=1,3,0r I’ll get an indication: +CUSD: 2,”00570065006E006E0020005300690065002000650069006E0020005700410050002D00660061006500680069006700650073002000480061006E006400790020006E00750074007A0065006E002C00200065007200680061006C00740065006E002000530069006500200069006E0020004B007500650072007A0065002000650069006E00650020004E006100630068007200690063006800740020006D00690074002000640065006D0020004C0069006E006B0020007A0075006D0020006B006F007300740065006E006C006F00730065006E002000480061006E006400790070006F007200740061006C00200022004D00650069006E002000430061006C006C005900610022″,0r|
Both times I get the dcs set to 0, but the second time the answer is encoded as UCS2. Do I just have to guess the formatting?
Thank you very much.
The DCS parameter is supported on 10.00.003 and should be handled correctly.
What we don’t know is if DCS value is provided by the network.
To verify this part, we would need a trace using an internal debug tool.
If you are interested on it, I will contact you directly to provide the tool.
Thank you very much, but we don’t have the second serial port connected, so , as far as I know, we cannot use the internal debugging tool.
Probably you are right, and the network provider is setting the wrong encoding.
Hi,
I’m using the AT+CUSD command to send USSD codes, and I’ve got two questions about the usage.
Question 1:
Some USSD commands don’t give back an indication. When can I be sure that there is no indication coming back. Is there some timeout or are there other means?
Question 2:
I’m getting +CUSD indications which have a format, that does not seem to be documentented in my AT Commands Reference guide. This is an indication coming as reply to AT+CUSD=1,*#21#,0 (querying call forwarding)
+CUSD:1,2,"+49302593xxxx",145r
+CUSD:1,4,"+49302593xxxx",145r
+CUSD:1,1,"+49302593xxxx",145r
I get four columns instead of the documented 3 (m,str,dcs), these indications don’t want any user interaction, though they start with a ‘1’. How to interpret those indications, and might there be even other, differently formatted +CUSD indications? Interestingly, sometimes I get +CCFC indications instead which have the exact format like those CUSD indications:
+CCFC:1,2,"+49302593xxxx",145r
+CCFC:1,4,"+49302593xxxx",145r
+CCFC:1,1,"+49302593xxxx",145r
Or could it be that +CCFC indications are wrongly presented as +CUSD indications?
FIRMWARE is 10.00.003
Thank you very much for helping.
Hi Christian,
it is because the call forwarding service is controlled by AT+CCFC command therefore the syntax of the response is the same.
Infact in case you use the ATD method to send USSD string the response is the following:
atd*#67#
+CCFC:1,1,"+39333xxxxxxx",145
OK
but I do not expect to see +CCFC using AT+CUSD=1,"string"
Hi Andrea,
> but I do not expect to see +CCFC using AT+CUSD=1,”string”
that was my question, I didn’t expect it either and I think it’s a bug.
I am using AT+CUSD, because I’m not sure which USSD calls are valid and which ones can establish a call (e.g. #31#030xxx).
But I have another question regarding USSD:
When I’m sending following command:
AT+CUSD=1,*100#,0r
I’ll get following indication:
+CUSD: 1,”Kontostand: 0.18 EURnBitte w{hlen Sie:n1 Konto aufladenn2 CallNow Transfern3 Mein CallYan4 Tarifoptionenn5 Guthaben Details”,0r
If I continue the menu selection with
AT+CUSD=1,3,0r
I’ll get an indication:
+CUSD: 2,”00570065006E006E0020005300690065002000650069006E0020005700410050002D00660061006500680069006700650073002000480061006E006400790020006E00750074007A0065006E002C00200065007200680061006C00740065006E002000530069006500200069006E0020004B007500650072007A0065002000650069006E00650020004E006100630068007200690063006800740020006D00690074002000640065006D0020004C0069006E006B0020007A0075006D0020006B006F007300740065006E006C006F00730065006E002000480061006E006400790070006F007200740061006C00200022004D00650069006E002000430061006C006C005900610022″,0r|
Both times I get the dcs set to 0, but the second time the answer is encoded as UCS2. Do I just have to guess the formatting?
Thank you very much.
The DCS parameter is supported on 10.00.003 and should be handled correctly.
What we don’t know is if DCS value is provided by the network.
To verify this part, we would need a trace using an internal debug tool.
If you are interested on it, I will contact you directly to provide the tool.
Thank you very much, but we don’t have the second serial port connected, so , as far as I know, we cannot use the internal debugging tool.
Probably you are right, and the network provider is setting the wrong encoding.