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

how to use HANDLE RANGE correctly for Multiconnection ?

good time dear Engineers!

Please explain how to use correctly HANDLE RANGE in functions of discovering. I use CENTRAL with up to 8 possible connections to PERIPH, so pls explain following:

sd_ble_gattc_primary_services_discover(conn_handle, start_handle, &uuid);

WHAT IS start_handle if 8 Active Connections co-exist ? why it is always 0x0001 ?

sd_ble_gattc_characteristics_discover(conn_handle, p_handle_range);

WHAT is p_handle_range if 8 ACTIVE CONNECTIONS ? for example, for 2 connections: if conn_handle1=0x0 and conn_handle2=0x1 ?

sd_ble_gattc_descriptors_discover(conn_handle, p_handle_range);

for different connections handles (0x0,0x1,etc..), must p_handle_range be different too ? e.g.

conn_handle1=0x00: p_handle_range  = {0x10,0x15}
conn_handle2=0x01: p_handle_range  = {0x20,0x25}

etc.. ?

How to Manage Handle Ranges in case of Disconnecting -> Connencting -> Discovering again , etc... correctly (in this cases old handles must be re-assigned again) ?

I have one SERVICE (1666) two CHAR's (d5aa, d780) in this service and 4 Descriptors in each CHAR.

I found SERVICE, CHARS and store it's HANDLEs in my database according to the Photo. Q: how to find all descriptors in each CHAR's ? What valid handle_range I should use as PARAMETER to sd_ble_gattc_descriptors_discover(...) ?

image description

if I use handle_range of [e.g. 0x09 - 0x0E] means from service start_ handle to last char handle_value , seems it's OK, all the Attribute founds success.

Parents
  • Hi Oleg,

    First, we need to clarify the conn_handle and the start_handle/p_handle_range they are completely unrelated.

    start_handle/p_handle_range has nothing to do with your number of peripheral connection.

    start_handle/p_handle_range is the handle ID in the attribute table. The attribute table is where the services, characteristics are located each of them has a handleID.

    The service discovery process (discovering primary services, characteristics) requires a handle ID range to work it. Basically it tell from where to where in the attribute table you are asking the server to reply what is the service and characteristic inside. You can have a look at section 4.4 and 4.6 at Vol 3 Part G in the Bluetooth Spec v4.2

    This handle ID is local for a specific server (usually on peripheral).

    Note that when you request for a service discovery from handle A to handle B, you may not receive all the primary services at once. The server may return with 1 or 2 services. You need to repeat discovery the service from the end handle of the last service to the last handle (handle B).

    I would strongly suggest to have a look at our database discovery library.

  • The handle_decl is the handle ID of the declaration, it should always is the first attribute of a characteristic. Come after that should be the value and descriptor(s) if any. This doesn't make much sense:

    connection[0].service[0].char[0].handle_value=0x000a; // to acces for read/write operations. connection[0].service[0].char[0].handle_decl =0x000b; // to acces for ??????? what ?

    handle_decl should be < handle_value

    In the figure you provided, the handle_decl and handle_value look more correctly.

    The descriptor is located after the value handle ID till the next characteristic/service, in other words, between the current handle_value and the next handle_decl.

    You can use nRF Master Control Panel to do a service discovery, you can have a clear view of how your attribute table looks like.

Reply
  • The handle_decl is the handle ID of the declaration, it should always is the first attribute of a characteristic. Come after that should be the value and descriptor(s) if any. This doesn't make much sense:

    connection[0].service[0].char[0].handle_value=0x000a; // to acces for read/write operations. connection[0].service[0].char[0].handle_decl =0x000b; // to acces for ??????? what ?

    handle_decl should be < handle_value

    In the figure you provided, the handle_decl and handle_value look more correctly.

    The descriptor is located after the value handle ID till the next characteristic/service, in other words, between the current handle_value and the next handle_decl.

    You can use nRF Master Control Panel to do a service discovery, you can have a clear view of how your attribute table looks like.

Children
No Data
Related