My application needs to know if device has flight mode turned on (radio is shut down). The ExTAPI API, lineGetEquipmentState, works well for other PocketPc phone devices but fails frequently on M1000.
lineGetEquipmentState frequently fails with 80000048 (LINEERR_OPERATIONFAILED)
I have attached code snippet.
Pseudo code looks like
1, initialize with lineInitializeEx
2. look for phone device by calling lineGetDevCaps and then checking media mode for the line device is LINEMEDIAMODE_INTERACTIVEVOICE
3. negotiate version with lineNegotiateAPIVersion
4. negotiate extension version with lineNegotiateExtVersion
5. open line with lineOpen
6. get radio state with lineGetEquipmentState
7. close line with lineClose
8. shut it down with lineShutdown
Step 6 frequently fails with 8000048 (LINEERR_OPERATIONFAILED)
Any idea, clue why it fails.
Your response is highly appreciated
Related
How can I detect if the device has flight mode turned on?
On phone devices it means radio is off.
On wifi devices it would mean wifi is turned off.
Thanks in advance,
Flightmode on means NO Radio.
Ie.: NO GSM, NO Bluetooth, NO WiFi.
On Himalaya there is a cross in that title-bar where normally the GSM signal strenth is shown. Also taping the GSM signal strength indicator shows whether or not youre in flight mode.
Take a look at the lineSetEquipmentState & lineGetEquipmentState in the SDK.
lineGetEquipmentState fails with LINEERR_OPERATIONFAILED
My application need to know if device has flight mode turned on (radio is shut down). The ExTAPI API, lineGetEquipmentState, works well for other PocketPc phone devices but fails frequently on XDAs and M1000.
lineGetEquipmentState frequently fails with 80000048 (LINEERR_OPERATIONFAILED)
Pseudo code looks like
1, initialize with lineInitializeEx
2. negotiate version with lineNegotiateAPIVersion for each line device
3. look for phone device by calling lineGetDevCaps and then checking media mode for the line device is LINEMEDIAMODE_INTERACTIVEVOICE
4. negotiate extension version with lineNegotiateExtVersion
5. open line with lineOpen
6. get radio state with lineGetEquipmentState
7. close line with lineClose
8. shut it down with lineShutdown
Step 6 frequently fails with 8000048 (LINEERR_OPERATIONFAILED)
Any idea, clue why it fails.
Your response is highly appreciated
Flight mode on Wifi devices
For non phone devices having wifi,
I tried looking for wifi line device by calling lineGetDevCaps and then checking media mode for LINEMEDIAMODE_DATAMODEM
Here all the line devices have this media mode.
Now when I call lineGetEquipmentState, it fails with LINEERR_OPERATIONUNAVAIL
I am still not sure how to detect flight mode is turned on on the wifi devices.
i´m using lineSetEquipmentState & lineGetEquipmentState on T-Mobil´s MDA 1, MDA 2 and MDA 3. Everything is working fine(On more then 40.000 Clients).
When you want to check FlightMode on MDA 3 for you WIFI Card you should use NDIS.
What do you mean by us NDIS?
I get the same errors on MDA III devices.
Yes, because you are using TAPI.
TAPI means Telephony Application Programming Interface and is not interessting when you would like to check WIFI.
NDIS means Network Driver Interface Specification and that is what you need.
Take a look at MSDN or the SDK.
Thanks
I have zero knowledge about NDIS, can you please give me starting pointers - relevant APIs.
Depands on what you would like to do.
Take a look at the NDIS faq.
http://www.ndis.com/faq/default.htm
I just want to check if the flight mode is turned on.
Hi,
I am attempting to develop a program which must have good control over the state of the built in GPRS or CDMA unit of a Windows Mobile 2003 PDA device.
One requirement is to be able to enter “flight mode” on demand (when the user selects a menu option). The user can not select the connection manager notification and manually select the “enter flight mode” link as this is a fully locked down application (the user does not have access to it). Hence I am looking for ways to programmatically enter/leave/query the status of flight mode.
At present we are using Connection Manager to deal with connection management and RIL to deal with entering/leaving flight mode. In previous versions we used TAPI (the lineGetEquipmentState and lineSetEquipmentState functions) to enter/leave flight mode.
Both approaches (using RIL or TAPI) are causing us grief, mainly due to having to support numerous PDA devices from numerous OEMs.
How have other people approached entering a device into flight mode via code? I am interested in suggestions on the following issues we have having with various techniques, and wondering if anyone has a solution which works well across a wide range of devices (we support various Symbol, Intermec, HTC, HHP, and Panasonic devices to name a few).
Our current issues are as follows:
If using TAPI to enter flight mode:
On some devices such as the Intermec 760 after using lineSetEquipmentState to enter LINEEQUIPSTATE_MINIMUM, querying the state via lineGetEquipmentState only returns the error LINEERR_OPERATIONFAILED. Entering full power mode again means lineGetEquipmentState starts returning proper values again. However you can’t assume that lineGetEquipmentState returning LINERR_OPERATIONFAILED means being in flight mode as periodically some devices are returning this even while in full power mode (i.e. call it 5 times, three might return LINEERR_OPERATIONFAILED and the other two will return valid results).
Alternatively I have tried using the lineGetLineDevStatus function and checking flags within the returned dwDevStatusFlags field. For instance LINEDEVSTATUSFLAGS_CONNECTED or, LINEDEVSTATUSFLAGS_INSERVICE. Again in testing this on numerous devices (eg. Xda IIi and Intermec 760 for instance) both the connect and inservice fields appear to be constantly set, even if in a GPRS based devices there is no SIM card present.
If using RIL to enter flight mode:
We have also tried accessing RIL (using information from http://www.xda-developers.com/ was very helpful in using this “undocumented” API), via calling RIL_SetEquipmentState(RIL_EQSTATE_MINIMUM) and listening for RIL_NOTIFY_RADIOEQUIPMENTSTATECHANGED notifications to tell us when the radio enters/leaves various power states. The problem with this approach is that on some devices (in certain cases) we appear to never get a notification indicating that we have returned to FULL power mode, instead we get RIL_EQSTATE_UNKNOWN being constantly returned.
On one device using the RIL interface even appears to lock up the device (followed by a soft reset a couple of minutes later) while we attempt to enter flight mode by calling, RIL_Hangup, RIL_UnregisterFromNetwork and RIL_SetEquipmentState in that sequence.
I’m open to suggestions on how to enter flight mode via code. Does Microsoft provide an API to do this across all devices in a consistent manor? I guess from previous similar experiences that is wishing too much.
At present I am somewhat dubious about using the RIL interface to enter flight mode while also using Connection Manager at the same time to maintain a connection. At present before attempting to enter flight mode I’m calling ConnMgrReleaseConnection in order to try to tidy up Connection Manager’s state as much as possible, but is it possible that Connection Manager is still getting confused by me going in underneath it (via RIL) and “pulling the carpet out from underneath it”?
Thanks,
Christopher Fairbairn
I have written code to send and receive modem commands and make a data call using the ATDT command. However, sometimes the modem starts to reply with "AT-Command Interpreter" on every command issued, and the command is never executed. At the same time the modem often responds with AT+CSQ: 99,99 (without issuing a request for CSQ).
Once it gets into this mode, I am unable to get it back to the state of actually processing the command. It looks as though this state happens when I am connected to the COM2: port and insert the unit into the cradle for ActiveSynch.
I assume that the problem has something to do with the RIL layer, and all I need to do is "reset" it.
Any suggestions?
Hi there, this is what im trying to do:
Connect bluetooth'd x7501 to my home computer (with usb bluetooth dongle) such that the phone can access my local area network/use intenet.
From scratch, the steps i've taken:
(cleared all partnerships etc)
(on pc): bluetooth devices --> add (tick my device is setup and ready to be found), hit next. device is found in the list. I select the device and hit next. I select choose my own passkey and enter a plaintext familiar word.
(on phone): "computer wants to connect with your device...etc" hit yes. enter plaintext passcode. hit next. wait. wait more. waiiiiiiiiiiiit. "Your device did not connect with computer. The connection failed or the passcode is incorrect".
(on pc): "Windows was unable to exchange passkeys with your device." (so i hit cancel and start again). This time i select 'choose a passkey for me'. I enter the passkey on the device. Wait. wait some more. computer says "bluetooth device successfully connected.."
(on phone): "Your device did not connect with computer, the connection failed or passcode is incorrect"
wtf?
since i wrote the passkey down i put it into the phone again and it connects.
this is issue #1.... can someone explain why this happens?
now issue #2. no matter how many times i hit refresh in the box 'select services to use from this device' it is always empty.
(on pc): properties on phone --> services --> tick activesync bluetooth service, hit apply, and OK. windows installs driver succesfully.
(on phone): hit refresh and wait. no services are found.. not even the activesync one i just enabled..??
now issue #3.
(on pc): blueooth personal area network devices --> select my phone and hit connect --> "the connection with the bluetooth network device failed".
any ideas whats going on here guys? im at my limit of understanding. even if i go to activesync and select connect via bluetooth it just takes me to the bluetooth settinsg page "turn on bluetooth/make this device visible" which has absolutely nothing to do with activesync pairing??
kind regards
sera
I'm not saying this is the problem . . . but some people have reported that they have had trouble with the newer roms and bluetooth with some devices. I have experienced it myself with the bluetooth on the redfly in particular. (Others have reported it also).
So after you have tried everything else, you might want to flash michy 5.1 to test out whether this is the problem. The newer roms (Michy 6.1, etc Nov08) didn't work for me with bluetooth and the redfly and I tried various of the newer Nov/Dec08 time period roms. But AP5 worked fine and I went to Michy 5.1 and thats where I'll stay for awhile.
First I'd try on my phone (doublechecking the bluetooth is discoverable):
start menue, settings, connections, bluetooth, 'mode' tab, check "turn on Bluetooth' box and 'make this device visible to other devices' box.
Then hit 'devices' tab, click add new device and follow what it says.
Would like to point out that using the same bluetooth dongle same PC, using linux (ubuntu 8.10) *exactly* the same problem occurs. Can see the device once, then it connects, and fails during pairing.
However after the pairing attempt the bluetooth icon dissapears (the adapter is no longer present). I think i am going to get another bluetooth dongle and try that first.
I am not using any hacked roms, just the plain phone rom
After obtaining a fix, and then disconnecting manually or automatically (via an app closure) I have to start the gps again within 10 seconds in airplane mode or 25 seconds out of airplane mode to reconnect. If I dont reconnect within this time frame it will not reconnect for about 40-50 minutes. Rebooting or shutting down does not help. This renders the gps specific functions of the phone useless. This does not impact the location services provided by other chips i.e. wifi, cdma (3g data).
If sats are only in view and no more than two are in use (a fix has not been obtained). You can end the session and restart it anytime without a reboot.
This test was actioned in and out of airplane mode but never connected to the network i.e only searching for the network. Its unlikely being connected to the network would impact the outcome of these tests. If you wish to test your own device you should download and use GPS test from the app store. Having or not having AGPS data has no impact on the tests outcome.
From reviewing the logs and assuming this is not a hardware issue my supposition is it appears that when an active gps session with a fix is closed the device does a gps_cleanup. Upon reconnecting it attemps to call back this session against cache that no longer exists. After about 50 minutes a new session is initiated. This problem is somewhat highlighted in this example code. https://github.com/android/platform_frameworks_base/commit/0a5098106c116f2b67c9e77e4ec0afbc92acd61c
I would also be interested in some insight into the cache cleanup commands in the gps.conf script file for this device. It appears GPS1_ CLEANUP_ENABLED=0 does not appear to work for this device. This example was pulled from another example http://forum.xda-developers.com/showthread.php?t=1338486 for another brand so maybe the commands are different with each device. I am also unsure if the gps.conf is read/executed too, per boot/ session/ agps call etc. I'm also unsure which permissions should be set.
I have also attached some log files of the various operations along with a copy of the GPS conf/ system files. In addition I have also noticed cleanup errors when im having problems getting a fix including status 9 errors and wrong prn errors too, I have no idea what these are.
I have already factory reset the phone without success and tried other roms. I do not believe this is a hardware error as it wouldn't function in the first instance.
Any insight would be appreciated.
Peter
Samsung R720
Android 2.3.4 Gingerbread
Log Details
B1 - It finds some sats but I intentionally terminate the session.
B2 - I then restart it. It finds sats again and gets a fix.
B3 - A continuation of B2 but it is terminated manually. A2 would occur next.
A1 - Reconnects at end of the long searching/ downtime period (50 minutes) and gets a fix. I'm not sure why it starts working at this point or what triggers this and im not sure if it´s captured in the log.
A2 - This attempts to reconnect to the previous session via a callback but it fails even though the session is ongoing.