HID over GATT on Android disconnects after 30 seconds

RE: HID over GATT on Android disconnects after 30 seconds

Sansei — Sat, 13 Jan 2018 13:28:31 GMT

Did you solve it finally or not? I have the same problem with Nordic_Ble_Preipheral_HID_KeyBoard (or mouse) where the connection got lost in a few moment periodically.

RE: HID over GATT on Android disconnects after 30 seconds

Chris — Mon, 06 Oct 2014 03:27:19 GMT

I'm having this problem too with the SoftDevice 7...

#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(20000, APP_TIMER_PRESCALER) /< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (15 seconds). */ #define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER) /< Time between each call to sd_ble_gap_conn_param_update after the first (5 seconds). */ #define MAX_CONN_PARAMS_UPDATE_COUNT 3 /**< Number of attempts before giving up the connection parameter negotiation. */

Ignore the comments, but I connect to the device on iOS 8, and after 35 seconds it just gets disconnected..

Which is 20 + (3 * 5) seconds.

cp_init.p_conn_params                  = NULL;
cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
cp_init.disconnect_on_fail             = false;
cp_init.evt_handler                    = on_conn_params_evt;
cp_init.error_handler                  = conn_params_error_handler;

Any ideas?

RE: HID over GATT on Android disconnects after 30 seconds

Andrew Kohlsmith — Mon, 25 Aug 2014 17:41:22 GMT

I see what the problem is, at least in my scenario which I don't know is the same.

With my application, if I set the MAX_CONN_INTERVAL down to 25ms, I get the timeouts. If I leave it up at 40ms, I do not. It looks like the soft device is ignoring my "do not disconnect on failure to negotiate the connection parameters" setting.

RE: HID over GATT on Android disconnects after 30 seconds

Andrew Kohlsmith — Mon, 25 Aug 2014 16:35:53 GMT

I am getting the same thing on iOS (8.0b5 on iPhone 5S as well as 7.1.1 on iPad3). My application is based on the Nordic ble_lbs demo code which sets up the connection as follows:

cp_init.p_conn_params                  = NULL;
cp_init.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY;
cp_init.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY;
cp_init.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT;
cp_init.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID;
cp_init.disconnect_on_fail             = false;
cp_init.evt_handler                    = on_conn_params_evt;
cp_init.error_handler                  = conn_params_error_handler;

FIRST_CONN_PARAMS_UPDATE_DELAY is 1s, NEXT_CONN_PARAMS_UPDATE_DELAY is 5s, and MAX_CONN_PARAMS_UPDATE_COUNT is 3. My disconnects occur almost exactly 15s (5s delay, 3 attempts) after connecting.

Like the original poster, the soft device does NOT resume advertising.

This doesn't appear to be an Android thing, but perhaps a soft device thing. I'm running s110 v6.0.0.

RE: HID over GATT on Android disconnects after 30 seconds

eric ely — Tue, 24 Jun 2014 11:25:52 GMT

Thanks for the response. Yes, I already had it set to false, and I don't think it is directly related to the connection parameter update.

I am keeping the interval between connection parameter updates extremely high. If I do that, and I have Wifi turned off in the Android phone, it will stay connected for a very long time. However, if I wait a few minutes press a button and send a HID key, there is about a 50% chance it will disconnect. Also, if I turn on Wifi in the Android handset, it will likely disconnect without any other action. So disconnects are happening outside of just connection parameter updates.

I have tried the RFDuino, which is using nrf51822 and a custom service on GATT as far as I can tell, with this exact phone. It will stay connected forever even with Wifi on. So there must be a way to keep the connection up. Is there an Android specific example provided by Nordic?

RE: HID over GATT on Android disconnects after 30 seconds

Øyvind — Tue, 24 Jun 2014 10:22:02 GMT

Hi,

You could try to set the disconnect_on_fail menber of ble_conn_params_init_t to false, and see if that helps. Then the application should not disconnect even if it is not satisfied with the connection parameters from the master.

BR, Øyvind

RE: HID over GATT on Android disconnects after 30 seconds

eric ely — Mon, 23 Jun 2014 22:32:37 GMT

UPDATE TO THE UPDATE: I found a way to sniff HCI packets from the Android side. By looking at the trace, as far as I can see, the Disconnect event is coming from the nrf51822. I see nothing in the logs, and then there is one packet:

HCI Packet Type: 0x04 (HCI Event)
Event Code: (0x05) Disconnect Complete
Parameter Total Length: 4
Status: 0x00 Success
Connection Handle: 0x0002
Reason: 0x08 Connection Timeout

So the nrf51822 is initiating the disconnect it seems. How can I catch this from the nrf51822 side before it sends that packet? I have the normal event handlers set up for ble events with breakpoints, but it doesn't get caught there. Where can I catch the reason the chip is sending that packet?

UPDATE: I set the next_conn_params_update_delay parameter in the ble_conn_params_init_t structure to a ridiculously high value. Once I do that, I can basically keep the Anrdoid phone connected nearly indefinitely. However, it doesn't solve the problem entirely. If I wait a long period of time (10 minutes or so) and then I send a media key, it does go through (the action registers on the phone), but then sometimes it will disconnect right after and sometimes it will stay connected. So it seems that there is still some kind of issue when packets go back and forth, the connection parameter update may have just been exacerbating the problem because packets were going back and forth every 30 seconds when the slave requested new parameters. By turning that off, I am using less packets and hence less chance of a disconnect.

I am trying to investigate. Anyone from Nordic have any thoughts in this issue?

Original: I played around with this a bit more. If I turn the Wifi off on the Android phone, it will stay connected a lot longer. I read in a few places that Android had an issue at one point that it would reject incoming connection parameter update requests if Wifi is on. However, it was supposed to be resolved in Android 4.4.

So turning Wifi off does help, but it doesn't entirely solve the problem because it will still disconnect after some time, but it's more like 5 minutes. At this point, I am starting to think that this has something to do with the Android phone missing connection events or not handling connect parameter updates properly. I am playing around with the NEXT_CONN_PARAMS_UPDATE_DELAY parameter to see if it helps. Is there a way (or is it a good idea) to never update the connection parameters once connected?

The thing is, I have used other BLE modules with this chip (like the RFDuino) and they maintain the connection indefinitely. So even if it is an issue with Android, there must be a way to work around it from the nrf51822.

The other annoying part is, when the phone disconnects, the nrf51822 isn't going back to advertise state. In some way, it is still connected to the Android phone. I have to unpair the two, turn off Bluetooth in Android and then re-scan and reconnect. So it takes a while just to debug/test.

RE: HID over GATT on Android disconnects after 30 seconds

davman — Mon, 23 Jun 2014 21:06:21 GMT

Got the same issue, but with BlueZ on Linux (so same)

RE: HID over GATT on Android disconnects after 30 seconds

eric ely — Mon, 23 Jun 2014 18:19:03 GMT

Anyone have insight here? I have tried setting the connection parameters to various things based on a different post, but that didn't help. I am quite stuck here and cannot proceed. iOS still works fine. Android will always disconnect after some period of time, even though it works properly while connected.