In case you haven't known it, the built-in 5-in-1 card reader on the Acer Aspire 5550 can only support SD but not SDHC (high-capacity) cards. Although this wikipedia article shows that normal SD card can be as large as 4GB, most of my 4GB SD cards are high-capacity, which can't be read by the built-in card reader. The same applies for the free USB SD card reader that comes with unit - both can only support SD cards up to 2GB. For the built-in card reader, nothing will happen when you insert an unsupported card. For the USB card reader, attempting to use an unsupported card will result in a continuously flashing red light. On the other hand, when the USB reader does not detect any card, the indicator will flash for 3 seconds, pause for 1 second and flash again.
Read More »
Sunday, December 27, 2009
Thursday, December 17, 2009
Using USSD on Windows Mobile to set call forwarding
In one of my recent projects, I need to set the call forwarding programmatically. My first attempt was to use the RIL_AddCallForwarding and RIL_GetCallForwardingSettings APIs provided by RIL. However, on all phones I tested, these API mysteriously failed with either E_FAIL, E_NOTIMPLEMENTED or E_INVALIDARG. After a few attempts, I gave up and concluded that these APIs are supported only on Windows CE, but not Windows Mobile (or at least MSDN says so).
My next attempt is to send USSD via lineSendUSSD() method. For example, to divert all incoming calls to another number, use **21*«dest number»#. Since the USSD codes to set call forwarding status are fixed, this methos should work for all phones (see this for the exact USSD codes). However, after some testing, this method is not as reliable as it sounds. It works perfectly on some phones. On some others the call to lineSendUSSD() returns E_FAIL when I passed in the code to set call forwarding but the same API works fine for 'normal' USSD code (e.g. *100# to check account info). On other phones, I received a response from the mobile operator saying that the service code is invalid - it seems as if the phone literally sends the USSD string to the mobile operator, instead of processing it and gives me the call forwarding status.
On a side note, using the .NET method Phone.Talk() on any USSD string will simply display an error message, saying that the signal is unavailable. Also, lineSendUSSD() are not supported on all phones. On phones where it is supported, not all USSD codes are accepted and the response cannot always be retrieved easily. It will most likely fail if the mobile operator returns a menu response for your USSD code (e.g. Reply with '1' for account balance, '2' for expiry date), in which case I haven't figured out how to reply programmatically, or even to retrieve the response text. It looks as if it has to do with the registry branch HKEY_LOCAL_MACHINE\Services\USSD\.
At the moment, I have no ideas why Microsoft makes it so difficult for developers just to send a USSD code.
Read More »
My next attempt is to send USSD via lineSendUSSD() method. For example, to divert all incoming calls to another number, use **21*«dest number»#. Since the USSD codes to set call forwarding status are fixed, this methos should work for all phones (see this for the exact USSD codes). However, after some testing, this method is not as reliable as it sounds. It works perfectly on some phones. On some others the call to lineSendUSSD() returns E_FAIL when I passed in the code to set call forwarding but the same API works fine for 'normal' USSD code (e.g. *100# to check account info). On other phones, I received a response from the mobile operator saying that the service code is invalid - it seems as if the phone literally sends the USSD string to the mobile operator, instead of processing it and gives me the call forwarding status.
On a side note, using the .NET method Phone.Talk() on any USSD string will simply display an error message, saying that the signal is unavailable. Also, lineSendUSSD() are not supported on all phones. On phones where it is supported, not all USSD codes are accepted and the response cannot always be retrieved easily. It will most likely fail if the mobile operator returns a menu response for your USSD code (e.g. Reply with '1' for account balance, '2' for expiry date), in which case I haven't figured out how to reply programmatically, or even to retrieve the response text. It looks as if it has to do with the registry branch HKEY_LOCAL_MACHINE\Services\USSD\.
At the moment, I have no ideas why Microsoft makes it so difficult for developers just to send a USSD code.
Subscribe to:
Posts (Atom)