Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Zephyr BLE connection management

Hi,

I have a bluetooth central app which connects to several BLE peripherals and am now working on fixing various connection reliability issues.
White lists and bonding are bring used and I am forcing connection loss via use of faraday bags.

I have questions related to connection management.

1) Use of bt_conn_le_create() verses bt_conn_le_create_auto() ?

On my initial scan of peripherals, I make my initial connection to the peripheral using bt_conn_le_create(); security level is set to L2 and the device is added to the whitelist.
On disconnects I call bt_conn_le_create_auto() to listen for whitelisted devices so they can reconnect.

Is a better schema to just do the scans, and add my peripheral devices to the white list. Then use bt_conn_le_create_auto() to connect to the white listed devices. When any peripheral is disconnected (callback); then call bt_conn_le_create_auto() to listen for the peripheral reconnecting?

Also Is it only necessary to set the security level to L2 on that initial connection; or must this be done on seeing each reconnection?
A similar question with regards to service discovery; must I only do this on the inital make of connection; or must this be done on each reconnection?

2) Use of bt_conn_ref() and bt_conn_unref() ?

Should bt_conn_unref() only be used when I am no-longer interested in a connection. IE seeing a deliberate disconnection? or should this be done for every disconnection I see even these environmental ones; where I hope to see the device reconnect?

KInd Regards,
Owain



  • Hi, 

    There are some APIs that are documented as giving you a reference. And the application needs to unref this when they don't use it anymore like thisthis and this.

     *  The caller gets a new reference to the connection object which must be
     *  released with bt_conn_unref() once done using the object.

    Neither the connected-callback invocation nor the disconnected-callback invocation comes with an ownership transfer of a bt_conn reference. (When a API does, it has to be documented in the API doc.) Any call to bt_conn_unref in disconnected() presumably gets rid of ownership acquired earlier from some other source.
    OwainIncus said:
    See here attached a trace where bt_conn_unref() is called on disconnect(); this results in an assertion that related to refrence counters.

    Do you use bt_conn_ref or the function would increase the counter? If not, then it doesn't need to call bt_conn_unref. I would correct my previous answer. 

    -Amanda H.

Related