BLE connection processing with nRF5340 Audio

I have a few questions about the sample source of nRF5340 Audio.

1. Where does the connection processing between the Gateway and Headset take place?

2. Where is the BLE bonding information set?

3. Is it possible to rewrite the bonding information?

Thank you in advance.

Parents
  • Hi

    1. Where does the connection processing between the Gateway and Headset take place?

    The handling of advertising occurs in bt_mgmt_adv.c, while the connection handling can be found in bt_mgmt.c. 

    2. Where is the BLE bonding information set?

    BLE bonding is handled by the Bluetooth host, similar to other (no audio) Bluetooth applications. 

    The exact storage of keys is handled by the bt_keys_store(..) function, which is called from smp.c here. The function itself is implemented in keys.c here, and uses the bt_settings module for the actual storage of data in flash. 

    3. Is it possible to rewrite the bonding information?

    Yes, this is possible. The bt_mgmt_bonding_clear() function in bt_mgmt.h/c allows you to delete the existing bonding data, in order to make room for new bonds. 

    Best regards
    Torbjørn

  • Is the connection process performed when bt_mgmt_init() is executed?

    Which function in bt_mgmt.c performs the connection process?

  • Hi

    Which particular part of the connection process are you referring to? 

    As a peripheral device you don't control when the connection process starts. Essentially what you do is to start some type of connectable advertising, and wait for a scanner nearby to send a connection request, which will start the connection process. Once the connection is established it will trigger the connected_cb(..) function in bt_mgmt.c, which controls what happens next.

    The low level handling of establishing and maintaining a connection is handled by the Bluetooth link layer directly, and as such is not visible in the application code. 

    Best regards
    Torbjørn

Reply
  • Hi

    Which particular part of the connection process are you referring to? 

    As a peripheral device you don't control when the connection process starts. Essentially what you do is to start some type of connectable advertising, and wait for a scanner nearby to send a connection request, which will start the connection process. Once the connection is established it will trigger the connected_cb(..) function in bt_mgmt.c, which controls what happens next.

    The low level handling of establishing and maintaining a connection is handled by the Bluetooth link layer directly, and as such is not visible in the application code. 

    Best regards
    Torbjørn

Children
  • Which part of the source is responsible for sending the connection request?

  • For nRF5340 Audio, where are the bonding values ​​assigned?

  • Hi

    Junichi said:
    Which part of the source is responsible for sending the connection request?

    Establishing connections in the central role is handled by the bt_mgmt_scan_for_conn.c module, which can be found in the src\bluetooth\bt_management\scanning\ folder. 

    The exact connection establishment is done by calling bt_conn_le_create(..), and if you search for it in the bt_mgmt_scan_for_conn.c file you can find it referenced in three other functions: device_name_check(), csip_found() and bond_connect()

    bond_connect() is called when you receive a directed advertising message, which means you want to connect to a previously bonded device (you should never receive directed advertising messages for non bonded devices). You will also call this function if you have used all the bond slots, since in this case you can not bond any new devices. 

    csip_found() is used if you want to connect to a device which is part of a coordinated set, as defined by the Coordinated Set Identification Service (CSIS). 

    For all other devices the device_name_check() function will be used to connect. 

    Best regards
    Torbjørn

  • Please tell me the following about running nRF5340 Audio with CIS.

    1. Am I correct in thinking that the Headset (Server) sends an advertisement, the Gateway (Client) scans the advertisement and connects?

    2. Where in the source is the key information for connecting with CIS set?

    3. If the device tree of the Headset and Gateway are different, can a connection be made even if only the Headset is built and flashed and only the Gateway is built and flashed using separate scripts?

    4. If I want to create several combinations of Gateway and Headset, how can I change the connection information so that it does not conflict with the others?

  • Hi 

    Junichi said:
    1. Am I correct in thinking that the Headset (Server) sends an advertisement, the Gateway (Client) scans the advertisement and connects?

    Correct.

    Junichi said:
    2. Where in the source is the key information for connecting with CIS set?

    What particular information are you referring to? 

    Junichi said:
    3. If the device tree of the Headset and Gateway are different, can a connection be made even if only the Headset is built and flashed and only the Gateway is built and flashed using separate scripts?

    This shouldn't matter. In the default example the scanner will look for a specific advertising name, and if it finds it the connection will be established. 

    Junichi said:
    4. If I want to create several combinations of Gateway and Headset, how can I change the connection information so that it does not conflict with the others?

    The easiest way to do this would be to change the advertising name on the peripheral side, and change the target name on the scanner side, to something unique. Then you can control which peripherals and scanners will connect, and which will not. 

    Best regards
    Torbjørn

Related