Peripheral disconnects from central S120 after BLE_GAP_EVT_CONN_PARAM_UPDATE

[Andrew]

I have set up a board using device_manager_central to connect with BTLE sensors. I have used a combination of the multilink example and the heart rate collector example along with my own code with the intention of being able to connect to multiple sensors at once.

Currently I can connect to the example heart rate monitor using a dev board but when trying to connect to an actual off the shelf heart rate monitor I keep getting disconnected after BLE_GAP_EVT_CONN_PARAM_UPDATE

With some debug in my code I get the following sequence output to my console:

PARAM_UPDATE_REQUEST
requested min_con = 800
requested max_con = 816
requested slave_lat = 0
requested sup_timeout = 600
ble event = 0x001d
PARAM_UPDATE_REQUEST
conn_param_update err code = 0
ble event = 0x0012
ble event = 0x0012
[DM]: Notifying application of event 0x12
Disconnect code 8
DM_EVT DISCONNECTION
ble event = 0x0011

the ble event 0x0012 is described as BLE_GAP_EVT_CONN_PARAM_UPDATE which should signify that the paramaters requested have indeed been updated however after the update I get a disconnect code 8 which is BLE_HCI_CONNECTION_TIMEOUT

Is there something I need to handle after the BLE_GAP_EVT_CONN_PARAM_UPDATE event that I'm just not seeing?

[Stefan Birnir Sverrisson]

Hi Andrew

To start with I want to point to this thread that explains a bit how the connection parameter negotiation procedure works

When you (as a central) get a connection parameter update request from the peripheral, you need to call sd_ble_gap_conn_param_update in order for the proper response to be sent to the peripheral. Are you doing that in your code? Then the response packet is sent to the peripheral and the connection parameter update packet is sent to the peripheral, see the S120 central message sequence chart and the S110 peripheral message sequence chart. On the other hand, if you do not call the sd_ble_gap_conn_param_update, the peripheral will not get the response packet and will probably re-transmit the connection parameter update request packet, as it assumes that the former packet was lost.

[Andrew]

I set up the packet sniffer to see how my connection parameter updates are different from the master control software on Android. From what I can tell, the problem seems to be the order of events.

Master control packets are in this order (This works):
 1. Slave -> Master : Parameter Update Request
 2. Master -> Slave : Control Opcode: LL_CONNECTION_UPDATE_REQ
 3. Slave -> Master : Empty PDU
 4. Master -> Slave : Rcvd Connection Parameter Update Response (Accepted)

My device manager central code is in this order (doesn't work):
 1. Slave -> Master : Parameter Update Request
 2. Master -> Slave : Rcvd Connection Parameter Update Response (Accepted)
 3. Master -> Slave : Control Opcode: LL_CONNECTION_UPDATE_REQ
 4. Slave -> Master : Empty PDU
 5. Master -> Slave : Control Opcode: LL_CONNECTION_UPDATE_REQ
 6. Slave -> Master : Empty PDU

All I'm using is the sd_ble_gap_conn_param_update()