Why do I use this function bt_conn_le_param_update( ), only after the power on the first time to work, then do not work
Why do I use this function bt_conn_le_param_update( ), only after the power on the first time to work, then do not work
Hi,
There should not be any limitations on how often you can call bt_conn_le_param_update(), and updating the connection parameters several times during a connection is common. In what way does it not work?
Is there no requirement for the interval between the first call to bt_conn_le_param_update() and the second call?
Can I dynamically adjust CONFIG_BT_CONN_PARAM_UPDATE_TIMEOUT?
No. This is static. But note that this only delays connection parameter update after connection establishment. It doe snot delay subsequent connection parameter updates.
One other thing, is CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS enabled? If so, it will automatically appen after the configured delay after the connection is established.
Sorry for chiming in. Are you using LLPM your application? In other words, are you using a connection interval less than 7.5ms in the first connection update call? If so, keep in mind that LLPM is only supported on 2M PHY. See https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/llpm/README.html for more details
Thank you for your reply. LLPM was not enabled, and the connection interval was set at 30ms. I feel that the two calls to update connection parameters were too short, resulting in the failure of the first call
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS is not enabled because I need to manually update the connection parameters
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS is not enabled because I need to manually update the connection parameters
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS is enabled by default, so unless you have disabled it it it used (you should see it in the generated .config). That is not a problem though, but as you cannot have parallell procedures, this is just an example that you need to handle that it could happen (check the return value and handle it appropriately).
Both calls checked the return value, no error was returned, but only the second call can normally print the connection parameter change information, the first call does not seem to have been executed, but I am sure it has been executed, probably was rejected by the central, so I want to know whether the interval between the two calls is required
What I find interesting is that if I connect my phone to the peripheral immediately after the broadcast, the two calls work, but if I connect after a while, the first call doesn't work