This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Update connection parameter programmatically

Hi

I want to update the connection parameter and send this request from nrf51822 to a smartphone app. I see there is a function ble_conn_params_change_conn_params() for this. However, every time I call this function, nrf51822 disconnects the current connection and goes back to advertising mode. What are the guidelines to send a connection update message from nrf51822?

Parents
  • Hi

    Initially, the central will connect to the peripheral with connection paremters that the central decides what is. After the connection is established, the Peripheral can send connection parameter update request to the central and the central most likely responds with a connection parameter update. However, by Bluetooth spec, the central is not obligated to responde to the connection parameter update request, it may just ignore it. The received update from the central is not certain to be what the peripheral requested. If the peripheral can not accept the connection parameter update from the central it can choose to disconnect from the central.

    The three following connection parameters are sent to the central for negotiation:

    #define MIN_CONN_INTERVAL                    MSEC_TO_UNITS(500, UNIT_1_25_MS)           /**< Minimum acceptable connection interval (0.5 seconds). */
    #define MAX_CONN_INTERVAL                    MSEC_TO_UNITS(1000, UNIT_1_25_MS)          /**< Maximum acceptable connection interval (1 second). */
    #define SLAVE_LATENCY                        0                                          /**< Slave latency. */
    #define CONN_SUP_TIMEOUT                     MSEC_TO_UNITS(4000, UNIT_10_MS)            /**< Connection supervisory timeout (4 seconds). */
    

    The connection interval has minimum and maximum value so that the central will have some flexibility in deciding the connection interval.

    If the peripheral receives connection parameter update from the central which is unacceptable it can choose to send another connection parameter update request to the central in order to make the connecton parameter negotiation be successful. How many connection parameter update requests are sent is determined by the MAX_CONN_PARAMS_UPDATE_COUNT constant in i.e. the ble_app_hrs example in the SDK. The FIRST_CONN_PARAMS_UPDATE_DELAY determines how long time should pass from start of notification until sending the first connection parameter update request, and the NEXT_CONN_PARAMS_UPDATE_DELAY determines how long after the first request the following connection parameter update requests should be sent.

    In the ble_app_hrs the connection parameter update request is initiated by starting an application timer with id: m_sensor_contact_timer_id. The timer is initialized in conn_params_init() call in the main function and it is started in the connect hook it seems.

Reply
  • Hi

    Initially, the central will connect to the peripheral with connection paremters that the central decides what is. After the connection is established, the Peripheral can send connection parameter update request to the central and the central most likely responds with a connection parameter update. However, by Bluetooth spec, the central is not obligated to responde to the connection parameter update request, it may just ignore it. The received update from the central is not certain to be what the peripheral requested. If the peripheral can not accept the connection parameter update from the central it can choose to disconnect from the central.

    The three following connection parameters are sent to the central for negotiation:

    #define MIN_CONN_INTERVAL                    MSEC_TO_UNITS(500, UNIT_1_25_MS)           /**< Minimum acceptable connection interval (0.5 seconds). */
    #define MAX_CONN_INTERVAL                    MSEC_TO_UNITS(1000, UNIT_1_25_MS)          /**< Maximum acceptable connection interval (1 second). */
    #define SLAVE_LATENCY                        0                                          /**< Slave latency. */
    #define CONN_SUP_TIMEOUT                     MSEC_TO_UNITS(4000, UNIT_10_MS)            /**< Connection supervisory timeout (4 seconds). */
    

    The connection interval has minimum and maximum value so that the central will have some flexibility in deciding the connection interval.

    If the peripheral receives connection parameter update from the central which is unacceptable it can choose to send another connection parameter update request to the central in order to make the connecton parameter negotiation be successful. How many connection parameter update requests are sent is determined by the MAX_CONN_PARAMS_UPDATE_COUNT constant in i.e. the ble_app_hrs example in the SDK. The FIRST_CONN_PARAMS_UPDATE_DELAY determines how long time should pass from start of notification until sending the first connection parameter update request, and the NEXT_CONN_PARAMS_UPDATE_DELAY determines how long after the first request the following connection parameter update requests should be sent.

    In the ble_app_hrs the connection parameter update request is initiated by starting an application timer with id: m_sensor_contact_timer_id. The timer is initialized in conn_params_init() call in the main function and it is started in the connect hook it seems.

Children
  • Looking a the connection parameter update request procedure in the specification now, I see that I am wrong in my statement that you mention. It says clearly in Bluetooth Core Specification v4.2, Volume 6, Part B, section 5.1.7.2, page 2646:

    Upon receiving an LL_CONNECTION_PARAM_REQ PDU the The master shall respond with either an LL_CONNECTION_UPDATE_REQ PDU or an LL_REJECT_IND_EXT PDU.
    

    In other words, it seems that the master is obligated to respond to the connection parameter update request (LL_CONNECTION_PARAM_REQ)

Related