bluetooth connection parameters help

[jon]

I am working with nRFx modules and have a few questions about updating parameters. I started my project with an example and modified what I needed. However, I am not sure if the parameters are getting set when I change them. Currently I go into main.c and change the following parameters:

#define MIN_CONN_INTERVAL                          MSEC_TO_UNITS(20, UNIT_1_25_MS)           
#define MAX_CONN_INTERVAL                         MSEC_TO_UNITS(75, UNIT_1_25_MS)           
#define SLAVE_LATENCY                                  0                                         
#define CONN_SUP_TIMEOUT               
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000, APP_TIMER_PRESCALER)  
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER) 
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                
#define TX_POWER_LEVEL                                4      

If I change these parameters, specifically the first three (connection interval, slave latency, and connection supervision timeout), will they automatically be set on with the central? I am currently connecting to a windows 10 device and trying to figure out if the parameters are being updated and if not, why? How would I check to see if they are getting updated?

[AndrzejB]

1. If you want to check parameters, that are currently used in the connection, check m_current_conn_params defined in ble_conn_params.c.
2. Parameters that you pick on the peripheral side are just preferable by peripheral, but the final decision is on central side. If central will not agree with parameters proposed by peripheral these parameters will be ignored
3. FIRST_CONN_PARAMS_UPDATE_DELAY and NEXT_CONN_PARAMS_UPDATE_DELAY determine when the Connection Parameter Update Requests will be performed. So, you rather should take care of this two parameters.

[jon]

This was a very helpful response, thanks! I am going to work on getting the m_current_conn_params sent across a uart to make this quick and easy to play with.

In regards to FIRST_CONN_PARAMS_UPDATE_DELAY and NEXT_CONN_PARAMS_UPDATE_DELAY, it seems if a timer will start if the preferred connection parameters are not the same as m_current_conn_params. First_conn_params_upate_delay will be the time at which the first update request is made, provided that the timer has been started due to unliked parameters. Next_conn_params_update_delay seems to be a recurring timer, if parameters are still not liked after the first update request, that the nrf again will ask for an update. Does this sound about right?