Peripheral disconnects from central S120 after BLE_GAP_EVT_CONN_PARAM_UPDATE

Question

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 · Accepted Answer

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.